On Tue, 13 Jul 2004, Ted Husted wrote:
On Tue, 13 Jul 2004 12:03:00 -0700 (PDT), Martin Cooper wrote:As long as it's easy for me to check out the entire gorilla if that's what I want. ;-)
But of course :)
That sounds nice in theory, but there are going to be cases where we'll need to share code between different 'opt's, and it's not clear (to me, at least) where that fits. For example, where would we put the methods that are currently in RequestUtils but that are tied to JSP? I would be very much opposed to JSP specific code being in core, but I'm not sure where else it would go. Would we need an opt-jsp just for that, that the other 'opt's depend on?
For now, they would have to stay in the core. Later, we can try and refactor them out.
My concern is that if we don't think about this kind of thing up front, we're going to find ourselves in a bind when we do try to split these things out.
I like the theory of not introducing a "taxonomy", as you put it, but I don't see that it's really avoidable - or even desirable, in some cases. For example, if the core is independent of servlets, portlets, JSP, etc., then we need somewhere to put shared servlet code, shared JSP code, etc. A hierarchy seems like a pretty good way of partitioning this.
So, we might have a JSP tree that has some "shared" or "common" JSP specific code, along with the JSP specific 'opt's like -taglibs, -el, et al.
Without something like this, I can't help thinking we'll end up with a bazillion top level 'opt's with nothing other than (hopefully) clear documentation (which people never read ;) to tell people what depends on what.
To put all that another way - if we have the structure you propose, where do you anticipate that we would put JSP specific code that is shared among opt-taglibs, opt-el and opt-faces? I think we need to have an answer to that question, at least, before we can know how well the structure will work.
For the foreseeable future, I would expect opt-el to *depend on* opt-taglibs. I don't know what opt-faces would share, but if there's that dependency relationship, then there may be no need to have another "lib-jsp" artifact.
Grepping imports in the struts-faces taglib package, I find these Struts imports:
org.apache.struts.Globals; org.apache.struts.config.ModuleConfig; org.apache.struts.util.MessageResources; org.apache.struts.util.RequestUtils; org.apache.struts.validator.Resources; org.apache.struts.validator.ValidatorPlugIn;
no dependency on other Struts JSP centric stuff. The RequestUtils calls all do accept pageContext as an argument:
ModuleConfig config = RequestUtils.getModuleConfig(pageContext);
Locale locale = RequestUtils.retrieveUserLocale(this.pageContext, null);
return RequestUtils.isXhtml(this.pageContext);
I kind of thought all of that stuff would have been moved to TagUtils, but if it hasn't and won't be, then there's no concern of the type that Martin suggests.
If there is no current concern, I wouldn't want to get stuck planning for this one might-be. However, if we needed it, I guess I'd propose a general "lib-*" naming convention for libraries which are pieces of the puzzle. So in this case, we might have
struts/lib-jsp/
/src
/project.xml
etcI'd be fine with them being at the top. But I'd rather not create them until they have substance.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place."
- Carlos Santana
