What about having a UtilityFactory class that provides RequestUtils and ViewUtils? It goes without saying we'd deprecate the static methods and delegate to new, non-static methods on an instance pulled from this factory. Does Struts have a consistent approach to factories and allowing code to replace the factory implementation? I know this would be a good opportunity to put Spring into the mix, but perhaps an abstract factory would be a good first step in abstracting implementation from usage.
Don
Nathan Bubna wrote:
You can indeed use Velocity+Tiles:
http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/struts/TilesTool.html
Also, while ya'll are pulling out the taglibs (hooray!!), i would like to just mention that there are some things in the TagUtils class that are useful to other view technologies like Velocity. in the midst of all this reshuffling, i would suggest at least considering keeping/moving some such things into a more generic ViewUtils type class. of course, i've not been working on Struts projects lately and have forgotten specifically what functions i'm thinking of and haven't time to look into it or offer patches; i just thought i'd put the idea out there.
and btw, congrats on all the great work happening w/Struts right now. i'm looking forward to when i've got a chance to play around with some
of these things.
Nathan Bubna
On Tue, 21 Dec 2004 18:29:43 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
It has been discussed, I believe, to separate Tiles from Struts, but no one seemed to know where it would go. jakarta-commons doesn't want taglibs, and for some reason I don't remember, the taglibs project wasn't accepted. It would be kinda funny, though, since Tiles used to be its own project that was assimilated into Struts when Struts was trying to divest iteself of code into commons.
I mentioned the separation of Tiles from their taglibs as I thought I heard somewhere of Velocity being able to use Tiles. I could be wrong though.
Don
Eddie Bush wrote:
Actually, I'd tend to agree with that. It makes more sense than separating Tiles and the Tiles taglibs - don't think you'd use the former without the latter. Maybe ... but I don't.
On Tue, 21 Dec 2004 20:35:53 -0500, Deadman, Hal <[EMAIL PROTECTED]> wrote:
Haven't look into this much but it would seem better to have a completely separate tiles sub-project that struts core would use. Don't JSF and Spring currently use tiles and have to include struts.jar when all they really want is tiles?
-----Original Message----- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 21, 2004 7:51 PM To: Struts Developers List Subject: Extracting taglibs
My basic assumption in approaching taglibs extraction into its own subproject is it can reference Struts classes, but Struts classes shouldn't reference it.
If that is correct, here are the changes I see happening to extract taglibs:
1. Move o.a.s.taglib out into its own subproject src tree 2. Remove methods in RequestUtils that delegate to TagUtils. They are marked as deprecated anyways and explicitly say they will be removed after 1.2. 3. Move properties in o.a.s.taglib.html.Constants that are referred to in Struts core code into o.a.s.Globals. (cancel and token keys) 4. Move o.a.s.taglib.tiles to o.a.s.tiles.taglib This one I'm not
sure
about. Should/can tiles be used w/o its jsp taglibs? If not, then it should stay in core w/ tiles. Otherwise, it could be moved out too.
That should be it, as far as I can tell. taglibs are already pretty well isolated from the rest of Struts which will make the extraction pretty straightforward.
I'd like to get this done before Christmas (25th) if there are no objections.
Don
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
