forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject [Discuss] Templating language - forrest:templates and Struts Tiles
Date Sun, 21 Nov 2004 22:29:41 GMT
Hello devs,
El vie, 19-11-2004 a las 09:54, Nicola Ken Barozzi escribió: 
> > That is as well filtering. The ft-approch filters fbits and can
> filter
> > nuggets.
> > <forrest-template>
> >     <fbit name="branding-trail-path"/>
> >     <hook name="intro">
> >       <fbit name="grouplogo"/>
> >       <fbit name="projectlogo"/>
> >       <fbit name="search-input" type="sport"/>
> >       <nugget name="sportNews"/>
> >     </hook>
> > </forrest-template>
> 
> No, here you are mixing content and view...
> 

:) 100% right. Content is part of the view.

El vie, 19-11-2004 a las 01:18, Ross Gardler escribió:
> The above forrest-template mixes content (the nuggest) with 
> functionality (the fbit). Content should be dealt with prior to this 
> stage, in the filtering stage as you suggest. However, the fbits are 
> part of the skinning process since they do not generate content on some 
> form of interface (skin) to functionality.
> 
> Please remind me, exactly what is the forrest-template used for?
> 
> (although I have never been comfortable with saying the logos are fbits, 
> they have content, I believe they are therefore nuggets.)

I *know* that we are here mixing content and view; content and
functionality. BTW I as well think that the logos are nuggets. 

El vie, 19-11-2004 a las 01:18, Ross Gardler escribió: 
>  >>Multiple formats can be asked for the same source: the filename
> asked
>  >> will be in the following manner.
>  >>
>  >>    name.type.format
>  >>
>  >> IOW:
>  >>
>  >>    myfile.content.html
>  >>    myfile.javadocs.html
>  >>    myfile.html
>  >>
>  >
>  > Is this like views?
> 
> I'm not making the connection, can you expand?

Definition - Forrest-View:
View = content (nuggets) + functionality (fbit) + design (style)

I will refer to incoming content as nuggets. Nuggets are pure content
(without any information about fct., style,...). I mean the actual
document is as well "just" another nugget (pure content). 

fbits can (but do not have to) use nuggets to implemend (or populate)
the actual functionality needed in the requested view. 

There are 3 fbit types (the longer I thing about those I believe that a
fbit always contains nuggets in one form or the other):

1) fbit containing nuggets (I mean it contains e.g. captions ->i18n
nuggets)
<forrest:fbit name="fontsize"/>

2) pure fbit (no content just functionality -> IMO very rare, the
example tag would as well contain i18n: close-schliessen-cerrar) 
<forrest:fbit name="close-window"/>

3) pure fbit *using* nuggets (e.g. profiling data for the actual view.)
<forrest:fbit name="searchbox" type="sport"/>

Normally the nuggets and fbits will be implemented in an overall design.
The design is a container concept of storing fbits and nuggets in
graphical container (template + hooks). Templates can be outputed in
different media (xhtml, fo,...) to create the overall design in
different media of the document. 

This design state should only use registered contracts for fbits and
nuggets but still have absolute controll over the style. See the last
scale-dev discussion. I learned that the original idea of leather will
not work like I first implemended it. It gives me now a good starting
point but IMO we have to give the designer the controll over our output
by defining a new templating language.

El vie, 19-11-2004 a las 09:54, Nicola Ken Barozzi escribió: 
> >>Note that fbits are skin dependant, so that a skin can decide to 
> >>implement them or not. 
> > 
> > So are nuggets. 
> 
> No, nuggets are not skin dependant. We could argue that fbits are not 
> skin dependant either but *format* dependent, but it will get too 
> confusing ;-)

The *existenz* of nuggets and fbits is indeed skin independent. Both
nuggets and fbits are *format* (or better view) dependant which makes
them skin (=view!) dependend. The skin will for different formats use
different nuggets and fbits.

A view (skin) for a mobile device will filter different content because
it will display different content from the site. e.g. our pdf do not
need the navigtion and filters it out. 

Maybe it is time to explain forrest:templates in detail by comparing it
with tiles from Struts. 

Struts is an implementation of the model-view-controller (MVC) concept.
The controller knows for all incoming repuests, which model he has to
process and which view to return. Models produces data and the view
displays them.

http://struts.apache.org/userGuide/dev_tiles.html
"Tiles builds on the "include" feature provided by the JavaServer Pages
specification to provide a full-featured, robust framework for
assembling presentation pages from component parts. Each part ("Tile")
can be reused as often as needed throughout your application. This
reduces the amount of markup that needs to be maintained and makes it
easier to change the look and feel of a website."

cp.
http://www.oracle.com/technology/oramag/oracle/04-may/o34dev_struts.html
<%@ taglib 
uri="/technology/WEB-INF/tlds/struts-tiles.tld" 
prefix="tiles" %>
<html>
<head>
  <title>
    <tiles:getAsString name="title"/>
  </title>
</head>

<body>
  <tiles:insert attribute="header"/>
  <tiles:insert attribute="body"/>
  <tiles:insert attribute="menu"/>
  <tiles:insert attribute="footer"/>
</body>
</html>
What happends here is quite simple but very powerful. Certain
placeholder have been defined where the actual content (or
functionality) will be inserted. 

This template can be used for every page but you can add as many
templates as you need.

On the other hand you have a controller config file: tiles-defs.xml.
Here you will define which views will use this template and which
content (in terms of header.jsp or another layout definition) should be
inserted in the view.

    <!-- sample tiles definitions
    <definition name=".mainLayout"
path="/common/layouts/classicLayout.jsp">
        <put name="title"  value="Sample Page Title" />
        <put name="header" value="/common/header.jsp" />
        <put name="menu"   value=".mainMenu" />
        <put name="footer" value="/common/footer.jsp" />
        <put name="body"   value=".portal.body" />
    </definition>

That is actually a real nice approach and a lot of tiles ideas will be
found in forrest:templates. 

I see that tiles is focused on jsp and html. I would like it more
abstract so I can reuse it easier for different ouput and input format.

The following examples should demonstrate that the forrest:template are
aimed to be atomic parts. 
<forrest:fbit name="search-input" type="sports"/>

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>

You can as well define the atomic parts in view templates directly
without grouping.
<forrest:view output-format="xhtml, fo" name="intro">
  <forrest:hook name="intro">
   <forrest:nugget name="grouplogo"/>
   <forrest:fbit name="search-input" type="sport"/>
   <forrest:nugget name="sportNews"/>
  </forrest:hook>
</forrest:view>

You can as well mix atomic parts with grouping templates.
<forrest:view output-format="xhtml, fo" name="intro">
  <forrest:hook name="intro">
   <forrest:nugget name="grouplogo"/>
   <forrest:call-template name="sports"/>
  </forrest:hook>
</forrest:view>

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.

I really like the site:someNode approach because it lets controll all
links of the webapp by editing site.xml. I can tell from experience that
the tiles-def.xml is not really efficient to manage. Tiles is coming
with struts that uses a controler config file struts-config.xml to
controll the webapp. 

site.xml and struts-config.xml have some similarities, they are both
controlling the flow of the webapp. When implementing a new view in
struts/tiles you have to register the action in struts-config.xml and
the view in tiles-def.xml.

We can use a new attribute in site.xml that will tell forrest with which
view the site should be rendered.
<index label="Index" href="index.html" view="intro"/>

All what I just said is still in an early developing state. I hope that
I could explain the basic concepts that I would like to know what you
think about our new templating language.

WDYT?  
-- 
thorsten

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


Mime
View raw message