[TYPO3-team-core-v5] GSOC: Neos SiteKickstarter & FluidBuilder

[Jacob Floyd]

Awesome feedback. Keep it coming!

I like the idea of SOA around the templating tool so that the backend can
do everything without requiring JS interaction. As for the frontend, of
course I would use emberjs... I want to reuse everything I possibly can
that you guys have already done. :) Neos uses emberjs, so, that's the
obvious choice for me.


On Thu, Apr 25, 2013 at 9:20 AM, Rens Admiraal <rens.admiraal at typo3.org>wrote:

> And just another penny: it might be cool to use emberjs... :)
>
>
> Op 4/25/13 15:42 , Bastian Waidelich schreef:
>
>  Jacob Floyd wrote:
>>
>> Hi Jacob,
>>
>>  [...] I was thinking of maybe working on a fluid template
>>> builder [...]
>>>
>>
>>
>> As discussed yesterday in the hangout already: I'm really really looking
>> forward to using a templavoila-like tool for Fluid templates that allows me
>> to drag & drop widgets (ViewHelpers, ContentElements, ...) on to a raw HTML
>> file, get a preview and "export" Fluid templates.
>> We always had something like this in the back of our heads when we worked
>> on Fluid..
>>
>>
>>  What do you want to see happen with the SiteKickstarter and some kind of
>>> Template/Fluid Builder?
>>>
>>
>>
>> I'm not very much into JavaScript-driven applications and I didn't have
>> the time to dare such project. But if I did, I would probably start it like
>> this:
>>
>> * create wireframes or even layouts (if possible with the help of a
>> designer) to get a clear vision of the feature set & UX
>>
>> * define the "building blocks" – e.g. The FluidBuilder probably always
>> works with Fluid templates, but the concept of "widgets" could be
>> extensible (starting with widget = ViewHelper + configuration but allowing
>> it to be ContentElement + configuration in the future for Neos templates)
>>
>> * completely separate the Frontend part from the Backend where the BE
>> does all the heavy lifting and has a simple API the FE part "talks" to
>>
>> I (maybe naively) expect the BE API to work along the lines of:
>>
>> wrapElement($domElement, $widgetIdentifier, $widgetConfiguration =
>> array())
>>
>> where..
>>
>> $domElement is some identification of the location where the widget
>> should be placed in the source HTML (maybe an XPATH expression?)
>>
>> $widgetIdentifier is a unique string for each widget (in the simplest
>> case just the ViewHelper classname?)
>>
>> $widgetConfiguration is an array of settings to be applied to the widget
>> instance (e.g. ViewHelper arguments for the VH case)
>>
>>
>> Technically the BE should store these information separately from the
>> actual HTML template so that the source can still be modified to some
>> extend. A service should be able to take a source string + the previously
>> stored widget positions & configurations and create a Fluid template from
>> it. With a caching layer in place this could even drive your application
>> directly..
>>
>> Well, this was just a brain dump and it certainly contains some pitfalls
>> but maybe it contains some inspiration for you.. Please don't understand
>> this as "the way to go" or even a wish-list! But feel free to get in touch
>> if you want to discuss your ideas. I just talked to Sebastian and he would
>> like to be involved as well.
>>
>>
>>  PS I've been absent from the TYPO3 world for the past few months because
>>> I got married and then started a semester of school. :)
>>>
>>
>> Congratulations and welcome back! :)
>>
>>
>> BTW: Sebastian had once created a nice little Firebug extension that
>> showed the Fluid source including generated documentation and highlighting
>> of the currently selected ViewHelper in the browser.
>>
>>
>>
> ______________________________**_________________
> TYPO3-team-core-v5 mailing list
> TYPO3-team-core-v5 at lists.**typo3.org <TYPO3-team-core-v5 at lists.typo3.org>
> http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-**team-core-v5<http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-team-core-v5>
>