However we combine the apps I want to make sure MailReader continues to be suitable for testing changes in. I often run through and/or modify MailReader to test changes before committing them.
David --- Ted Husted <[EMAIL PROTECTED]> wrote: > Steve Raeburn wrote: > > In the interests of ease of understanding, the first application would > not > > necessarily exhibit best practice all the time. For instance, in the > > examples I put together I have made no effort to protect JSPs with a > > security constraint or by placing them under WEB-INF. I felt this was > not > > necessary to demonstrate the tags in use and might confuse novice > users. I > > don't necessarily think this app should use modules as this could > again > > confuse new users. I'm prepared to be convinced on that, Ted :-) > > I'm -1 on demonstrating anything but best practices all the time. We > made that mistake with MailReader and it has haunted us ever since. > Unfortunately, people expect everything we do to be an example they can > emulate. > > Though, I don't agree that using a security constraint or placing pages > under WEB-INF is a best practice. It's a common *pattern*, but there's > no tangible benefit. If I do do it, it's just to remind other team > members to follow the "Link only to actions (never to server pages)" > best practice. [See what I mean, just because I document the pattern, > people think I advocate it as a best practice =:)] > > Meanwhile, I would be +1 on using Tiles in the Struts Examples module, > since there is so much repetitive markup, anything else would be a bad > practice =:) > > > > The second application should demonstrate current best practice in the > > context of a working, realistic application. The purpose of this app > would > > not be to tutor novice users but to show how Struts features can be > used > > together to create real-world applications. Struts Pet Store springs > to mind > > as a possible example. > > I think something like this might be a good candidate for the Struts > Application site at SourceForge. IMHO, our scope here should be the core > > documentation, a simple starter application (MailReader is fine), and a > library of examples, like the ones you started. I think much of the > Tiles-Doc would work better in the example format as well. > > To help with the understanding how it all comes together, I'd like to > adopt the "example" format for the MailReader too. So instead of just > having a plain text "tour", we would have an annotated walk-through, > where people can call up the corresponding source code and JSPs along > the way. (Wish I thought of that when I first wrote the tour -- we had > the Tomcat Examples even then). > > > > Struts-blank would continue as the basic starter application template. > > +1, and I think this should be the only second application that we need, > > and only because it's intended use is to drag, drop, and develop. > > The intended course would then be to walk through MailReader to get the > big picture, start your own development with Struts Blank, picking and > choosing whatever use cases you needed from the Examples. For additional > > background, the core documentation would be "right there" as well. > > -Ted. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
