I think Steve's limited patch to solve the backward compatibility problem is reasonable. I don't think we should be changing any tags or other code to support direct JSP access.
David --- Steve Raeburn <[EMAIL PROTECTED]> wrote: > > What is the point of having a front controller if you then have > > to have code > > all over the place that checks to see if it was invoked, and if > > not, do its > > job for it? This issue is much bigger than just getting taglibs > > and modules > > to work together. The implication is that tags should continue to work > > correctly in the absence of *any* per-request processing the > controller > > does. Think about that for a minute. You'll also bypass the Tiles > request > > processor, and then expect Tiles to work correctly in your JSP pages. > Who > > knows what else? > > If a developer wants to use features such as Tiles or Modules then I > think > the onus is on them to understand the implications of that decision. If > a > requirement of the feature is that the request must go via the > ActionServlet > then that's just one of the things that needs to be documented and > adhered > to. > > With a simple JSP, such as a Welcome page you don't actually need to go > via > the ActionServlet but you may want to use a Struts tag in the page. This > might not be best practice but it's easy and (arguably) appropriate for > very > simple pages. And lots of people do it, including us as evidenced by the > Struts web apps. > > I'm not suggesting checks all over the place and I'm not suggesting that > *all* tags should operate independently of the RequestProcessor. > However, > many tags do not *need* that environment to function. Struts has allowed > this up until now and what you are suggesting is IMHO a significant > change. > > I don't think it's reasonable to enforce restrictions on other users who > don't need that feature UNLESS there's no alternative. I'm not convinced > that there is no alternative because it appears that a minor fix allows > the > status quo to continue and doesn't interfere with the modules > enhancements. > > > > Any directly accessed JSP would be assumed to be > > > part of the default module and the message resources obtained > > accordingly. > > > If you try to access a JSP directly *and* expect it to work as > > part of a > > > module *then* you deserve all that's coming to you ;-) > > > > The problem is that this behaviour will cause even *more* confusion > when > > people try to use modules. We specifically tell people that their > existing > > apps should "just work" when dropped in as a non-default module. > > But if they > > are accessing JSP pages without going through the controller, they > will > > suddenly find that the wrong message resources are being picked > > up. Wouldn't > > it be better for them to see an error message, rather than having > > to figure > > out what happened by themselves? > > > > -- > > Martin Cooper > > > > At the moment, anyone who tries to upgrade to the nightly build would > get an > nasty NullPointerException which I definitely don't think is better. If > it's > a choice between explaining to *everyone* that they *must* go via an > Action > and amending the advice to modules users that they can only drop their > app > into a module if they don't directly access JSPs then I'm for the > latter. > > I'm certainly not bent on ensuring at all costs that we allow developers > to > directly access JSP pages, but that if we can continue to do so without > compromising the new features then we should. > > The suggested patch allows existing applications, including the struts > web > apps, to keep on working while allowing the additional module changes to > work. I'd say that was win-win :-) > > Steve > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
