You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2010/03/11 00:47:59 UTC

Name of application module class too complicated?

Seems like we keep hitting the error where people change web.xml,
rename their filter, and are confused that their AppModule is no
longer loaded.

I think the way that T5 locates the module class from the filter name
is over-engineered.

I think it should just be fixed as "AppModule", in the services
package, end of story.

Thoughts?

-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by Inge Solvoll <in...@gmail.com>.
We're using a different filter name than "app". It would not be a good thing
to remove support for this, potentially lots of bad press for T5. It's very
important that any upgrade from 5.1 to 5.x can be done in minutes or hours,
without frustration. I even found the upgrade from 5.0.18 to 5.1.0.5 to be
semi-frustrating, due to some encoder issues.

I too like Josh's suggestion, I was thinking the same thing. I don't see why
it's more complicated for the user.

If both AppModule and <FilterName>Module is missing, just report the error
"AppModule is missing". Backwards compatible and quite clear.

On Thu, Mar 11, 2010 at 8:45 AM, Ulrich Stärk <ul...@spielviel.de> wrote:

> I agree and I favor Josh's suggestion. I don't agree with Howard that it's
> making things more complicated. Just in code but that's none of the users'
> business. We could just have this fallback but only document the new
> behaviour.
>
> Uli
>
>
> On 11.03.2010 08:17, Igor Drobiazko wrote:
>
>> A fixed name like "AppModule" would have been a much better decision but
>> it
>> is just too late. We should *never* deprecate or remove any of the naming
>> conventions. There are a lot of online articles and few books on T5
>> describing the convention. Just imagine a frustration of someone who just
>> read an old online article, followed the convention (Filter name + Module)
>> and is wondering why his module is not located. Oh, the Tapestry guys
>> changed the convention in version 5.x. Very frustrating. Tapestry has been
>> criticized of breaking the backward compatibility. There so much apps out
>> there that use other name than AppModule.
>>
>> In contrast we are introducing interfaces ServiceDef2, ContributionDef2 to
>> keep the compatibility with apps build with older T5 versions. IMHO
>> changed
>> naming conventions are much harder to debug then changed interfaces.
>>
>> On Thu, Mar 11, 2010 at 12:47 AM, Howard Lewis Ship<hlship@gmail.com
>> >wrote:
>>
>>  Seems like we keep hitting the error where people change web.xml,
>>> rename their filter, and are confused that their AppModule is no
>>> longer loaded.
>>>
>>> I think the way that T5 locates the module class from the filter name
>>> is over-engineered.
>>>
>>> I think it should just be fixed as "AppModule", in the services
>>> package, end of story.
>>>
>>> Thoughts?
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator of Apache Tapestry
>>>
>>> The source for Tapestry training, mentoring and support. Contact me to
>>> learn how I can get you up and productive in Tapestry fast!
>>>
>>> (971) 678-5210
>>> http://howardlewisship.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: Name of application module class too complicated?

Posted by Ulrich Stärk <ul...@spielviel.de>.
I agree and I favor Josh's suggestion. I don't agree with Howard that it's making things more 
complicated. Just in code but that's none of the users' business. We could just have this fallback 
but only document the new behaviour.

Uli

On 11.03.2010 08:17, Igor Drobiazko wrote:
> A fixed name like "AppModule" would have been a much better decision but it
> is just too late. We should *never* deprecate or remove any of the naming
> conventions. There are a lot of online articles and few books on T5
> describing the convention. Just imagine a frustration of someone who just
> read an old online article, followed the convention (Filter name + Module)
> and is wondering why his module is not located. Oh, the Tapestry guys
> changed the convention in version 5.x. Very frustrating. Tapestry has been
> criticized of breaking the backward compatibility. There so much apps out
> there that use other name than AppModule.
>
> In contrast we are introducing interfaces ServiceDef2, ContributionDef2 to
> keep the compatibility with apps build with older T5 versions. IMHO changed
> naming conventions are much harder to debug then changed interfaces.
>
> On Thu, Mar 11, 2010 at 12:47 AM, Howard Lewis Ship<hl...@gmail.com>wrote:
>
>> Seems like we keep hitting the error where people change web.xml,
>> rename their filter, and are confused that their AppModule is no
>> longer loaded.
>>
>> I think the way that T5 locates the module class from the filter name
>> is over-engineered.
>>
>> I think it should just be fixed as "AppModule", in the services
>> package, end of story.
>>
>> Thoughts?
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 11 Mar 2010 04:41:17 -0300, Kalle Korhonen  
<ka...@gmail.com> wrote:

> Agree with Igor. Ok, so it might trip up a few new users, but at least
> it fails fast and the reason is very understandable.

