[TYPO3-mvc] f:form.dateselect ? (fluid)

Franz Koch typo3.RemoveForMessage at elements-net.de
Tue Jan 5 15:08:49 CET 2010


>> these are exactly the reasons (apart from no time ;) ) why this has not
>> been done yet.
>
> Maybe it makes sense to provide within FLUID a set of view helpers for ExtJS as it is shipped with
> the Core (and there is infrastructure for loading it), but create additional extensions/packages for
> other frameworks.

I wonder for what I would need a FLUID viewhelper for JS stuff. Isn't it 
so, that the trend is to move all js at the end of the body tag in a 
external file and thus only provide some special markup (IDs, classes) 
in your HTML that your JS-methods are aware of?

At least I'm working that way now, that f.e. I only assign the class 
'slideshow' to a "ul"-tag and the script is automatically transforming 
this ul into a slideshow. I do the same with JS form validation - simply 
by adding a "f-required" or "f-eval-date" class to the fields. Same for 
lightbox-stuff - all you need is a rel-attribute etc.

So for the most common stuff you might not need a dedicated viewHelper 
dealing with JS-stuff - all you need is a viewHelper providing common 
markup that you as developer can transform with any JS-framework you like.

Ok, it would be nice if FLUID could also trigger the integration of 
certain JS snippets to a autogenerated merged JS file, but that's not 
necessary in the first step I think, if ever. If FLUID would provide 
common HTML-markup for use in JS, addon-extensions/libraries for various 
JS-frameworks might arise in TER which could hook in the FLUID 
viewHelpers and trigger themselfs the necessary JS integration for their 
particular framework. Might that be a solution?

-- 
kind regards,
Franz Koch

---------------------------------------------------
PayPal-Account: 'paypal _at_ elements-net _dot_ de'
---------------------------------------------------


More information about the TYPO3-project-typo3v4mvc mailing list