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]



Reply via email to