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 Mon, 22 Nov 2004 11:42:29 GMT
El lun, 22-11-2004 a las 09:56, Nicola Ken Barozzi escribió:
<snip part="something it seems we agree on"/>
> ...
> > Nevertheless you can group this atomic parts as well within an grouping
> > template. 
> > <forrest:template name="sports" output-format="xhtml">
> > <forrest:hook name="sports">
> >   <forrest:fbit name="search-input" type="sports"/>
> >   <forrest:nugget name="sportNews"/>
> > </forrest:hook>
> > </forrest:template>
> > 
> > This can be different for another output-format.
> > <forrest:template name="sports" output-format="fo">
> > <forrest:hook name="sports">
> >   <forrest:nugget name="sportNewsAbstract"/>
> > </forrest:hook>
> > </forrest:template>
> IMV these are defined in what I have called "theme", that is pure view 
> without inserting the functionality that instead has been inserted in 
> the skin phase.

what means IMV I could not find it ;-)

Yes and no, I see themes as the styling state of the the view (last
stage->here I totally agree) because theming will add as well the style
for the functionality to the skin (I will now only use the word view for
skin, because I have a different definition of skin I guess).

I see themes like the css-files for a view. A view will return a certain
skelleton. Each theme of the view will use this skelleton and just alter
the css for the theme.

I cannot remember where I read the following example but it goes a wee
bit like this. If you you use css then you do not have to alter the
skelleton of your html page because you will just alter the css. Lets
say you want add a Xmas theme for pelt. Then you will take the css and
change it to the Xmas style info. e.g. you may add a logo that contains
a snowman,...

Theming is pure css-styling (coloring, ...). Themes will work only for
certain views (because they are producing a certain html-skelleton where
the theme is based on). I hoped that scale-dev would be the leather-dev
default theme but due to the fact that the leather view produces a
skelleton that is free from graphical hooks it is pretty hard.   

Saying this I now will define what skins, views and themes do:
*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

When we use leather DOM as internal skin, this is going to the core and
is producing all aviable nuggets and fbits as placeholder.

Then we will just add a default view and theme to leather. That means
leather will just contain:
-leather.ft (default view)
-leather.css (default theme)

If we will aim to support only *one* skin (leather) and thing of views
as former skins all upcoming new skins (=views, if leather is one and
only) will have to contain those information, which are easily
extensible for new features in the future.

BTW IMO we should rename skin to views in the future. So we are talking
about leather-, corium-,... views (). 

> > This templates then can be easily overridden and adjust by designer. The
> > idea is that the designer can add his own implementation of the
> > contracts.
> There are two things I want to have your opinion about, and how to 
> insert them in the above scenario:
> 1 - Users should be able to add nuggest without changing skin or theme.
>      For example, adding an extra newsfeed on the right hand side.

The user do not have to change the skin (see above) but have to extend
the default forrest:view provided by e.g. leather. 

This based on the need that the user (designer) wants to place the new
nugget on certain position. For the sake of design he may introduce a
new forrest:hook and the newsfeed forrest:nugget to his main view.

I. default view:

<forrest:view output-format="xhtml, fo" name="default">
  <forrest:hook name="intro">
   <forrest:nugget name="grouplogo"/>

II. a. add atomic parts to default view

<forrest:view output-format="xhtml, fo" name="default">
  <forrest:hook name="intro">
   <forrest:nugget name="grouplogo"/>
  <forrest:hook name="newsfeedHook">
    <forrest:nugget name="newsfeed"/>

II. b. add forrest:template and use it with <forrest:call-template/>
<forrest:template name="newsfeed" output-format="html, fo">
<forrest:hook name="newsfeedHook">
  <forrest:nugget name="newsfeed"/>

<forrest:view output-format="xhtml, fo" name="default">
  <forrest:hook name="intro">
   <forrest:nugget name="grouplogo"/>
  <forrest:call-template name="newsfeed"/>

III. create a new view and link the page that is using it in site.xml
with <index label="Index" href="index.html" view="pagesWithNewsfeed"
Note: this snippet contains @theme.

<forrest:view output-format="xhtml, fo" name="pagesWithNewsfeed">
  <forrest:hook name="intro">
   <forrest:nugget name="grouplogo"/>
  <forrest:call-template name="newsfeed"/>

Then the nugget has to be registered in the contract list and can be
used on the whole site or just in certain parts of the site.

That leads us to the suggestion to adopt the ressources dir of plugins
for a forrest project. In this dir we should add a new dir "views" where
the default view for the used skin goes and the extended customized
projects views.

> 2 - Content filtering. Let's say I want to colorize java code...

Can you extend?


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

View raw message