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

Bastian Waidelich bastian at typo3.org
Thu Apr 25 15:42:32 CEST 2013


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.


-- 
Bastian Waidelich
--
Core Developer Team

TYPO3 .... inspiring people to share!
Get involved: typo3.org


More information about the TYPO3-team-core-v5 mailing list