> 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]
