You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Alex Kwan <er...@hotmail.com> on 2004/01/14 07:55:50 UTC
Nobody is interested in this? Re: How to split a web application into modules?
Hi, All
Firstly, Sorry about the last duplicated mail to this group. But I'm
really want to find a solution or discuss with your guys(especially the
committer of Tapestry). But after several days waiting, Nobody seemed to be
interested in my post. Is this problem too silly or too easy to solve or my
English is too bad? This does depress me a lot.
----- Original Message -----
From: "Alex Kwan" <er...@hotmail.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Tuesday, January 13, 2004 10:03 AM
Subject: How to split a web application into modules?
> Hi, All
>
> Recently, my company is developing a complex web application with
> Tapestry. But
>
> We found that the tapestry lacks the way to support multi-module
> development.
>
> Firstly, let me describe the context:
>
> In real projects
> 1) The UI design team and the developer team should be working on
different
> resources and it's better to put their work into different directories
(The
> way that Tapestry advocates).
>
> We should let the developers to edit the classes and the page
specifications
> and let designers
> to work on html templates and other resources like images and css files,
so
> the best solution I found is to put the page specifications into the
> classpath
>
> (Stay with classes) and put the templates into the web context path (Not
in
> the
>
> WEB-INF).
>
> 2) You will need to split the application into some modules and let the
> developers to focus on their own modules.
>
> That means developers should work on their own page definitions and should
> not edit the big application specification file. For example, in struts,
>
> we can divide the struts-config.xml into several configurations,
>
> and each one represents a module, the developers could only edit their own
>
> modules configuration.
> But now, in tapestry, the pages can only be defined in the application
> specification unless you organize them into a library.
>
> Secondly, Lets assume that we have a project named test and it has two
> module m1, m2. According to the contexts described above, we should
organize
> the project like this:
>
> src
> +--m1
> | +---Page1.page, Page1.java, m1.library
> +--m2
> +---Page2.page, Page2.java, m2.library
> webroot
> +--m1
> | +----Page1.html, Page1.css
> +--m2
> | +----Page2.html, Page2.csss
> +--WEB-INF
> +---test.application
>
> And in the test.application, we can declare the m1.library and m2.library
> which are corresponding to module m1 and module m2.
>
> Currently, this solution seems to work. The UI team will work on the
webroot
> and the developer team will work on the src directory. Each module's
> definition is
>
> limited in their definitions.
>
> But this solution still has some problems. For example, if page1 want to
> redirect to page 2, it must call cycle.active(m2:page2), but now, we only
>
> have two ways to achieve this: redefine page 2 in m1.library or
> add a reference to m2.library in m1.library specification. The first way
> will
>
> cause duplication but the second way will cause the Tapestry to DEADLOCK
> when it begin to parse these specifications.
>
>
> So, how do I to solve this problem? I think if we can enhance the
namespace
> mechanism of tapestry (Give the java namespace ability to tapestry), we
will
> solve this problem gracefully.
>
>
>
> Does anyone else have some better ideas?
>
>
>
> Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Nobody is interested in this? Re: How to split a web application into modules?
Posted by Slava Dodatko <sl...@anahoret.com>.
Hello Alex.
The last some days I too expect the answer to your question.
It looks as if you have outlined unique way to resolving this issue
and without some modification of Tapestry is impossible to solve this
problem more finely.
Wednesday, January 14, 2004, 8:55:50 AM, you wrote:
> Hi, All
> Firstly, Sorry about the last duplicated mail to this group. But I'm
> really want to find a solution or discuss with your guys(especially the
> committer of Tapestry). But after several days waiting, Nobody seemed to be
> interested in my post. Is this problem too silly or too easy to solve or my
> English is too bad? This does depress me a lot.
--
Best regards, Slava.
Anahoret Team.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Nobody is interested in this? Re: How to split a webapplication into modules?
Posted by Geoff Longman <gl...@intelligentworks.com>.
Need to make a note here that Spindle's as you type parser can't handle
XML includes.
Geoff
----- Original Message -----
From: "Marilen Corciovei" <le...@nemesisit.rdsnet.ro>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Wednesday, January 14, 2004 6:08 AM
Subject: Re: Nobody is interested in this? Re: How to split a webapplication
into modules?
> To simplify/modularize the .application file we used XML include which
> works ok with the tapestry xml parser.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE application PUBLIC
> "-//Apache Software Foundation//Tapestry Specification 3.0//EN"
> "http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd" [
> <!ENTITY gpages SYSTEM "auto/autopages.application">
> ]>
> <!-- $Id: service.application,v 1.13 2003/10/06 20:48:06 len Exp $ -->
>
> and then insert the auto pages with
>
> &gpages
>
> Len
>
> On Wed, 2004-01-14 at 11:29, Erik Hatcher wrote:
>
> > Alex - you've touched on an issue that probably all of us that are
> > building bigger web applications with Tapestry have struggled with.
> >
> > I don't like having all pages in the same directory, or having to
> > declare them in the .application file to have them segregated into
> > subdirectories. We are currently declaring them in .application. But
> > the namespace is still flat in this regard. We have not tried making
> > libraries of pages, but if there is a deadlock when libraries refer to
> > one another then there is a bug that needs to get fixed, I presume.
> >
> > But, supporting better URL's, which should imply some separation for
> > page paths as well more implicitly, is on tap for post 3.0 release. If
> > you have some suggestions on how to make this happen technically,
> > please hop over to tapestry-dev and start a thread there.
> >
> > Erik
> >
> >
> > On Jan 14, 2004, at 1:55 AM, Alex Kwan wrote:
> >
> > > Hi, All
> > > Firstly, Sorry about the last duplicated mail to this group. But
> > > I'm
> > > really want to find a solution or discuss with your guys(especially
the
> > > committer of Tapestry). But after several days waiting, Nobody seemed
> > > to be
> > > interested in my post. Is this problem too silly or too easy to solve
> > > or my
> > > English is too bad? This does depress me a lot.
> > >
> > > ----- Original Message -----
> > > From: "Alex Kwan" <er...@hotmail.com>
> > > To: "Tapestry users" <ta...@jakarta.apache.org>
> > > Sent: Tuesday, January 13, 2004 10:03 AM
> > > Subject: How to split a web application into modules?
> > >
> > >
> > >> Hi, All
> > >>
> > >> Recently, my company is developing a complex web application with
> > >> Tapestry. But
> > >>
> > >> We found that the tapestry lacks the way to support multi-module
> > >> development.
> > >>
> > >> Firstly, let me describe the context:
> > >>
> > >> In real projects
> > >> 1) The UI design team and the developer team should be working on
> > > different
> > >> resources and it's better to put their work into different
directories
> > > (The
> > >> way that Tapestry advocates).
> > >>
> > >> We should let the developers to edit the classes and the page
> > > specifications
> > >> and let designers
> > >> to work on html templates and other resources like images and css
> > >> files,
> > > so
> > >> the best solution I found is to put the page specifications into the
> > >> classpath
> > >>
> > >> (Stay with classes) and put the templates into the web context path
> > >> (Not
> > > in
> > >> the
> > >>
> > >> WEB-INF).
> > >>
> > >> 2) You will need to split the application into some modules and let
> > >> the
> > >> developers to focus on their own modules.
> > >>
> > >> That means developers should work on their own page definitions and
> > >> should
> > >> not edit the big application specification file. For example, in
> > >> struts,
> > >>
> > >> we can divide the struts-config.xml into several configurations,
> > >>
> > >> and each one represents a module, the developers could only edit
> > >> their own
> > >>
> > >> modules configuration.
> > >> But now, in tapestry, the pages can only be defined in the
application
> > >> specification unless you organize them into a library.
> > >>
> > >> Secondly, Lets assume that we have a project named test and it has
two
> > >> module m1, m2. According to the contexts described above, we should
> > > organize
> > >> the project like this:
> > >>
> > >> src
> > >> +--m1
> > >> | +---Page1.page, Page1.java, m1.library
> > >> +--m2
> > >> +---Page2.page, Page2.java, m2.library
> > >> webroot
> > >> +--m1
> > >> | +----Page1.html, Page1.css
> > >> +--m2
> > >> | +----Page2.html, Page2.csss
> > >> +--WEB-INF
> > >> +---test.application
> > >>
> > >> And in the test.application, we can declare the m1.library and
> > >> m2.library
> > >> which are corresponding to module m1 and module m2.
> > >>
> > >> Currently, this solution seems to work. The UI team will work on the
> > > webroot
> > >> and the developer team will work on the src directory. Each module's
> > >> definition is
> > >>
> > >> limited in their definitions.
> > >>
> > >> But this solution still has some problems. For example, if page1 want
> > >> to
> > >> redirect to page 2, it must call cycle.active(m2:page2), but now, we
> > >> only
> > >>
> > >> have two ways to achieve this: redefine page 2 in m1.library or
> > >> add a reference to m2.library in m1.library specification. The first
> > >> way
> > >> will
> > >>
> > >> cause duplication but the second way will cause the Tapestry to
> > >> DEADLOCK
> > >> when it begin to parse these specifications.
> > >>
> > >>
> > >> So, how do I to solve this problem? I think if we can enhance the
> > > namespace
> > >> mechanism of tapestry (Give the java namespace ability to tapestry),
> > >> we
> > > will
> > >> solve this problem gracefully.
> > >>
> > >>
> > >>
> > >> Does anyone else have some better ideas?
> > >>
> > >>
> > >>
> > >>
> > >> Alex
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > >> For additional commands, e-mail:
tapestry-user-help@jakarta.apache.org
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Nobody is interested in this? Re: How to split a web
application into modules?
Posted by Marilen Corciovei <le...@nemesisit.rdsnet.ro>.
To simplify/modularize the .application file we used XML include which
works ok with the tapestry xml parser.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC
"-//Apache Software Foundation//Tapestry Specification 3.0//EN"
"http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd" [
<!ENTITY gpages SYSTEM "auto/autopages.application">
]>
<!-- $Id: service.application,v 1.13 2003/10/06 20:48:06 len Exp $ -->
and then insert the auto pages with
&gpages
Len
On Wed, 2004-01-14 at 11:29, Erik Hatcher wrote:
> Alex - you've touched on an issue that probably all of us that are
> building bigger web applications with Tapestry have struggled with.
>
> I don't like having all pages in the same directory, or having to
> declare them in the .application file to have them segregated into
> subdirectories. We are currently declaring them in .application. But
> the namespace is still flat in this regard. We have not tried making
> libraries of pages, but if there is a deadlock when libraries refer to
> one another then there is a bug that needs to get fixed, I presume.
>
> But, supporting better URL's, which should imply some separation for
> page paths as well more implicitly, is on tap for post 3.0 release. If
> you have some suggestions on how to make this happen technically,
> please hop over to tapestry-dev and start a thread there.
>
> Erik
>
>
> On Jan 14, 2004, at 1:55 AM, Alex Kwan wrote:
>
> > Hi, All
> > Firstly, Sorry about the last duplicated mail to this group. But
> > I'm
> > really want to find a solution or discuss with your guys(especially the
> > committer of Tapestry). But after several days waiting, Nobody seemed
> > to be
> > interested in my post. Is this problem too silly or too easy to solve
> > or my
> > English is too bad? This does depress me a lot.
> >
> > ----- Original Message -----
> > From: "Alex Kwan" <er...@hotmail.com>
> > To: "Tapestry users" <ta...@jakarta.apache.org>
> > Sent: Tuesday, January 13, 2004 10:03 AM
> > Subject: How to split a web application into modules?
> >
> >
> >> Hi, All
> >>
> >> Recently, my company is developing a complex web application with
> >> Tapestry. But
> >>
> >> We found that the tapestry lacks the way to support multi-module
> >> development.
> >>
> >> Firstly, let me describe the context:
> >>
> >> In real projects
> >> 1) The UI design team and the developer team should be working on
> > different
> >> resources and it's better to put their work into different directories
> > (The
> >> way that Tapestry advocates).
> >>
> >> We should let the developers to edit the classes and the page
> > specifications
> >> and let designers
> >> to work on html templates and other resources like images and css
> >> files,
> > so
> >> the best solution I found is to put the page specifications into the
> >> classpath
> >>
> >> (Stay with classes) and put the templates into the web context path
> >> (Not
> > in
> >> the
> >>
> >> WEB-INF).
> >>
> >> 2) You will need to split the application into some modules and let
> >> the
> >> developers to focus on their own modules.
> >>
> >> That means developers should work on their own page definitions and
> >> should
> >> not edit the big application specification file. For example, in
> >> struts,
> >>
> >> we can divide the struts-config.xml into several configurations,
> >>
> >> and each one represents a module, the developers could only edit
> >> their own
> >>
> >> modules configuration.
> >> But now, in tapestry, the pages can only be defined in the application
> >> specification unless you organize them into a library.
> >>
> >> Secondly, Lets assume that we have a project named test and it has two
> >> module m1, m2. According to the contexts described above, we should
> > organize
> >> the project like this:
> >>
> >> src
> >> +--m1
> >> | +---Page1.page, Page1.java, m1.library
> >> +--m2
> >> +---Page2.page, Page2.java, m2.library
> >> webroot
> >> +--m1
> >> | +----Page1.html, Page1.css
> >> +--m2
> >> | +----Page2.html, Page2.csss
> >> +--WEB-INF
> >> +---test.application
> >>
> >> And in the test.application, we can declare the m1.library and
> >> m2.library
> >> which are corresponding to module m1 and module m2.
> >>
> >> Currently, this solution seems to work. The UI team will work on the
> > webroot
> >> and the developer team will work on the src directory. Each module's
> >> definition is
> >>
> >> limited in their definitions.
> >>
> >> But this solution still has some problems. For example, if page1 want
> >> to
> >> redirect to page 2, it must call cycle.active(m2:page2), but now, we
> >> only
> >>
> >> have two ways to achieve this: redefine page 2 in m1.library or
> >> add a reference to m2.library in m1.library specification. The first
> >> way
> >> will
> >>
> >> cause duplication but the second way will cause the Tapestry to
> >> DEADLOCK
> >> when it begin to parse these specifications.
> >>
> >>
> >> So, how do I to solve this problem? I think if we can enhance the
> > namespace
> >> mechanism of tapestry (Give the java namespace ability to tapestry),
> >> we
> > will
> >> solve this problem gracefully.
> >>
> >>
> >>
> >> Does anyone else have some better ideas?
> >>
> >>
> >>
> >>
> >> Alex
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Nobody is interested in this? Re: How to split a web application into modules?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Alex - you've touched on an issue that probably all of us that are
building bigger web applications with Tapestry have struggled with.
I don't like having all pages in the same directory, or having to
declare them in the .application file to have them segregated into
subdirectories. We are currently declaring them in .application. But
the namespace is still flat in this regard. We have not tried making
libraries of pages, but if there is a deadlock when libraries refer to
one another then there is a bug that needs to get fixed, I presume.
But, supporting better URL's, which should imply some separation for
page paths as well more implicitly, is on tap for post 3.0 release. If
you have some suggestions on how to make this happen technically,
please hop over to tapestry-dev and start a thread there.
Erik
On Jan 14, 2004, at 1:55 AM, Alex Kwan wrote:
> Hi, All
> Firstly, Sorry about the last duplicated mail to this group. But
> I'm
> really want to find a solution or discuss with your guys(especially the
> committer of Tapestry). But after several days waiting, Nobody seemed
> to be
> interested in my post. Is this problem too silly or too easy to solve
> or my
> English is too bad? This does depress me a lot.
>
> ----- Original Message -----
> From: "Alex Kwan" <er...@hotmail.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Tuesday, January 13, 2004 10:03 AM
> Subject: How to split a web application into modules?
>
>
>> Hi, All
>>
>> Recently, my company is developing a complex web application with
>> Tapestry. But
>>
>> We found that the tapestry lacks the way to support multi-module
>> development.
>>
>> Firstly, let me describe the context:
>>
>> In real projects
>> 1) The UI design team and the developer team should be working on
> different
>> resources and it's better to put their work into different directories
> (The
>> way that Tapestry advocates).
>>
>> We should let the developers to edit the classes and the page
> specifications
>> and let designers
>> to work on html templates and other resources like images and css
>> files,
> so
>> the best solution I found is to put the page specifications into the
>> classpath
>>
>> (Stay with classes) and put the templates into the web context path
>> (Not
> in
>> the
>>
>> WEB-INF).
>>
>> 2) You will need to split the application into some modules and let
>> the
>> developers to focus on their own modules.
>>
>> That means developers should work on their own page definitions and
>> should
>> not edit the big application specification file. For example, in
>> struts,
>>
>> we can divide the struts-config.xml into several configurations,
>>
>> and each one represents a module, the developers could only edit
>> their own
>>
>> modules configuration.
>> But now, in tapestry, the pages can only be defined in the application
>> specification unless you organize them into a library.
>>
>> Secondly, Lets assume that we have a project named test and it has two
>> module m1, m2. According to the contexts described above, we should
> organize
>> the project like this:
>>
>> src
>> +--m1
>> | +---Page1.page, Page1.java, m1.library
>> +--m2
>> +---Page2.page, Page2.java, m2.library
>> webroot
>> +--m1
>> | +----Page1.html, Page1.css
>> +--m2
>> | +----Page2.html, Page2.csss
>> +--WEB-INF
>> +---test.application
>>
>> And in the test.application, we can declare the m1.library and
>> m2.library
>> which are corresponding to module m1 and module m2.
>>
>> Currently, this solution seems to work. The UI team will work on the
> webroot
>> and the developer team will work on the src directory. Each module's
>> definition is
>>
>> limited in their definitions.
>>
>> But this solution still has some problems. For example, if page1 want
>> to
>> redirect to page 2, it must call cycle.active(m2:page2), but now, we
>> only
>>
>> have two ways to achieve this: redefine page 2 in m1.library or
>> add a reference to m2.library in m1.library specification. The first
>> way
>> will
>>
>> cause duplication but the second way will cause the Tapestry to
>> DEADLOCK
>> when it begin to parse these specifications.
>>
>>
>> So, how do I to solve this problem? I think if we can enhance the
> namespace
>> mechanism of tapestry (Give the java namespace ability to tapestry),
>> we
> will
>> solve this problem gracefully.
>>
>>
>>
>> Does anyone else have some better ideas?
>>
>>
>>
>>
>> Alex
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org