It doesn't fails, as no warning or error message is shown when the default  
module is not found. A middle-of-the-road solution would be an error  
message.

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da  
Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by Kalle Korhonen <ka...@gmail.com>.
Agree with Igor. Ok, so it might trip up a few new users, but at least
it fails fast and the reason is very understandable. Why remove
additional flexibility that is already there. The simplest solution is
to emphasize this in the documentation with bold letters and be done
with it.

Kalle


On Wed, Mar 10, 2010 at 11:17 PM, Igor Drobiazko
<ig...@gmail.com> wrote:
> A fixed name like "AppModule" would have been a much better decision but it
> is just too late. We should *never* deprecate or remove any of the naming
> conventions. There are a lot of online articles and few books on T5
> describing the convention. Just imagine a frustration of someone who just
> read an old online article, followed the convention (Filter name + Module)
> and is wondering why his module is not located. Oh, the Tapestry guys
> changed the convention in version 5.x. Very frustrating. Tapestry has been
> criticized of breaking the backward compatibility. There so much apps out
> there that use other name than AppModule.
>
> In contrast we are introducing interfaces ServiceDef2, ContributionDef2 to
> keep the compatibility with apps build with older T5 versions. IMHO changed
> naming conventions are much harder to debug then changed interfaces.
>
> On Thu, Mar 11, 2010 at 12:47 AM, Howard Lewis Ship <hl...@gmail.com>wrote:
>
>> Seems like we keep hitting the error where people change web.xml,
>> rename their filter, and are confused that their AppModule is no
>> longer loaded.
>>
>> I think the way that T5 locates the module class from the filter name
>> is over-engineered.
>>
>> I think it should just be fixed as "AppModule", in the services
>> package, end of story.
>>
>> Thoughts?
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de/blog
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by Chris Mylonas <ch...@opencsta.org>.
+1

I'm quite new to Tapestry, and each tutorial has a different way of doing
something.  They all seem to work, but I'm still in a bit of no-mans-land
with why it all works.  This will come with time though.

For instance, three weeks ago I started with the "Tapestry for
non-believers" tutorial which I didn't quite get 100% (and rushing through
didn't get to work 1st time).  Then jumped to a brilliantly written french
tutorial (thanks google translate) that used hibernate and spring in a
different non-tapestry (and non maven) way.  Failing seems to be the way to
learn because after that, I understood what worked a little more.

The Packt book has a solid tutorial I worked through today and will finish
in a day or two as time permits.

Now when I say "different way" I think a lot boils down to the naming of
packages.  Sometimes it's entities, sometimes it's model for the
persistent/DB stuff.

And this difference in naming seems to be at the bottom of this AppModule
discussion.

A picture would tell a thousand words in a scenario like this, although I
haven't got the foggiest idea where I may come across this problem in the
future and should admit that I'm currently "punching above my weight" on
this topic.

Kind Regards,
Chris


On Thu, Mar 11, 2010 at 6:17 PM, Igor Drobiazko <ig...@gmail.com>wrote:

> A fixed name like "AppModule" would have been a much better decision but it
> is just too late. We should *never* deprecate or remove any of the naming
> conventions. There are a lot of online articles and few books on T5
> describing the convention. Just imagine a frustration of someone who just
> read an old online article, followed the convention (Filter name + Module)
> and is wondering why his module is not located. Oh, the Tapestry guys
> changed the convention in version 5.x. Very frustrating. Tapestry has been
> criticized of breaking the backward compatibility. There so much apps out
> there that use other name than AppModule.
>
> In contrast we are introducing interfaces ServiceDef2, ContributionDef2 to
> keep the compatibility with apps build with older T5 versions. IMHO changed
> naming conventions are much harder to debug then changed interfaces.
>
> On Thu, Mar 11, 2010 at 12:47 AM, Howard Lewis Ship <hlship@gmail.com
> >wrote:
>
> > Seems like we keep hitting the error where people change web.xml,
> > rename their filter, and are confused that their AppModule is no
> > longer loaded.
> >
> > I think the way that T5 locates the module class from the filter name
> > is over-engineered.
> >
> > I think it should just be fixed as "AppModule", in the services
> > package, end of story.
> >
> > Thoughts?
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator of Apache Tapestry
> >
> > The source for Tapestry training, mentoring and support. Contact me to
> > learn how I can get you up and productive in Tapestry fast!
> >
> > (971) 678-5210
> > http://howardlewisship.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de/blog
>

Re: Name of application module class too complicated?

