Re: Struts JSR?
Craig R. McClanahan said: ... My personal vision is that Struts developers will focus their energy on the controller and model tiers, leveraging the existence of standard (and not) technologies in the view tier. as someone using and working on the VelocityStruts project, this is great to hear! i do hope this is the path the Struts project/community takes. The Struts HTML tags have had their three years of fame :-) -- it's time to get on with life and develop innovative solutions where there are still holes in the big picture. But that's up to each of us individually, of course. ... couldn't agree more! Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Martin Cooper said:
...
Another thought on this. When we get to Struts 2, I'd like to see us
remove all of the JSP-ness of Struts from the core, and also add some
degree of support for other presentation technologies, such as XSLT and
Velocity. So, instead of having 'taglib' where it is in the above tree, we
might want to do something like:
struts/
...
presentation/ (or whatever name we want)
jsp/
taglib/
{others when we get to them}/
...
interesting. i've wondered before if the VelocityStruts code (but not all of
Velocity Tools, of course) might be better off in Struts land. something to
keep in mind i suppose.
Incidentally, where would Tiles land in all of this? In theory, it's not
tied to JSP, but rather to Servlets, so it might be applicable to some
other presentation technologies, but clearly not all.
Tiles works great for us, and we are able to use it in such a way that we can
mix and match JSP and Velocity tiles. i definitely think Tiles can and should
avoid dependence on any particular presentation technology.
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Compartmentalization of Modules (was Re: [18111] et al)
James Mitchell said: html:link module=exercise action=welcome / I don't think that's the best idea. Doing that means your pages know they are in a particular module. ... does the action=foo attribute mean that you are in a particular action? ;) i think the idea was to identify which module you're linking *to*, not which one you are *in*. Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Joe Germuska said: Could stxx's XML processing features be put into Struts 1.x? Yes, but before that happens, I think some sort of url feature for forwarded paths should be put in first. This would allow a request to easily be forwarded to a different presentation system without modifying or overriding the request processor. For example, a forward to a jsp page could look like: jsp://Foo.jsp, for tiles: tiles://Foo.jsp, and for stxx: stxx://Foo.xsl. This feature would make it easy to have multiple presentation engines, a feature we say Struts supports, but it doesn't really. I'm still uncomfortable with minting new URL schemes. Couldn't this be solved by deploying an additional servlet mapped to handle other extensions? This is how JSPs work as it is; if your deployment descriptor gave *.xsl to the STXX servlet, then requestDispatcher.forward() would give control to STXX just to do the view rendering. I thought this was how the Velocity/Struts integration stuff worked already. that's precisely how we do it, and everything works just fine. i too think new URL schemes are a redundant complexity. Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standard HTML Tags (was Extending Standard Tags ...)
/controller for applications (web and otherwise). I believe over at Struts, people have also been doing the same. Right at the top of the Struts home page it says, For the View, Struts works well with JavaServer Pages, including JSTL and JSF, as well as Velocity Templates, XSLT, and other presentation systems. I also recall several occasions on the struts-user mailing list when Struts committers have corrected the misconception that Struts is in any way bound to JSP. In fact, I'm pretty sure I've said it myself. actions speak louder than words. as long as the taglibs are bound up in the same release cycle, jar, and distribution as the core, then i believe the misconception will persist. I don't quite understand why I am not helping. I'm in favour of repackaging the taglibs and giving them a seperate release cycle. hmm. from your previous email that seemed to be your second choice, but ok, i'm glad to hear it! I want to reduce the number of Struts specific libraries in favour of the the general purpose and standard JSTL. And I think it's great that users have a choice of view technologies. The only thing I disagree with you about is that I think the Struts taglib is fine where it is and should be included in the distribution whereas you would have us remove it and ship a framework that can't actually do anything. again, i have no problem keeping the tags in the Struts project if the community wants them there. but the framework does plenty for me without the tags, so IMHO, they don't *need* to be in the same distribution. or at least, not in the same jar (we agree there, right?) How would you suggest we include example applications without including at least one view technology? you could just put the taglibs jar in the WARs for the example app(s) that need it, just like you would with any other library the example apps are dependent on. for instance, one of the VelocityStruts example apps Gabe made demonstrates using Struts with *both* Velocity and JSP. once the taglibs are separated, we will include the taglib jar in the WAR for that app, but not have it in the rest of the distribution. if you included a VelocityStruts app in the Struts examples, would you argue that VelocityTools should be distributed with Struts besides being in the example app's WAR? And if we're going to bundle support for a view technology, shouldn't it be the most widely used, widely understood and standard (as in JCP, not as in the standard for Struts) one? as long as the core and the taglibs have separate release cycles and are in separate jars, i won't be too picky. :) if you want to ship them together, go for it. though personally, i think the 16MB size of the Struts 1.1 distribution could use a little paring down somewhere. there's already a ton of jars (mostly duplicates) between the lib, struts-el/lib, and the example WARs. but i digress, that is another matter. :) Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standard HTML Tags (was Extending Standard Tags ...)
Steve Raeburn said: David Graham said: --- Steve Raeburn [EMAIL PROTECTED] wrote: I'm still happy to be in the view business, but I do think that decoupling the controller from the view would be A Good Thing. The controller has no dependency on the view. The taglibs are dependent on what the controller stores in the various scopes. You could develop an app without using the html taglib at all (XML, Velocity, etc). Agreed. It's almost unthinkable, but you can even develop an app without Struts :-) But I was focussing on JSP which is still the most common view technology. At the minute it's not practical to create a JSP Struts app without the html taglib so, in my view, Struts as an application framework is dependent on that taglib. that's ridiculous. i've been working on Struts apps for nearly a year and i have *never* once used the html taglib. if you wanna say Struts is dependent on it, you've got the funkiest definition of dependent that i've heard in a long while. following that logic i could say that the internet is dependent on Internet Explorer because it's the most common means of using it. FWIW, JSF has much richer view support than Struts does. It supports features that Struts users have wanted like binding form data to native data types on beans that don't implement any particular interface or extend a certain class. Yup, that's a possible (probable?) way forward. I'm not ignoring other view technologies or JSF, just focussing on what is commonly in use now. focus is fine. tunnelvision is not. For discussion, here's my view of how things might progress: - Short term: continue to separate the taglibs from the Struts core into their own cvs/build/distribution. continue? i didn't know the taglibs had even begun to be moved to a separate cvs, build, or distribution. and if i'm wrong on this one, i'd love to be corrected :). - Medium term: drop support for the old taglibs and move the el tags up to the core distribution (or their own distribution if that's what is decided). I understand that breaks support for JSP 1.1 and I'm personally OK with that but I do appreciate that may not be the general consensus. ... i don't believe any taglibs or other view technology should be part of the core distribution. the question of where these View libraries are developed is secondary. i'm definitely with Ted on this one. develop it wherever there's a community interested in developing it, but please give the taglibs a separate release cycle. over in VelocityTools, we've tried hard to dispel this notion that Struts is a JSP technology. i think we've had a little success with that, but you're not really helping here. while it's true that other view technologies can use Struts, as long as the Struts developers treat JSP as the standard view and distribute the two together, i believe you are significantly limiting the potential of Struts as a framework/controller for applications (web and otherwise). Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
Steve Raeburn said: I would prefer going with simpler, specialised classes than a monolithic DispatchAction but if there is a consensus to combine them then I accept your point. A combined action may perhaps offer more flexibility. A concrete subclass might be able to resolve the method in different ways depending on what was present at runtime. (request parameter, parameter, key). i never liked the separate dispatch actions. so, i ended up writing one of these combined ones of my own. i think it's a good way to go. the flexibility allows me to extend all my actions from the one class and later worry about how the dispatch method is specified (via things that don't have to be re-compiled: struts-config, velocity templates, etc). However, I'm not sure that flexibility justifies the increased complexity of the class or of understanding how to use it. Potential areas for user confusion would be misunderstanding the order of preference for resolving the method names or not recognizing conflicts that could arise between them. yes, the order of precedence/preference would need to discussed and well documented/exampled. Also, what happens if we need to resolve by other means? Add more weight to the super class or add another specialized sub class? ... i don't think there's really that many reasonable ways to specify a dispatch, and you're just talking here about combining the various dispatch actions, right? Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tiles w/o JSP (was: Re: Building struts-legacy (was: ...)
Ted Husted said: Craig R. McClanahan wrote: Splitting Tiles and Validator is a little tougher if we go for the previously popular idea of melding all the custom request processor subclasses into a single one (since we don't have multiple inheritance and don't have a decomposition solution yet - which is at least partly my fault). Unless someone can show me how Tiles can be used without JSP, I would be tend to be -1 on integrating Tiles with the inner core, or making any other product changes that imply a specific presentation technology. Ted, i'd love to hear your thoughts on this: http://nagoya.apache.org/wiki/apachewiki.cgi?TilesTool it's been offered as a contribution to the Velocity-Tools project. i'm inclined to take it, but since i've never used Tiles (yet), i'm soliciting other's opinions/evaluations. i am a little concerned that some of the Tiles classes use things in the org.apache.struts.taglib.tiles package (e.g. ComponentConstants). once the struts taglibs are separated from the core, i don't want to keep a dependency on them. ... I'd be very much in favor of integrating something like Tiles as part of the request processor, so long as it is accessible to non-JSP technologies. But I'm not sure if we have that now. agreed. Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm.getMap() change
David Graham said:
i don't know about JSTL-EL, but Velocity users would only need a
get(String
key) method to have ${form.prop} work for us. and i think this will
make
several of us happy too! :)
Because DynaActionForm is a DynaBean, it already has a get(String) method.
cool. i was happy and didn't even know it! thx! :)
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Velocity Tools 1.0 released
The Velocity team is happy to announce the release of Velocity Tools 1.0. Velocity Tools is a collection of Velocity subprojects offering servlets and tools for rapid, clean web development with Velocity, tools for using Velocity with Struts, and a set of generic tools to help with any Velocity project. Please see the Velocity Tools website (http://jakarta.apache.org/velocity/tools/index.html) for more information. For more info on Velocity+Struts see http://jakarta.apache.org/velocity/tools/struts/index.html Both source (http://jakarta.apache.org/site/sourceindex.cgi) and binary (http://jakarta.apache.org/site/binindex.cgi) distributions are available through the the usual Apache mirror sites. Please remember to verify the signatures of the distribution using the keys found on the main Apache web site (http://www.apache.org/dist/jakarta/velocity-tools/KEYS) when downloading from a mirror. Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts repackaging (was RE: [PROPOSAL] Modular Struts Examples)
David Graham said: ... Struts is view agnostic. You can use any view technology you like. agreed! but it could be made friendlier to non-JSP view technologies. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16814 :-) (btw, congrats again on getting 1.1 out. ya'll are great!) Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interesting Bug Fact
David said: Can you explain why? Having the JSP tags in the Struts distro doesn't seem to hurt you if you don't use JSPs. well, i'm assuming that releases of the Struts core library would no longer have to wait on fixes and upgrades to the JSP tags. it would also help in dispelling the seemingly frequent perception that Struts is just for those using JSPs. Nathan said: ... It would also *greatly* please those of us who prefer to use Struts without using JSPs. Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The RequestUtils interface
Ted said: ... The RequestUtils package is really the JspRequestUtils package, and probably should stay that way. Hmm. Then perhaps it should be so named. :) The much better route, IMHO, is for other presentation devices to do their own, optimized versions of RequestUtils. perhaps, but on the other hand, a more generalized and central RequestUtils would make it easier to keep all varying presentation layers in sync as Struts continues to evolve. i could go either way. I do have a few tweaks of my own for the Velocity Tools package. Should I send you the patches to review, Anthony? The velocity-dev list would be a great place to share those. :-) Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The RequestUtils interface
David said: I've always been a little unclear about what RequestUtils' role should be. Passing in the ServletContext is redundant because (at least in servlet 2.3) you can get the session from the request and the ServletContext from the session. But what do you do if you need the ServletContext but no session exists for the request? Do you want the RequestUtils to be responsible for creating a session? I'm not sure I like that. I think it's fine to pass the ServletContext as well as the request. Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
David said: I believe the Velocity site has a comparison to JSP. Of course, they like Velocity better. If it's important that new developers be productive immediately I would go with JSP because that's a java standard that they will already know. also, if you haven't already, be sure you look into the Velocity Tools subproject. a fair bit of work has already been done there to integrate Struts and Velocity. personally, i use the two together and am really enjoying the process. i'm of the lucky few :) that has had almost no experience with JSP, so i'm no doubt a little biased, but i don't think you need to worry about time spent learning Velocity. it's really quite small and simple; the basics can be picked up quickly. if you want to do JSP well, you can easily spend more time learning taglibs (unless you already know them of course). one thing that may ease your concern is that with the Velocity Tools project, it is quite easy to use both Velocity and JSP side by side. there are examples included there for that. also, the Veltag allows you to use Velocity right inside JSP (link below). the one drawback you should be aware of for Struts+Velocity is that not as many people do it yet, and there's not exactly prodigous amounts of documentation or examples floating around yet. the Velocity Tools stuff is a good start though, and if you look into it, be aware that much of the documentation for tool management and such is mostly in the javadocs right now. here's some links that may be of interest to you: Gabe Sidler's docs on Velocity+Struts: http://www.teamup.com/jakarta-velocity-tools/struts/docs/index.html Velocity Tools home: http://jakarta.apache.org/velocity/toolsubproject.html Veltag: http://jakarta.apache.org/velocity/veltag.html Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
Craig said:
...
For example, here's a simple little loop example in
Velocity syntax and a couple approaches in JSP:
Velocity:
(Note -- it's assumed that the Customer collection has been stored in the
VelocityContext by some preceding business logic.)
actually, if you are using the Velocity/Struts support in the Velocity Tools
project, the recommended pattern is to define a set of tools in an xml
config. these will then be automatically placed in the template's Context
and available for you to pull the needed data. there are other ways of
getting objects into the template still, but i don't have time to detail
them here. see the docs concerning the VelocityViewServlet for that. oh,
and Jon Stevens does a good job of explaining the Pull MVC Model here:
http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
#foreach $result in $results {
tr
td$result.ID/td
td$result.Name/td
/tr
}
actually, this is syntax is almost completely wrong. :)
a more fitting example would be:
#foreach( $result in $sometool.results )
tr
td$result.ID/td
td$result.Name/td
/tr
#end
velocity and it's supporting tools are evolving too. :-)
...
* Velocity advocates used to argue that using Velocity was safer
because it restricted what a page designer could do to calling
getter methods. This was never a completely true argument
(how do *you* know that the getter method of the beans you are
calling doesn't mutate something?), but it's been pretty much
eliminated by the fact that you can call arbitrary methods
in Velocity.
yes, it is possible to design badly even in Velocity, but perhaps we could
agree it's at least harder in Velocity to do so.
...
There was an interesting article on onjava.com about a project to
implement a simple blogger app that used both Struts and Velocity:
http://www.onjava.com/pub/a/onjava/2002/04/17/wblogosj2ee.html
I was particularly struck by the following snippet of Velocity code:
$macros.showNavBar(true)
which builds part of the UI by rendering the navigation bar. I don't know
about you, but that looks an awful lot like a scriptlet equivalent:
% macros.showNavBar(true); %
to me :-).
yeah, no offense intended to David Johnson, but that's a really poor way to
use Velocity. it looks as though that method is intended to spit out some
HTML hardcoded into whatever $macros is or some such thing. the HTML
shouldn't come from the java, it should be in the template to begin with, or
at least defined the global Velocimacro library. that way the code could
just be:
#showNavBar( true)
anyway, i hope i'm not coming off too argumentative, it's just that these
are poor examples of using velocity. i wouldn't want people to get the
wrong idea. :)
Nathan Bubna
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
Matt said: See comments below... yeah, no offense intended to David Johnson, but that's a really poor way to use Velocity. it looks as though that method is intended to spit out some HTML hardcoded into whatever $macros is or some such thing. the HTML shouldn't come from the java, it should be in the template to begin with, or at least defined the global Velocimacro library. that way the code could just be: #showNavBar( true) anyway, i hope i'm not coming off too argumentative, it's just that these are poor examples of using velocity. i wouldn't want people to get the wrong idea. :) As I am a committer on the Roller project - I'm curious to know what a better way of implementing this would be. We do want Roller to be a best-practices examples - so any advice is appreciated! Velocimacros are what you want. you can create a specify a library template of velocimacros in your velocity.properties that would be available to all your templates. see http://jakarta.apache.org/velocity/user-guide.html#Velocimacros this provides some nice encapsulation to avoid both hard-coding html or xml or whatever and yet not have to copy-paste or retype the same stuff every time. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
Craig said: ... Sorry ... I was following an example from a published article (don't remember where) so I presume that it (at least) *used* to be correct :-0. yeah, it may have been right (or closer) once, but not since at least two years ago (when i started using velocity). ... * Velocity advocates used to argue that using Velocity was safer because it restricted what a page designer could do to calling getter methods. This was never a completely true argument (how do *you* know that the getter method of the beans you are calling doesn't mutate something?), but it's been pretty much eliminated by the fact that you can call arbitrary methods in Velocity. yes, it is possible to design badly even in Velocity, but perhaps we could agree it's at least harder in Velocity to do so. Harder != Impossible. yep, that's what i said. we agree then! :) ... There was an interesting article on onjava.com about a project to implement a simple blogger app that used both Struts and Velocity: http://www.onjava.com/pub/a/onjava/2002/04/17/wblogosj2ee.html I was particularly struck by the following snippet of Velocity code: $macros.showNavBar(true) which builds part of the UI by rendering the navigation bar. I don't know about you, but that looks an awful lot like a scriptlet equivalent: % macros.showNavBar(true); % to me :-). yeah, no offense intended to David Johnson, but that's a really poor way to use Velocity. it looks as though that method is intended to spit out some HTML hardcoded into whatever $macros is or some such thing. the HTML shouldn't come from the java, it should be in the template to begin with, or at least defined the global Velocimacro library. that way the code could just be: #showNavBar( true) Fine ... still looks like a scriptlet to me :-). looks can be deceiving! with a proper velocimacro, the HTML isn't hard-coded into java classes. that may not be important to some folks, but it is to me. i think it goes a long way toward *encouraging* good MVC separation. it's not just a matter of syntax, but of design philosophy as well. ... Actually, Ted's Struts book (Struts In Action) devotes an entire chapter to using Velocity and Struts together, including how VelocityViewServlet helps you out. It would make a pretty good starting point for people interested in learning how to combine them. yeah, i haven't gotten to see it, but i heard he talked about the Velocity+Struts stuff in it. i'm hoping it gets more people looking into and/or using that code. i think there's some good potential there, but progress has kinda plateaued lately. it could use some fresh users/contributers to prod things along. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Roller-development] RE: Velocity vs. JSP: objective tests?
Dave said: No offence taken, but I do have some comments, which are below... yeah, no offense intended to David Johnson, but that's a really poor way to use Velocity. it looks as though that method is intended to spit out some HTML hardcoded into whatever $macros is or some such thing. the HTML shouldn't come from the java, it should be in the template to begin with, or at least defined the global Velocimacro library. that way the code could just be: #showNavBar( true) anyway, i hope i'm not coming off too argumentative, it's just that these are poor examples of using velocity. i wouldn't want people to get the wrong idea. :) In the case of the NavBar, there was an existing JSP NavBar tag and I wanted to use that NavBar from Velocity. In general, I think you (whoever you are) are correct: the Velocity template (or a Velocity macro) should be responsible for creating the HTML based on the model objects that have been placed into the context. [snip] yeah, i had a feeling it was something like that. i can see that that is useful for initial development, but unless you have some real need to keep that HTML output always in sync with the NavBar tag, i think it would be best to move away from that as you continue to develop the product. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
