Re: PROPOSAL: Template Screens

[Craig R. McClanahan]

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='/chapterTemplate.jsp' >
> >   
> >   
> >   
> >   
> >   
> > 
> > ---
> >
> > To use it :
> >   
> >
> > ---
> > Or, if you want to overload one attribute :
> >> definition='introductionScreen' />
> >
> > ---
> > Or,  if you want to overload or add others attributes :
> >   
> > 
> > 
> >   '
> >
> > ---
> >  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 :
> >   
> >
> > However, it is possible to implement  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"  

Re: PROPOSAL: Template Screens

[Cedric Dumoulin]

  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='/chapterTemplate.jsp' >
> >   
> >   
> >   
> >   
> >   
> > 
> > ---
> >
> > To use it :
> >   
> >
> > ---
> > Or, if you want to overload one attribute :
> >> definition='introductionScreen' />
> >
> > ---
> > Or,  if you want to overload or add others attributes :
> >   
> > 
> > 
> >   '
> >
> > ---
> >  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 :
> >   
> >
> > However, it is possible to implement  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 h

Re: PROPOSAL: Template Screens

[David Geary]

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='/chapterTemplate.jsp' >
>   
>   
>   
>   
>   
> 
> ---
>
> To use it :
>   
>
> ---
> Or, if you want to overload one attribute :
>definition='introductionScreen' />
>
> ---
> Or,  if you want to overload or add others attributes :
>   
> 
> 
>   '
>
> ---
>  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 :
>   
>
> However, it is possible to implement  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.geocit

Re: PROPOSAL: Template Screens

[Maya Muchnik]

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='/chapterTemplate.jsp' >
>   
>   
>   
>   
>   
> 
> ---
>
> To use it :
>   
>
> ---
> Or, if you want to overload one attribute :
>definition='introductionScreen' />
>
> ---
> Or,  if you want to overload or add others attributes :
>   
> 
> 
>   '
>
> ---
>  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 :
>   
>
> However, it is possible to implement  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
> > 

Re: PROPOSAL: Template Screens

[Cedric Dumoulin]

  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 :
--

  
  
  
  
  

---

To use it :
  

---
Or, if you want to overload one attribute :
  

---
Or,  if you want to overload or add others attributes :
  


  '

---
 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 :
  

However, it is possible to implement  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

Re: PROPOSAL: Template Screens

[Wong Kok Wai]

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/

Re: PROPOSAL: Template Screens

[Incze Lajos]

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

...

...
 
...



b.jsp

...
   

Re: PROPOSAL: Template Screens

[David Geary]

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

[Cedric Dumoulin]

  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

[Maya Muchnik]

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

[David Geary]

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

[Wong Kok Wai]

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/

PROPOSAL: Template Screens

[David Geary]

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' %>


  
  
  
  
  


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"));
%>



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:



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
> 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:
>
>  content='<%= chapter + "/footer.html" %>' />
>
> In that case, the footer content would be
> /chapters/templates/footer.html.
>
> david