Posted by Igor Drobiazko <ig...@gmail.com>.
A fixed name like "AppModule" would have been a much better decision but it
is just too late. We should *never* deprecate or remove any of the naming
conventions. There are a lot of online articles and few books on T5
describing the convention. Just imagine a frustration of someone who just
read an old online article, followed the convention (Filter name + Module)
and is wondering why his module is not located. Oh, the Tapestry guys
changed the convention in version 5.x. Very frustrating. Tapestry has been
criticized of breaking the backward compatibility. There so much apps out
there that use other name than AppModule.

In contrast we are introducing interfaces ServiceDef2, ContributionDef2 to
keep the compatibility with apps build with older T5 versions. IMHO changed
naming conventions are much harder to debug then changed interfaces.

On Thu, Mar 11, 2010 at 12:47 AM, Howard Lewis Ship <hl...@gmail.com>wrote:

> Seems like we keep hitting the error where people change web.xml,
> rename their filter, and are confused that their AppModule is no
> longer loaded.
>
> I think the way that T5 locates the module class from the filter name
> is over-engineered.
>
> I think it should just be fixed as "AppModule", in the services
> package, end of story.
>
> Thoughts?
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
Best regards,

Igor Drobiazko
http://tapestry5.de/blog

Re: Name of application module class too complicated?

Posted by Robert Hailey <ro...@cmediacorp.com>.
On Mar 11, 2010, at 9:45 AM, Massimo Lusetti wrote:

> On Thu, Mar 11, 2010 at 2:11 AM, Howard Lewis Ship  
> <hl...@gmail.com> wrote:
>
>> On Wed, Mar 10, 2010 at 4:42 PM, Josh Canfield <joshcanfield@gmail.com 
>> > wrote:
>>> I've always just used AppModule...
>>>
>>> How about:
>>> look for <FilterName>Module
>>> look for AppModule
>>> Throw exception "can't find <FilterName>Module or AppModule"
>>>
>>
>> That's making it more complicated, not less.
>
> What Josh propose is the best way for handling this, let users who
> read doc use what they learned and help lazy users start with T5.

I agree. I think the only question is wither to throw the exception or  
simply log something.

>
> By my point of view this is a non-issue at all and could definitely be
> kept the way it's now, what should be avoided is breaking current and
> correct working code.

But apparently it is an issue or else users of the framework would not  
be running into it. Specifically, the issue is that the "filter-name"  
parameter does not logically imply a connection to "module-controller- 
name" for beginners (-:like me:-).

--
Robert Hailey

> -- 
> Massimo
> http://meridio.blogspot.com



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by Massimo Lusetti <ml...@gmail.com>.
On Thu, Mar 11, 2010 at 2:11 AM, Howard Lewis Ship <hl...@gmail.com> wrote:

> On Wed, Mar 10, 2010 at 4:42 PM, Josh Canfield <jo...@gmail.com> wrote:
>> I've always just used AppModule...
>>
>> How about:
>> look for <FilterName>Module
>> look for AppModule
>> Throw exception "can't find <FilterName>Module or AppModule"
>>
>
> That's making it more complicated, not less.

What Josh propose is the best way for handling this, let users who
read doc use what they learned and help lazy users start with T5.

By my point of view this is a non-issue at all and could definitely be
kept the way it's now, what should be avoided is breaking current and
correct working code.

-- 
Massimo
http://meridio.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by Howard Lewis Ship <hl...@gmail.com>.
On Wed, Mar 10, 2010 at 4:42 PM, Josh Canfield <jo...@gmail.com> wrote:
> I've always just used AppModule...
>
> How about:
> look for <FilterName>Module
> look for AppModule
> Throw exception "can't find <FilterName>Module or AppModule"
>

That's making it more complicated, not less.


> Josh
>
> On Wed, Mar 10, 2010 at 3:47 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> Seems like we keep hitting the error where people change web.xml,
>> rename their filter, and are confused that their AppModule is no
>> longer loaded.
>>
>> I think the way that T5 locates the module class from the filter name
>> is over-engineered.
>>
>> I think it should just be fixed as "AppModule", in the services
>> package, end of story.
>>
>> Thoughts?
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
> --
> --
> http://www.bodylabgym.com - a private, by appointment only, one-on-one
> health and fitness facility.
> --
> http://www.ectransition.com - Quality Electronic Cigarettes at a
> reasonable price!
> --
> TheDailyTube.com. Sign up and get the best new videos on the internet
> delivered fresh to your inbox.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by Klaus Kopruch <kl...@materna.de>.
+1 for Josh's suggestion


Josh Canfield wrote:
> 
> I've always just used AppModule...
> 
> How about:
> look for <FilterName>Module
> look for AppModule
> Throw exception "can't find <FilterName>Module or AppModule"
> 

