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 <hls...@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-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Best regards, Igor Drobiazko http://tapestry5.de/blog
