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

[Rens Admiraal]

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.
>
>