forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [Discuss] Templating language - forrest:templates and Struts Tiles
Date Tue, 23 Nov 2004 11:25:02 GMT
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ó:
> ...
> >>Cool!
> > 
> > :) 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 
> filtering.

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. Besides this corium will
add the view/theme information in site.xml. 

> 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*. I mean we make an internal markup that
produces *all* nuggets and *all* fbits contracts as placeholder. This
will be done with leather contracts. That means we will not support any
other skin then leather but we will *create* *views* from our current
ones (tigris and pelt).

The *view* can then decide to use the placeholder, add new ones and add
graphical placeholder. The view is creating the html-skelleton that is
used for *theming*. Themes are view dependend but e.g. you can write
*one* theme for *x* view derivatives.

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


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
*themes* add the final design implementation for the view in form of

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


"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message