Re: PROPOSAL: Template Screens
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
Re: PROPOSAL: Template Screens
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
Re: PROPOSAL: Template Screens
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.
Re: PROPOSAL: Template Screens
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
Re: PROPOSAL: Template Screens
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
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
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
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
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 [EMAIL PROTECTED] 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/
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 faade 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:[EMAIL PROTECTED]]
Sent: Wednesday, February 21, 2001 2:52 PM
To: Joel Regen
