Hi David, and everybody,

  I understand David's position, there is a proverb which said "who go slowly go
surely" ;-)
  But, please, don't forget that I have already work for a long time on Components
proposal. A lot of peoples have tried them, and give positive feedback, as well as
improvement, on proposed features. Also, people hesitate to use Components in long
term because they are not sure that Components will be maintained if they are not
part of a large project.
I think that everyone could take advantages if we join our efforts to propose a
strong "Extended Templates Proposal", rather than to propose two tools providing
nearly the same.

  Saying that, here are some ideas for Template Screens Proposal :
  I think that we can reuse actual Templates syntax, rather than introducing too
much new tags or using scriptlet. This will simplify learning and comprehension of
Templates.

  Following is an example of how we could define a screen inside a jsp :
--------------
<template:screenDefinition id='introductionScreen' scope='request'
template='/chapterTemplate.jsp' >
  <template:put name='title' content='Templates' direct='true'/>
  <template:put name='header' content='/header.html' />
  <template:put name='sidebar' content='/sidebar.jsp' />
  <template:put name='content' content='/introduction.html'/>
  <template:put name='footer' content='/footer.html' />
</template:screenDefinition>
---------------

To use it :
  <template:insert definition='introductionScreen' />

---------------
Or, if you want to overload one attribute :
  <template:insert template='/anotherchapterTemplate.jsp'
definition='introductionScreen' />

---------------
Or,  if you want to overload or add others attributes :
  <template:insert  definition='introductionScreen' >
    <put name='title' content='Another Title' />
    <put name='leftSidebar' content='/leftsidebar.jsp' />
  </template:insert>'

---------------
 Some comments :

   * In the "screenDefinition", you can define all or only some of the attributes.
     So, you can drop "template='/chapterTemplate.jsp' "
   * If you specify some attributes in 'insert' tag, they overload previously
     defined attributes, or add new one.
   * This syntax is implementation independent : object produced by tag handler
     'template:screenDefinition' could be a Map, or a complex structure.
   * There is no 'role' attribute in the example, but we can use it.
   * Advantage of this syntax is that it is the same than 'insert'. This syntax can
     also be used in a xml description file, without introducing new concepts.
   * Another advantage, is that there is no scriplet inside JSP page.

Now, we need to find a way to define 'screenDefinition' outside a JSP page (ex: in
action).
A Map could be a candidate. But putting 'content', 'content-type' (direct) and
'role' inside Map's value is not so easy to use.
We could thing of a class ScreenDefinition, having some method reflecting the tag
syntax :
  setTemplate( String templateName )
  put( String name, Object content );
  put( String name, Object content, boolean direct );
  put( String name, Object content, boolean direct, String role );
     ...
  Such class could be easiest to use in code. Once an instance is created, it is
put in servlet context (request, session, ...).
Then, object is used in the same way as if it is define in the JSP page :
  <template:insert definition='screenDefinitionName' />

However, it is possible to implement <insert definition="aDefinition" /> in order
to accept a Map as well as a ScreenDefinition, if we want to keep both
possibilities.

   Last, I thing that tag name 'template:screenDefinition' is too restrictive : we
could effectively define a screen , but we can do much more with it, like defining
a 'Component' ;-) . So maybe we need to propose something else for this tag name
(first ideas : 'template:definition', or 'template:instance' ).

    Cedric


David Geary wrote:

> I see template screens as a first step towards Cedric's Components. Template
> screens provide the foundation necessary for Components: Programmatically
> defining screens.
>
> The next step is adding support for defining screens from an XML file, whether
> that's struts-config.xml or a separate file. Then we can add inheritance and
> locale support.
>
> I want to build this iteratively, with a design that reflects Struts design
> patterns (such as screen definitions that are analagous to the Map bean in the
> Link tag)*, rather than adopting Cedric's code wholesale.
>
> I'm more than willing to have Cedric or others pitch in some code.
>
> david
>
> * The Struts map-bean-property-to-request-parameter design pattern.
>
> Cedric Dumoulin wrote:
>
> >   A kind of  "screen configuration" (called instances) is proposed in
> > Components project, which can be seen as an extension of Templates.
> >   Screens are defined in a configuration file. You can also have different
> > configuration files for different Locale : appropriate screens will be loaded
> > according to user Locale.
> >   There is also an "inheritance"  mechanism allowing a screen to extend
> > another screen : you define your main screen, and derived other screens from
> > it, only changing what is relevant.
> >   To no more about Components :
> >     (main site) http://www.lifl.fr/~dumoulin/components/
> >    (mirror)      http://www.geocities.com/cedricdumoulin//components
> >
> >   I am currently rewriting part of the code to allows easy addition of other
> > "configuration file reader". Like this, it will be possible to load instances
> > from, for example, a database. This will also allows dynamic change of
> > instances. Code rewriting will not affect actual  tags syntax.
> >
> >    Cedric
> >
> > Maya Muchnik wrote:
> >
> > > Hi,
> > > I think the screen configuration through a xml-file is made in Components
> > > project (see for example,
> > > componentInstances.xml file). It is very convenient. As you maybe know,
> > > the project extends ActionServlet class.
> > > Maya
> > >
> > > David Geary wrote:
> > >
> > > > Yes, that's a good idea, applicable for static screens.
> > > >
> > > > We should still allow for programmatic definitions, though. Servlets or
> > > > servlet filters are good candidates for creating dynamic screen
> > > > definitions.
> > > >
> > > > david
> > > >
> > > > Wong Kok Wai wrote:
> > > >
> > > > > Is it possible to define the screen definition in the
> > > > > struts-config.xml? I think this will be more flexible.
> > > > >
> > > > > __________________________________________________
> > > > > Do You Yahoo!?
> > > > > Get email at your own domain with Yahoo! Mail.
> > > > > http://personal.mail.yahoo.com/

Reply via email to