forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [Discuss] Templating language - forrest:templates and Struts Tiles
Date Tue, 23 Nov 2004 14:03:11 GMT
Thorsten Scherler wrote:
> El mar, 23-11-2004 a las 10:09, Nicola Ken Barozzi escribió:
>>Thorsten Scherler wrote:
>>>El lun, 22-11-2004 a las 20:05, Ross Gardler escribió:
>>>:) cheers ;-)
>>It still seems too complicated for the user... The normal user would 
>>want to simply say "add this newsfeed" and get done with it. Same for 
> That is what corium will be all about. ;-)
> Corium can only be run in webapp mod because the user can change the
> look & feel of his/her project via forms. Corium is a view editor. 
> -> Press a button /add new element/ 
> -> define the source dir/file or contract
> = New nugget is in the view
> In corium the usages of f:t is internal. The forms will produce f:t
> snippet that will be inserted in the view dir. 

Adding a tool on top of something difficult still keeps the thing 
difficult ;-)

Seriously, it *must* be easy to use also by hand.

This can be done if we insert the concept of "groups", where many 
nuggets can reside in the same view "group".

> Besides this corium will add the view/theme information in site.xml. 

Wait a sec, this has to be decided still.

>>IMHO the templating language must be used only by the skin/theme/view 
>>(gosh, so many! ;-) designer, and not by the user.
> I agree that we now have to many (skin/view/theme) and that f:t are
> aimed on designer and advanced user but like I said we will use this
> work in corium again. ;-)
>>(BTW, I think I agree with your distinction between skin, view and 
>>theme, I just have to digest it a bit more to make it mine)
> IMO we should drop *skins*.

Yes, I agree.

>>I think we have come to an initial possible architecture. Thorsten, do 
>>you have time to edit the forrest 0.1 document to insert these things?
> docs-author/content/xdocs/TR/2004/WD-forrest10.html 
> you mean?


> I am unsure about the skins.
> *skin* produces placeholder for nuggets/fbits skelleton.
> *views* can use certain placeholder and add design information to the
> skin.
> *themes* add the final design implementation for the view in form of
> css-files.

Yes. That's why I want you to edit it :-)

> IMO we should just provide all placeholder for registered nuggets/fbits
> by default as input in the *filtering stage*. The filtering state will
> then only filter the markup of the nuggets/fbits that are needed in the
> view in comparing it with the *.ft.
> I mean we do not have to generate content that is not needed. That means
> we create here a subset of all contracts and produce their markup.
> Step 4 should be called "Viewing" and add a link to the f:t docs.
> Besides that I would like to change the appearances of skin to view. 
> We agreed that nuggets are as well view dependant. 
> We still need the new format for the skinconf. 
> I as well suggest that we change that to viewconf.xml. Here the *user*
> (and not so much the designer) can alter the view without altering f:t.
> In viewconf the information about the theming (<color>,...) should go as
> well.

Wait a sec, one thing at a time :-)

IMHO first we need to agree on the main phases, then we can show how a 
document evolves in the stages, then we can start discussing how the 
config files look like. Let's nail this part first.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message