struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject Re: [PROPOSAL] Modular Struts Examples
Date Thu, 03 Jul 2003 13:44:28 GMT
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 <husted@apache.org> 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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message