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.
-- Martin Cooper
It's also possible that other taglib distributions are dependant on RequestUtils, so once we decide what to do, they'd have to be deprecated and available in both places for a while.
For starters, we can make a clean drop of the taglib package into struts-opt-taglib, and proceed from there.
(Better to get 80% of what you want now, then 100% never.)
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
