RE: [OS-webwork] Ognl status
We should also check out http://jbeans.org/ for this stuff... It looks pretty cool. -Original Message- From: Patrick Lightbody [mailto:plightbo;cisco.com] Sent: Thursday, October 31, 2002 1:53 PM To: [EMAIL PROTECTED] Cc: Drew Davidson Subject: Re: [OS-webwork] Ognl status Followup: Drew Davidson pointed out that precompiling the parse trees would speed things up a TON, which it did: Total time (OGNL): 2213 Total time (OGNL compiled): 100 Total time (WebWork BeanUtil): 80 Total time (Commons-BeanUtils): 111 You can run these tests yourself by checking out sandbox and running ant from within the xwork directory. Ognl will allow us to write TypeConverters for each bean and/or property, but it doesn't have a way to convert data back to a desired form (String in our case, but since this is XWork, we'll want to support any type of conversion). -Pat - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 4:44 PM Subject: [OS-webwork] Ognl status OK, I was playing with Ognl today and performance became a problem. Below is my post to ognl-interest, I'll keep everyone posted. In the meantime, maybe ditching PropertyEditors but coming up with our own (FAST) BeanUtil implementation that doesn't use PropertyEditors would be best. It shouldn't need to be very complex. The main things we need are: - complete data conversion for both setting and getting data - ability to write our own data converters for each webwork action (not class) - Uh oh... I may have hit a major roadblock in trying to switch to using Ognl in WebWork: it appears to be VERY slow. I ran a simple test, setting 7 different attribute types (some of which involve type conversion), repeating 1000 times: Total time (OGNL): 2463ms Total time (BeanUtil): 91ms BeanUtil is a WebWork utility method that uses the JavaBeans APIs (PropertyEditor, etc). Any thoughts on this? I'm using the optimized binary under JDK 1.4.1. --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Validation in xwork (Ognl?)
When we talk about BeanUtil, that's a webwork class, right? I'm wondering because someone (James Strachan maybe?) on their blog suggested using commons beanutil... Just another thought. -Original Message- From: Patrick Lightbody [mailto:plightbo;cisco.com] Sent: Friday, November 01, 2002 3:29 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Validation in xwork (Ognl?) Yup, so we can either report the error or silently ignore it -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 01, 2002 10:59 AM Subject: RE: [OS-webwork] Validation in xwork (Ognl?) What if it fails to convert the value? Will that throw an exception? -Original Message- From: Patrick Lightbody [mailto:plightbo;cisco.com] Sent: Friday, November 01, 2002 11:15 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Validation in xwork (Ognl?) Ognl won't help with validation (maybe we can look at FormProc for something like that), but it will do all levels of type conversion you require. That includes global level, as well as bean level, and even property level. -Pat - Original Message - From: Dick Zetterberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 01, 2002 3:14 AM Subject: Re: [OS-webwork] Validation in xwork (Ognl?) Hi there, When implementing the new BeanUtil replacement it would be good if it could allow you to also specify parse formats on a global (static) level as well. This is possible with the current implementation by registering my own PropertyEditors with the PropertyEditorManager class. I use this today in order to override several of Webworks property editors for example DateEditor and different number editors. It is good because I can then: - Use one standard dateeditor throughout my application. That editor supports the different date formats that my customer wants to allow. The dateformat does not necessary have to follow a standard but can be any format the customer prefers. - Have localised/customised error messages generated from my property editors, for example when input in a date or number field is not valid (not parseable). - I do not have to clutter my code by creating alot of BeanInfo classes, unless I really need it. So it would be nice if the new implementation would allow something similar as well. Best regards, Dick Zetterberg [EMAIL PROTECTED] - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 1:44 AM Subject: [OS-webwork] Ognl status In the meantime, maybe ditching PropertyEditors but coming up with our own (FAST) BeanUtil implementation that doesn't use PropertyEditors would be best. It shouldn't need to be very complex. The main things we need are: - complete data conversion for both setting and getting data - ability to write our own data converters for each webwork action (not class) --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing
RE: [OS-webwork] Webwork Security Requirements
Or we could have the webwork.action.packages property set the root packages to search from, so that if you have an action foo.bar.Foo1, and webwork.action.packages=foo, then a url like http://example.com/bar/Foo1.action would look for bar.Foo1, then foo.bar.Foo1. In other words, use the part of the package after the set prefixes as the path to the action in the url. Alias's could be created either in the same package (alias=foo1) or in a different package (alias=/bar2/foo1). Then the JSP's could be found the same way they are now, based on the path (in this case looking in /bar for JSP views). This would allow you to know what paths your actions are going to be executed under, so you can secure them. Jason -Original Message- From: Maurice C. Parker [mailto:maurice;vineyardenterprise.com] Sent: Saturday, November 02, 2002 7:29 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork Security Requirements This is Jira issue WW-53 (http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-53). I have stored the meatiest portions of this thread there so that we can remember this stuff for a future release. Here's my comment that I attached in Jira: Mike's last suggestion is much more palatable. Perhaps it could even be boiled down further. If we add concept of relative vs. absolute addressing to aliases then you wouldn't even need the new attribute. This would be using the action in the current directory: action name=Foo1 alias=foo1 view name=successfoo.jsp/view view name=inputfooform.jsp/view /action This would only allow you to access the action in it's absolute address: action name=Foo1 alias=/secure/blah/foo1 view name=successfoo.jsp/view view name=inputfooform.jsp/view /action That still leaves the issue of using actual class names as actions. Perhaps in a distant future release require that the alias be used and not allow the direct utilization of classnames. -Maurice On Friday, November 1, 2002, at 08:54 PM, Mike Cannon-Brookes wrote: Actually - I'm not sure I agree. Personally, I see the 'non path mapped' nature of WebWork actions as a flaw. I haven't found one good use for them yet. I would love to see something to stop actions from moving. I think the configuration can be made very simple - it need not be as complex as Jason listed here. action name=Foo1 alias=foo1 path=/secure/blah view name=successfoo.jsp/view view name=inputfooform.jsp/view /action Just an optional path element is all that's really needed - there could also be a 'default path' attribute at the top of the file actions - that's not really a lot of complexity for such a needed feature is it? -mike On 2/11/02 12:28 PM, Maurice C. Parker ([EMAIL PROTECTED]) penned the words: Guys, Adding more junk to the Actions.xml is a sure way fire way to make using WebWork more difficult. Do a comparison of our mapping file and Struts and you will see what I'm talking about. Jason, we've been over this repeatedly. People on the list have given you many helpful suggestions to solve your problem ranging from writing a security filter to clever web.xml configurations. You have been given a solution, it's now up to you to implement it. -Maurice On Friday, November 1, 2002, at 06:40 PM, Patrick Lightbody wrote: Jason, I agree. I believe that configuration in WebWork is one area of improvement that should be addressed in the next version. I'll jot up some ideas I've had as well as yours. Maybe if we get a Wiki set up soon we can drop stuff there. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: Opensymphony-Webwork@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Friday, November 01, 2002 1:06 PM Subject: [OS-webwork] Webwork Security Requirements I'm hoping that at the beginning of next year we'll be able to replace the web framework we're using (a proprietary one built by the consultants we brought in to get us kick-started) with Webwork. One of the drop dead requirements is going to be easy integration with J2EE declarative security. We need to be able to secure paths using deployment descriptors. Right now this is impossible in webwork because of the way paths are used: not as paths for finding actions, but as paths for finding JSPs. You can run an action from any path, if you know its name. I'm not sure of the best way to handle this in Webwork, but I would think this is a common requirement for J2EE apps, and most users won't want to have to write a security framework like Atlassian did for Jira. One possible solution would be to be able to break the config files up into multiple configuration files (good for multi-developer concurrent development anyway) and be able to assign each of these config files a path that they configure the app for. So you have Actions.xml: actions actionset name=foo path=/foo configfile=foo.xml/ actionset name
RE: [OS-webwork] Webwork Security Requirements
Let's not play at semantics here with pedantic trivialities. Replace can't support J2EE declarative security with only supports J2EE declarative security in a way which is so cumbersome as to be unusable in a non-trivial system and re-read it. The point isn't that it's impossible to use web.xml, but that it's made unusable in any practical sense because of the way the current setup works. You'd have to either: A) come up with a naming convention such as *Buyer.action to secure for buyers B) Have a separate web.xml entry for each action and each alias Of these, A) is probably the most usable option, but hardly meets the goals of separating deployment concerns for security and development concerns. B) is just ridiculous if you get over 10 actions or so, as you'll probably have at least as many aliases. This is simply NOT manageable. In our current app, we have over 400 handlers (the equivalent of an action in the framework we currently have to use). So, for the classes plus aliases, we're talking over 800 entries we'd have to have in web.xml. Is the declare each action in your web.xml separately option really the best practice you want to put out there for Webwork for securing apps using J2EE declarative security? Jason -Original Message- From: Maurice Parker [mailto:maurice.parker;pmic.com] Sent: Monday, November 04, 2002 11:22 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork Security Requirements Jason Carreira wrote: - (on viruswall) email-body was scanned and no virus found - --- - I guess that's possible, but it's not really the point. J2EE provides declarative security that works well enough, and that's what we're using. I can tell you now that if Webwork can't support J2EE declarative security, I won't be able to get it in here, and I'm sure there are a lot of other shops where that will also be the case. As a framework which supports servlet development, Webwork should support the J2EE security framework, even if it allows people to bypass it and do their own security implementations. J2EE decaritive security for a web application is taken configured via your web.xml file. To say that WebWork doesn't support this is patently false. It is very possible to use you web.xml file to restrict access to your Actions. It's your opinion that it's too inconvient to declare each action in your web.xml separately and you want to do it based on directory wildcards. We will probably add the ability only reference alias' by thier absolute pathname in a future version, but I think it highly unlikely that you will configure permissions in you actions.xml. In the meantime either configure you Actions individually in you web.xml file or write you own filter to do directory based restriction. -Maurice Security products have a vested interest in plugging into app server security frameworks, but probably won't support a webwork security framework without having to go in and code the interconnects ourselves. Jason -Original Message- From: Maurice Parker [mailto:maurice.parker;pmic.com] Sorry if I was overly harsh, but the fact that WebWork will not integrate a security framework has been discussed and decided upon more than once. Why can't you write a filter that reads a config file and checks the incoming URL to see if it is requesting an action that you would like to restrict access to? How does that solution not solve your problem? -Maurice --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Views.properties - to deprecate or not
I created a JIRA issue for multiple config files at http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-82 +1 for deprecating views.properties. Multiple configuration methods make webwork more confusing, not less -Original Message- From: James Cook [mailto:jim.cook;dot.state.oh.us] Sent: Monday, November 04, 2002 5:22 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Views.properties - to deprecate or not I don't particularly like actions.xml, and I really like the simplicity of views.properties. I find it much easier to read. I'm ambivalent about deprecating views.properties only because it is a bitch to maintain in a multi-user environment. At early stages in a project, it is a heavily edited file that CVS doesn't always play well with. The upside of actions.xml is the ability to separate the file out into multiple XML documents and aggregate them in actions.cml using the XML entity format. +0 -Original Message- From: [EMAIL PROTECTED] [mailto:opensymphony-webwork-admin;lists.sourceforge.net]On Behalf Of Mike Cannon-Brookes Sent: Monday, November 04, 2002 5:00 PM To: [EMAIL PROTECTED] Subject: [OS-webwork] Views.properties - to deprecate or not Hey all, OK - let me see if I can boil this issue down to simplicity. Should we deprecate views.properties? In my view, it should be deprecated - ie it will still work, but will no longer be documented or referred to. - actions.xml is a far simpler format to read - anyone using J2EE MUST understand XML configuration files by now already - maintaining two 'default' view configuration mechanisms can only confuse new users. +1 from me. -mike --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Property tag (beating the decomposed horse)
Yeah, not like the current ever-so-transparent ww:property tag that everyone just understands without any explanation. -Original Message- From: Hani Suleiman [mailto:hani;formicary.net] Sent: Monday, November 11, 2002 7:34 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Property tag (beating the decomposed horse) Excellent! A great way of ensuring nobody is able to use webwork without first going through lots of docs. Quoting boxed [EMAIL PROTECTED]: Attached to this email I have the code for the following tags: ContextTag, FocusTag, PopTag, PushTag and PrintTag. These do what PropertyTag does today and more: ww:context id=foo value=bar/ pulls bar from the valuestack and puts it into the page context as foo. ww:focus value=foo/ww:focus moves the focus to foo within the body of the tag (push at start of tag, and pop at end of tag). ww:push value=foo/ pushes foo to the top of the valuestack. ww:pop/ pops the top value off the valuestack ww:print value=foo/ fetches foo and prints it. You will note that the code is way cleaner, that the resulting tags are more flexible and most importantly, the entire documentation for them is pretty much what I wrote above. This last point is the most important since the full page and confusing document on property tag that we have today is no user friendly. // Anders Hovmöller --- 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 --- 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: Property tag (beating the decomposed horse)
I think this type of break with the past is exactly what Xwork 2.0 SHOULD be for. Leave the property tag in there, but mark it as deprecated with links to the new, much more intuitive tags (although I don't think we need separate push and pop tags, just the ww:context). If we can't ever change anything, then how will Xwork ever improve? -Original Message- From: Maurice Parker [mailto:maurice.parker;pmic.com] Sent: Monday, November 11, 2002 1:04 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: Property tag (beating the decomposed horse) Patrick Lightbody wrote: You might not like Anders for the changes he made without asking, but this this stubbornness is pretty sickening. Patrick, this is nothing personal. This is a logistical decision. 1) Changing the behavior of the PropertyTag hurts our userbase. 2) Adding addional tags makes the PropertyTag (and the taglibs as a whole) more confusing, not less. It's not about being stubborn. It's about making decisions based on facts and analysis rather than emotionally charged debate. If you want me to change my position on this matter, you have to convince me that a change is for the greater benifit of the community. As it stands right now, I believe that the proposed change would in fact have the opposite effect. -Maurice -Pat - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 11, 2002 8:01 AM Subject: Re: [OS-webwork] Re: Property tag (beating the decomposed horse) It's a different approach I suppose. I didn't know of the TWO uses of the propertytag, let alone the 3 uses. I'm not angry or irritated at anyone because of it, in fact, I was rather delighted when I found out the other uses. I'm glad they're documented now. Most of all however, I like the fact that I was able to use propertytag without reading any docs. I like the fact that I was using the valuestack without even understanding what it is, or how and why it's working its magic. Maybe adding more tags will make that easier, it just doesn't feel that way though based on all the discussion here. Quoting Chris Miller [EMAIL PROTECTED]: Agreed. While I'm not a regular WW user these days due to circumstances beyond my control (and I use Velocity with WW rather that JSP anyway), I still try to keep abreast of WW's progress. From what I've read of this debate, one thing is readily apparent. The existing property tag is *not* intuitive. To quote an earlier comment from Mike: Well, I actually wrote the original two uses of the PropertyTag (which you are correct - is in fact 3, would you believe I didn't know about the third one? ;)) Correct me if I'm wrong but I am sure that Mike uses WW extensively, and has been doing so for quite some time. If even he didn't know all the subtleties of that tag, what chance does a newbie have? Documentation alone isn't the best solution - docs plus intuitive design is. Has anyone here ever tried to use all the various permutations of the struts html:select tag for iteration? There is a lot of documentation for that tag, and I've been using it for quite some time now. But almost without fail I still have to either cut'n'paste existing code, or refer to the documentation to get the damn thing working each and every time! I haven't looked at the replacement tags Anders has submitted so I can't comment on whether those are 'better' or not, but I would encourage everyone in this debate to think about what the taglib should look like in a perfect world, ie *without regard for what currently exists*. THAT should then become the goal for XWork 2.0. Obviously backwards compatibility is crucial, but deprecation can take care of that if need be. Chris Jason Carreira [EMAIL PROTECTED] wrote in message news:CD44D03584C7A249A3F86891B24EB8EA03FDCAB9;ehost003.intermedia.net ... Yeah, not like the current ever-so-transparent ww:property tag that everyone just understands without any explanation. -Original Message- From: Hani Suleiman [mailto:hani;formicary.net] Sent: Monday, November 11, 2002 7:34 AM Subject: Re: [OS-webwork] Property tag (beating the decomposed horse) Excellent! A great way of ensuring nobody is able to use webwork without first going through lots of docs. --- 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 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
RE: [OS-webwork] Re: Property tag (beating the decomposed horse)
The problem is that the arguments for property tag boil down to That's the way we've always done it. I mean come on, we're not 80 year old grandmothers here. We can and do cope with change on a daily basis, and this one seems like a change that would make the learning curve easier and the code base more straightforward. The property tag is a powerful thing, but perhaps TOO powerful, with too many potential side effects and usages. Better to have several tags with more focused functions which are easily documented and used. -Original Message- From: Rickard Öberg [mailto:rickard;dreambean.com] Sent: Monday, November 11, 2002 1:31 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: Property tag (beating the decomposed horse) Jason Carreira wrote: I think this type of break with the past is exactly what Xwork 2.0 SHOULD be for. Leave the property tag in there, but mark it as deprecated with links to the new, much more intuitive tags (although I don't think we need separate push and pop tags, just the ww:context). If we can't ever change anything, then how will Xwork ever improve? Change is ok. Unmotivated change is not ok. It is not about having the most votes (I personally don't really like this counting business), it's about having the best arguments. Good arguments lead to better decisions, which will be better for the community. This is what Maurice is saying, and I agree. /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 --- 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
Along this line, I've mentioned before that one of the top requirements I've got for a framework, and we're hopefully going to be switching to a new (better) framework in the next few months, is the ability to use J2EE declarative security to secure paths. This means that the way actions are invoked needs to be rethought. Currently, there's no way to keep people from executing your actions without creating a separate J2EE declarative security entry for each action (and each alias, etc). This is, IMHO, a HUGE drawback. Jason -Original Message- From: Chris Nokleberg [mailto:[EMAIL PROTECTED]] I think it would be more useful if instead of applying directly to actions, the filters/interceptors applied to paths (URLs). The paths could support wildcards, either Servlet-style or a more complete regexp style. e.g. define secure = persist, security, execute define open = standard - security map /* = open map /admin/* = secure (but probably in xml) There would need to be some thought about how to combine stacks of interceptors, path matching precedence, etc. This is probably best done in conjuction with nailing down actions to specific paths. -Chris --- 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] context and pre/post processing
Wow, I'm just reading through the posts in this list (got a little behind) and this is
AWESOME. This definitely should be done.
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 30, 2002 3:31 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] context and pre/post processing
Patrick Lightbody wrote:
In your last email you talked about changes in the context and
pre/post processing. I think I know what you are hinting at (simply
the ActionFactory and move the work in the Action implementation
itself), but maybe you can go in to more detail here? Also, how could
it be an alternative way of chaining?
As I've been working a LOT with AOP lately some of the ideas could be
easily applied here too. One of the ideas is the generic interceptor
chain, i.e. to chain a bunch of proxies together and start it by simply
invoking the first.
For example:
Action myAction = ActionFactory.getAction(foo); myAction.execute();
---
Action getAction(String name)
{
return new SecureAction(new ChainAction(new FooAction()));
}
---
public class SecureAction
extends ActionProxy
{
public SecureAction(Action nextAction)
{
this.next = nextAction;
}
public String execute()
throws Exception
{
// Do security check
// Delegate to next
return next.execute();
}
}
---
I hope the basic idea is obvious. Some chaining could be done by simply
having proxies do stuff either before or after the execute() invocation.
Having such things be proxies instead of actions separates them from
real actions as they should typically not influence the result string
(i.e. they have side-effects but don't effect the flow). Of course, just
as servlet filters *can* return immediately instead of delegating to the
next servlet, proxies can shortcut the flow here too (the SecureAction
would be one example, which would return unauthorized if the executor
is not allowed to call the action.
The ChainAction would be used to transfer parameters when a chain is
executing. Like so:
ThreadLocal previousAction = new ThreadLocal();
public String execute()
throws Exception
{
Object previous = previousAction.get();
if (previous != null)
// Copy parameters from previous to current
previousAction.set(currentTargetAction);
try
{
return next.execute();
} finally
{
if (previous != null)
previousAction.set(previous);
}
}
---
This would allow the action itself to call other actions in its
execute() method and have parameters be transferred transparently: public String
execute()
throws Exception
{
Action myAction1 = ActionFactory.getAction(foo1);
Action myAction2 = ActionFactory.getAction(foo2);
myAction1.execute();
myAction2.execute();
return SUCCESS;
}
--
Both the above actions would have secured execution (thanks to
SecureAction) and copied parameters from the parent, and with very
little work. The action can then also decide whether to ignore what they
return, or to return SUCCESS iff all actions succeed. A helper can
easily run them in parallel. Etc. There are LOTS of possibilities here,
but the main point is that the code would be very clean.
And, the old way to do augmented actions was to do a subclass and
override execute(), do stuff (e.g. security checks), then do
super.execute() which in turn could do things, and finally call
doExecute(). That is (obviously?) a rather cumbersome, static, and
generally boring way to do things, and I think using action proxy chains
would be both easier and more dynamic. Plus, they could be configured in
XML instead of specified explicitly through inheritance.
And, once you get into runtime attributes (which I have, courtesy of the
AOP framework I'm fiddling with) it gets even cooler, because then you
can configure the chain by using attributes. Like so:
/**
* @attributes
*filters=secure,chain,validation
*success=blah.vm
*error=failure.vm
*/
---
And if you feel like the above is providing too much info in code then
simply introduce pre-packaged stacks:
config
filters name=standard
filter name=secure/
filter name=chain/
filter name=validation/
/filters
/config
along with the runtime attribute definition:
/**
* @attributes
*filters=standard
*/
(BTW, I can *guarantee* you that before long we're going to see runtime
attributes being pushed into IDE's rather than having them as Javadoc,
so it's going to be really truly awesome)
and if you want to go really funky then redefine stacks like so: config
filters name=standard
filter name=mycustomfilter/
filters name=defaultstandard/
/filters
filters name=defaultstandard
filter name=secure/
filter name=chain/
filter name=validation/
/filters
/config
and without changing any code/javadoc you just changed the way all
actions that use the standard filter stack works. Pretty neat.
Have you
RE: [OS-webwork] Rethink
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Here are some that I can think of: * Try to avoid .action URL's * Allow for multiple read-actions to be on the same page (HMVC) * Allow for multiple forms to be on the same page, and be developed independently (the portal case). This essentially means that parameters need to be prefixed so that they don't clash. * Allow write-actions to be performed before a page starts rendering, but then make the result of that action available DURING rendering. * Minimize coupling to servlet environment. XWork will probably still be a framework that is used mostly for web stuff, but it must be possible to use it in a non-servlet environment too. Having multiple dispatchers from the start is a great way to ensure this. * Allow sharing of view code between different views * Make it trivial to implement Portlets (JSR 168) using XWork. This is a personal pet peeve, but I think you'll love it once the Portlet API solidifies later this year. It's a great thing I think. /Rickard Some of the lifecycle and multi-component stuff here sounds a lot like Java Server Faces. I just finished reading the two articles on JSF at onJava.com: http://www.javaworld.com/javaworld/jw-11-2002/jw-1129-jsf.html http://www.javaworld.com/javaworld/jw-12-2002/jw-1227-jsf2.html I must say, I'm underwhelmed in a lot of areas, especially with how much processing has to be done for every request and the heavy dependency on JSP and the web, but the potential for real tool support is very appealing. What are people's thoughts on supporting JSF with Webwork, perhaps with a different Dispatcher? --- 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
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 5:37 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Rethink Patrick Lightbody wrote: Great! So we can expect a finished product by Friday? :) Friday? *yawn* :-) Glad to have you on board with this. Of course, I'll be around to help in any way possible -- just gimme a holler. Will do. I'm afraid I'm gonna thrash around in the current sandbox code quite a lot. One thing though: I desperately need to know if chaining needs to be possible given the concept of interceptors. I want to see if there are easier ways to deal with the usecases where chaining is used currently. Yes, For our needs, chaining is very very helpful. More on this below... Also, I want to establish some design goals. IMHO the end result will be better with more strict requirements. Here are some that I can think of: * Try to avoid .action URL's * Allow for multiple read-actions to be on the same page (HMVC) * Allow for multiple forms to be on the same page, and be developed independently (the portal case). This essentially means that parameters need to be prefixed so that they don't clash. * Allow write-actions to be performed before a page starts rendering, but then make the result of that action available DURING rendering. * Minimize coupling to servlet environment. XWork will probably still be a framework that is used mostly for web stuff, but it must be possible to use it in a non-servlet environment too. Having multiple dispatchers from the start is a great way to ensure this. * Allow sharing of view code between different views * Make it trivial to implement Portlets (JSR 168) using XWork. This is a personal pet peeve, but I think you'll love it once the Portlet API solidifies later this year. It's a great thing I think. /Rickard Some goals I would hope for: * declarative security friendly URLs and the ability to protect your actions from being called. * multiple configuration files, to improve multi-user version control concurrency - 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. This allows for very fine grained reusable application pieces, which can be put together dynamically by creating a URL. 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. Jason --- 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]
Couldn't the Method objects found the first time through reflection for parameterizing the Action instances be cached and reused, making the reflection performance hit negligible? I've never profiled reflection to see where the biggest performance hit is, but if it's the Class and Method lookup, this could help (and be used for the Action field population, as well) -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 11:59 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action configuration XML [Commands] What is missing from this example currently is commands. Any ideas are welcome here. One option is to have the action declaration look like this: action name=fooDefault class=SimpleAction.doDefault interceptors-ref name=default/ result name=success view=bar.action/ /action i.e. suffix the class name with the method name. This means that any public method with a string result (or even void, which would default the result to SUCCESS) can be invoked. Any comments on this? I think that the ability to have parameters applied before the action is initialized is a feature needed, even if it could be slow. For the most part there will be zero params, so the slowdown isn't an issue. Commands, in my opinion, should not be part of the configuration if they aren't part of the core framework -- meaning that since ActionSupport deals with commands but Action is the only core part of the framework, commands don't deserve special treament. That was where I got the idea for having parameters that would be applied before the Action is executed. So with that said, I think commands should be configured like so: action name=fooDefault class=SimpleActiont interceptors-ref name=default/ result name=success view=bar.action/ params param name=commanddefault/param /params /action The end result is the same (since commands needed reflection anyway). The only difference is that there is an option for even more flexability, but no one has to use it if they are worried about reflection (though since every single HTTP request parameter is also reflected, I see no big problem by adding this as well). -Pat --- 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 --- 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
You can put a declarative security line for */deleteUser.action, can't you? Not to say that this is good, in fact it's horrible, but at least it COULD work. -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: Action invocation Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdas dasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /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 --- 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
You make a base package with the 3, then 2 other packages which extend the base package and add the actions for each role to its respective package. -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 2:26 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation Jason Carreira wrote: I'm thinking we could use your idea of packages, and map packages to certain paths, then you could easily secure by package. What if you have 10 actions in a package, and 3 are public, 4 are allowed by one role, and 6 are allowed by another (i.e. there's an overlap). How do you do that with secure by package? /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 --- 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
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] That is how I have implemented the filter currently: if there's an action for the JSP, then execute it, otherwise do nothing (i.e. run JSP as usual). /Rickard I don't like the idea of exposing the view we're mapping to. What If I want to change the view that is mapped from the action? I think it would be better to have: http://somehost.com/myPackage/myAction So you don't have to have any kind of extension... Just logical URLs that make sense. Jason --- 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
Yes, this is assuming that your servlet dispatcher is mapped to /*.. If you're building your whole app with xwork, this is an ok assumption. You could have it under something else, like /xwork, if you wanted. The ServletDispatcher would use the rest of the path info (/myPackage/myAction) to find the package (myPackage) and then find the action mapping (for myAction). -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 3:47 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation Jason Carreira wrote: I don't like the idea of exposing the view we're mapping to. What If I want to change the view that is mapped from the action? I think it would be better to have: http://somehost.com/myPackage/myAction So you don't have to have any kind of extension... Just logical URLs that make sense. What would trigger the action filter/servlet? /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 --- 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
As opposed to what? This is a model-2 MVC framework. It uses a controller servlet as its entry point. -Original Message- From: Robert Nicholson [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 5:59 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation It would seem some folks are assuming that all requests will go via the servlet and therefore if myAction is deemed to be an action then it will be executed. This obviously has a high overhead factor. On Thursday, January 2, 2003, at 08:47 PM, Rickard Öberg wrote: Jason Carreira wrote: I don't like the idea of exposing the view we're mapping to. What If I want to change the view that is mapped from the action? I think it would be better to have: http://somehost.com/myPackage/myAction So you don't have to have any kind of extension... Just logical URLs that make sense. What would trigger the action filter/servlet? /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 --- 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 --- 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
I'm pretty sure I read an article about doing it... Anybody else have any experience doing this? -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 10:16 AM To: [EMAIL PROTECTED] Subject: 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 --- 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
FW: [OS-webwork] Re: Re: Action invocation
Did anyone have any thoughts on this skin / package config stuff I sent this morning? -Original Message- From: Jason Carreira Sent: Friday, January 03, 2003 9:47 AM To: '[EMAIL PROTECTED]' Subject: RE: [OS-webwork] Re: Re: Action invocation -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 6:06 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: Re: Action invocation Chris Miller wrote: What would happen if the skins had to be explicitly defined in the configuration, or if none were defined then XWork would default to pinned paths? Then there would be an outcry of too much to configure.. waaah. :-) What if we just had the skins defined either at a global level, or at a package by package level (or even down to the action, if needed). Sorry, I've forgotten the exact details of Rickard's XML config stuff skins skin name=default root=/WEB-INF/jsp/default/ skin name=neon root=/WEB-INF/jsp/neon/ /skins package name=default classes=com.example.actions skin=default view type=ERROR/WEB-INF/jsp/error.jsp/view action name=common class=CommonAction view type=INPUTcommon.jsp/view view type=SUCCESScommon.jsp/view /action /package package name=foo classes=com.example.actions.foo extends=default path=/foo action name=foo1 class=FooOne view type=INPUTfoo1.jsp/view view type=SUCCESSfoo1.jsp/view /action /package package name=neonfoo extends=foo path=/neon/ This shows a couple of ideas: 1) The skins are defined at the top and define the base path to look under for pages 2) Packages have paths which define the URL path under the webapp for which they apply (to make path based security easy) 3) Packages with no path are not directly executable, so you can have your default package which cannot be accessed, and only holds common config information for its children 4) Packages inherit from their parent packages, so that all 3 packages have a common action defined 5) The neon package has both common and foo1 actions defined, and needs to have JSPs under /WEB-INF/jsp/neon for error.jsp, common.jsp, and foo1.jsp --- 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
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] 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) 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. 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. Jason --- 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
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] 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? 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 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. Jason --- 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
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] The problem with that is keeping them in sync. I'd prefer using one file with namespaces instead. I'm planning on using Xdoclet, I don't know about you. :-) --- 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] So long
Well, I certainly hope you reconsider. Xwork could certainly use your talents. I don't really think the ideas presented here are that far apart. Perhaps you could list what you see as the biggest requirements for your portlet app from Xwork, and we can see where the gaps lie. Jason -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 04, 2003 10:57 AM To: WebWork Subject: [OS-webwork] So long All, After having read all comments on the changes I wanted to make, as well as some not-so-nice comments by people on #java (boxed and Joe Ottinger for example), I've decided that it's not a good idea for me to be architecting XWork. It seems I and most of you have rather different requirements for what such a framework should contain, and how it would work. Thus, trying to make a framework which fits both worlds is just too much pain. So, I'm resigning from the position as architect of XWork. If noone else is interested I'd suggest that Pat resume his work. I'll probably start working on another framework instead, but which would be totally geared towards the upcoming Portlet API. AFAICT portlets is going to become a very nice way to build web components and pluggable web apps in the coming year, so I see little reason for me to work on a non-portlet approach. Good luck! regards, 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 --- 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
Ah well... personally I don't really care, since I have never used declarative security and will never use it either. You might change your tune when you're asked to integrate your CMS product with an existing security framework... Especially if it's a large user base and they've gone with an enterprise security infrastructure based on something like Netegrity Siteminder. Those products will have integration with large app servers, etc., but you'd have to develop your own plugins. Using standard security frameworks allows you to more easily integrate with a whole security system. This is why I've pushed for us to stay with standard J2EE security rather than developing our own user / role framework. Jason --- 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] XWork Interceptors
As for intercepting transactions, I would say have a key that is set in the context which tells the after() part of the Tx interceptor what to do. Kind of like setting rollbackOnly on a UserTransaction. Assume that the transaction should be committed unless an exception is caught or rollbackOnly is set on the ActionContext. -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 10:24 AM To: os-ww Subject: [OS-webwork] XWork Interceptors So anyway, I'm just going to disregard the Documentation thread and start a thread that is actually useful :) (Though, Ken, we're still hoping your willing to do some Doc work!) 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? Also, Interceptors would fit in to the GenericDispatcher area. I think that they would replace ActionFactoryProxies entirely, correct? 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? -Pat --- 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 --- 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
Well, for a different example, how about setting up a Hibernate Session and then closing it on the way out? Then Hibernate can manage your transactions. -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 10:35 AM To: [EMAIL PROTECTED]; Patrick Lightbody Cc: os-ww Subject: Re: [OS-webwork] XWork Interceptors I have to say, I really do think that adding tx on this level is a bad idea. For one thing, webwork is NOT a tx system, whatever it talks to should provide whatever tx support you require. Reinventing the wheel by handling the tx on this level seemsa waste of effort (vendors have already spent years getting their tx impls to work very nicely). To my mind (I'll admit I didnt read all the previous emails about interceptors in great detail, so I might be repeating old/known/wrong stuff), interceptors are pretty much like filters. An interceptor would choose what to intercept, then have access to context and whatnot to adds its own stuff. It can choose to then keep passing the request, or bail out. Similarly, an interceptor can be applied post-action. Quoting Patrick Lightbody [EMAIL PROTECTED]: So anyway, I'm just going to disregard the Documentation thread and start a thread that is actually useful :) (Though, Ken, we're still hoping your willing to do some Doc work!) 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? Also, Interceptors would fit in to the GenericDispatcher area. I think that they would replace ActionFactoryProxies entirely, correct? 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? -Pat --- 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 --- 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 --- 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
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()).ge
tTypeConverter();
OgnlUtil.setProperties(ActionContext.getContext().getParameters(),
invocation.getAction(), typeConverter);
return invocation.next();
}
}
I'm not so sure about this case. In this case, you need to map the
interceptor to your classes, rather than it being the default. Yes, we
can work on packages and interceptor defaults, but the fact remains that
if you leave one line out of your xwork.xml, all of a sudden request
params don't get set on your actions which equals lots of confused
emails to the list.
---
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
I agree here. I like having the safety of knowing that if we decide to re-architect the presentation layer of our app (and we're looking at re-doing some of it with Thinlets), then there could be a framework there to let us do that... -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 11, 2003 11:10 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] XWork: core concepts I would highly recommend against going down this path. Otherwise, just focus on WebWork 1.4. Plus, even if all our actions are used for the web, remember that by making the core framework non-web-based, you also make testing much easier as well. -Pat - Original Message - From: matt baldree [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 5:34 AM Subject: Re: [OS-webwork] XWork: core concepts +1 - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 6:29 AM Subject: Re: [OS-webwork] XWork: core concepts On Saturday, January 11, 2003, at 03:29 AM, Rickard Öberg wrote: 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) I don't use any of those and am quite unlikely to eve ruse them. Reason: I use app clients. webwork/xwork to me is ALL about being web only, and its role is to handle view related stuff and marshall things for the backend. EJBs do all the actual 'meat'. Appclients for me provide a far greater degree of separation, as if I went with the webwork framework for my swing clients, due to the possibility of wildly different UI's, I suspect I'd end up having to add a whole bunch of special chains/collections of actions for the appclients to use. I strongly suspect that swing/non web usage makes up 1% or less of all the users. Lets not make this unpleasant for the silent majority just to win a marketing line or two or some coolness points by saying 'we have nothing to do with the web!'. xwork should be targeted at the web, and should make the life of web developers a lot more pleasant and fun. It should NOT enforce that though and should work well outside of it, but web people should definitely be the main target audience. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- 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 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- 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
I'm not sure I see the disconnect here. What's so different about Xwork? Views can still be JSP / Velocity / XSLT which generates HTML. It's still a great framework for web app development. If the ThreadLocal thing is the only sticking point, then lets talk about that. I'm personally for the changes Patrick made, as I think it makes the framework much more flexible. For instance, you could queue actions using JMS with all of the context (the ActionInvocation, or whatever Patrick has named it) carried along. However, that said, if it's such a big deal that people are talking about forking the code base and splitting Xwork and Webwork, then I think we should roll it back and discuss. -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Reflection I think there are two directions here and I don't see any easy resolution at this stage. So, yes I think two projects make sense. My next question is Is there room for these two projects at OS? Does it make sense or will it be a distraction since they do have overlap? Should WW move back out on its own? -Matt - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 7:24 AM Subject: 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 =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- 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 --- 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
It's not that it's difficult to keep it Swing compatible and it's not a choice of loosing features. The new features, the biggest one being Interceptors, IMHO, are in no way involved in this. This is really a question of cleaning up some (IMO) ugliness in the original code that was put in to keep backward compatibility. Actions were originally spec'd to have a method, execute(), with no parameters. That was back when we had ServletAware, etc., and the context information would be made available to the Action before it was executed. When it was decided to get rid of these interfaces, to decouple Webwork from Servlets, it was decided to move to ActionContext, which uses a ThreadLocal to save the execution context for the Action in a way that is easily available, local to the current execution, and doesn't have to be passed as a parameter. Unfortunately, if you want Action preparation, execution, etc, to be able to be run from multiple threads, ThreadLocals are, at the very least, very difficult to use, and, at the worst, unworkable. Is this a huge deal? No, not really. Would it be nice to be able to do this the right way? Yes. But, if it is a requirement that old Actions not have to change their method signature and be able to get the params from the ActionContext ThreadLocal, then this is a limitation that can be documented and worked around. Just my $0.02 Jason -Original Message- From: Robert Carlens [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 1:11 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Reflection I have been following this list for quite some time with great interest. I really like all the new ideas for XWork. I think it would be sad not to see those ideas become implemented only because it would be difficult to keep it Swing compatible. If an alternative is to break Webwork and XWork into two different projects I think it would be unfortunate, however, considering the alternative (miss out on all the great new functionality) I still think it would be worth it, but that's just my thinking for all it's worth. /Robert -Original Message- From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 12 Jan 2003 14:24:26 +0100 Subject: 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 omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM
RE: [OS-webwork] Reflection
Can you explain? I'd like to know. -Original Message- From: Heng Sin Low [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 8:48 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Reflection The multiple thread thing is simple/trivial to solve using AOP. I'm not sure this would cause any performance issue though. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Reflection
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Why is it difficult? Whenever there's a thread disconnect you just get the state, and then re-set it when you want to restart the execution. What exactly is the difficulty? I'm not as familiar with the non-common usages of ThreadLocals as you are. I understand how they can be gotten and set, but how do you get them from another thread to set into this thread, when a new thread is kicked off (or a new thread, like the event handler in Swing, is suddenly being used)? --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Scope for 1.4
So, after we finally push 1.3 out the door, we're going to need an idea of what should be in 1.4. My suggestion would be refactor the GenericDispatcher and ActionFactory to put the Interceptor code in, and have a relatively quick release after 1.3 with that stuff added (and any bug fixes). Thoughts? Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: A plea - WAS Re: [OS-webwork] Reflection
Funny, we were just talking about this here today. We've got a simple command pattern implementation for running batch jobs now, and I was talking about how, if we moved to Webwork, we could make a MessageDrivenDispatcher (an MDB) that would run jobs asynchronously... -Original Message- From: Peter Kelley [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 5:28 PM To: [EMAIL PROTECTED] Subject: Re: A plea - WAS Re: [OS-webwork] Reflection After reading this for a while I cannot recall who asked for swing clients in the first place. I don't think they were ever a requirement. In terms of non web stuff I would like to see something that could talk to JMS in an asynchronous manner but I'm not going to lose sleep if it's outside the scope. We have developed a somewhat webwork like Message EJB implementation which will do fine for the forseeable future. On Mon, 2003-01-13 at 20:20, Philipp Meier wrote: I think we should keep swing clients out of the discussion at the moment. Although I do not have very much experience with swing clients, the design patterns differ from the request-response pattern of web or rpc clients. So I see no problem in pushing the development slightly away from the web to a more generic request-response pattern. -billy. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi- bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Hidden token
Hi all, In our evaluation of Struts vs. Webwork, I was asked about the ability to do hidden tokens on WW built forms and URLs. Struts apparently, in their form and link tags, have the possibility of (optionally) adding a hidden token (either as a hidden form field, or through URL rewriting), which can keep the user from clicking twice and executing your action twice. I don't remember seeing anything like this in WW, although my take is that this would be easy enough to add to the URLTag. Also, is there a ui:form tag? I'm not sure what all got added. I remember Rickard was talking about something to prevent 2 submits, but I'm not sure what it was... Thoughts? Would this be something good to add (given that it would be optional and not break anybodies existing code)? Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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
Right, I just want to keep it from processing twice... Hit it twice if you want. -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 4:30 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Hidden token This doesn't prevent them from clicking 2x but prevents them from hitting back button and resubmitting. If you want to prevent clicking button 2x, you have to use javascript. - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 3:04 PM Subject: [OS-webwork] Hidden token Hi all, In our evaluation of Struts vs. Webwork, I was asked about the ability to do hidden tokens on WW built forms and URLs. Struts apparently, in their form and link tags, have the possibility of (optionally) adding a hidden token (either as a hidden form field, or through URL rewriting), which can keep the user from clicking twice and executing your action twice. I don't remember seeing anything like this in WW, although my take is that this would be easy enough to add to the URLTag. Also, is there a ui:form tag? I'm not sure what all got added. I remember Rickard was talking about something to prevent 2 submits, but I'm not sure what it was... Thoughts? Would this be something good to add (given that it would be optional and not break anybodies existing code)? Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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 --- 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 --- 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
Just thought this out some more. Here's how it could work: the hidden token is set in the session when the form is shown, then added to the form as a hidden field. When the action processes the form, you look for the token and make sure it's the same as the last one you put in the session before you process. Jason -Original Message- From: Jason Carreira Sent: Wednesday, January 15, 2003 4:04 PM To: [EMAIL PROTECTED] Subject: [OS-webwork] Hidden token Hi all, In our evaluation of Struts vs. Webwork, I was asked about the ability to do hidden tokens on WW built forms and URLs. Struts apparently, in their form and link tags, have the possibility of (optionally) adding a hidden token (either as a hidden form field, or through URL rewriting), which can keep the user from clicking twice and executing your action twice. I don't remember seeing anything like this in WW, although my take is that this would be easy enough to add to the URLTag. Also, is there a ui:form tag? I'm not sure what all got added. I remember Rickard was talking about something to prevent 2 submits, but I'm not sure what it was... Thoughts? Would this be something good to add (given that it would be optional and not break anybodies existing code)? Jason -- Jason Carreira Technical Architect, Notiva Corp. phone:585.240.2793 fax:585.272.8118 email:[EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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 --- 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
In WW? Is this already there? Or did you do this in your project? -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 6:05 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Hidden token yes, this is how we did it. - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 3:48 PM Subject: RE: [OS-webwork] Hidden token Just thought this out some more. Here's how it could work: the hidden token is set in the session when the form is shown, then added to the form as a hidden field. When the action processes the form, you look for the token and make sure it's the same as the last one you put in the session before you process. Jason -Original Message- From: Jason Carreira Sent: Wednesday, January 15, 2003 4:04 PM To: [EMAIL PROTECTED] Subject: [OS-webwork] Hidden token Hi all, In our evaluation of Struts vs. Webwork, I was asked about the ability to do hidden tokens on WW built forms and URLs. Struts apparently, in their form and link tags, have the possibility of (optionally) adding a hidden token (either as a hidden form field, or through URL rewriting), which can keep the user from clicking twice and executing your action twice. I don't remember seeing anything like this in WW, although my take is that this would be easy enough to add to the URLTag. Also, is there a ui:form tag? I'm not sure what all got added. I remember Rickard was talking about something to prevent 2 submits, but I'm not sure what it was... Thoughts? Would this be something good to add (given that it would be optional and not break anybodies existing code)? Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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 --- 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 --- 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 --- 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
Did you modify the ui tags to automatically do this? I also added a Jira issue for this -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 7:44 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Hidden token my project. i can add it when i get a chance. - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 6:10 PM Subject: RE: [OS-webwork] Hidden token In WW? Is this already there? Or did you do this in your project? -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 6:05 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Hidden token yes, this is how we did it. - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 3:48 PM Subject: RE: [OS-webwork] Hidden token Just thought this out some more. Here's how it could work: the hidden token is set in the session when the form is shown, then added to the form as a hidden field. When the action processes the form, you look for the token and make sure it's the same as the last one you put in the session before you process. Jason -Original Message- From: Jason Carreira Sent: Wednesday, January 15, 2003 4:04 PM To: [EMAIL PROTECTED] Subject: [OS-webwork] Hidden token Hi all, In our evaluation of Struts vs. Webwork, I was asked about the ability to do hidden tokens on WW built forms and URLs. Struts apparently, in their form and link tags, have the possibility of (optionally) adding a hidden token (either as a hidden form field, or through URL rewriting), which can keep the user from clicking twice and executing your action twice. I don't remember seeing anything like this in WW, although my take is that this would be easy enough to add to the URLTag. Also, is there a ui:form tag? I'm not sure what all got added. I remember Rickard was talking about something to prevent 2 submits, but I'm not sure what it was... Thoughts? Would this be something good to add (given that it would be optional and not break anybodies existing code)? Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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 --- 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 --- 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 --- 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 --- 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
RE: [OS-webwork] Hidden token
I wouldn't want to put this on the wiki before it's decided to do it... I put it in Jira instead -Original Message- From: Joseph Ottinger [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 8:42 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Hidden token Actually... in case you guys don't know it, you have this cool wiki at http://www.opensymphony.com:8668/space/start where this sort of concept would be really cool to detail. Online docs, you might say, with ongoing practices and resources for opensymphony users. There's also the formtags library on opensymphony, which HAS a form tag that wouldn't be difficult (at ALL) to modify to include behaviour like this. For that matter, formtags even has access to the webwork valuestack already, so it can be a drop-in solution if you so desire. (It doesn't use templates; if you recall, that was on the drawing board before the drawing board collapsed under it.) On Wed, 15 Jan 2003, Jason Carreira wrote: I was thinking we could, like Struts does, make it an option to have a ui:form (which we don't have right now) and ww:url tag add this hidden token, through a hidden input field or URL rewriting, respectively. -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 8:23 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Hidden token no just added a hidden input field. this really isn't a ui tag. - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 6:40 PM Subject: RE: [OS-webwork] Hidden token Did you modify the ui tags to automatically do this? I also added a Jira issue for this -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 7:44 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Hidden token my project. i can add it when i get a chance. - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 6:10 PM Subject: RE: [OS-webwork] Hidden token In WW? Is this already there? Or did you do this in your project? -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 6:05 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Hidden token yes, this is how we did it. - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 3:48 PM Subject: RE: [OS-webwork] Hidden token Just thought this out some more. Here's how it could work: the hidden token is set in the session when the form is shown, then added to the form as a hidden field. When the action processes the form, you look for the token and make sure it's the same as the last one you put in the session before you process. Jason -Original Message- From: Jason Carreira Sent: Wednesday, January 15, 2003 4:04 PM To: [EMAIL PROTECTED] Subject: [OS-webwork] Hidden token Hi all, In our evaluation of Struts vs. Webwork, I was asked about the ability to do hidden tokens on WW built forms and URLs. Struts apparently, in their form and link tags, have the possibility of (optionally) adding a hidden token (either as a hidden form field, or through URL rewriting), which can keep the user from clicking twice and executing your action twice. I don't remember seeing anything like this in WW, although my take is that this would be easy enough to add to the URLTag. Also, is there a ui:form tag? I'm not sure what all got added. I remember Rickard was talking about something to prevent 2 submits, but I'm not sure what it was... Thoughts? Would this be something good to add (given that it would be optional and not break anybodies existing code)? Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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
[OS-webwork] Woohoo!
So we had our Webwork vs. Struts talk today, and I was able to convince people here that there was sufficiently enough better about WW to make us use it instead of Struts, even though Struts is the standard, of sorts! Cool. Off to catch a plane home... -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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] Woohoo!
Title: Message Well, it really came down to usability issues. We looked at things like having to have separate FormBeans tied to the Actions 1-1 (because you have to cast to the expected FormBean subclass). Also,we looked at some sample code for Struts and Webwork (we looked at code for Chiki, a Wiki implemented with Struts, and Jira. Thanks Mike for having clean code!). It was very apparent that you had to do a lot of busy work to initialize things and do the setup that the framework should have done for you in Struts, whereas in Webwork, it was pretty much all business code. Command driven actions were also a big hit, as our lead architect came from a Next background, and apparently they did code like that all the time. In general, I think it was just a general feeling that Webwork was better abstracted and architected than Struts. Other advantages, like the ValueStack and the expression language, were less easy to express, since they hadn't begun to use them yet. Some of the concerns were (in no order): -Less userbase - I pointed out that with a smaller project we have a better chance of making changes and making WW do what we need -JSTL and JSF support -tool support -Original Message-From: Volkmann, Mark [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 5:52 PMTo: '[EMAIL PROTECTED]'Subject: RE: [OS-webwork] Woohoo! Can you share with us the justification you used for using WebWork instead of Struts? Others may find it useful. Perhaps you've already done that and I accidently deleted the email. If so, could you resend it to me? -Original Message- From: Jason Carreira [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 3:13 PM To: [EMAIL PROTECTED] Subject: [OS-webwork] Woohoo!So we had our Webwork vs. Struts talk today, and I was able to convince people here that there was sufficiently enough better about WW to make us use it instead of Struts, even though Struts is the "standard", of sorts! Cool. Off to catch a plane home... -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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 ***WARNING: All e-mail sent to and from this address will be received orotherwise recorded by the A.G. Edwards corporate e-mail system and issubject to archival, monitoring or review by, and/or disclosure to,someone other than the recipient.
RE: [OS-webwork] Hidden token
-Original Message- From: Robert Nicholson [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 5:50 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Hidden token I think the only reason Struts needs the ui:form is to associate the form to the form bean. I'm against the idea of a ui:form tag. ie. mandatory use of WW UI tags for proper behaviour. Struts form beans don't work unless you use their UI tags. I was proposing the ww:form tag only to do this (the hidden token) for you. I believe Rickard's proposed method will also require this (or would you do form action=ww:url .../?) I suppose we could also have the token creation be in a util action that would populate the session, and you could call it from the jsp using ww:action as well. --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Hidden token
-Original Message- From: Robert Nicholson [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 5:52 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Hidden token If I quickly hit the the submit button twice what happens? What guarantee is there that the execution of both actions isn't interleaved? Well, the first thing the action would do is check the token and remove it from the session. Is access to the session thread safe? Either way, you'd want to synchronize the read and clear of the token (or temporary URL), and whichever one got it first would succeed. --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Hidden token
-Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 7:27 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Hidden token I have the code ;). I can add it if it is what people want but Rickard has a point in trying to make this more automatic without adding a manual field. I guess we could have the old fashion way and if/when the portlet framework develops we can use it. -Matt Does the automatic way support both problem conditions: 1) reloading the result page and thereby re-posting the form data, and 2) the user hitting the back button and submitting the form again. I think it does, and I'm sure the hidden token does, but I wanted to check for sure. --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] RC2?
I thought the point was to get us ready to release 1.3? I don't think we want to add EVERYTHING, or we'll never get 1.3 out the door :-) -Original Message- From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 19, 2003 10:12 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] RC2? I vote for all features going into RC2. That's kinda the point of an RC rather than a final release - so people can test the new features? :) -mike On 20/1/03 1:50 PM, Jason Carreira ([EMAIL PROTECTED]) penned the words: I'd vote for new features (small, well tested ones) going into RC2... -Original Message- From: Peter Kelley [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 19, 2003 7:14 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] RC2? Does RC2 have to be the same features as RC1 but with fixed bugs or can extra features (Jasper Reports enhancements) be included. On Fri, 2003-01-17 at 11:33, matt baldree wrote: Are we ready to push out another release candidate? I think it would be nice to get the recent performance patches out the door. -Matt -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi- bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi- bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Branching 1.3 to allow for new development
I propose that we branch the current code base to be the code base for 1.3 and any bugfixes thereto, and allow new development to occur on the head (with bugfixes merged back, of course). Thoughts? Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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
[OS-webwork] Validation Framework (checked into Xwork)
I checked a new validation framework into Xwork this morning that I got running last night. It's based on some ideas like runtime attributes and deployment descriptors. What it does (triggered by a ValidationInterceptor in the interceptor list for an action) is to load validation xml files for the action, in the following order, using classloader.getResourceAsStream(): 1) package/of/action/ActionName-validation.xml 2) package/of/action/alias-validation.xml The xml file is parsed to create a Map of fieldname to List (containing one or more FieldValidator's). FieldValidator is an interface with the following signatures: void setMessage(String message); String getMessage(); void validate(String propertyName, Action action) throws ValidationException; All validators have a message property, and can have other properties (using the usual get/set naming) which will be set during configuration load time. A validator.xml file looks like this: validators field name=bar validator type=required message value=You must enter a value for bar./ /validator validator type=int param name=min value=6/ param name=max value=10/ message value=bar must be between 1 and 10./ /validator /field /validators The params here are set using Ognl into the properties of the validator, so your validators can have whatever properties you need. Unlike Interceptors, which are (must be) stateless, Validators maintain the setup state in these properties and are cached after the initial load for an alias and reused. What this allows is for you to pull all of your validation out of your actions and reuse it. It should make Actions even more simple and straightforward. One other thing I've added (and this is all in the Xwork code) is a ValidationAware interface that Actions can implement to get the error messages set into them by the FieldValidator's. It's just the same method signatures from ActionSupport in WW. Otherwise, the FieldValidator just logs the message (if it extends FieldValidatorSupport, that is. If you want it to do something else, then implement FieldValidator). Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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] Validation Framework (checked into Xwork)
Well, I didn't know it existed, for one :-)
In looking at it, it seems like it does too much. It seems to combine
bean population with validation. I'm also not sure how I feel about the
whole validation with any scripting language and RE's, etc. I actually
really kind of hate things that bundle BSF and allow scripting like
that. It's like .Net to me... Yes, you can write in multiple languages,
but it doesn't seem like a good idea.
That said, my mind could be changed. I have some attachment to my code,
but not enough that I wouldn't dump it if something better was there and
did what I wanted.
Can you describe how this could plug in where I have mine in place? It
would be called as an Interceptor after the parameters have been set
(both static configuration parameters and runtime request parameters).
It needs to be able to find configuration files (your framework also
uses XML files, I believe) for the Action class which act as defaults,
and alias specific configuration files which add to the defaults. This
should be dynamic, i.e. I shouldn't have to register the configuration
files in some master configuration file.
So how good a fit is it?
Also, has anyone looked at commons validator
(http://jakarta.apache.org/commons/validator/index.html)? It doesn't
seem to have any docs... From looking at the JavaDoc, it looks ok, but
it looks like it takes a little too much code to do it (it should be
seamless).
Thoughts anyone?
-Original Message-
From: Anthony Eden [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 21, 2003 6:03 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Validation Framework (checked into Xwork)
Jason,
Why are you writing a new validation framework when FormProc
has already
gone through these issues? Check out FormProc (
http://formproc.sf.net/
) and let me know if their is something missing which would
be necessary
to make it fit WebWork developer needs.
Sincerely,
Anthony Eden
Jason Carreira wrote:
Don't have all of the answers there yet (glad to have
help!), but what
I was thinking for i18n support was to change
message value=my message/
To
message key=message1My default message/message
Any thoughts on how to do parameterized messages? Maybe have:
message key=message1
default${0} is an invalid name/default
messageparam value=fooProperty/
/message
Don't know... There's definitely more to be done here.
-Original Message-
From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 21, 2003 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Validation Framework (checked into Xwork)
How would you handle i18n support, and parametrised messages?
Eg, if you wanted '${0} is an invalid name' as your message
Quoting Jason Carreira [EMAIL PROTECTED]:
I checked a new validation framework into Xwork this morning that I
got running last night. It's based on some ideas like runtime
attributes and deployment descriptors. What it does
(triggered by a
ValidationInterceptor in the interceptor list for an action) is to
load validation xml files for the action, in the following order,
using
classloader.getResourceAsStream():
1) package/of/action/ActionName-validation.xml
2) package/of/action/alias-validation.xml
The xml file is parsed to create a Map of fieldname to List
(containing one or more FieldValidator's). FieldValidator is an
interface with the following signatures:
void setMessage(String message);
String getMessage();
void validate(String propertyName, Action action) throws
ValidationException;
All validators have a message property, and can have other
properties
(using the usual get/set naming) which will be set during
configuration load time.
A validator.xml file looks like this:
validators
field name=bar
validator type=required
message value=You must enter a value for bar./
/validator
validator type=int
param name=min value=6/
param name=max value=10/
message value=bar must be between 1 and 10./
/validator
/field
/validators
The params here are set using Ognl into the properties of the
validator, so your validators can have whatever properties
you need.
Unlike Interceptors, which are (must be) stateless, Validators
maintain the setup state in these properties and are cached
after the
initial load for an alias and reused.
What this allows is for you to pull all of your validation
out of your
actions and reuse it. It should make Actions even more simple and
straightforward. One other thing I've added (and this is
all in the
Xwork code) is a ValidationAware interface that Actions can
implement
to get the error messages set into them by the
FieldValidator's. It's
just
RE: [OS-webwork] Validation Framework (checked into Xwork)
FormProc can do as much or as little as you like. If you only specify a validator then the values will only be validated. If you want to use FormProc to do type conversion then you can specify a type converter. This goes the same for storing the data (in a bean, hash map, etc), Regarding alternative methods for validation: I believe that it is up to the developer using FormProc as to how they want to validate. The nice thing about FormProc is that you can do what you want with it. That's fair. As long as I don't have to use all of it. The actual integration with WebWork would probably have to be done by someone else as a.) I am not intimately familiar with WebWork, b.) I don't have a lot of time to work on it. The main reason I suggested FormProc was because it is mature and has already gone through issues like i18n. Yeah, no problem. I'm talking about me doing it, just trying to judge if it's a good fit and I should look into it more. I don't think it would be exceptionally difficult to integrate FormProc and WebWork though. Your interceptor would need to call the method: process(FormData[] formData, Locale locale) throws Exception; ...which is in the Form class. You can see an example of extending the Form class in the HttpForm class, which converts an HttpServletRequest to an array of FormData objects. So do Actions have to extend Form? That's a big drawback. Would it be possible to abstract that? Or just automatically wrap a bean? Right now what I've got is field validators that are given the name of the field to work on, and can use Ognl to get the value of the field (Ognl uses reflection under the covers to get it) and can use it in validation. The configuration is completely pluggable as well, by implementing the FormConfiguration interface. The FormManager class then allows you to add named configurations which are then retrieved when the Form by the same name is passed to the FormManager.configure() method. Ok, so this is where I could plug in the auto-finding configuration, or is that already built in? There was also talk of an abstraction for pluggable validation. Anyone working on this yet? Interceptors allow anything to be pluggable! :-) Seriously, I implemented this validation stuff as an Interceptor, and just about anything else like this which is orthogonal to the execution of an Action can be done this way, including plugging in any validation framework you wanted. Jason --- 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
[OS-webwork] Xwork 1.0 and Webwork 2.0 Mission Statements
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. Xwork 1.0 Mission Statement: The Purpose: To create a generic, reusable, and extensible command pattern framework not tied to any particular usage. Features: * Flexible and customizable configuration based on a simple Configuration interface * Core command pattern framework which can be customized and extended through the use of interceptors to fit any request / response environment * Built in type conversion and action property validation using Ognl * Powerful validation framework based on runtime attributes and a validation interceptor Webwork 2.0 Mission Statement: The Purpose: To create the best Model-2 MVC web application framework supporting advanced web application development paradigms such as component based development and code reuse. Features: * Built on XWork, but customized to be specifically tailored for web application development * Custom web-specific Xwork interceptors * Flexible configuration extended from Xwork with web-specific configuration parameters * Multiple web-based views, including custom JSP taglibs, Velocity support with pre-built macros, XSLT views, and JasperReports -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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()
-Original Message- From: boxed [mailto:[EMAIL PROTECTED]] If Ognl is just totally unacceptable, then let's discuss two options: When we discussed this in #java it sounded to me like one could plug in a custom syntax parser into OGNL, thus solving this issue nicely. Did I misunderstand? If this is possible, this would be a great solution. If not, then maybe revamping the EL is the way to go. --- 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? [Small problem]
-Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Thoughts? One way would be to make the WW 2.0 framework/config more rigid and to remove the ResultInterceptor stuff and specifically hard code the ServletDispatcher to doing the dispatching _in_ the servlet itself (problem solved, but then generic results aren't possible in WW, which includes chaining, and then we open up the door to possibly more hardcoding). Anyway, I'm outta here, let me know what you guys think. -Pat -1 to hardcoding. I like the way the core framework services are becoming pluggable replaceable interceptors. I still don't understand the reason for wanting to access actions from their view URLs... Jason --- 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] Ognl: peek(), up(), and down()
-Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 11:03 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Ognl: peek(), up(), and down() It is possible, but it involves basicacally writing at least _part_ of our own EL using JavaCC. I'll ask the Ognl guys more about it today. Don't we already have our own EL written using JavaCC? :-) --- 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? [Small problem + solution?]
I don't plan on using it, so as long as it doesn't mess up the core +1 -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 2:37 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem + solution?] 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? -Pat - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 1:33 AM Subject: Re: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem] Found one small problem with this approach (and it may just be that using the filter + the servlet at all times just can't always work perfectly): If you are using the filter and servlet and access success.jsp, the action will be invoked, then the ResultInterceptor will kick in, call ServletDispatcherResult, which will see that the filter is in use and _not_ dispatch, since the filter is going to chain right after. This is the correct behavior. But if the result of the action executing is _different_ than the URL being request (ie: error.jsp), the ServletDispatcherResult does what it should (dispatch out to error.jsp) but the filter will still try to grab the original request to success.jsp. Thoughts? One way would be to make the WW 2.0 framework/config more rigid and to remove the ResultInterceptor stuff and specifically hard code the ServletDispatcher to doing the dispatching _in_ the servlet itself (problem solved, but then generic results aren't possible in WW, which includes chaining, and then we open up the door to possibly more hardcoding). Anyway, I'm outta here, let me know what you guys think. -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 12:06 AM Subject: 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 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- 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] Xwork configuration update
I've checked in some new Xwork configuration code. Here's the test xwork.xml file: xwork package name=default result-types result-type name=chain class=com.opensymphony.xwork.ActionChainResult/ /result-types interceptors interceptor name=timer class=com.opensymphony.xwork.interceptor.TimerInterceptor/ interceptor name=logger class=com.opensymphony.xwork.interceptor.LoggingInterceptor/ interceptor name=chain class=com.opensymphony.xwork.interceptor.ChainingInterceptor/ interceptor name=params class=com.opensymphony.xwork.interceptor.ParametersInterceptor/ interceptor name=static-params class=com.opensymphony.xwork.interceptor.StaticParametersInterceptor/ interceptor name=component class=com.opensymphony.xwork.interceptor.component.ComponentInterceptor / interceptor name=result class=com.opensymphony.xwork.interceptor.ResultInterceptor/ interceptor name=stack class=com.opensymphony.xwork.interceptor.StackInterceptor/ interceptor-stack name=defaultStack interceptor-ref name=result/ interceptor-ref name=static-params/ interceptor-ref name=params/ interceptor-ref name=stack/ /interceptor-stack interceptor-stack name=debugStack interceptor-ref name=timer/ interceptor-ref name=logger/ /interceptor-stack /interceptors action name=Foo class=com.opensymphony.xwork.SimpleAction action-params param name=foo17/param param name=bar23/param /action-params result name=success type=chain param name=actionNameBar/param /result interceptor-ref name=debugStack/ interceptor-ref name=defaultStack/ /action /package package name=bar extends=default namespace=/foo/bar interceptors interceptor-stack name=barDefaultStack interceptor-ref name=debugStack/ interceptor-ref name=defaultStack/ /interceptor-stack /interceptors action name=Bar class=com.opensymphony.xwork.SimpleAction interceptor-ref name=barDefaultStack/ /action /package /xwork Here you can see that I've implemented Rickard's ideas (see http://www.opensymphony.com:8668/space/RickardXWorkThoughts). 1) Packages - All configuration settings are in a package. Result types, interceptors, and actions are all package context specific, no more global settings (unless you have a default package and have your other packages extend it). Result, Interceptor, and Action configurations are inherited by packages which extend another package, such as package bar above, which extends default. 2) Interceptor stacks - Make it easier to have sets of interceptors you apply together in a certain order. These are also inherited as part of the interceptor definition inheritance. Essentially these are just name mappings to lists of interceptors instead of one Interceptor. 3)Namespaces - a new idea of mine, this allows actions to be aliased with the same name, providing they are in different namespaces. With the ServletDispatcher, this equates to the path before the action name, which will allow for J2EE declarative security. Namespaces are optional attributes of package definitions and, if excluded, defaults to . If the action configuration is not found with the supplied namespace, the namespace is checked as the default namespace, which makes it work like we have now (any path works, you get the action aliased with the name). Check out the code in the sandbox in CVS. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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] Wiki dammit
Can someone please explain to me how to publish a page on the Wiki? I can't seem to find a link to create a new page Gaah! Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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] Using the WiKi
Cool. Got it. It sure wasn't obvious though! Maybe my wiki paradigm has been messed up because we use Traction at work. -Original Message- From: Erik Beeson [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 10:40 PM To: Subject: [OS-webwork] Using the WiKi To add a page to the WiKi (as I understand it): Create and account and login. Go to the page that you want to link to your new page. Edit the page by clicking the [edit] link in the upper right hand corner. Create a link to your new page by putting the link text in []. (See http://snipsnap.org/space/snipsnap-QuickTour) Save the page. You'll have a link on the page saying [create MyLinkText] Go to your new page and edit it as desired. --Erik See the following for more help: http://snipsnap.org/space/snipsnap-QuickTour http://snipsnap.org/space/snipsnap-help --- 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 --- 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 configuration update
Can a stack reference a stack? It is sometimes nice of actions could refer to default which in turn could refer to either defaultStack or defaultDebug. Actions then refer to default and can be switched between production and debug simply by editing the debug interceptor stack reference. Yep. See the example config file. Interceptor instances and stacks are saved in the same Map, so either can be referenced the same way. Only one thing, either an Interceptor instance or a stack, can be referenced by one name, though. --- 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] Releasing 1.3 and new development
People have been adding new stuff, like the Velocity based templates, while the head is still (as far as I know) supposed to be 1.3 RC2. I like new stuff (see Xwork), but we really need to branch 1.3 to keep it clean of new stuff so we can develop against the head. If we end up needing to release 1.3.1 or somesuch to fix bugs, then we'll need the 1.3 source tree as a base to work from without keeping people from moving forward. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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] Releasing 1.3 and new development
+1 to all of that. Who wants to (and knows how to) create a branch? -Original Message- From: Kirk Rasmussen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 1:04 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Releasing 1.3 and new development I am in total agreement. A stable 1.3 branch is definitely needed. I think it would be very confusing for a new WW user to be expected to pull from the CVS head when the head potentially changes minute by minute. The 1.2 release has been totally ignored because work continued on the head to create the 1.3 release. IMO the feature sets should be better defined with specific goals so that developers know when a release is ready to be baked. I might be wrong but it seems that 1.3 was arbitrarily created because its been long enough since the 1.2 release. Consistent logging, performance enhancements and stability seems to be the goals of 1.3 from what I can tell. I an very confident that myself and several others on this list would help to maintain the 1.3 branch if necessary. BTW great job guys! WW does indeed rock! Regards, Kirk Rasmussen Lucasfilm Ltd. -Original Message- From: Jason Carreira [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 7:36 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Releasing 1.3 and new development Nononono you misunderstood. My bad. I want to branch 1.3 to be able to do bug fixes for any future 1.3.x releases. I want to keep the CVS head for continuing development and new features with a view to a 1.4 release. Xwork 1.0 and Webwork 2.0 can, and should, remain in the sandbox for now, until a LOT of issues are worked out and it's been fleshed out to do everything that WW 1.3 does. My point was really to be able to get back to 1.3 for bug fixes while not keeping people from continuing to develop against the CVS head. I'm not terribly comfortable with CVS, so I was throwing this out for someone to do. If we were using Perforce, I would create a branch, because branching is fast and low cost and it's how you do most code management in P4. Jason -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 10:27 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Releasing 1.3 and new development I like webwork head cvs, and want to see it keep moving forward. We can tag a release (1.3) anytime now, really. Only thing that perhaps needs doing is updating some of the docs, and having decent release notes. xwork is still sandbox, and is nowhere near production worthy (right?) and I'd much rather than those of us who enjoy webwork and contributing to it don't end up feeling like second class citizens in favour of xwork. Quoting Jason Carreira [EMAIL PROTECTED]: People have been adding new stuff, like the Velocity based templates, while the head is still (as far as I know) supposed to be 1.3 RC2. I like new stuff (see Xwork), but we really need to branch 1.3 to keep it clean of new stuff so we can develop against the head. If we end up needing to release 1.3.1 or somesuch to fix bugs, then we'll need the 1.3 source tree as a base to work from without keeping people from moving forward. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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-webw ork --- 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 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See
RE: [OS-webwork] ActionContext clarification
Konstantin, I think the problem here is that you're not using the Model2 paradigm, which Webwork is based upon. It sounds like you are hitting the JSPs directly, whereas, in Webwork, we would hit foo.action, which (because *.action is mapped to the Webwork ServletDispatcher) would be handled by Webwork, and the ActionContext would be automatically set up for you and ready to access from ActionContext.getSession(). Jason -Original Message- From: Konstantin Priblouda [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 8:30 AM To: [EMAIL PROTECTED] Cc: webwork-devel Subject: Re: [OS-webwork] ActionContext clarification 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... Another question: It seems to me that ActionContext is stored as TreadLocal, is this map kept in synch with session contents? regards, = Konstantin Priblouda ( ko5tik )Freelance Software developer http://www.pribluda.de play java games - http://www.yook.de render charts online - http://www.pribluda.de/povray/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.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 --- 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
-Original Message- From: Chris Nokleberg [mailto:[EMAIL PROTECTED]] When is the next WebWork release planned for? -Chris Good question :-) --- 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
-Original Message- From: Joseph Ottinger [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 9:28 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] XWork flux What areas are likely to change the most? I personally can see webwork2's functionality being expanded to feature-completeness (I *think* - is there a list around that actually goes into what feature-complete would mean?) and configuration on both xwork and webwork 2. Do you see core changes going in? Oh, other than the ThreadLocal thing, there are also remaining questions about Ognl and whether we can plug in our EL, or whether it should be undertaken to re-architect our existing EL for performance. Jason --- 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
How does nanning fit into xwork? (http://nanning.sf.net/) Nanning is a open source AOP library. IMHO the whole interceptor stuff in xwork can be modeled using nanning. -billy. Hey! We've already GOT interceptors! AOP is cool and all, but I don't think it's necessary to use AOP for interceptors here. The interceptors in Xwork work pretty darned well (if I do say so myself) :-) --- 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: [Fwd: (Offtopic) Freemarker WAS Using SiteMesh for the UI tags]
I'm not asking that you love me or anything but keep it to yourself. If you feel the temptation to say negative personal things about me or anybody else connected with FM, I hope you will have the sense to bite your tongue or sit on your hands or whatever is necessary. And we'll all be better off. That's a win-win proposition. And I hope you'll do the same and stop this thread now. This is a mailing list to discuss the development of an opensource project, and that is what we, the subscribers of this list, would like to get back to. Jason --- 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] Partition XWork [Was: Re: XWork flux]
-Original Message- From: Erik Beeson [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 7:57 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Partition XWork [Was: Re: XWork flux] Jason says 7 jars, Hani says 1, Pat says 2. I have two things to say. Ummm... No. I said the real question was Then said I thought one Webwork jar was enough. First, should webwork-2.0.jar include the code in xwork-1.0.jar, or should it depend on it? One way makes webwork-2.0.jar stand alone, the other keeps the webwork (not xwork) specific code abstracted from xwork code. I think we could include the xwork-1.0.jar in the distribution, and it would need to be in the classpath when you run webwork, just like it needs commons-logging, etc. Second, maybe there should be one separate jar for the view code? Why? Webwork is going to be almost ALL view code, since we're abstracting out the command pattern stuff into xwork. So I guess in a way, there is a separate jar for the view code, it's just called Webwork :-) Third, all of this should be configurable via build.properties, so one could have a single webwork-2.0.jar with everything included, or one could have more smaller jars as Jason suggested. Again, I didn't suggest it, and don't think it's a good idea. I also don't think building xwork into webwork is a good idea, since they'll be separate CVS modules. I guess the real question is what should the default be? Maybe 2 files, like Pat said, and have the web tied view code in webwork.jar and the non web view code in xwork.jar? Ok, so 3 things to say. --Erik Jason --- 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] Parameters and the ValueStack
I think id is the only thing not looked up, and should be the only thing not looked up. The reason is that id is a standard attribute to set something into the page request with a certain name, and it's not dynamic anywhere else. -Original Message- From: Erik Beeson [mailto:[EMAIL PROTECTED]] Sent: Friday, January 31, 2003 8:49 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Parameters and the ValueStack I'm talking about webwork 2.0. Should everything be lookedup on the stack? Pat's TextfieldTag currently doesn't. I just want some clear standard to be decided upon. --Erik On Sat, 1 Feb 2003, Scott Farquhar wrote: Erik, Which values are not looked up on the stack? I know that id isn't (in iterator tag). Anything else? I don't think that this can be fixed in current webwork, as we would not be able to maintain backwards compatibility? You should add this as a feature to webwork 2.0. Cheers, Scott Erik Beeson wrote: The biggest complaint that I hear about the ww taglib is the when to and when not to enclose params in single quotes. Currently, the best method for figuring this out seems to be to check the source to see if the param is ever looked up on the stack. Could there be some standard agreement made as to what is and what isn't looked up on the stack? Thoughts? --Erik --- 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 -- ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support --- Need a simple, powerful way to track and manage issues? Try JIRA - http://www.atlassian.com/software/jira --- 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 --- 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 --- 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] how to access bean property?
Title: RE: [OS-webwork] how to access bean property?
Andre,
You'll want to do ActionContext.getContext() instead of new ActionContext().
ActionContext.getContext() gets the ThreadLocal instance which is populated by the ServletDispatcher.
You'll probably also want to maintain a reference to your TestBean :-)
Here's an example:
public class TestAction extends ActionSupport {
private TestBean myBean;
public TestBean getMyBean() {
return myBean;
}
public void setMyBean(TestBean myBean) {
this.myBean = myBean;
}
protected String doExecute() throws Exception {
myBean = new TestBean();
BeanUtil.setProperties(ActionContext.getContext().getParameters(), myBean);
return SUCCESS;
}
}
Then, in your success.jsp, which is mapped as the success result of TestAction in the views.properties or actions.xml (see the docs for how to configure actions and view mappings), you can do this:
webwork:property value=myBean !-- This will call getMyBean() on your action and put it on the top of the value stack --
The name is: webwork:property value=name/ !-- This will call getName() on your TestBean and print it to the page
/webwork:property
This is a good way to do it if you have several parameters from the TestBean that you want to display, but, if you have just one, like in this case, it's probably better to do this:
webwork:property value=myBean/name/
Which will call getMyBean.getName() and print that out to the page.
Hope that helps.
I've also put this up on the Wiki:
http://www.opensymphony.com:8668/space/How+do+I+populate+a+form+bean+and+get+the+value+using+the+taglib%3F
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andre Mermegas
Sent: Friday, January 31, 2003 9:00 PM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] how to access bean property?
Hey all,
If Im doing something like:
In my Action.doExecute()
ActionContext ac = new ActionContext(); BeanUtil.setProperties(ac.getParameters(),new TestBean());
TestBean has one property name.
How do I access the name property using the ww taglibs?
ww:property value=name/ doesnt seem to be hitting the bean. ww:property value=$name/ does work, picking up the request parameter directly.
I thought maybe I had to name the object bean and then pass it in, like TestBean tb = new TestBean(); and then pass in the tb object and do ww:property value=tb/name/ but that doesnt work either.
I've been looking through the docs, but I cant find it. I know I'm not hitting the Bean on the view.
Regards,
-Andre Mermegas
Regards,
-Andre Mermegas
RE: [OS-webwork] how to access bean property?
I agree. PropertyTag does too much. In WW 2.0 we're planning on having
ww:property JUST do the output of the value, and have the pushing onto
the value stack be done by
ww:push
...use value here...
/ww:push
-Original Message-
From: Erik Beeson [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 31, 2003 10:34 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] how to access bean property?
Read Jason's email again carefully. For that to work, you
need to have the ww:property value=name / tag inside the
body of the first tag. Like I said, check Jason's example
again carefully.
To the developers who don't want to break up PropertyTag,
here we see the problem with a single tag that tries to do too much.
--Erik
On Fri, 31 Jan 2003, Andre Mermegas wrote:
Oh, one thing, I tried pushing the testBean to the top of the value
stack by doing
ww:property value=testBean/
and then accessing it
ww:property value=name/
But the first ww:property is actually outputting, not
pushing the bean
to the top of the value stack I think.
com.versionary.beans.TestBean@a33d00
Regards,
-Andre Mermegas
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of
Jason Carreira
Sent: Friday, January 31, 2003 9:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] how to access bean property?
Andre,
You'll want to do ActionContext.getContext() instead of new
ActionContext().
ActionContext.getContext() gets the ThreadLocal instance which is
populated by the ServletDispatcher.
You'll probably also want to maintain a reference to your
TestBean :-)
Here's an example:
public class TestAction extends ActionSupport {
private TestBean myBean;
public TestBean getMyBean() {
return myBean;
}
public void setMyBean(TestBean myBean) {
this.myBean = myBean;
}
protected String doExecute() throws Exception {
myBean = new TestBean();
BeanUtil.setProperties(ActionContext.getContext().getParameters(),
myBean);
return SUCCESS;
}
}
Then, in your success.jsp, which is mapped as the success result of
TestAction in the views.properties or actions.xml (see the docs for
how to configure actions and view mappings), you can do this:
webwork:property value=myBean !-- This will call
getMyBean() on
your action and put it on the top of the value stack --
The name is: webwork:property value=name/ !-- This will call
getName() on your TestBean and print it to the page
/webwork:property
This is a good way to do it if you have several parameters from the
TestBean that you want to display, but, if you have just
one, like in
this case, it's probably better to do this:
webwork:property value=myBean/name/
Which will call getMyBean.getName() and print that out to the page.
Hope that helps.
I've also put this up on the Wiki:
http://www.opensymphony.com:8668/space/How+do+I+populate+a+form+bean+
an
d+get+the+value+using+the+taglib%3F
http://www.opensymphony.com:8668/space/How+do+I+populate+a+form+bean+a
nd
+get+the+value+using+the+taglib%3F
-Original Message-
From: [EMAIL PROTECTED] [
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]]
On Behalf Of
Andre Mermegas
Sent: Friday, January 31, 2003 9:00 PM
To: [EMAIL PROTECTED]
Subject:[OS-webwork] how to access bean property?
Hey all,
If I'm doing something like:
In my Action.doExecute()
ActionContext ac = new ActionContext();
BeanUtil.setProperties(ac.getParameters(),new TestBean());
TestBean has one property name.
How do I access the name property using the ww taglibs?
ww:property value=name/ doesn't seem to be hitting the bean.
ww:property value=$name/ does work, picking up the request
parameter directly.
I thought maybe I had to name the object bean and then pass it in,
like TestBean tb = new TestBean(); and then pass in the tb
object and
do ww:property value=tb/name/ but that doesn't work either.
I've been looking through the docs, but I cant find it. I
know I'm not
hitting the Bean on the view.
Regards,
-Andre Mermegas
Regards,
-Andre Mermegas
---
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
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Opensymphony
RE: [OS-webwork] Xwork 1.0 / Webwork 2.0 design session
Oops, forgot to list the time... I was thinking 2PM Eastern time Monday 2/3... -Original Message- From: Jason Carreira Sent: Saturday, February 01, 2003 12:23 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Xwork 1.0 / Webwork 2.0 design session On the table is the ThreadLocal issue and how to re-introduce it. The current Xwork code uses an ActionInvocation which is passed to each of the interceptors and holds the state of the request processing. In order to make Actions (more) backward compatible in WW 2.0, we need to re-introduce the ThreadLocal state management concept from WW 1.2/1.3. Rickard, etc. let me know if this is a good time for you. Anyone who plans to attend, please look through the sandbox code first. If you have any other issues you'd like to discuss, please post them to this list so people have time to think about them beforehand. Patrick has suggested we do this on #xwork on irc.werken.com, so that it can be logged at http://irc.werken.com/channels/. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone:585.240.2793 fax:585.272.8118 email:[EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- 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 / Webwork 2.0 design session
Oops! I was looking at the wrong week when I scheduled this. I've got an appointment at 1:45. How about Tuesday at 2? Does that work for everyone who wants to attend? -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 02, 2003 6:17 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Xwork 1.0 / Webwork 2.0 design session I'll be there. Anyone else? We had some mementum going a couple weeks back, I'd like to see it pick up again. Please, anyone who is interested in XWork and/or WebWork 2.0, join us! If you have firewall issues and can't connect to IRC from work, contact me and I can help you find ways around it if possible. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 31, 2003 9:28 PM Subject: RE: [OS-webwork] Xwork 1.0 / Webwork 2.0 design session Oops, forgot to list the time... I was thinking 2PM Eastern time Monday 2/3... -Original Message- From: Jason Carreira Sent: Saturday, February 01, 2003 12:23 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Xwork 1.0 / Webwork 2.0 design session On the table is the ThreadLocal issue and how to re-introduce it. The current Xwork code uses an ActionInvocation which is passed to each of the interceptors and holds the state of the request processing. In order to make Actions (more) backward compatible in WW 2.0, we need to re-introduce the ThreadLocal state management concept from WW 1.2/1.3. Rickard, etc. let me know if this is a good time for you. Anyone who plans to attend, please look through the sandbox code first. If you have any other issues you'd like to discuss, please post them to this list so people have time to think about them beforehand. Patrick has suggested we do this on #xwork on irc.werken.com, so that it can be logged at http://irc.werken.com/channels/. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- 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 --- 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] where might info on this be?
Yes, this should be on the wiki... Link it to the example page I just put up about getting the values from an action... -Original Message- From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] where might info on this be? Almost, but not quite. :) RULES OF THE STACK: 1) The stack is just a stack of objects. 2) Initially the stack contains the Action executed (this is why as you say value=foo calls action.getFoo()) 3) New objects are placed onto the stack during the body of various tags (like ww:iterator or ww:property for example) 4) Using the expression language you can navigate UP the stack (ie ../ to move up the stack, / to root an expression from the top of the stack) 5) Using the expression language you can navigate DOWN the object graph from any point on the stack (ie / to move down the object's methods) How is that for a brief primer? Should we put this on the Wiki? Anyone have any other rules to add? -mike On 4/2/03 10:15 AM, Andre Mermegas ([EMAIL PROTECTED]) penned the words: Yeah, I've been looking at the wiki and saw that document, it is very helpful for the syntax, thanks. As far as the value stack goes, I've been thinking about it a bit, and this is what I've come up with, The stack begins with whatever properties comes from the Action directly, so errors is a base property because it has a getter/setter in ActionSupport and through inheritance my Action. As witnessed by: ww:iterator value=errors key=ww:property value=key/, value=ww:property value=value/br /ww:iterator Anything attached to the Action say for instance a bean that has a getter/setter; its properties are not visible from the base of the stack because the getters and setters for the beans properties are not in the action but are in the bean, so to access them you must prefix the property value with objectName/propertyname. As witenessed by: name=ww:property value=testBean/name/ I think I get it now. Regards, -Andre Mermegas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of boxed Sent: Monday, February 03, 2003 5:36 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] where might info on this be? 3.) A list of all possible views.properties entries like action.* what is available and what does it do. I'm aware of the basic ones: foo.action, foo.success, foo.error, foo.none, foo.input, foo.login for having looked at the Action interface but are there any other possible? I don't know. The suffixes are just strings. An action returns a String, and that return value is what you map in the views.properties file. Nothing more, nothing less. 2.) A good explanation of how exactly the value stack works, The wiki has a reference: http://www.opensymphony.com:8668/space/WebWork +Expression+Language+Syn ta x Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- 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 --- 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 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- 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 as the UI widgets [WW 2.0]
-Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 2:08 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Velocity as the UI widgets [WW 2.0] I agree, I had that convern as well. The current jars in lib/core are: beanutils logging collections digester ognl oscore velocity We could get rid of beanutils, digester, and collections. That's something XWork is using but really has no need to (we could parse the simple XML by hand). Where are we using BeanUtils and Digester? We ARE parsing the XML by hand, using a javax.xml.parsers.DocumentBuilder. I know I've used commons collections in some areas, but it may have been pulled out again. What are we using from oscore? Jason --- 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 as the UI widgets [WW 2.0]
Sure, that works. -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 10:09 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Velocity as the UI widgets [WW 2.0] I'm willing to get up early. Would we like to reschedule it for 23 hours from now? -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 04, 2003 6:03 AM Subject: RE: [OS-webwork] Velocity as the UI widgets [WW 2.0] -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Yeah, I think the only way is to do it at around 8-9 AM EST, which means afternoon here, which means late at night down under. Any other time will mean that someone is asleep :-) Well, 9 AM here means 6 AM in California, where Patrick is. I don't know if there is a good solution --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- 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] UI widgets won't render
Someone please Wiki this -Original Message- From: Andrew Lombardi [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 4:08 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] UI widgets won't render Kristian, Need to copy the templates folder over to your webapp ... and define the location in webwork.properties. -a Kristian Duske wrote: Hello everyone, I've been trying to build a simple example to find out how to use forms and validation in WebWork. I have put the following tag in a file named editItemForm.jsp: ... form action=webwork:url value='addItem.save'/ method=POST ... ui:textfield label='asdf' name='title' size=40 maxlength=60/ ... /form The problem is that the textfield won't get rendered at all. I have tried a lot of different methods (I have put an Action in front of it, I have called the jsp directly, I have checked my config files, etc.). The examples work fine though. I really have no idea what I might be doing wrong. I'd be really really glad if someone could shed some light on this. Thanks in advance Kristian --- 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 -- to your success! ___ andrew lombardi president mystic coders ___ http://www.mysticcoders.com 949 . 515 . 8840 x 6 == === This message is for the named person's use only. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. == === --- 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 --- 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] Graphical submit buttons and WW 1.2.1
Good question. I don't have an answer, but whoever figures this out, please Wiki it too. :-) -Original Message- From: Kirk Rasmussen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 3:50 PM To: webwork list Subject: [OS-webwork] Graphical submit buttons and WW 1.2.1 Hi All, I was wondering if someone has tried using multiple graphical submit buttons on a single form? For example let's say I have the following: form ui:textfield label='Email' name='userID' maxlength=100/ ui:password label='Password' name='password' maxlength=32/ input type=image src=/img/sign_on.gif name=doSignIn value=Sign In / input type=image src=/img/update.gif name=doUpdate value=Update Settings / /form If I had regular submit buttons (i.e. type=submit), the dispatcher would call setDoSignIn() and setDoUpdate()) because the parameter name would simply be doSignIn and doUpdate respectively. But in the case of graphical submit buttons the parameters sent from the browser become doSignIn.x and doSignIn.y and doUpdate.x and doUpdate.y. Other than making my action ServletRequestAware and using the servlet request directly to look at the parameter is there a best practices for dealing with this issue? Thanks, Kirk Rasmussen Lucasfilm Ltd. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- 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 / ActionContent - Stateless/Stateless behaviour, help
-Original Message- From: Joel Cordonnier [mailto:[EMAIL PROTECTED]] OK ! but before the action is executed, the servlet sessions parameters are set, no ? The Session is there beforehand, and is managed by the Servlet container. I don't want to persist them, just retrieve some XML content. For some action the XML retrieved must be user-specific and for other no-user specific. The only solution i see is to check what's in the HTTPSession and when initializing the ActionContent, put the user-id in the Session, Well, your XML content can be a property in your Action and you can retrieve it using getMyXml(), or, if you're putting it into a web page, you could use something like webwork:property value=myXml/ Without knowing more specifically what you're trying to do, I can't tell you any more. Jason --- 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] Irc.werken.com
Can anyone else attach to irc.werken.com? I can't seem to connect. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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] Irc.werken.com
Now I'm on... Keep trying if you're having problems -Original Message- From: Jason Carreira Sent: Wednesday, February 05, 2003 8:43 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Irc.werken.com Can anyone else attach to irc.werken.com? I can't seem to connect. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone:585.240.2793 fax:585.272.8118 email:[EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- 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] Irc.werken.com
It's in 13 minutes -Original Message- From: Joseph Ottinger [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 8:40 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Irc.werken.com Is the meeting NOW?! On Wed, 5 Feb 2003, Jason Carreira wrote: Can anyone else attach to irc.werken.com? I can't seem to connect. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant --- 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 --- 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] Followup to the IRC meeting: ThreadLocal impl
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 problem is during the ActionInvocation stack. How do the Interceptors interact with the parameters, the session, and the application map? I was creating a new ActionContext object and passing that as part of the ActionInvocation (replacing the Map context in there now), 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(). This is the path I started down when I decided I would open it up to the floor and schedule the meeting. Any thoughts? Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- 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] Help needed with parametric action
Did you ever get this resolved?
-Original Message-
From: Sebastiano Pilla [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 06, 2003 11:04 AM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] Help needed with parametric action
Greetings,
I'm having some troubles when trying to pass parameters to one of my
actions and I'm stumped: I believe I must be missing something
embarassingly simple, but it appears I'm too dumb to figure
it out for
myself...
The problem: I have a class that extends ActionSupport and
implements both
ApplicationAware and ParameterAware, but the setParameters
method always
receives an empty map...
I call this action in a JSP page in this way:
%@ taglib uri=WebWorkTags prefix=webwork %
webwork:action name='content.BlogPostAction'
webwork:param name='lowerBoundDay' value=3 /
webwork:param name='upperBoundDay' value=-1 /
/webwork:action
I've placed some logging calls in doExecute() and
setParameters(), and
they're both called as I expect:
[2003-02-06 16:51:44,822] DEBUG
com.datafaber.action.content.BlogPostAction - setParameters
- pParameters = {} [2003-02-06 16:51:44,952] DEBUG
com.datafaber.action.content.BlogPostAction
content.BlogPostAction - Action executing..
[2003-02-06 16:51:44,962] DEBUG
com.datafaber.action.content.BlogPostAction
content.BlogPostAction - doExecute - mParameters = {}
However, the Map object passed to setParameters is empty!
What I'm doing wrong? Am I using an incorrect syntax in my JSP? Am I
totally off-base here and should be doing this in an entirely
different way?
Thanks for any help.
Sebastiano Pilla
E-TREE S.p.a. Via Fonderia 43 - 31100 Treviso (Italy)
phone +39.0422.3107 fax +39.0422.310888
http://www.e-tree.com http://www.webanana.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
---
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
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]]
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; }
However, for those cases where a separate bean is used (e.g. a value
object from EJB) it would be overriden by the action as:
public Object getModel() { return someModelBean; }
When the dispatcher has executed an action and needs to
decide what to
put on the ValueStack it simply checks for the Model
interface and uses
it if available. If not available, then the action itself is used.
This would be largely transparent, but would allow for easy
use of the
form bean concept in Struts. If you need it it's there, but the
default is that action=model.
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.
What say ye?
/Rickard
+1. Sounds good to me. I've added a Jira task to add this to WW2.0. Speaking of which,
+can someone make it so people can comment on Jira Issues? And maybe make it so I can
+assign things to myself?
I'm thinking for WW2.0 this can be put directly into the Action Interface, and have
the default behavior described by Rickard in ActionSupport.
Jason
---
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
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] The context is set by the dispatcher: * Set context * Create action * Invoke action (which may invoke other actions) I've checked this into the sandbox. It doesn't work exactly like this as I've checked it in. Instead, the ActionContext is created and set during the init() of the ActionInvocation. This allows the Dispatcher to be VERY simple. All it needs to do is create a new ActionInvocation with the Action name and (optional) namespace, and then invoke() it. Patrick checked in some mods last night to what I did to make action chaining work by saving out and passing on the ValueStack to the next ActionInvocation (and corresponding ActionContext). Check out the sandbox and feel free to comment. Jason --- 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] Help needed with parametric action
Please post any details you have, and a sample app that shows the problem, if possible. -Original Message- From: Sebastiano Pilla [mailto:[EMAIL PROTECTED]] Sent: Friday, February 07, 2003 9:22 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Help needed with parametric action At 15.09 07/02/2003, Jason Carreira wrote: Did you ever get this resolved? No, unfortunately I haven't... Problem is, I can't seem to be able to pinpoint the exact problem, not even after a good night's sleep. I'm reasonably sure it's my fault, but I haven't got a clue. However, the Map object passed to setParameters is empty! Sebastiano Pilla E-TREE S.p.a. Via Fonderia 43 - 31100 Treviso (Italy) phone +39.0422.3107 fax +39.0422.310888 http://www.e-tree.com http://www.webanana.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 --- 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] file ui tag for jsps
I just don't think anyone ever did it. I think it's a good idea. -Original Message- From: Justen Stepka [mailto:[EMAIL PROTECTED]] Sent: Friday, February 07, 2003 4:31 PM To: [EMAIL PROTECTED] Subject: [OS-webwork] file ui tag for jsps Hey guys... The time has come that I need to use the file upload features of webwork and I'm wondering why there isn't a UI tag for file upload? The case wishing such a feature existed is because I may want to send the user back to the form with a status message of You must supply a filename or something similar. I'm pretty sure that I'll end up coding something to handle this on my own, but is there a reason this doesn't existing in the UI core? Thanks, Justen Stepka --- 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 --- 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] where might info on this be?
If you want to save things in the Session, you need to do it explicitly. The ValueStack is only valid during one request / response cycle. -Original Message- From: Andre Mermegas [mailto:[EMAIL PROTECTED]] Sent: Friday, February 07, 2003 2:23 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] where might info on this be? Hey all, Is there a new value stack created for every view coming from an Action? Or is it possible to back reference previous Actions executed, basically what I'm getting at is the value stack session like? If so how? From my tests it doesn't seem to be, but I could be doing it wrong =) Regards, -Andre Mermegas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mike Cannon-Brookes Sent: Monday, February 03, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] where might info on this be? Almost, but not quite. :) RULES OF THE STACK: 1) The stack is just a stack of objects. 2) Initially the stack contains the Action executed (this is why as you say value=foo calls action.getFoo()) 3) New objects are placed onto the stack during the body of various tags (like ww:iterator or ww:property for example) 4) Using the expression language you can navigate UP the stack (ie ../ to move up the stack, / to root an expression from the top of the stack) 5) Using the expression language you can navigate DOWN the object graph from any point on the stack (ie / to move down the object's methods) How is that for a brief primer? Should we put this on the Wiki? Anyone have any other rules to add? -mike On 4/2/03 10:15 AM, Andre Mermegas ([EMAIL PROTECTED]) penned the words: Yeah, I've been looking at the wiki and saw that document, it is very helpful for the syntax, thanks. As far as the value stack goes, I've been thinking about it a bit, and this is what I've come up with, The stack begins with whatever properties comes from the Action directly, so errors is a base property because it has a getter/setter in ActionSupport and through inheritance my Action. As witnessed by: ww:iterator value=errors key=ww:property value=key/, value=ww:property value=value/br /ww:iterator Anything attached to the Action say for instance a bean that has a getter/setter; its properties are not visible from the base of the stack because the getters and setters for the beans properties are not in the action but are in the bean, so to access them you must prefix the property value with objectName/propertyname. As witenessed by: name=ww:property value=testBean/name/ I think I get it now. Regards, -Andre Mermegas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of boxed Sent: Monday, February 03, 2003 5:36 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] where might info on this be? 3.) A list of all possible views.properties entries like action.* what is available and what does it do. I'm aware of the basic ones: foo.action, foo.success, foo.error, foo.none, foo.input, foo.login for having looked at the Action interface but are there any other possible? I don't know. The suffixes are just strings. An action returns a String, and that return value is what you map in the views.properties file. Nothing more, nothing less. 2.) A good explanation of how exactly the value stack works, The wiki has a reference: http://www.opensymphony.com:8668/space/WebWork+Expression+Lang uage+Synta x Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- 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 --- 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 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM +
RE: [OS-webwork] Commons Jelly
I have to disagree with Hani here. I think Jelly looks cool. I agree that the Jakarta projects tend to be overly interconnected, but this doesn't seem too bad. -Original Message- From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 08, 2003 7:06 PM To: [EMAIL PROTECTED] Subject: FW: [OS-webwork] Commons Jelly Another view option with our existing EL then :) -- Forwarded Message From: James Strachan [EMAIL PROTECTED] Date: Sat, 8 Feb 2003 15:30:30 - To: Mike Cannon-Brookes [EMAIL PROTECTED] Subject: Re: [OS-webwork] Commons Jelly FWIW, you could drop in OGNL (or indeed any expression language) into Jelly pretty easily if you wish. Any TagLibrary can decide which expression langauges it wishes to use where so you could easily use Jelly + OGNL as a view technology in WW if thats what you wanted to do. James --- http://radio.weblogs.com/0112098/ - Original Message - From: Mike Cannon-Brookes [EMAIL PROTECTED] To: James Strachan [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 3:16 PM Subject: FW: [OS-webwork] Commons Jelly More Jelly opinions. -mike -- Forwarded Message From: Kelvin Tan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Sat, 8 Feb 2003 19:46:15 +0800 To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Commons Jelly My initial inkling was to have Jexl as a possible replacement to the current EL, but looking deeper into OGNL convinces me that it doesn't match up in terms of functionality. Something interesting, though, is Jelly's support for multiple expression languages... quote Jelly has native support for a Velocity-like expression language called Jexl snip as well as support for other pluggable expression languages like XPath via Jaxen, JavaScript, beanshell and Jython. /quote Use Jelly as a basis for multiple EL support? But I have a strange feeling I'm way over my head here..:-) Just ignore me, if that's the case. You could drop in OGNL (or indeed any expression language) pretty easily if you wish. On Thu, 6 Feb 2003 23:07:49 -0800, Patrick Lightbody said: Can you give some deeper examples of how this might occur? I'm thinking it could just be a view technology, so maybe you can show me other examples where it is more than a view. -Pat - Original Message - From: Kelvin Tan [EMAIL PROTECTED] To: opensymphony- [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 10:27 PM Subject: [OS-webwork] Commons Jelly Did a search in the archives and didn't find anything noteworthy re: WW + Jelly, so thought I'd bring it up. Has this been discussed before? Perhaps not just using it as another view, but in a more integrated fashion, ala OGNL and the current EL? After all, Jelly has a large collection of existing taglibs, and support for JEXL... Regards, Kelvin The book giving manifesto - http://how.to/sharethisbook --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Opensymphony- webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- 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 --- 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 -- End of Forwarded Message __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- End of Forwarded Message --- 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 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com
RE: [OS-webwork] [WW2] new ServletRedirectResult feature
Good job Pat!
-Original Message-
From: Patrick Lightbody [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 09, 2003 12:57 AM
To: os-ww
Subject: [OS-webwork] [WW2] new ServletRedirectResult feature
Just put in a dinky little new WW 2.0 feature:
ServletRedirectResult now supports putting in parameters in
the location attribute. What that means is you can do:
result name=success type=redirect
param
name=location/workflow/info.action?workflowId=${workflowId}/param
/result
And then ServletRedirectResult will look for all matching ${
.. } and use the value stack to find the text between and
insert it in. By default this feature is turned ON, but you
can turn it off with param name=parsefalse/param. What
do you guys think?
-Pat
---
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
---
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] Localized and Parameterized Validation Messages in Xwork
I built the message localization and parameterization stuff for the
validation framework in Xwork. It uses the cool stuff Patrick put in to
parse the Redirect URL and apply Ognl to expressions inside ${...} for
parameterization and pushes the Validator on the stack before it does
this so you can get parameters from either the Validator or the Action.
The localization stuff builds off of the getText() stuff from
ActionSupport (which has now been copied over to Xwork) to get localized
validation messages and have defaults.
The text parsing stuff is going to be VERY useful in a lot of spots.
More details on this later, I promise. Check out the sandbox code if
you're too eager to wait, especially the test cases, which demonstrate
this functionality.
Jason
--
Jason Carreira
Technical Architect, Notiva Corp.
phone: 585.240.2793
fax: 585.272.8118
email: [EMAIL PROTECTED]
---
Notiva - optimizing trade relationships (tm)
---
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] [WW2] new ServletRedirectResult feature
This is in the sandbox, not the current Webwork code. -Original Message- From: Wayland Chan [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 9:40 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] [WW2] new ServletRedirectResult feature -1 We'll never get 1.3 final out if we keep adding stuff (no matter how useful it is). Joseph, next time submit your hack to the project. Even if it is a gross hack, the idea could have been carried forward and refactored with help from others. --- Joseph Fifield [EMAIL PROTECTED] wrote: Awesome! I recently needed something like this and couldn't find it in 1.3. I came up with a solution by extending RedirectAction, but it was very much a gross hack :( Is there any way something like this could be included in some upcoming 1.x release? Oh, and if I missed something and it's already supported there, my apologies! Joe __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.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 --- 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] using ww:url
Title: Message I think this should just be ww:url page="smallImageURL"/ I think. Most all of the attribute values are evaluated, so this will try to get the smallImageURL property from the ValueStack. Can someone verify? -Original Message-From: Andre Mermegas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 7:40 PMTo: [EMAIL PROTECTED]Subject: [OS-webwork] using ww:url Hey all, So, Id like to do something like this: ww:iterator value="@FeaturedItemsKey" img border="0" src="" page="ww:property value="smallImageURL"/" / / /ww:iterator but page attribute doesnt accept expressions, anybody have a suggestion on a better way to do it? Thanks! =) Regards, -Andre Mermegas
RE: [OS-webwork] Webwork 2.0
-Original Message- From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 1:43 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork 2.0 Low, I don't know about anyone else's dates, but I'm giving a presentation on WebWork 2 at The Server Side's Symposium in mid June, so it will be stable, tested and released by then ;) And as for WW + Velocity + Hibernate + SiteMesh, yes that is a killer combination of tools. Cheers, Mike Hey! How'd you get that gig?!?! Can you at least get Patrick and I in for free? Ha ha... No, really. Ok, then, I expect you to get in there and start coding! :-) Jason --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Webwork 2.0
I guess that depends on how much help we get :-) It would be good if someone besides Patrick and I were to work on things (hint hint). Patrick and I were talking about releasing a first Alpha of XW1.0 / WW2.0. What features from WW1.x need to be ported over to WW2? This isn't an academic question... I'm flying home tonight (probably leaving the office for the airport at about 4-4:30 Central time) and I asked this question to Patrick last night: What's the next most pressing need in WW2.0? Give me something to do on my flight. Jason -Original Message- From: Heng Sin Low [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 1:16 AM To: OS-Webwork Subject: [OS-webwork] Webwork 2.0 All, We are currently evaluting the framework to use for our new CRM product. I'm bias towards webwork and really like many of the features plan for webwork 2.0 ( I've been using webwork and are not entirely happy with the current version ). So, my concern now is the schedule of webwork 2.0 and whether it would be inline with our development schedule ( We are looking at releasing the first version by September 2003 ). I do not mind to live with the rough edges of the initial beta release but would like to know the estimated schedule of webwork 2.0 ( For e.g, when it will be promoted from sandbox, what is the estimated first beta release date, etc ). Also, We are looking at using webwork, velocity, hibernate and sitemesh together, maybe someone here can share his/her experience with us ? thanks. Regards, Low __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.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 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Webwork 2.0
Ok, what do we want to see for docs? Should we go back into the stuff from 1.x and re-do that, or just document the new / different stuff for now? Here's a quick outline: Xwork 1)Introduction a) What is Xwork Xwork is a generic command pattern framework... b) How does Xwork relate to Webwork? Webwork 2.0 is built on top of Xwork... 2) The basics a) Actions Actions are the basic unit of execution... 1) The Action Interface 2) ActionSupport 3) Lifecycle b) No FormBeans? Xwork / Webwork does not require the use of FormBeans like Struts... 3) Configuration - Xwork.xml 4) Ognl Ognl is used as both the expresion language and bean population utility for Xwork... 5) Interceptors a) Utility Interceptors The TimerInterceptor and LoggingInterceptor ... b) Parameter Interceptors - populating your Action The StaticParameterInterceptor and ParameterInterceptor populate your Action fields... c) ResultInterceptor 6) Validation Framework (optional) a) The ValidationInterceptor b) Defining validation rules in a validation.xml c) Building a FieldValidator d) Localized and Parameterized messages I'll take 3, 5, and 6. Patrick, you take (at least) 4, and Joe, since you brought it up, you get 1 and 2 :-) What else do we need in there? Jason -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 1:18 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork 2.0 Actually, I think Joe may be right for once in his life. We should get cracking on the documentation soon. Maybe you can work on a skeleton documentation effort while you're on the plane? -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 13, 2003 7:25 AM Subject: RE: [OS-webwork] Webwork 2.0 I guess that depends on how much help we get :-) It would be good if someone besides Patrick and I were to work on things (hint hint). Patrick and I were talking about releasing a first Alpha of XW1.0 / WW2.0. What features from WW1.x need to be ported over to WW2? This isn't an academic question... I'm flying home tonight (probably leaving the office for the airport at about 4-4:30 Central time) and I asked this question to Patrick last night: What's the next most pressing need in WW2.0? Give me something to do on my flight. Jason -Original Message- From: Heng Sin Low [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 1:16 AM To: OS-Webwork Subject: [OS-webwork] Webwork 2.0 All, We are currently evaluting the framework to use for our new CRM product. I'm bias towards webwork and really like many of the features plan for webwork 2.0 ( I've been using webwork and are not entirely happy with the current version ). So, my concern now is the schedule of webwork 2.0 and whether it would be inline with our development schedule ( We are looking at releasing the first version by September 2003 ). I do not mind to live with the rough edges of the initial beta release but would like to know the estimated schedule of webwork 2.0 ( For e.g, when it will be promoted from sandbox, what is the estimated first beta release date, etc ). Also, We are looking at using webwork, velocity, hibernate and sitemesh together, maybe someone here can share his/her experience with us ? thanks. Regards, Low __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.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 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your
RE: [OS-webwork] Webwork 2.0
I started building one. The consensus at the design meeting last week was that creating a dependency on another validation framework was a Bad Thing, so, since it only took a few hours to put in localized and parameterized messages, we're sticking with our own. -Original Message- From: Francisco Hernandez [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 4:37 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork 2.0 i havent kept up with all the emails but will you guys be building your own validator? or will an existing one be used? - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 13, 2003 12:01 PM Subject: RE: [OS-webwork] Webwork 2.0 Ok, what do we want to see for docs? Should we go back into the stuff from 1.x and re-do that, or just document the new / different stuff for now? Here's a quick outline: Xwork 1)Introduction a) What is Xwork Xwork is a generic command pattern framework... b) How does Xwork relate to Webwork? Webwork 2.0 is built on top of Xwork... 2) The basics a) Actions Actions are the basic unit of execution... 1) The Action Interface 2) ActionSupport 3) Lifecycle b) No FormBeans? Xwork / Webwork does not require the use of FormBeans like Struts... 3) Configuration - Xwork.xml 4) Ognl Ognl is used as both the expresion language and bean population utility for Xwork... 5) Interceptors a) Utility Interceptors The TimerInterceptor and LoggingInterceptor ... b) Parameter Interceptors - populating your Action The StaticParameterInterceptor and ParameterInterceptor populate your Action fields... c) ResultInterceptor 6) Validation Framework (optional) a) The ValidationInterceptor b) Defining validation rules in a validation.xml c) Building a FieldValidator d) Localized and Parameterized messages I'll take 3, 5, and 6. Patrick, you take (at least) 4, and Joe, since you brought it up, you get 1 and 2 :-) What else do we need in there? Jason -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 1:18 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork 2.0 Actually, I think Joe may be right for once in his life. We should get cracking on the documentation soon. Maybe you can work on a skeleton documentation effort while you're on the plane? -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 13, 2003 7:25 AM Subject: RE: [OS-webwork] Webwork 2.0 I guess that depends on how much help we get :-) It would be good if someone besides Patrick and I were to work on things (hint hint). Patrick and I were talking about releasing a first Alpha of XW1.0 / WW2.0. What features from WW1.x need to be ported over to WW2? This isn't an academic question... I'm flying home tonight (probably leaving the office for the airport at about 4-4:30 Central time) and I asked this question to Patrick last night: What's the next most pressing need in WW2.0? Give me something to do on my flight. Jason -Original Message- From: Heng Sin Low [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 1:16 AM To: OS-Webwork Subject: [OS-webwork] Webwork 2.0 All, We are currently evaluting the framework to use for our new CRM product. I'm bias towards webwork and really like many of the features plan for webwork 2.0 ( I've been using webwork and are not entirely happy with the current version ). So, my concern now is the schedule of webwork 2.0 and whether it would be inline with our development schedule ( We are looking at releasing the first version by September 2003 ). I do not mind to live with the rough edges of the initial beta release but would like to know the estimated schedule of webwork 2.0 ( For e.g, when it will be promoted from sandbox, what is the estimated first beta release date, etc ). Also, We are looking at using webwork, velocity, hibernate and sitemesh together, maybe someone here can share his/her experience with us ? thanks. Regards, Low __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.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 --- This SF.NET email is sponsored by: FREE SSL
RE: [OS-webwork] Webwork 2.0
The argument was that we did not want to introduce another dependency. I was actually arguing FOR FormProc, but the feeling was that we wanted to keep the required dependencies to a minimum. The main thing I was looking for in FormProc were the localized and parameterized messages, which turned out to be relatively easy to implement, and the ability to define scripts for validation. I'm currently thinking about adding another type of Validator, which is not tied to one particular field, and I'm thinking the first implementation would be one which uses Ognl to evaluate the expression you give it. Since Ognl can be used for basically ANYTHING, including defining lambda expressions, this should easily handle this requirement as well. By looking at the current ValidationInterceptor, however, it should be relatively easy to see how to plug another validation framework into Xwork, and I'd be happy to help you if you want to do that. Which framework were you thinking of? -Original Message- From: Kelvin Tan [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 10:49 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Webwork 2.0 Since the minutes of the meeting are not out (or are they?), its not immediately clear why doing so is a BT. Would you kindly elaborate on how this consensus was arrived at, and why reinventing the wheel, so to speak, is better than using something already tested and in use? Or alternatively, point me to the minutes...:-) Thanks. Kelvin On Thu, 13 Feb 2003 19:41:01 -0800, Jason Carreira said: I started building one. The consensus at the design meeting last week was that creating a dependency on another validation framework was a Bad Thing, so, since it only took a few hours to put in localized and parameterized messages, we're sticking with our own. -Original Message- From: Francisco Hernandez [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 4:37 PM To: opensymphony- [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork 2.0 i havent kept up with all the emails but will you guys be building your own validator? or will an existing one be used? - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 13, 2003 12:01 PM Subject: RE: [OS-webwork] Webwork 2.0 Ok, what do we want to see for docs? Should we go back into the stuff from 1.x and re-do that, or just document the new / different stuff for now? Here's a quick outline: Xwork 1)Introduction a) What is Xwork Xwork is a generic command pattern framework... b) How does Xwork relate to Webwork? Webwork 2.0 is built on top of Xwork... 2) The basics a) Actions Actions are the basic unit of execution... 1) The Action Interface 2) ActionSupport 3) Lifecycle b) No FormBeans? Xwork / Webwork does not require the use of FormBeans like Struts... 3) Configuration - Xwork.xml 4) Ognl Ognl is used as both the expresion language and bean population utility for Xwork... 5) Interceptors a) Utility Interceptors The TimerInterceptor and LoggingInterceptor ... b) Parameter Interceptors - populating your Action The StaticParameterInterceptor and ParameterInterceptor populate your Action fields... c) ResultInterceptor 6) Validation Framework (optional) a) The ValidationInterceptor b) Defining validation rules in a validation.xml c) Building a FieldValidator d) Localized and Parameterized messages I'll take 3, 5, and 6. Patrick, you take (at least) 4, and Joe, since you brought it up, you get 1 and 2 :-) What else do we need in there? Jason -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 1:18 PM To: opensymphony- [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork 2.0 Actually, I think Joe may be right for once in his life. We should get cracking on the documentation soon. Maybe you can work on a skeleton documentation effort while you're on the plane? -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 13, 2003 7:25 AM Subject: RE: [OS-webwork] Webwork 2.0 I guess that depends on how much help we get :-) It would be good if someone besides Patrick and I were to work on things (hint hint). Patrick and I were talking about releasing a first Alpha of XW1.0 / WW2.0. What features from WW1.x need to be ported over to WW2? This isn't an academic question... I'm flying home tonight (probably leaving the office for the airport at about 4-4:30 Central time) and I asked this question to Patrick last night: What's the next most pressing need in WW2.0? Give me something to do on my flight. Jason -Original Message- From: Heng Sin Low [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 1:16 AM To: OS-Webwork Subject: [OS-webwork] Webwork 2.0
[OS-webwork] Xwork docs
Well, I tried to attach my first pass at some Xwork docs to a message, but it doesn't seem to have gone through, so I put it into the Sandbox CVS. It's available here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/opensymphony/sandbox/xwor k/docs/index.html?rev=1.1content-type=text/vnd.viewcvs-markup Everyone feel free to jump in! Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
