As to blank, let's leave them in until we have a better all-around solution to bootsrapping a Struts application. The idea is that the applications using blank as a starting point may use Tiles and the Validator. Blank should come "fully-loaded" in terms of configuration, but "nearly-empty" in terms of content :)
As to MailReader, my preference would be that it not load anything it doesn't use. -T. On Thu, 24 Feb 2005 10:43:47 -0500, James Mitchell wrote: > Great! > > In making local mods for the various apps, I noticed the blank app > is loading tiles and validator plugins, yet they are not used. > Since we already have a tiles app and a validator app, I don't > think that needs to be there. > > My primary reason for wanting to remove that is so that I don't > have an extra dependency for building apps. If anyone doesn't want > it removed, then I'll just leave it, no biggie. > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > ----- Original Message ----- > From: "Ted Husted" <[EMAIL PROTECTED]> > To: "Struts Developers List" <dev@struts.apache.org> > Sent: Thursday, February 24, 2005 10:33 AM > Subject: Re: Struts mailreader > > > +1 > > The other justification was defensive programming. If they tried to > open the page directly, it would blow up, since the expected > objects would not be in the request. But, since then, we've stopped > linking to pages directly, so the tag is a feature without a cause > :) > > If we want to demonstrate this and that, then we should setup an > actual cookbook application, like the one Steve Raeburn started. > > * http://www.ninsky.com/struts/index.html > > Otherwise, any example application should be a best-practice > example of how we would write the application in practice. > > For MailReader, the tag is redundant and can just be removed. The > Actions already check for the user bean and forward to logon if > it's missing. SecurityFilter is cool, but it might be overkill for > an application of this size. If I were to gong to make changes, I'd > probably move it all to a DispatchAction and reduce the login > checks to a single method call. (While putting in a remark to > consider SecurityFilter if additional Actions are added in a > subsequent iteration.) > > -Ted. > > On Thu, 24 Feb 2005 09:55:58 -0500, James Mitchell wrote: > >> If I recall correctly, the app:checklogon tag was initially >> written to simply demonstrate how to write a custom taglib. >> However, I am of the opinion that (while intentions were good) >> that tag should be removed as it demonstrates what I would call a >> "bad practice" wrt j2ee security. We could replace that >> functionality with something like security filter. >> >> Yes, I am volunteering ;) >> >> Your thoughts? >> >> >> -- >> James Mitchell >> Software Engineer / Open Source Evangelist >> EdgeTech, Inc. >> 678.910.8017 >> AIM: jmitchtx >> >> >> ------------------------------------------------------------------ >> -- - To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