-- 
View this message in context: http://old.nabble.com/Name-of-application-module-class-too-complicated--tp27857530p27928213.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by "Joachim Van der Auwera (PROGS bvba)" <jo...@progs.be>.
+1 easier + backwards compatible

Josh Canfield wrote:
> I've always just used AppModule...
>
> How about:
> look for <FilterName>Module
> look for AppModule
> Throw exception "can't find <FilterName>Module or AppModule"
>
> Josh
>
> On Wed, Mar 10, 2010 at 3:47 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>   
>> Seems like we keep hitting the error where people change web.xml,
>> rename their filter, and are confused that their AppModule is no
>> longer loaded.
>>
>> I think the way that T5 locates the module class from the filter name
>> is over-engineered.
>>
>> I think it should just be fixed as "AppModule", in the services
>> package, end of story.
>>
>> Thoughts?
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>     
>
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by Piero Sartini <li...@pierosartini.de>.
+1 for Josh's suggestion as well.
Backward compatibility is a must. If both modules are present, the old
behaviour (<FilterName>Module) should take precedence.

               Piero

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by Josh Canfield <jo...@gmail.com>.
I've always just used AppModule...

How about:
look for <FilterName>Module
look for AppModule
Throw exception "can't find <FilterName>Module or AppModule"

Josh

On Wed, Mar 10, 2010 at 3:47 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Seems like we keep hitting the error where people change web.xml,
> rename their filter, and are confused that their AppModule is no
> longer loaded.
>
> I think the way that T5 locates the module class from the filter name
> is over-engineered.
>
> I think it should just be fixed as "AppModule", in the services
> package, end of story.
>
> Thoughts?
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
--
http://www.bodylabgym.com - a private, by appointment only, one-on-one
health and fitness facility.
--
http://www.ectransition.com - Quality Electronic Cigarettes at a
reasonable price!
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by Howard Lewis Ship <hl...@gmail.com>.
On Wed, Mar 10, 2010 at 4:05 PM, Robert Hailey <ro...@cmediacorp.com> wrote:
>
> On Mar 10, 2010, at 5:47 PM, Howard Lewis Ship wrote:
>
>> Seems like we keep hitting the error where people change web.xml,
>> rename their filter, and are confused that their AppModule is no
>> longer loaded.
>
> That is precisely my issue! IT WORKS! Thanks.

Thought so; this is documented but people miss it consistently.

>
>> I think the way that T5 locates the module class from the filter name
>> is over-engineered.
>>
>> I think it should just be fixed as "AppModule", in the services
>> package, end of story.
>>
>> Thoughts?
>
> Is there utility in a multi-module tapestry app?
>
> The other possibility would be to fail to initialize if it does not find the
> *Module.class it expects? I would have caught on if there was an exception
> like "cannot locate class: %{prefix}/services/[MyKillerApp]Module", and
> whereas the vast majority of security measures would be dependent on the
> contents of the class being able to casually "unlink" it in a config file is
> a bit disconcerting.
>
> Thanks again!
>
> --
> Robert Hailey
>
>>
>> --
>> Howard M. Lewis Ship
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 10 Mar 2010 21:05:22 -0300, Robert Hailey <ro...@cmediacorp.com>  
wrote:

> On Mar 10, 2010, at 5:47 PM, Howard Lewis Ship wrote:
>> I think the way that T5 locates the module class from the filter name
>> is over-engineered.
>> I think it should just be fixed as "AppModule", in the services
>> package, end of story.

That's a good idea.

> Is there utility in a multi-module tapestry app?

Yes. AppModule would include the other modules through @SubModule or  
module autoloading.

> The other possibility would be to fail to initialize if it does not find  
> the *Module.class it expects?

It makes sense, all real applications have some configuration to be done.

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da  
Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Name of application module class too complicated?

Posted by Robert Hailey <ro...@cmediacorp.com>.
On Mar 10, 2010, at 5:47 PM, Howard Lewis Ship wrote:

> Seems like we keep hitting the error where people change web.xml,
> rename their filter, and are confused that their AppModule is no
> longer loaded.

That is precisely my issue! IT WORKS! Thanks.

> I think the way that T5 locates the module class from the filter name
> is over-engineered.
>
> I think it should just be fixed as "AppModule", in the services
> package, end of story.
>
> Thoughts?

Is there utility in a multi-module tapestry app?

The other possibility would be to fail to initialize if it does not  
find the *Module.class it expects? I would have caught on if there was  
an exception like "cannot locate class: %{prefix}/services/ 
[MyKillerApp]Module", and whereas the vast majority of security  
measures would be dependent on the contents of the class being able to  
casually "unlink" it in a config file is a bit disconcerting.

Thanks again!

--
Robert Hailey

>
> -- 
> Howard M. Lewis Ship
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org