You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by David Geary <sa...@tri-lakesonline.net> on 2001/02/28 08:45:30 UTC
PROPOSAL: Template Screens
Joel Regen wrote:
> David,
> Wouldn't it make sense to introduce a few attributes to the template tags
> that allow specification of values using references to beans? This idea is
> used extensively in the other struts tags. Look at the html:link tag, for
> example. It allows you to specify a bean that contains a property that can
> be used as the value for a named request parameter. This kind of
> parameterization is fairly powerful.
Indeed.
> With these attributes in place you can leverage the use of the controller
> actions (in an MVC architecture) to setup one or more 'template specifiers'
> in session or request context and redirect to the JSP that contains the
> template tags. It alleviates the need for extensive use of logic: tags.
> yes?
Absolutely. Thanks to Joel for pointing this out! I found his email so
inspiring that I took a crack at this in my local build. Here's how it works:
Currently, you use templates like this: (this is from the struts-template
example)
<%@ taglib uri='/WEB-INF/tlds/struts-template.tld' prefix='template' %>
<template:insert 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:insert>
Collectively, template:put tags within a template:insert tag define a screen,
which is equivalent to a single Web page. Each screen contains regions; for
example, there are five regions in the code fragment above: title, header,
sidebar, content, and footer. Those regions, identified by the name attribute,
either include content or print it directly, depending upon the direct
attribute.
The template:put tag stores its three attributes--name, content, and direct--in
an instance of ScreenDefinition. That class is a simple façade for a hash
table. (See org.apache.struts.taglib.template.util.ScreenDefinition).
I've added a new template tag** that lets you specify that screen definition
directly. Here's how you use it:
<%@ page import='org.apache.struts.taglib.template.util.Content' %>
<%@ page import='org.apache.struts.taglib.template.util.ScreenDefinition' %>
<% ScreenDefinition screenDefinition = new ScreenDefinition();
screenDefinition.put("title", new Content("Struts Templates Example",
"true"));
screenDefinition.put("header", new Content("/header.html", "false"));
screenDefinition.put("sidebar", new Content("/sidebar.jsp", "false"));
screenDefinition.put("content", new Content("/introduction.html",
"false"));
screenDefinition.put("footer", new Content("/footer.html", "false"));
%>
<template:screen template='/chapterTemplate.jsp'
screen='<%= introductionScreen %>'/>
The template:screen tag effectively lets you move the template:put tags into a
bean (a ScreenDefinition). But creating that bean is too painful because the
author must know about the Content and ScreenDefinition classes (I can hardly
remember where they are or what they're called). We can fix the problem with
another tag that creates a screen definition, like this:
<template:screenDefinition id='introductionScreen' scope='request'
regions='<%= new String[] {
"title", "header", "sidebar", "content", "footer" } %>'
content='<%= new String[][] {
{ "Struts Template Example", "true" }, // title
{ "/header.html", "false" }, // header
{ "/sidebar.jsp", "false" }, // sidebar
{ "/introduction.html", "false" }, // content
{ "/footer.html", "false" } // footer
}%>'
/>
The template:screenDefinition tag creates a screen definition and stores it in
the specified scope, with the specified id. For the code listed above, that
screen definition is named introductionScreen and it's placed in request scope.
You can specify any of the four scopes (page/request/session/application).
With the screenDefinition tag, the author only deals with String arrays,
instead of Content and ScreenDefinitions.
Templates are powerful because they centralize page layout, which simplifies
page maintenance, and allows global changes. The tags proposed here let you
define numerous screen definitions in a single JSP file, which centralizes your
screen definitions.
Like templates themselves, which simplify page layout and enable global layout
changes, screens simplify screen creation and maintenance, and allow global
screen changes.
david
* The ContentMap class has been renamed to ScreenDefinition.
** I wanted to take Joel's advice and add some attributes to the existing
template:insert tag, but this new tag doesn't have a body, so they must be
separate tags.
>
> Joel
>
> -----Original Message-----
> From: David Geary [mailto:sabreware@tri-lakesonline.net]
> Sent: Wednesday, February 21, 2001 2:52 PM
> To: Joel Regen
> Subject: Re: switchable layout
>
> Joel Regen wrote:
>
> > David,
> >
> > you wrote:
> > ...
> > > chapter = content.substring(0,content.lastIndexOf("/"));
> > ******* Do you mean ...lastIndexOf("."));... here ^^^^?
> > I'm a bit confused here ;-)
>
> No, it's "/". That line of code is parsing a request parameter that
> indicates
> the content's directory. So, for the following URI ...
>
> book.jsp?content=/chapters/templates/introduction.html
>
> ... the chapter variable would be /chapters/templates. That variable's
> used
> to include other content, such as a footer, like this:
>
> <template:put name='footer'
> content='<%= chapter + "/footer.html" %>' />
>
> In that case, the footer content would be
> /chapters/templates/footer.html.
>
> david
Re: Problem using form tags across template pages
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Martin Cooper wrote:
> OK, now I see what's happening. The <html:form> tag sets the form bean as a
> page attribute, so when your nested page (the one brought in using the
> template tags) is processed, the form bean is not available, since it is in
> a different page context. Hence the <html:text> tag, which needs access to
> the form bean, fails.
>
> One way to fix this would be to have the <html:form> tag store the bean as a
> request attribute instead of a page attribute. However, I'm not sure if that
> would break something else. I don't think so, but I'm not certain. That's a
> question for Craig, I think.
>
Hmm, that would also deal with a question someone else had earlier, where they
wanted to put the <html:form> tag into a "main" JSP page, and the fields in a
<jsp:include>. I will look at it in more detail.
>
> --
> Martin Cooper
> Tumbleweed Communications
>
Craig
Re: Problem using form tags across template pages
Posted by Martin Cooper <ma...@tumbleweed.com>.
OK, now I see what's happening. The <html:form> tag sets the form bean as a
page attribute, so when your nested page (the one brought in using the
template tags) is processed, the form bean is not available, since it is in
a different page context. Hence the <html:text> tag, which needs access to
the form bean, fails.
One way to fix this would be to have the <html:form> tag store the bean as a
request attribute instead of a page attribute. However, I'm not sure if that
would break something else. I don't think so, but I'm not certain. That's a
question for Craig, I think.
--
Martin Cooper
Tumbleweed Communications
----- Original Message -----
From: "Incze Lajos" <in...@mail.matav.hu>
To: "Martin Cooper" <ma...@tumbleweed.com>
Sent: Wednesday, February 28, 2001 2:25 PM
Subject: Re: PROPOSAL: Template Screens
> On Wed, Feb 28, 2001 at 01:54:16PM -0800, Martin Cooper wrote:
> > What exception are you getting? Also, which build of Struts are you
using?
> >
> > I don't see any code that checks for being contained in a form (but that
may
> > be part of the problem!), except in the <template:put> tag, so some more
> > information on what's happening would definitely help.
> >
> > Thanks,
> >
> > Martin.
> >
>
> I did not check the code but in a formar letter i've read this
> diagnosis (I cite it all):
>
> -------------------------------------------------------------------------
> Date: Wed, 31 Jan 2001 16:04:41 -0800
> From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> To: struts-user@jakarta.apache.org
> Subject: Re: Help Please: Resource not found
>
> TMalvos@gcre.com wrote:
>
> > When trying to call a JSP I receive the following message from Tomcat:
> >
> > javax.servlet.ServletException: Cannot find bean under name
> > org.apache.struts.taglib.html.BEAN
> > at
>
>org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextIm
pl.java:459)
> >
> > I checked the STRUTS distribution and did not find it. Has anyone
> > encountered this before? Thanks.
>
> You would get this error if you tried to use one of the input field tags
like
> +<html:text>
> -------------------------------------------------------------------------
>
> I experianced the same exception and I felt so, that probably the
> jsp got by the template does not feel itself inside an html:form.
> There was no code check as I found very quicly the above reference.
> incze
Re: PROPOSAL: Template Screens
Posted by Incze Lajos <in...@mail.matav.hu>.
On Wed, Feb 28, 2001 at 01:18:54PM -0700, 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.
>
Slightly off-topic but relates to the template tags. I've raised this problen
before - maybe we have to big traffic. In this scenario...
a.jsp
--------------------------------------------------------------------
...
<html:form action="..." >
...
<template:get content="x" /> <!-- x points to b.jsp -->
...
</html:form>
--------------------------------------------------------------------
b.jsp
--------------------------------------------------------------------
...
<html:text property="..."> <!-- etc. don't mind the syntax
...
--------------------------------------------------------------------
... the servlet will crash because Struts feels that <html:text> was
defined outside an <html:form>. I think configuring forms with templates
is a major usecase of the template library, and it is _very_ annoying
that in b.jsp you had to use native HTML input tags instead of the
struts family (half of the dessigne work has gone). I think this
can be resolved only if struts taglibs were more closely coupled though
ee what would be the best way to it. Thanks incze
Re: PROPOSAL: Template Screens
Posted by Maya Muchnik <mm...@pumatech.com>.
Hey, guys,
I have a good proposal: include Cerdic to struts developer team.
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/
Re: PROPOSAL: Template Screens
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
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/
Re: PROPOSAL: Template Screens
Posted by Cedric Dumoulin <ce...@lifl.fr>.
Well, if there is no objections, I am ready to provide an implementation of my
suggestion for template screens (build on top of Templates).
If there is some comments, please let me know before I start.
Cedric
David Geary wrote:
> Cedric's got some good ideas here, and I agree with someone else who said he should be
> a committer.
>
> Craig?
>
> david
>
> 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/
Re: PROPOSAL: Template Screens
Posted by David Geary <sa...@tri-lakesonline.net>.
Cedric's got some good ideas here, and I agree with someone else who said he should be
a committer.
Craig?
david
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/
Re: PROPOSAL: Template Screens
Posted by Cedric Dumoulin <ce...@lifl.fr>.
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/
Re: PROPOSAL: Template Screens
Posted by Wong Kok Wai <wo...@yahoo.com>.
Hi David,
It maybe useful to study the portlet concept in
JetSpeed. I see your proposal and portlet essentially
different way to implement dynamic screen layout.
--- David Geary <sa...@tri-lakesonline.net> 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/
>
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: PROPOSAL: Template Screens
Posted by David Geary <sa...@tri-lakesonline.net>.
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/
Re: PROPOSAL: Template Screens
Posted by Cedric Dumoulin <ce...@lifl.fr>.
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/
Re: PROPOSAL: Template Screens
Posted by Maya Muchnik <mm...@pumatech.com>.
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/
Re: PROPOSAL: Template Screens
Posted by David Geary <sa...@tri-lakesonline.net>.
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/
Re: PROPOSAL: Template Screens
Posted by Wong Kok Wai <wo...@yahoo.com>.
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/