David Geary wrote:
> Cedric's got some good ideas here, and I agree with someone else who said he should
>be
> a committer.
>
See proposal on STRUTS-DEV.
>
> Craig?
>
> david
>
Craig
>
> Cedric Dumoulin wrote:
>
> > 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/
