Re: [OS-webwork] Velocity vs. JSP
Eric Webb wrote: Since moving to web application frameworks (jakarta turbine and ww2) I've exclusively used velocity. I find velocity's syntax to be simple, clean, and sufficently powerful for constructing views. I mean, when you get down to it, a view is simply html (in most cases), and velocity does it nicely. Custom macros and the #parse() marco allow me to create modular .vm files that can be reused many many times. snip Ditto that. We've built our CMS/Portal product to use WW/Velocity exclusively, and we're VERY happy with that. The major pro's we've seen are: 1) Clean syntax 2) Great performance 3) Templates does not have to be in files (JSP files do) All in all, much recommended. /Rickard --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Velocity vs. JSP
remigijus wrote: Ok it sounds nice, I'm not against velocity, I'm just curious. How many hits you are getting per day and peak load? What hardware and software do you use? We do load tests sometimes, but it's hard to compare that with reality. In reality, we do have one web hotel server which currently hosts 57 customers, and with a total of 14.600 (dynamic) pages. I'd guess about 10 of those are so-called high-volume sites. We have no HTML output caching, so if Velocity didn't perform the server would crash. This is currently a 3Ghz/1.5Gb/Linux box, with Apache/JBoss/Tomcat as infrastructure and our CMS running inside of that. For the next version we're switching to Apache/Tomcat only. Did you tryed to look at Freemarker, how can you compare Freemarker vs Velocity. I got allergic to Jonathans Freemarker rules-rants early on, and hence never bothered with it. Velocity *is* limited. Which is why it fits our purposes perfectly. YMMV. /Rickard --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Velocity vs. JSP
Erik Jõgi wrote: Rickard Öberg wrote ... 2) Great performance 3) Templates does not have to be in files (JSP files do) ... where does the performance win over JSPs come from? As JSPs are compiled into servlets, how do you beat that? Don't know, don't care. It's just faster :-) That's probably not inherent though; it may very well be that it is possible to make a JSP compiler that creates equally fast output. However, since JSP's are converted into classes you will run into memory management problems on sites with many pages, as the JSP-servlet-classes are tougher to cache than AST's for Velocity templates. if you don't put your templates into separate files, then where do you put them? and how do you specify in xwork.xml which one to pick as the view? Typically we have a template file with a default, but in a number of cases we allow it to be edited by the end-customer. The edited version is stored in a database, along with all the other content. The Velocity is therefore a part of a customized Portlet configuration. It just happens to be a very rendering-related configuration option. We also very often use Velocity for non-HTML cases, such as generating emails. It's nice to be able to have one way to generate all dynamic text, whether it's HTML or emails, and which customers can edit without having to call us. /Rickard --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Portlet API
Marino wrote: Is there any news regarding Webwork support for Portlet API. There is a JIRA issue for that (http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-6) created on 10/05/2002, but without any progress? We have a bunch of portlets using WW1 which we are considering porting to WW2 as we are implementing the Portlet API (possibly by integrating Pluto directly). So far it seems like it can be used as-is, although there are probably some utility-classes that could be written to make it easier to use. /Rickard --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: Spam:[OS-webwork] Xwork and hot redeploy
Jason Carreira wrote:
webwork.configuration.xml.reload=true
In your webwork.properties to tell it to check and automatically reload
XML configuration files (this includes the xwork.xml file and any other
included xwork configuration files, validation.xml files, and type
conversion .properties files right now).
As far as being able to have the one Xwork.jar and have multiple
configurations, that's a good idea... Please add a Jira issue. I've
always hated that Singleton, so we can look at how to get rid of it. In
the meantime, is it possible to have the one xwork.jar file and have
Jboss load it individually in the classloader of each web app (instead
of just once in the server classloader)?
No, but you can have it appear as one singleton while it really is many
by doing a classloader switch internally.
E.g.:
Map clSettings = new HashMap();
String getFoo(String bar)
{
Map settings =
(Map)clSettings.get(Thread.currentThread().getContextClassloader());
if (settings == null)
...
return (String)settings.get(bar);
}
This at least gives you one singleton per deployment. If you use a
WeakHashmap for clSettings you can even have the stated be garbage
collected properly.
/Rickard
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] OGNL madness - evaluated tag attributes
Jason Carreira wrote: I really dislike the option of which syntax to use... Lets choose one and use it... Definitely agree. Think about the case where many components/projects using WebWork needs to be merged into one big app. Oh that won't work because we used optional method Foo, whereas you used Bar is NOT a good situation. Said it before, and will say it again: What makes a framework powerful is not what it allows, but what it does not allow. This is one of those cases where this is really important to remember. /Rickard --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] OGNL madness - evaluated tag attributes
boxed wrote:
Drew McAuliffe wrote:
I agree, and I think that it should be the ${} syntax. The reason I
like the
optional syntax is solely for backwards compatibility.
I don't see why you are using java if you prefer that way of writing
personally.
Let's compare the alternaitves:
ww:property value=name/
ww:property value=${name}/
Am I wrong in assuming that simple usage of the variables is the most
common thing in the WW EL? Because if it is then implementing a more
verbose syntax for it is counterproductive. The rule of thumb is to make
the most common actions simple and intuitive and there is nothing
intuitive about the ${} syntax.
Right. In Velocity the other way makes sense because the $ is used in
plain HTML, i.e. comparing:
ww:property value=name/
${name}
--
But when comparing between the alternatives as above, I think it's
better to use the non-$ approach.
/Rickard
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork 1.4 release
Hani Suleiman wrote: WebWork 1.4 has been released, appropriate press blurbage will be showing up on your regular news channels in the next day or so I expect. You can grab it from https://webwork.dev.java.net/files/documents/693/1790/webwork-1.4.zip Any feedback/testing would be most appreciated. I think it's a pretty solid release with plenty of fixes and good reasons to upgrade. Release notes can be found at https://webwork.dev.java.net/servlets/ProjectDocumentView? documentID=1791noNav=true Thanks to all those who contributed, by filing issues, writing docs, fixing bugs, writing incredibly cool and fast new parsers, emailing in code, and providing encouragement. Thanks to the ww2 guys for providing motivation too (and I don't mean that in a snide way!). Way to go Hani! As we are currently basing our entire product on WW 1.3 this is great news! regards, Rickard --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] velocity tool support
Matt Ho wrote: I've opted to move this to the webwork extensions rather than have it part of the webwork core. Although the VelocityServlet will be deprecated, that won't be til Velocity 1.5! One of the features that's extremely appealing about the velocity tool project is the ability to easily add your own helpers to the velocity context. To that end, I've added a ToolContext (similar to velocity tools ToolboxContext) that allows you to add objects to the velocity context. What does this buy you that the #bean macro doesn't? The problem with this proposal, as I see it, is that they will always be instantiated, even if they're not used. By using #bean macro only those tools that are actually used will be created. IMO that's better. /Rickard --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] EL Performance Between 1.3 and 2.0
Drew McAuliffe wrote: That's consistent with numbers I've found in migrating one app from 1.3 to 2.0. I've always held out hope that this was just something that optimization could take care of. In the meantime, my performance isn't terrible, but it doesn't fly like it did in 1.3, either. Here's hoping the optimization works! I'd offer help except I'm terrible at profiling. If you identify things that profiling indicates need work and need someone to handle some grunt work, let me know. I'm eager to get my old performance back. If you want a good profiler to test with I can really really really really recommend JProfiler. The latest version is a dream to work with. regards, Rickard --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Old wounds!
Francisco Hernandez wrote: i believe it was suggested that everyone start using the ActionContext threadlocal to get what previously gotten by the Aware interfaces.. Yup, that was it. why using ActionContext instead of Aware is another question :) Because it's easier and less verbose? /Rickard --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Old wounds!
Dick Zetterberg wrote: Removing the interfaces would break many old applications so that should probably never be done. (Since those are the applications using WW1). So, since the interfaces will not be removed, then the deprecation might instead be removed so you don't get the annoying warnings all the time (or rather, you can turn on the deprecation warnings and not be flooded with warnings you already know about). I suppose you meant turn off the deprecation warnings. /Rickard --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] List of products using WebWork
Jason Carreira wrote: I've added a section on the WebWork page which lists products using WebWork http://wiki.opensymphony.com/space/WebWork Feel free to add yours... I've added our CMS/portal/doc mgmt tool SiteVision to the list. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Running WebWork on Sun ONE Application Server 7
Bernard Choi wrote: In this particular, our application which uses webwork resides in an environment along with other applications. That environment is controlled by another team, who imposes such restrictions. Ok, but the question then still remains: why impose such restrictions? I have yet to find a good reason to use permissions in server-side applications (except for hosting applications in an ISP/ASP environment). If you're in the same company it doesn't make much sense, and seems mostly just like a hassle. regards, Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Running WebWork on Sun ONE Application Server 7
Bernard Choi wrote: This solved the problem, as webwork was now working fine. However, understandably, granting all permissions is not acceptable in the final system. Why not? /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XW/WW2 press release text for review
Hani Suleiman wrote: 1) I don't see the need to cuss webwork1. He's not cussing WebWork. He's explaining what is and why it is. 2) The portlet sentence seems rather bizarre to me, a portal dispatcher? JSR-168 says very little about portals, so a portal dispatcher is certainly not self-explanatory, to me at any rate. It'd be the equivalent of a servlet dispatcher but adapted to the portlet API. For example, it'd have to deal with separated action/rendering phases, which WW2 is perfectly adapted for right now (IMO). 3) 'Two strategies for handling form submission' seems another odd detail to choose to highlight. Smells too much of 'look at how clever we are for coming up with this trick!' rather than 'this is why the average person should use webwork2'. I didn't see it that way. 4) 'JPublish is replacing their...'...JPublish isn't a bunch of guys, it's a product. True. Replace their with its. I thought the writing was pretty good. I on the other hand question the need for boasting about a beta. It'd be weird to do a press release now, and then a similar one in a week or two when the final release is out. /Rickard --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Webwork in Swing Application?
Joshua wrote: I'm new to this project. Reading through the documentation I came across a statement that WW, unlike Struts, is not based on the Servlet API and so can be used in a java Swing application. Assuming I have not misread the documentation statement, can someone who has actually done this give me a pointer on how to do it? Sure, I'm using it for a Swing-applet. Just register the server-side dispatcher in web.xml like so: servlet servlet-namedispatch/servlet-name servlet-classwebwork.dispatcher.ClientServletDispatcher/servlet-class /servlet and use the ClientDispatcher in your Swing application to execute actions. You create them and populate them (by calling setters) yourself. Giving it to the ClientDispatcher will send it to the server for execution, and then it will be sent back when execute() is done so you can extract the result from it. That's pretty much all there is to it. Any questions? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] HTTP 204 Trick
Dick Zetterberg wrote: Is it not possible to perform this 204 trick just by adding a new standard action that just sets the header and returns NONE? Similar to how the Redirect action works in WW1.x. One would then just chain to this action whenever one wants the header to be set? Would that work, or have I misunderstood something? That should work just fine. /Rickard --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] HTTP 204 Trick
Jason Carreira wrote: So you don't think there should be a HttpHeaderResult to enable you to return special Http header codes? That's not what I said. I was talking about the result codes, not view types. HttpHeaderResult seems fine to me. /Rickard --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Portlet ?
Fernando Martins wrote: I just came to a point that I would really love to start using portlets all over my Portal. I even find myself coding having in mind how everything will fit into portlets. Unfortanetly nothing new on: http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-6 Are there any thoughts on this or do we have to wait for Rickard to come up with some magic tricks? :) What is the status of JSR168? It's almost ready for publid draft. I've read the community draft, and am implementing it in our CMS/portal product SiteVision. And where can one find more info on it? The JSR page is about it. The only biggie that I can see from the spec is that there is now an explicit distinction between action and rendering actions. Action actions (using XWork terminology) are invoked when forms are submitted, and there is only one action action being invoked for each page rendering (possibly zero if no form was submitted). There needs to be a new controller that understands this idea, and which also knows how to switch between a bunch of actions, since you can't use the URL (really) to do it. Either a hidden form field or a URL association trick is needed. There's also some stuff with how JSP's/servlets are included from portlets, and how URL's are constructed (the parameter names need to be encoded with the portlet id on the page), but other than that it's pretty straightforward. We'll do some work in this area once we start working on the Portlet API migration/implementation. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] JavaOne meetings +
Michael Blake Day wrote: How do you guys allow customers to modify velocity templates without mucking with WAR files? We have portlets which render pieces of pages, and a portlet have a map (string-object) as configuration. We typically have a template entry which contains the template to be used (defaulted to some .vm file in the WAR). Then the user can edit this template by editing the portlet which brings up a Swing editor with a textarea containing the template. It's really cool. I've made a Flash demo with this which is available here: http://dreambean.com/Scripting/Scripting.html I've had to put a login on it though (we don't want certain competitors to see what kewlness we have), but simply email me off-list for login info. /Rickard --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] JavaOne meetings +
Anthony Eden wrote: Are you trying to allow modifications of Velocity templates stored in an unexpanded WAR? There is not an easy way to do this as far as I know. Well, it shouldn't be *that* hard, but it'd be a hassle when you do upgrades *shiver* This is not to say it can't be done but its probably not worth the hassle since the interface to files in the Servlet API is geared towards reading only. I'm going to go out on a limb and guess that Rickard's system doesn't pull templates from the file system but rather from some sort of database. Yup (from Jisp). Velocity can pull template data from any ResourceLoader implementation. Therefore you can pull templates from the filesystem, databases, in-memory, or wherever they may reside as long as you provide the appropriate ResourceLoader implementation. Or (as we do) you can simply give Velocity a String with the template. And of course, String's are easy to store in databases. /Rickard --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] JavaOne meetings +
Gerry Seidman wrote: I am evaluating Velocity for a mission critical application (300+ heavy internal users + web presence for another 25,000 moderate users and 250,000 occasioinal users). Does anyone have experience with this type of deployment? We've built our entire CMS product on WebWork+Velocity, and the performance is awesome. Try surfing www.konj.se for example, which is running on our CMS on a 1Ghz Linux box along with 15 other customers (including our own homepage). We've also found Velocity templates to be easy to build and maintain, and we can even let our customers do their own customizations without much trouble. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] (somewhat OT) velocity vs jsp
Hani Suleiman wrote: Alright, so based on the feedback so far, the consensus seems to be: webwork jsp UI tags are much slower than velocity equivalents. So the culprit seems to be the webwork UI tags, not jsp itself. Well, it's the base JSP include overhead that is bad, really. Including a JSP has in my own benchmarks a 2ms overhead. For some applications, like our portal product as an example, that is just totally unacceptable. Velocity has a vastly lower overhead for includes, as boxed said practically no time at all. /Rickard --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] (somewhat OT) velocity vs jsp
Hani Suleiman wrote: Most people seem to be in agreement that velocity templates are at least an order of magnitude faster that jsp pages, which to me seems a bit...odd. So I was wondering if anyone has good (small) examples of this being the case. Webwork examples don't count as good examples because they involve a lot more than just jsp vs velocity, and might well be due to differences in webwork's velocity stuff vs webwork's jsp taglib. So, can anyone take up the challenge, and prove to me that a velocity page that prints out some bean properties is faster than a jsp page which does the exact same thing? Maybe a very basic sample app that anyone can run to see for themselves? Well, we have built our entire portal product on WebWork/Velocity, and although I don't have the same in JSP I'm rather convinced that the performance we get is to a large extent due to our use of Velocity. Here's a sample page: http://www.konj.se/index.html This page assembles a whole lot of dynamic data (ALL data you see is taken from an object model) and uses Velocity to render it. Typically such pages render below 100ms, and as you can see it's a whole lot more complex than the MonthList.jsp page which takes forever to render in JSP. Not sure if this helps you, but I can tell you that at least I am very happy with the decision we made to use Velocity. regards, Rickard --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] best practices around forms with multiple submitbuttons
Jason Carreira wrote: Set the button names to all be command and set the value to the name of a command in your CommandDriven Action and have methods named doSave,doCancel, etc. This does not work well with an i18n'ized app, and also doesn't work if the button name has several words. It's a very tough issue, and I don't have any better answer though... /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] IoC Mini Tutorial [Was: ParameterAware deprecation]
Rob Rudin wrote: I think one drawback can be that you have to do some extra null- checking. In the case of a connection, the class probably has a private instance of Connection, and when it needs to use the Connection, it might not have a guarantee that the Connection is not null - i.e. that setConnection has been called. If the class actively creates its Connection, then it doesn't have to worry about nulls. Of course, it then has to worry about database errors that might occur in getting the Connection, which it doesn't have to worry about in the IoC approach. Thanks, but right now I want to hear Patrick's view of it. We have discussed this issue before, and concluded (if memory serves me right) that it was a bad idea. It is worrysome that he's done a 180 and seems to have forgotten what the problems were. So, in order to ensure that we have at least the same understanding of what the problems are, it's his view I'm after. Right now I'm just puzzled. I hope that's clear enough. regards, Rickard --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] IoC Mini Tutorial [Was: ParameterAware deprecation]
Jason Carreira wrote: Why don't you just go ahead and tell us what you see as drawbacks for this approach. Obviously if Patrick thought the drawbacks outweighed the benefits then he wouldn't be endorsing it. The only thing that is obvious is that the drawbacks Patrick *saw* did not outweigh the benefits. What I'm trying to figure out is what Patriack saw, because we have discussed this before, which is why I'm surprised by his turnaround. So, please, Patrick answer the question as thoroughly as possible. I'll explain my view after that. regards, Rickard --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Configuration questions
Jason Carreira wrote: I started looking at doing this and ran into some snags. For instance, if the code calling the Proxy wants to get at the Action, how does it do that? The ActionInvocation won't even have been created yet, if the Proxy hasn't been executed, and will the Action make sense in a context outside of the execute method of the ActionProxy? Well, that's a damn good question :-) One could argue that an invocation should be created immediately upon creation of actionproxy, and when it's invoked then the reference to it is lost so that any subsequent calls to get the action (from the wrapped invocation) would get a new invocation/action. Perhaps not a perfect solution, but it would give us all the right semantics (I think). After the execute on the ActionProxy, should the ActionInvocation still be available? All in all, I was more sure of this design before I started doing it :-) After the invocation the the invocation should be thrown away (I think). As you said, it's really only once you start doing it that all these problems emerge. Keep doing it and we'll take the issues as we go along. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote: I was thinking it would be good to let them be able to do a series of modifications to the programmatic configuration side then commit them all at once. The runtime configuration is not really a cache, it's another set of data structures that is built from the first set. But, that data structure could be created on each call to the configuration, i.e. there's a deterministic way to get it from the registered package contexts. So, in *effect* it *is* a cache. That's a good question. Are there any other frameworks we can look at for inspiration here? Don't know. I was hoping your experience with Portals and Portlets would enlighten us :-) Well, the portlet API uses an XML file similar to web.xml in order to tie things together. It would be possible to do something similar here, where there is a main config file which is *always* XML, and in which one register the parts that are available, and which may use any configuration style to load it's particular configuration. E.g.: xwork !-- Register subapp foo which uses XML config -- application name=foo param name=config.xmlfoo.xml/param /application !-- Register subapp bar which uses DB config -- application name=bar param name=config.dbjava:/BarDS/param /application /xwork Something like that. I think that the top needs to have a well-defined format though, in XML, similar to how web.xml works. As I said in an earlier post sometimes you want flexibility and sometimes you want rigidity. This is a place for rigidity. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Commands implemented
Jason Carreira wrote: action name=commandTest class=com.opensymphony.xwork.SimpleAction param name=foo123/param result name=error type=chain param name=actionNamebar/param /result interceptor-ref name=static-params/ command name=myCommand method=commandMethod param name=bar456/param result name=success type=chain param name=actionNamefoo/param /result interceptor-ref name=logger/ /command /action Why are params declared explicitly? What's wrong with finding them implicitly, as is done in WebWork? Sounds like a refactoring disaster waiting to happen. Any configuration that is mostly just duplication of code is a bad idea IMHO. Also, it is in general VITAL that we try to keep the configuration required for each action/command down to a minimum. Consider the above when you have 50-100 commands/actions. That's a lot of stuff to keep track of. This should be the last major change to configuration. The only other thing I want to do, and I just thought of this while I was writing this, is to make name optional on the Action and have it not create a runtime ActionConfig for the action itself if there is no name, although you could have several commands underneath the action which would be configured. Sounds ok. I also refactored the names of the config classes. Configuration - ConfigurationProvider ConfigurationFactory - ConfigurationProviderFactory DefaultConfiguration - DefaultConfigurationProvider Why not XMLConfigurationProvider? I mean, that's what it is. SimpleConfiguration - SimpleConfigurationProvider Why not TestConfigurationProvider? I mean, that's what it is. I've also created 2 new classes in the ActionConfig class hierarchy to support commands: ActionCommand ^ | ActionConfig ^ | HierarchicalActionConfig ActionCommand has: methodName Interceptors Parameters Results resultParameters ActionConfig adds: Class clazz TypeConverter HierarchicalActionConfig adds: Commands ActionConfig is the runtime datastructure, the other 2 are used on the programmatic side. Ok, so go ahead and start making fun of my class naming, but you'd better have some better ideas :-) See above. I'll write another email with questions about this stuff. Oh, and I think there might be more major changes to it ;-) /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Commands implemented
Jason Carreira wrote: There are 2 types of parameterization, and you're free to use either or both. The params in the configuration are static params which are intended to parameterize a reusable Action for one or more aliases. For instance, if you had an email action you might parameterize it with the server address, etc. Ok, so it's more like config stuff. I see. Right, we've covered this before. My bad. You don't HAVE to put params, etc. into the config, but you can if you need to. IIRC we argued about this before, and I think my position was that you'd typically want configuration to live elsewhere, but, as you said just don't use it (except that it becomes a built-in anti-pattern). /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote: Sort of, but it's not used that way. In what way is it not used as a cache? E.g.: xwork !-- Register subapp foo which uses XML config -- application name=foo param name=config.xmlfoo.xml/param /application !-- Register subapp bar which uses DB config -- application name=bar param name=config.dbjava:/BarDS/param /application /xwork What happened to the idea of breaking up the config file with an entity resolver? Then you could have package1 package2 This could be another way of breaking up the config file. But I agree it would be good to be able to have different configuration provider types and have them pulled together into one app. You're assuming that they're all configured with XML. The example I gave showed how the subapps were registered using XML, but their configuration could be loaded from whatever. Now, there's another approach to that (as I think I have mentioned before). We could say that the ONLY way to configure XWork is through XML. But, it would be entirely possible to have an entity resolver that creates XML from another configuration format or source. That way we'd need pluggable entity resolvers instead of pluggable configuration providers. Not sure which approach is best though. Any thoughts on that? /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Commands implemented
Jason Carreira wrote: We'll have to agree to disagree :-) I think it's useful for some cases. How about this one: You've got an action you want to alias multiple times with different defaults? If that ever comes up, I'll answer it. So far I've never come across such a situation, for me or anyone else. And I'm sure there's thousands of other hypothetical situations we're not covering either. If you have a a concrete example of where this would occur, bring it on :-) /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote: -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED] Yes, and the right way to do this is probably to enforce that views have this style /WEB-INF/foo where foo is the name of the subapp, i.e. do a hard prefixing. This will ensure that you can always get them to play along nicely, with a little admin if necessary. We're talking about subapps here, but they all seem to be packaged together? Wouldn't you want your subapps to be packaged in a war file of some sort? Yes, it's kind of like multiple WAR's in an EAR, except they're multiple XWork modules in one WAR. So, yes, the subapps are packaged in a WAR file. The same WAR file. Why not use the standard XML way to include files in other files, i.e. using entities? The above seems a bit like reinventing the wheel. Do you have an example of this? I've never used this. Never used entities? They're pretty straightforward. Here's an example (straight from our AOP config): !DOCTYPE aspects SYSTEM aspects.dtd [ !ENTITY interceptors SYSTEM interceptors.xml !ENTITY serverinterceptors SYSTEM serverinterceptors.xml !ENTITY extensions SYSTEM extensions.xml !ENTITY serverextensions SYSTEM serverextensions.xml !ENTITY services SYSTEM services.xml !ENTITY objects SYSTEM objects.xml !ENTITY forum SYSTEM forum.xml !ENTITY form SYSTEM form.xml !ENTITY levis SYSTEM levis.xml ] aspects !-- System definitions -- interceptors; serverinterceptors; extensions; serverextensions; services; objects; !-- Modules -- forum; form; /aspects --- Which coincidentally gives an example of multiple subapps in one app, i.e. the form/forum stuff. It'd be cool if one didn't have to declare the entities, i.e. to be able to have resolve the entities automatically (e.g. forum.xml; would automatically resolve to forum.xml without having to declare it first). I have not been able to figure out how to do that though. If anyone knows, please tell :-) /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Configuration questions
Jason Carreira wrote: * This method in ConfigurationManager is wrong: Interceptor getInterceptor(String clazz) It assumes that there is only one instance of each interceptor class. This does not account for the case where one instance is used with many names (compare with servlets), and configured differently in each case. It has to change to: Interceptor getInterceptor(String namespace, String name) Patrick and I have talked about parameterized Interceptors but we were unable to come up with an example yet, so we didn't implement it (YAGNI in action). I agree that if we decide to have parameterized Interceptors, this is necessary. Ok, well I guess this argument is the same as parameterized commands. I have a couple of interceptors in my own AOP application that are indeed parameterized, so at least in that context there's a need, and I can make a similar example for this case (this, interestingly enough, touches upon the parameterization issues of commands too that I mentioned in my last post). * the getAll* methods in the PackageContext's should not be there. The contexts may understand their own stuff, and that they happen to have a parent, but they should not be responsible for putting it all together. That's the task of the ConfigurationManager IMHO. I'm not even sure a PC should have a direct link to it's parent. Maybe the name is enough, and the CM should make the connection. Well, maybe. This just made a lot of things easier. I'll have to look in the code again for more specific examples. Just move them to the CM. Some issues not related to configuration: * It seems ActionInvocation's are called directly by code. A better way to do this is to create an ActionProxy which upon execute() creates an invocation and invoke it. This ensure that invocations are not reused. In general an invocation is not a good thing to deal with directly since it's conceptually a side-effect of something else. Hiding it behind an ActionProxy would fix this. Sounds like a good idea, but how do we prevent people from using ActionInvocations directly? Would we make them package local and put the ActionProxy in there as well? I'm not sure why people would try to use it directly, but using package protected constructors would work. In what way? Well, mainly the good 'ol curly braces thing (and I have thus far never seen a good reason why one would put 'em on the same line), and also how portions of the class is delineated. I prefer the template used in WW, which had more clearly defined sections. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote: Why is an interface needed here? I thought this was just a singleton thingy which the app can query. Are there several implementation possibilities, and if so, why? Probably not needed. I just created them to keep me sane. Ok. Then I'd propose that it's removed. :-) Let's keep simple things simple. Sometimes you want flexibility and strategy possibilities, and sometimes you want rigidity and stability. This is a case of the latter I think. IMHO that's backwards. This thing should be a stupid data holder, nothing more. It's 3) that determines when the data should be reloaded. But you want to give the API users one thing to interact with, that being the ConfigurationManager. It's already got to know how to build the runtime configuration from the programmatic configuration. Can't this be done when a configuration bundle is registered with the ConfigurationManager? Or, lazily upon access? Should work just fine as far as I can tell. That's backwards. It should be possible to have N implementations, one for each kind of configuration, simultaneously. Remember, an application may be created by merging several subapps, and each subapp may have its own way to read configuration. The total app must be able to handle this. With only One way to read configuration that is not possible. That's a good point. We'll take it up with Patrick... I'll plead his starting that. :-) In general, this app created from subapps is something that needs to be considered in all aspects. WebWork was monolithic in this sense, and it'd be good if we can move away from that. As I've already noted a couple of times, I think in the future it will be more common to build webapps from smaller webapps, e.g. through portlets. This is backwards, because how would you know when to call reload()? The only entity which can know this are the individual ConfigurationFactories. Okay. We can look at how this should be implemented. I still think the user needs to be able to trigger this programmatically, though, like a refresh my config. Ok, how about this then: have the configuration loaders be able to register with the configuration API, and on refresh simply give them a callback. That way the bundles (which should be *stupid*) does not contain logic that understand refreshing. Then, any loaders that can reload can remove the previous configuration and add a new one. I see your points, but I still think there are some details to be worked out. Check out the code and let me know how you think it should change. There's always details to work out :-) I'll check it out. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote:
Here's what I'm thinking:
1) Remove the ManageableConfiguration Interface (was
ProgrammableConfiguration) - this is just ConfigurationManager 2)
Make RuntimeConfiguration into a class and move that part of
ConfigurationManager over to it
There will always be only one RuntimeConfiguration which is created
by ConfigurationManager from the configuration structures it holds
which are initialized by the ConfigurationProviders
I'm having a little trouble seeing exactly what it would lead to, so
hard to comment on. Just do it, and I'll look at the end result.
Can't this be done when a configuration bundle is registered with
the ConfigurationManager? Or, lazily upon access? Should work just
fine as far as I can tell.
The problem here is the case of programmatic configuration. If
someone writes code to call into the ConfigurationManager to change
the configs, then they need to be able to generate the runtime
configuration from it.
If someone adds/removes configuration - clear cache. When a value is
needed - either rebuild the entire cache or just the cache for that value.
In general, this app created from subapps is something that needs
to be considered in all aspects. WebWork was monolithic in this
sense, and it'd be good if we can move away from that. As I've
already noted a couple of times, I think in the future it will be
more common to build webapps from smaller webapps, e.g. through
portlets.
I agree. How would the sub-apps configuration get loaded? How are
they packaged?
That's a good question. Are there any other frameworks we can look at
for inspiration here?
Ok, how about this then: have the configuration loaders be able to
register with the configuration API, and on refresh simply give
them a callback. That way the bundles (which should be *stupid*)
does not contain logic that understand refreshing. Then, any
loaders that can reload can remove the previous configuration and
add a new one.
This is what it does now. Here's the reload() method on
ConfigurationManager:
public synchronized void reload() throws ConfigurationException {
packageContexts.clear(); ConfigurationProvider config =
ConfigurationProviderFactory.getConfig(); config.init(this);
buildRuntimeConfiguration(); }
This, in order, clears the current data structure, gets the
ConfigurationProvider (which could be changed to a List of
ConfigurationProviders) and tells it (them) to init, passing it this
so that they can call back to the ConfigurationManager to register
configurations, then it builds the runtime configuration from the
registered configurations.
Ok. I'll have to look at the code to see all the implications of this I
think.
/Rickard
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote: How about ManagableConfiguration? or ConfigurationPackage or ConfigurationUnit or ConfigurationBundle Either works, but maybe ConfigurationBundle best describes what it actually is. --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote: -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED] Ah, ok, I looked at the interface you sent in email, and true, it doesn't describe it well. But, I would argue that the interface should be split, as I described in my first email on programmatic configuration. You'd typically have 3 players involved: 1 Some configuration repository which the application can use to get configuration settings. This is the RuntimeConfiguration Interface. Both this and ProgrammableConfiguration are implemented by ConfigurationManager right now. This uses a very flat data structure. You call getActionConfig(String namespace, String name) to get an ActionConfig. The Package structures, etc. are stripped away as they're only used to provide defaults and inheritance. Why is an interface needed here? I thought this was just a singleton thingy which the app can query. Are there several implementation possibilities, and if so, why? 2 Some configuration bundle containing settings that have been loaded. This mostly just have get/set methods. This is ProgrammableConfiguration. It also has a reload() method to tell it to get the new configuration from 3, below, and buildRuntimeConfiguration(), which can be thought of as a save method which tells it to generate the runtime configuration from the hierarchical configuration structures which can be programmatically tweaked. IMHO that's backwards. This thing should be a stupid data holder, nothing more. It's 3) that determines when the data should be reloaded. 3 Various loaders which read configuration files (e.g. XML) and create configuration bundles and register these with the repository. This is ConfigurationFactory, which can have one object implementing Configuration registered with it (by default this is DefaultConfiguration). That's backwards. It should be possible to have N implementations, one for each kind of configuration, simultaneously. Remember, an application may be created by merging several subapps, and each subapp may have its own way to read configuration. The total app must be able to handle this. With only One way to read configuration that is not possible. When ConfigurationManager.reload() is called, it calls ConfigurationFactory.getConfiguration().init(this) to tell the Configuration to load its configuration and register the configuration params with the ProgrammableConfiguration it's passed (ConfigurationManager). DefaultConfiguration starts at init() and loads the xwork.xml file, parsing through it building up data structures and registering them with the ProgrammableConfiguration it is passed. This is backwards, because how would you know when to call reload()? The only entity which can know this are the individual ConfigurationFactories. It then becomes possible to configure the app at runtime without using 3 at all, since 2 can be created programmatically. Instances of 2 can also be serialized and sent around in a system without much trouble. Hadn't thought of sending serialized configuration objects around. Why would you want to do this? Why not? :-) Example: using JMX to configure. Using a Java client to configure. Storing serialized configuration in a database. Etc. etc. Right now what happens is that ConfigurationManager has a static instance which is initialized at class initialization and calls reload to get the Configuration from the ConfigurationFactory. See above. That's the wrong approach. Do you see why? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Webwork 2.0 example app
Cameron Braid wrote: Rickard, Is your AOP Framework availible for public use ? Nope. I built it when we started on the CMS/portal SiteVision that we're developing, but it has not yet been released for public use yet. Ironically, we're actually having a little trouble seeing what benefits it would give us, which is why we haven't released it (along with time constraints). /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Webwork 2.0 example app
Jason Carreira wrote: Undying praise and gratitude? :-) I tried that one, but my co-workers didn't fall for it :-) They just saw the enourmous mountain of support email I'd have to deal with - less time for actual work. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] OT: Wiki [Was: Webwork 2.0 example app]
Patrick Lightbody wrote: Yup, I personally like SnipSnap, but it's got a lot of missing features that make it just not good enough. Mainly: 1) Email notifications 2) Revision history 3) File attachments Agree with these. 4) WikiNaming support (I hate doing [Foo Bar], I like FooBar) But certainly not with this one. The Wiki I'm running now (using SnipSnap) is used by non-techie people, and for them it's certainly easier to use the [Name goes here] style. Also, I don't see how names with non-letters would work (e.g. [Oberg, Rickard]) using the WikiNaming style. My personal requirements for a Wiki, which aren't adressed in SnipSnap, involves a much higher level of security. I do *not* want anyone to be able to just sign up and edit pages. It's a disaster waiting to happen. /Rickard --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] re: some suggestion about ww2.0
Steve Conover wrote: Would it be possible to make the view selection algorithm pluggable, as a Strategy or something like that? Just a thought. It could be, but it would have to account for allowing multiple algorithms to be present. If a webapp A is composed of webapps B and C, both of which use WebWork but with algo's X and Y respectively, A needs to work as expected. This is a generally tricky situation, but as we move more towards a portlet-world where apps are composed of smaller components it is a very important thing to consider. In general I'm not in favor of pluggability at that level. It tends to confuse more than it helps. /Rickard --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action Properties HttpSession
Chris Nokleberg wrote:
I have an idea: how about adding an interface Model that has one
method Object getModel(). It would be implemented in ActionSupport as:
public Object getModel() { return this; }
It is a good idea. Maverick does something similar, I think.
Might I suggest that the method be:
Object model()
getModel makes it a property, which then becomes part of the model
itself.
hm.. IIRC model() is also a property (both getModel and model is
tested if the model property is accessed.
*If* I recall correctly we might as well use getModel(), since it looks
cleaner.
/Rickard
--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic
Got blog? I do. http://dreambean.com
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Velocity Views
Scott Farquhar wrote: What advantage does this have over the included WebworkVelocityServlet? He never said that he wasn't using the WebworkVelocityServlet. The method he describes is mostly just to get access to the action as a Velocity object. Otherwise it would be impossible to call methods, as he described. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action Properties HttpSession
Dick Zetterberg wrote: By using this one could avoid doing form names such as myBean/oneProperty and simply use oneProperty instead, if the getModel() method returns the model to be used both as input and as result. But if your bean contains other beans then you still have to use names like otherBean/newProperty, and if you today use several beans in your action you would have to create a wrapper class for them to use as the model (instead of just adding a get method for each bean in the action). In that case you could continue to use the action as the wrapper. So I do not see a very big practical advantage with the proposed addition. For the cases you mention, sure. But there's quite a number of cases where only one bean is being used as input/output and for that case it becomes much cleaner. However, I am not against it if you find it useful, as long as the old way of doing it still works. As I noted the default would be that it works exactly like today. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Velocity Views
Kelvin Tan wrote: Interesting. flamebaitI happen to come from the Turbine + hardcore Velocity (JSP sucks, mostly) camp, so would be interested to know why you choose JSP + Velocity, and not either. /flamebait Does it have anything to do with WebWork support for either? I'm currently using Velocity for about 90%, and JSP for the rest. The 10% JSP are usually forms, since the form tags are not available in Velocity yet. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Followup to the IRC meeting: ThreadLocal impl
Jason Carreira wrote: Ok, so this is a follow-up to the ThreadLocal discussion this morning. So during the ActionInvocation.invoke call, if there are no more Interceptors, it should set the ActionContext into the ThreadLocal? That's what I was thinking. The context is set by the dispatcher: * Set context * Create action * Invoke action (which may invoke other actions) The problem is during the ActionInvocation stack. How do the Interceptors interact with the parameters, the session, and the application map? See above. No problemo. I was creating a new ActionContext object and passing that as part of the ActionInvocation (replacing the Map context in there now), IMO the context should not be a part of the request. The ActionInvocation corresponds to the ServletRequest (in servlet lingo), and the context corresponds to the ServletContext (in servlet lingo). but the problem is that the getters and setters for Session, etc are static, so getting the Session and setting something into it doesn't work if the current instance is not set into the ThreadLocal. On the other hand, if those setters are made non-static, then in the Action, you'll have to do: ActionContext.getContext().getSession() instead of ActionContext.getSession(). See above. ActionContext.getSession() should be fine. This is the path I started down when I decided I would open it up to the floor and schedule the meeting. Any thoughts? As above. Don't try to mix everything together into pure request stuff. The ActionInvocation is one thing, the context is different. There are *some* stuff that is in between, but not much. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Tomcat not mapping *.action to WebWork
Andrew Lombardi wrote: Rickard, I've upgraded the version of Tomcat to the latest 4.1.18 and I'm no longer getting the security permissions errors. However, the URI *.action is still not being mapped and I continue seeing this in the log files: WARN [DefaultConfiguration] Skipping XML action configuration for actions.xml does that provide any clues? Well, it seems as though it can't find it. Either it's in the wrong place (i.e. not in WEB-INF/classes) or it's spelled wrong, or something like that. That's the reasons I can think of anyway. /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork flux
Joseph Ottinger wrote: Can we PLEASE get back to useful discussion? I'm interested in seeing if XWork is usable, and how much in flux it's considered to be. Alright, I'd estimate that the fluxness of XWork is about 70%. Which doesn't mean a whole lot I guess. Wait and see. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork flux
Simon Stewart wrote: Rickard, just a thought, but how much of the code in XWork is derived form (or at least, similar in principle to) your own AOP framework? I get the feeling that there could be a significant amount of overlap between the two in terms of configuration, interceptors, etc. Not a whole lot really. The XWork stuff is highly specialized for the thing it does, whereas my AOP framework is totally generic. Some of the configuration is similar, like packages and such, but still very very different. I use runtime attributes a lot for configuration, which isn't possible here (for example). The ideas are similar though. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Why the 2 lib dirs in skeleton.zip?
Wayland Chan wrote: Included in the WW1.3 distribution is a skelecton-project.zip file. There are two lib directories containing different jar files. skeleton +--lib +--src +--lib The top one is for the build, and the second one is for compiling/runtime. Very separate purposes, so they can't/shouldn't be merged. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] ActionContext clarification
Konstantin Priblouda wrote: Yep. I have to live with frameset, and on couple the first executions of various jsps it delivers different objects. But then it stabilizes... Kind of weird. I think I will provide 2 methods for my factory: from jsp feed it with session and extract object from t here and fromj action just ask ActionContext for object with the same key. Is there a better ( servlet agnostic? more webworky? ) way to obtain global object from web application? Well, if you're using scriptlets then I guess you can use the request directly. The WebWorky way is to have all code that does stuff in actions, and in that case you'd never have any problem. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] ActionContext clarification
Konstantin Priblouda wrote: So you suggest that I convert my factory class into action, and this action shall deposit my desired class in [say] thread local upon execution? Is there webwork example for such factory actions? What are you using the factory for? Sounds like the dispatcher to me. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] ActionContext clarification
Konstantin Priblouda wrote:
Is there webwork example for such factory actions?
What are you using the factory for? Sounds like the
dispatcher to me.
I need a application-global object.
Original version was:
---%-
public static getFoo(HttpSession bar) {
Foo foo = bar.getValue(FOO_KEY);
if(foo == null) {
foo = new Foo();
bar.put(FOO_KEY,foo);
}
return foo;
}
---%-
Hm.. this is not application-global. It is session-specific.
Then i was in need to perform the same from action
- so I modified this method to luse Map instead of
session
and added another static method which just feeds first
one with ActionContext.getSession()
Shall I use [say ] GenerixcDispatcher to initialize
ActionContext ?
First of all: do you want it to be application-wide or session-wide?
Regardless, the initialization should probably be done using a
ServiceContextListener.
/Rickard
--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic
Got blog? I do. http://dreambean.com
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] ActionContext clarification
Konstantin Priblouda wrote: Regardless, the initialization should probably be done using a ServiceContextListener. What is ServiceContextListener? Nothing in webwork docs about it, neither in servlet api Sorry, I meant this one: http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletContextListener.html /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] ActionContext clarification
Konstantin Priblouda wrote: Well, not quite webworky :) The idea is to not reinvent the wheel. I would like to be servlet-agnostic... Ok, then put the code that initializes the context in a class and call it from a ServiceContextListener. What is correct way to obtain ActionContext which was initialized with HttpSession data if there is HttpSession around? I think ServletActionContext.getSession() works. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] ActionContext clarification
Konstantin Priblouda wrote: What is correct way to obtain ActionContext which was initialized with HttpSession data if there is HttpSession around? I think ServletActionContext.getSession() works. This method does not exists in current CVS version of webwork... Sorry, that should be ActionContext.getSession() Another question: It seems to me that ActionContext is stored as TreadLocal, is this map kept in synch with session contents? The reference to the session is updated every time an action is executed. Execute an action - works. Don't execute an action - doesn't work, or unspecified. Again, if you just run an action access to the context is not a problem. If you try to access the context in any other scenario, you're asking for trouble. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] (Offtopic) Freemarker WAS Using SiteMesh for the UI tags
I'll bite. Just this once. Jonathan Revusky wrote: Absolutely, go read it. I think you should go read it too, Rickard. Your comments here do not seem to be based on any grasp of what really happened. Just re-read it, and it re-confirmed my assesment of what happened, and my comments still stand. Anybody who reads the thread and was not born yesterday will see that the Velocity people started all the personal attacks, all the ad hominem and character assastination stuff against me specifically because they could not deal with me in legitimate debate. That you, Rickard, cannnot see through this, does not speak terribly well for you. Okidoki. I am specifically saying that this is where the thread starts. Somebody starts talking about comparing monetary value and I take the opportunity to point out that FreeMarker has the features they want. The discussion continues where a bunch of the Velocity people decide to debate philosophically the desirability of decimal numbers and such. What I meant was that it was a pretty good start of the rant, that went on and on and on and on. I really think you ought to read the thread as well. I think that if you do, you will discover, to your chagrin, that my characterization of it is correct, and that, in fact, you owe me an apology. I owe you zilch. What an eloquant way to say I have the right to say whatever I want, wherever I want, whenever I want, no matter what anyone else thinks. It's really fine up until the very last point. Your above reasoning would allow us to go to the Struts list to explain to them what a monumentally mediocre piece of work they have, Hold on a second. I *never* stated on the Velocity list that Velocity was a monumentally mediocre piece of work. I just stated it here. On the Velocity list, I restricted myself to pointing out that features (such as decimal support among other things) that Velocity users were lobbying for, were already present in FreeMarker. That has its obnoxious side, but it is completely fair comment and I do not believe that you can really maintain otherwise. You went in there with a specific agenda (which you stated yourself after a while), and from that point of view you thought that I have the right to say whatever I want, wherever I want, whenever I want, no matter what anyone else thinks, which is a point where we disagree and is the attitude that I objected to. I wouldn't want Struts people strutting around here like you did, and neither would I want WW folks ranting on the Struts lists. It's just bad taste. In any case, your basic stance is fundamentally nonsensical. If you wanted to know what my behavior would be like on this list if FreeMarker became an OS project, the thing to look at would be my behavior on the FreeMarker list, *not* on the Velocity list. Furthermore, your characterization of my behavior on the Velocity list (though utterly irrelevant anyway) is also inaccurate. The other people invariably commenced the ad hominem attacks on me because they could not deal with me in legitimate technical debate. This is not a matter of legitimate controversy. It is what a reading of the electronic record will show. And again, those who are interested in understanding this story should go read it. It's quite illuminating, especially since we seem to see completely different things. BTW, in terms of my assessment of Velocity's quality as a piece of work, I pretty much completely pulled my punches there. I mean, just as one example, look at the way Velocity handles macro parameters. It passes them in as strings, that are reparsed and evaluated every time the parameter is referenced in the macro. I simply pointed out that features that people had been lobbying unsuccessfully for in Velocity for god-knows-how-long were available in FreeMarker. That's probably an interesting point, but this is the WW list. We don't really care. which get the level of usage and attention that it does because it is a part of apache.org. Factually correct (one could argue), but oh so irrelevant. I guess we will just have to agree on disagreeing on this point. Well, as for agreeing to disagree, with the overtones of political correctness and relativism, well... sorry... I don't just agree to disagree with you on this matter. I am stating that your characterization of what happened is FALSE. And I have backed up the assertion by pointing to the exchange in question that anybody can read. Or so you think. Most amusing. Note that the reading of it is not particularly flattering to me. It shows my ability to push people's buttons for fun somewhat. BUT the behavior of the other people in the thread was typically far worse than mine. That much is pretty clear. To you. In other words, if someone else is a prick you have the right to be a prick too. Interesting logic, and again I guess we will just have to agree on disagreeing on this point. I was simply stating
Re: [OS-webwork] (Offtopic) Freemarker WAS Using SiteMesh for theUI tags
Still off-topic. Rickard Öberg wrote: hge snip Goodbye Jonathan. Jonathan is bashing on me off-line. Has anyone read the Velocity thread and found my characterization of it as disgusting to be way out of line and bordering on harassment of Jonathan? He sez: And you had no fucking business badmouthing me on a public list where it was completely off-topic. Also, the characterization of my ranting -- as if nobody else's shit stank there -- was fundamentally dishonest. Did anyone consider my opinion of the thread as badmouthing him? Just curious. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
Francois Beauregard wrote: A few developers here have used freemarker a little while ago and loved it. It seems to be a very good alternative to velocity. Since it worked for WebWork and after some little discensions the community seems be very well and alive, I would like to throw the suggestion the freemarker joins OpenSymphony. If the suggestion makes sense, an evaluation of the ptoential must be done by both party. Also, goals and directions for the project should be established first. I think this is the part that was missing when the WebWork joined OpenSymphony. Well, I remember some not so long ago the FreeMarker main developer went to the Velocity lists and ranted like crazy. It was a very disappointing read and he just wouldn't give up. I'm sure FreeMarker is ok technically, but I'd prefer to keep stuff like that out of here. So, no, I don't think FreeMarker should join OS. IMHO. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
Francois Beauregard wrote: I was not aware of that fact. You are right. OpenSymphony seem to have got lately to a point where there is a good exchange of ideas and the community moves forward. This must stay the way it is right now. Do you remeber the reasons for the ranting? Yes, his belief that FreeMarker was the ultimate solution and that he was entitled to telling everyone of this regardless of everyone on the list begging for the opposite. It was (to me) quite disgusting. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
Francois Beauregard wrote: Just wanted to emphasize the fact that supporting Freemarker as a view technology in WebWork and integrating Freemarker as an OpenSymphony project are two really separate issues. Oh absolutely. If someone wants to integrate FreeMaker go right ahead. I have no problem with that. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Freemarker WAS Using SiteMesh for the UI tags
Jonathan Revusky wrote: François, I don't believe that you should take Rickard's account of what happened as definitive, particularly when there is a complete electronic record of all of this that anybody can look at. Absolutely, go read it. In the following post, a velocity users asks about monetary values in a velocity template. At some point in the thread, I respond. Here is the initial post of that thread, entitled Comparing Monetary Value. http://www.mail-archive.com/velocity-user@jakarta.apache.org/ msg08355.html Here is my initial contribution to the thread and thus, I suppose, this is an example of my ranting: http://www.mail-archive.com/velocity-user@jakarta.apache.org/ msg08366.html Not really, but it's a good start. I would encourage you to read through the whole thread and how it developed. It actually becomes piquant. Quite entertaining stuff. But I think you'll see that Rickard's characterization of what happened is pretty stretched. What you'll see is that various people attempt to engage me in debate and then, when they end up looking foolish *but fairly, in legitimate technical debate* they then start the attacks on my person. And then they later claim (quite mendaciously, of course) that I was the one engaging in personal attacks on them!!! As Jonathan said, read the thread. Yes, his belief that FreeMarker was the ultimate solution and that he was entitled to telling everyone of this regardless of everyone on the list begging for the opposite. To be clear, I see no real problem with telling people about FreeMarker on a Velocity mailing list. There are 2 key reasons for this: 1. Velocity is a monumentally mediocre piece of work that only receives the level of usage and attention that it does because it is part of apache.org. Since there is such a huge disparity in the visibility of Velocity and something like FreeMarker, I have no compunctions about mentioning FreeMarker on the Velocity list, no more than I would in mentioning FreeMarker on a list devoted to JSP. In any case, my behavior there may have its obnoxious side. Fine. Okay BUT... but what is the basic grievance? At the end of the day, the end-user can always choose to use whichever tool suits him best. You may also note that my posts were invariably factual and could have been helpful to anybody making such a decision. It appears that the Velocity community did not want anybody making comparisons. What an eloquant way to say I have the right to say whatever I want, wherever I want, whenever I want, no matter what anyone else thinks. It's really fine up until the very last point. Your above reasoning would allow us to go to the Struts list to explain to them what a monumentally mediocre piece of work they have, which get the level of usage and attention that it does because it is a part of apache.org. Factually correct (one could argue), but oh so irrelevant. I guess we will just have to agree on disagreeing on this point. 2. Velocity developers have engaged in this kind of behavior themselves on the webmacro mailing list. This was particularly obnoxious because, of course Velocity is little more than a rip-off clone of Webmacro in the first place. In fact, the origin of it is that Webmacro was supposed to be an apache project, but there was some falling out between Jon Stevens and Justin Wells and Jon Stevens started the webmacro clone that became velocity. But anyway, given the history, the velocity developers are very poorly placed to scream and holler about me showing up on their mailing list. You see, they have bad karma... In other words, if someone else is a prick you have the right to be a prick too. Interesting logic, and again I guess we will just have to agree on disagreeing on this point. It was (to me) quite disgusting. Well, I'm glad you put the to me there in parentheses. I am quite convinced that some people derived vicarious pleasure from it. :-) Absolutely: you seemed to have fun. That's why I added to me, because I had a hunch that you'd disagree. But anyway, I very honestly do not want to start a flamewar here. I don't have the time for it and I don't have any quarrel with anyone here. In fact, I have little intention of participating much more on this list. But here's the key point: Look, there's a complete electronic record of all of this. Go look at it and see if Rickard's characterization of my 'ranting' is accurate. That's pretty reasonable, huh? Sure enough. And ironically, your post is an excellent example of the kind of stuff I want to avoid in OpenSymphony. Now back to our regular programming. regards, Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http
Re: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem +solution?]
Patrick Lightbody wrote: I found a possible way around this, but I'm not sure if it's a good idea or not :) What if the FilterDispatcher never actually makes a call to filterChain.doFilter()? This would get around the duplicate view request problem outlined below, but would require that the filter -must- be the last one applied or else you'll loose the application of filters further down the chain. I don't think this is too bad though, since we can just -clearly- document that the FilterDispatcher (if you want to use it) must be applied last. Thoughts? Works for me :-) /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Configuration question
Hani Suleiman wrote: Looking over the *Configuration framework, it looks like keys that aren't found result in a IllegalArgumentException being thrown. Now, the DelegatingConfiguration goes through all configurations when trying to find any named property. This means that there are a *lot* of getString calls to each configuration, hence a lot of new exceptions being thrown and caught which is rather expensive. My question is, why was this done this way? Why not just use nulls or some other static marker object if we need to distinguish between 'the value is null' and 'I don't know anything about this value'? The reason is that it's easier to code client-code using exceptions. Instead of doing null-checks all the time you can write code that assume that certain settings are available, and then simply try/catch it in case it wasn't available. That was the reason. Improving performance may be a more important factor though, so go ahead and change it if you want to. Just make sure that all calls to the conf. does proper null checking. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork 2.0: FilterDispatcher?
Patrick Lightbody wrote: snippetysnap What do you think? Rickard, would this work for you? Everyone else, would this work for YOU? ;) Works for me! :-) /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Ognl: peek(), up(), and down()
Patrick Lightbody wrote: If Ognl is just totally unacceptable, then let's discuss two options: 1) Redevelop the WW EL with speed as well as type conversion both as a top priority 2) Develop XWork to support pluggable ValueStack implementations Just a point on 2. This will introduce muchos confusion, especially in a situation where you want to compose an application from two individually developed parts which may use different implementations. It's also a documentation problem (it's like this, unless you use this stack, because then it looks like this, which has this and this semantics). Sometimes flexibility is good, sometimes it's a recipe for disaster. In this particular case I'd say it's the latter. Either make OGNL work ok, or go with 1). I'd personally prefer 1). /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance
Robert Nicholson wrote: Were those JSPs precompiled or at least had you visited them once already? I accessed the page loads of times using webstress and calculated an average. It's a couple of ms for JSP's, and about a ms for Velocity. That may not seem like much, but it adds up (especially if you, like us, use includes EVERYWHERE). /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Xwork 1.0 and Webwork 2.0 Mission Statements
Sounds good to me! /Rickard Jason Carreira wrote: Here's a first pass at mission statements for Xwork 1.0 and Webwork 2.0. Hopefully this will help clear up what Xwork is, what Webwork is, and what is and is not in scope for each project. snip --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Performance
Patrick Lightbody wrote: I believe that rewriting it to work for Lists would be just fine. The main thing it is doing is essentially _skipping_ all the EL stuff, which I believe is OK since templates are only usually edited once. Another thing that could be an idea is to use Velocity for the templates. I measured the raw overhead of doing an RD.include() on an empty Velocity template and an empty JSP. The overhead was way higher for a JSP, so in any include-intensive situation (e.g. tag templates) Velocity is a better choice. And same as above applies: they're only usually edited once so what it's implemented with isn't that important. Another good thing about using Velocity instead of JSP is that the performance is more consistant since it's not reliant on the JSP engine quality which, in some cases, is not what it should/could be (Tomcat/Jetty for example). /Rickard --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Hidden token
boxed wrote: I proposed the ability to associate URL's with actions. When the URL is requested the action is executed and the association is removed. This removes the need for any Javascript solution or any hidden fields or any such tricks. Would the result of this execution be stored so that the second click would lead to the already generated result then? I don't know. Probably not. The above feature would only ensure that only code that is SUPPOSED to be executed actually gets executed. /Rickard --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Hidden token
Erik Beeson wrote: There would be no hidden field. When the URL is generated that URL is associated with the actions to be run. There's no way to figure out from the URL what actions will be executed. So you get URLs like: http://www.myhost.com/some/path/wfjIFEOwijofOEIWjfIOWEkaAIoqjklnfoSyEj?foo=bar And then a map associates that with an action on the server side. Is that correct? --Erik No. Example: xw:url page=foobar.html action=blahblah xw:param name=foo value=bar/ /xw:url would generate the following URL: foobar.html?foo=bar When the server runs foobar.html it first executes blahblah and makes the result available somehow for the rendering process to use. Pretty straightforward. If foobar.html?foo=bar is hit again then nothing happens, since the action has already been executed. /Rickard --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Hidden token
Joseph Ottinger wrote: I'd prefer adding it to the wiki or the current release of WW, since there are some users who actually use what's there now as opposed to vapourware, even though the vapourware is promising. Didn't you resign from OpenSymphony? Or was it just that you stopped doing things? /Rickard --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Hidden token
Jason Carreira wrote: I remember Rickard was talking about something to prevent 2 submits, but I'm not sure what it was... I proposed the ability to associate URL's with actions. When the URL is requested the action is executed and the association is removed. This removes the need for any Javascript solution or any hidden fields or any such tricks. And this is also how the Portlet API is going to work. The only problem with it is that you'd have to use a JSP tag or similar to generate the URL. IMHO it's the best solution to this problem. /Rickard --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Reflection
boxed wrote: The problem is not right or wrong, the problem is the pro's and con's of the various approaches, and AFAICT the explicit approach has some limitations, whereas the non-explicit approach has no limitations. I can think of an example right now when the explicit solution is much more flexible than the ThreadLocal solution: Action1 creates two sets of data and starts off two threads, executes Action2 and Action3 with these two maps as parameters, then joins on the threads and continues on with its own execution. Did I miss something here? Would this be easier to implement with ThreadLocal (with JNDI?)? If the threading is done by XWork it would be equally simple. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Reflection
Erik Beeson wrote: Rickard, as I understood, XWork was to break away from J2EE, hence removing web from the name. If new versions with strong web ties are going to remain, shouldn't they remain under the original WebWork name? That is something I wanted to gauge by my last couple of emails. I personally do not believe (at this point) that making the web part optional is going to work very well. I certainly don't believe that it is going to be feasible, or even a good idea, to make a framework that allows code to be written for both Swing and the web. They're different beasts with different requirements, with completely different thinking behind how code gets written. We have a lot of Swing code in our project, and when I look at it I simply don't see how something like XWork would fit in, or why it would be useful. What *is* useful is to allow actions to be called without a servlet environment, but more or less *only* for testing/debugging purposes. Executing actions as a response to asynchronous messages could work too. But that's about it. I do not believe that actions (except for maybe 1% of special cases) can be reused in so different spaces. I remain open to the *possibility* of it, but so far I just haven't seen it. So, given all of this, my resignation from XWork still holds. The requirements that have been voiced the last few days are not mine, and I don't think they're compatible with my goals, at least not without serious compromises that will only hurt the end result. The question then becomes: would it be useful to do *both* XWork and WebWork, but as separate projects with these different goals? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
Peter Kelley wrote: Good to have you back I'm not back. I'm trying to see whether it's any point in me restarting the XWork. Are views a core concept ? Tricky one. Yes, I guess they should be, somehow. The other thing we might want to address is whether or not XWork will be somewhat seperated at the core from the web. This is a very difficult question. Separating it from the javax.servlet API should be possible, but overall I have the feeling that trying to make a *too* generic solution might be crippling. A little poll: *) How many have actions that are used with more than one kind of dispatcher? *) How many are using WebWork in Swing apps? *) How many are using WebWork for RPC style stuff? (the ClientServletDispatcher and friends) /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Getting rid of thread locals
Patrick Lightbody wrote: ThreadLocal implies that you always have a single thread throughout the lifecycle of the action (prepare, execute, print results). This is true for a servlet container (single thread/request), but not so in other areas. No, it doesn't imply that. If the execution chain is broken, then one simply takes the context and reuse it whenever the chain is restarted. /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork Interceptors
Patrick Lightbody wrote:
So anyway, I'm just going to disregard the Documentation thread and start
a thread that is actually useful :)
Good idea :-)
(Though, Ken, we're still hoping your willing to do some Doc work!)
Same here!
So besides Action Chaining, Rickard made a good point that interceptors is
very important as well. I'd like to talk about the actual implementation
now -- using the transaction scenario as an example.
How will the interceptor know when to rollback or commit? Of course on an
Exception it should, but what about on ERROR or INPUT? What if the action,
to signify it's is complete, used COMPLETE instead of SUCCESS? Do you see my
point? How can we make interceptors work for all cases? I'm guessing some
sort of configuration is needed for each interceptor on each action, so we
could do something like:
interceptor class=...
param name=commit.valuessuccess, complete/param
/interceptor
And then the interceptot could know to rollback if the return value isn't
one of those two.
Rickard, is this what you had in mind?
In this particular case I think it's best to look at how EJB works: for
any application result from a method invocation (e.g. void, some value,
an application exception) the transaction is committed. The transaction
is ONLY rollbacked if a) a runtime exception was thrown b)
setRollbackOnly() has been called. I.e. the interceptor does not need to
be configured.
So, what if you (for some reason) really do want ERROR to lead to a
rollback? Well, simply add an interceptor that on ERROR calls
setRollbackOnly, and have it after the tx interceptor (i.e. it is
invoked before the tx interceptor on the way back). Have *that*
interceptor be configurable, and add it whereever you want this kind of
behaviour. That way the tx interceptor itself is nice and clean, and you
can still get app-specific behaviour at some points.
Also, Interceptors would fit in to the GenericDispatcher area. I think that
they would replace ActionFactoryProxies entirely, correct?
Yup. In my XWork implementation ActionFactory is now just a class that
instantiates an action directly, and initializes the interceptor chain
for it. Everything that the AF proxies used to do is now in interceptors
that are executed on execute() invoke. This means that the
GenericDispatcher is typically not needed. Just do this:
Action action = ActionFactory.getAction(foo);
action.execute();
And this can be done *within* another action without problem.
Also, maybe
Rickard you can provide some sample psuedo code for an Interceptor as well
as how it would go about being invoked in GenericDispatcher?
As I said, I don't think GD is needed anymore. Here's an example
interceptor I wrote:
public class ParameterInterceptor
implements ActionInterceptor
{
// ActionInterceptor implementation --
public String execute(ActionInvocation invocation)
throws Exception
{
// Set parameters
TypeConverter typeConverter =
Configuration.getInstance().getAction(invocation.getName()).getTypeConverter();
OgnlUtil.setProperties(ActionContext.getContext().getParameters(),
invocation.getAction(), typeConverter);
return invocation.next();
}
}
--
This replaces the action factory that transfers servlet parameters to
the action. Pretty straightforward. Note that the ActionInvocation is a
temporary object, i.e. it contains request-specific information in
addition to the static interceptor chain.
/Rickard
--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic
Got blog? I do. http://dreambean.com
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork Interceptors
Hani Suleiman wrote: Sure, however, please do keep in mind that many people do choose to use EJB's for the tx stuff. Session beans really are great for that kind of thing. I realise that you and others have much against EJBs, and that's fair enough, but I was just voicing the sentiment that I don't want xwork to become a framework that aims to replace EJBs. For those who want to use EJB's to do the tx demaraction, you'd simply remove the tx interceptor. /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork Interceptors
Typo. Rickard Öberg wrote: When configuring actions you don't typically specify individual actions, ...individual interceptors, --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Documentation
Joseph Ottinger wrote: He was probably offended by all the horrible negativity aimed at him on #java. What was said about him on #java? /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWorks under jboss 3.04
Udstrand, Gary wrote:
I am trying to deploy the webwork.war file that is part of the WebWork
1.3rc1 package under jboss 3.04. I keep getting the following
deployment error :
14:51:24,710 ERROR [URLDeploymentScanner] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@b34
mailto:org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@b34
cf404{ url=file:/C:/jboss-3.0.4/server/default/apps/webwork.war,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: Could not create deployment:
file:/C:/jboss-3.0.4/server/default/apps/webwork.war;
- nested throwable: (java.lang.NoClassDefFoundError:
org/apache/commons/logging/LogFactory)
Add Commons Logging from Jakarta.
/Rickard
--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic
Got blog? I do. http://dreambean.com
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
Chris Nokleberg wrote: I don't understand this logic. A property default is a default for form parameters, obviously it can change. If you want to fix the value for a particular mapping, you add it to actions.xml. Not quite. In an action there are two sets of parameters: initialization parameters and form parameters. From an action point of view they are equivalent however, since both are set through set* methods. If both are set the same way then there is a potential security problem if a user sets an init parameter through a form submission. I.e. a parameter which was supposed to be set through some initialization parameter is instead provided by the user. The way to get around that is to: 1) Set form parameters first and init parameters later. However, this makes it impossible to use the init parameters during the prepare() step, which is where they would be perhaps most useful. 2) Require that all init parameters are set in xwork.xml. Even if the default is ok, the value must be provided again, or else there is a security hole. Both of these two issues go away if init-parameters are provided through the context, or similar, i.e. not by calling set* methods in the action. The argument that it will hurt performance is really misleading IMHO. You're assuming a certain implementation. Sure, I'm assuming reflection. Is there any other way to do it? For one thing, since the parameters and values and destination classes are known ahead of time, you can pre-convert all of the values. etc., etc. That's certainly possible, and would remove some of the overhead. The other issues still remain. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
Chris Nokleberg wrote: Here's another way: define the roles that are allowed to access an action in xwork.xml, and create an interceptor that checks it. Then it can work exactly like how web.xml works, except it can do so for the case where an unsecure action calls a secure action too. That is a lot of extra machinery where pinning the action would work instead. A lot of extra machinery?! You declare what roles may access it in xwork.xml. One could even provide defaults at the package level. How is that a lot of extra machinery? Between skinning and support for declarative security, it seems to me the latter is wanted by more people. How do you know this? BTW, if interceptors had at least an optional URL-mapping component, you could do skinning via /* - DefaultSkinInterceptor /bar/* - BarSkinInterceptor So one should write an interceptor for a skin? Isn't that a little too much extra machinery? I find it strange how on one hand you argue against triggering functionality based on URL-matching, What argument are you talking about? AFAIK I haven't made any such argument. but on the other hand argue for that exactly through your skinning examples. Not following. What in the skinning examples is triggering functionality based on URL-matching? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
boxed wrote: I will run the action without a result a few times to start off to make sure it compiles and goes through to success and so forth. I also have some (very few) actions that don't actually have a view at all, but write directly to the servlet output stream. Yes I know it's ugly, I hate it too, but there are several cases where I am pretty much forced to do this, most notably when the output needs to be streaming in some way. There is another early development thing you can do to make initial development easier, but that includes a change to MakeIterator (my diff and source is attached) and a default mapping of success to a jsp that does: ww:iterator ww:print value=value/propertyType / ww:print value=key /br / /ww:iterator I find it very handy for initial debugging. That's a very good point. So, it seems that .action invocation is indeed something that is necessary to keep. The argument against .action invocation, then, is only with regard to declarative security. Would it be ok to declare what roles may access it in xwork.xml? (both on action and package level) One nice thing about that is that the information could be used by many different invokers, as opposed to the declarative security through web.xml option which only works for the web case. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Jason Carreira wrote: That's the argument against .action invocation with any path. If we pin actions to certain paths in the config files, as I've proposed, then this is not an issue. True, but it's more configuration to do. If it can be avoided that'd be nice. One nice thing about that is that the information could be used by many different invokers, as opposed to the declarative security through web.xml option which only works for the web case. Then you have to synchronize your roles in web.xml with the roles in xwork.xml. Plus, your servlet container can't automatically determine that you aren't logged in when you try to access a secured area and pop up the log-in prompt or load the log-in form. No, but the controller servlet can, I think. If the execution interceptor returns LOGIN, then the controller should be able to return headers that correspond to showing the log-in prompt, or one could simply have a view mapped to LOGIN that returns those headers. Or am I missing something? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
Jason Carreira wrote: Creating an extra interceptor to re-create J2EE declarative security is at least some extra machinery compared to just using what is there. I'm not saying that it's bad, in fact I kind of like the idea of restricting which roles can run packages of actions, but I would prefer to add that IN ADDITION to being able to pin packages to certain URL paths to enable the use of J2EE declarative security and make it optional. It's sounding to me like we really need 2 configuration files here: 1) xwork.xml : the standard xwork configuration which applies to all Dispatcher types. This would include package and action configuration 2) xwork-web.xml : configures web specific configurations, such as URL paths to pin packages, and view mappings The problem with that is keeping them in sync. I'd prefer using one file with namespaces instead. The reason I would say to put the view mappings in the xwork-web.xml is because you might want to use the same set of actions for web and Swing based apps, and you'd want to have different view mappings. Interesting point. How many people would use it though? How realistic is that? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Jason Carreira wrote: As opposed to the extra configuration to assign roles to packages and coordinate them with the roles in web.xml? I really don't like the idea of putting security information into xwork. If we pinned packages to URL paths, and protected the paths using J2EE declarative security, you've only got security information in one place, and it can be changed at deploy time (and even at run time, depending on your servlet container). Good point. I agree with that. But, there's still a need to add roles to xwork.xml I think, for the cases where the actions are invoked by other actions, or by some dispatcher other then a servlet controller. No, but the controller servlet can, I think. If the execution interceptor returns LOGIN, then the controller should be able to return headers that correspond to showing the log-in prompt, or one could simply have a view mapped to LOGIN that returns those headers. Or am I missing something? Can this be done? I'm not sure... I think this would require container-specific code for each container we support. Isn't just a case of returning standard HTTP headers? (for the prompt I mean). Also, what should happen if an action is invoked through an include and is not allowed access to. This is by far the most common case I have anyway (I don't have ANY other case). How would that work? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
Mike Cannon-Brookes wrote: I have _never_ needed to use the fact that actions can move paths, and I would hasten to guess that 95% of WebWork users don't care either? That might be so, yes. Leave the option open to do both, and we'll satisfy the security problems (by pinning paths). Make the path's optional then. Ok, that could work. PS IMHO the principle of least surprise here is that actions are NOT available anywhere. Maybe, maybe not. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
Mike Cannon-Brookes wrote: Hrm - no, this is thinking the wrong way mate :) If webwork defined paths, security would work perfectly right? So why not have webwork only 'work' if the path is correct (and defined)? Ie /admin/foo.action would execute foo, but /bar/admin/foo.action would execute nothing. Then the action would be pinned to that particular path, and skinning wouldn't work. That way you keep .action, AND your security works fine? Here's another way: define the roles that are allowed to access an action in xwork.xml, and create an interceptor that checks it. Then it can work exactly like how web.xml works, except it can do so for the case where an unsecure action calls a secure action too. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Re: Action invocation
Matt Ho wrote: I look at it this way. There are a couple accepted ways of implementing declarative security: 1. Securing based on path (Servlets for example) 2. Securing based on authenticated role (EJBs for example) There are of course proprietary implementations. Ideally, I would love XWork to support 1 and 2 orthogonally. I can understand forcing developers to rely on approach 1 as it's a common web practice, but I can't agree with forcing developers to use approach 2 only. snip This would essentially mean that XWork would have to support these two invocation types: /action/bar /foo/bar.action The first case would work well with path based security and roles, and the other would have no choice but to use roles. However, feature-wise the second case supports skinning. And then there's the third case which also supports path based security: /foo/xyzzy.jsp (which invokes bar action) Maybe it's possible to support all three. Question is: is it better to support as many options as possible, or is it better to have one way to do things? I suppose it's a tradeoff between flexibility and complexity. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
Heng Sin Low wrote: May be don't use reflection then and delegate this to the action itself. For e.g, this can be implemented by adding an init method to the Action interface that take a map as parameter. This would also allow us to differentiate between init parameter ( usually for configuration purpose ) and runtime parameter ( usually use input ). That would work just fine. You could do this in the prepare() step. Making a baseclass that has an implementation that does BeanUtil.copy(Map, this); would do the trick. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Jason Carreira wrote: As opposed to what? This is a model-2 MVC framework. It uses a controller servlet as its entry point. Using a controller servlet that intercepts all requests but only deals with some of the requests is going to be unnecessary overhead. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Jason Carreira wrote: Maybe, but is it an acceptable level of complexity for the benefits (simplictiy, security, etc) it provides? For instance, I would like to have all of my JSP pages under WEB-INF, so they can only be used from the servlet, rather than being accessed directly, which would most likely cause them to break, since the context hasn't been set up for them. I don't think that's even theoretically possible. Velocity would work, of course, but I don't think JSP's would. Setting up a security constraint so that noone could access *.jsp would do the trick though. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
matt baldree wrote: Personally, I like these ideas. I think this design would lead people to cleaner solutions. I think it is time to make some decisions. I think Rickard should architect XWork. It would then be up to him to assign/delegate work on different modules, etc. I'm not convinced the current direction will lead to the best outcome. Rickard has established himself in past frameworks, application servers and his new portal product to earn the right to architect XWork. Besides, he mainly wrote WW. I may be wrong, but I don't remember an e-mail asking if he wanted to architect XWork or what role he wanted to play. I think this is a mistake. I think we should at least offer him the opportunity to architect XWork. I think his ideas have solidified and he is ready to right some code :). So, any dissenters? I'm not interested in getting XWork out the door quickly but when it does come out, I want it to be GREAT. No dissenters then? :-) I must admit that at first I was reluctant to the idea, since I already have so many irons in the fire, with the portal product and AOP framework coming along. However, since XWork could borrow so much from the AOP stuff, it's really not that much work, at least for the core (or so it seems). We (my company) are also greatly dependent on XWork being as good as it can be, so that's a huge motivational factor here. I would hence gladly take on this role, at least when it comes to shaping the core of it. Once the dust settles somewhat, and there will be a lot of dust initially, I think there will be great opportunities for others to do major contributions to it, especially when it comes to creating standard interceptors that can be shipped with the framework. Alternative dispatchers is also a very important part. So, if everyone is ok with me as (initially) main architect, I'll get to it. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML
Mike Cannon-Brookes wrote: Copmments: - interceptor-ref name= is ugly XML! Why not just interceptor ref= / ? It's obvious that the name= attribute refers to the name of an interceptor from the tag name Because you'd then mix referring to an interceptor and defining one. Take a look again. If you can think of a better name I'm all for it, but there do need to be two. - is there a global package? No, that's why there's the depends thing, which usually includes standard which in a sense is the global package. - how are parameterised actions handled? (one of the other main xwork goals?) I didn't know that was a goal. The implementation that is currently in CVS sets these parameters on each request, which is a lot of reflection. It seemed too heavy to me. Isn't it better to have configuration be handled in a traditional way? (i.e. by calling some config API) Remember that actions are going to be instantiated ALL THE TIME. Using the Preferences API might be an option here. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Jason Carreira wrote: Some goals I would hope for: * declarative security friendly URLs and the ability to protect your actions from being called. See the Action invocation post. .action URL's should go away with that. * multiple configuration files, to improve multi-user version control concurrency See the Action configuration XML, and particularly the package idea. With XML entities you're there. - In the current (proprietary) framework we use, this is done by having one main configuration file which maps certain paths to certain config files. These sub config files define the request handlers (like actions) and response handlers (like views). The nice thing about this is the way chaining is handled. Below a certain path, which is mapped to a sub-config file, every path segment is treated as a reference to a handler. So, for instance, if we have a sub-section with a separate config file mapped to /foo, this url: /foo/handler1/handler2/handler3 Would look up and invoke handler1, then handler2, then handler3 in that order, and return the response handler (view) associated with the final request handler (action), unless an error is encountered. Which is bad because you're displaying the guts of your application to the user. URL's of that kind will likely be shortlived. No good. This allows for very fine grained reusable application pieces, which can be put together dynamically by creating a URL. You'll get the same with actions calling actions (easy with the new API) and action interceptors. Except it's all under the covers. Unfortunately, the current framework doesn't have the concept of the value stack, and does everything by binding beans into the request. Handlers don't have properties like Actions, but are more stateless and just use the request parameters directly. Ok, I see. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
