[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