Re: [s2] Should tags be their own plugin?
Oh, but one question: I assume if one were to make JSP 2.0-style tags (.tag files) they couldn't be bundled as a plugin, right? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=135292messageID=207484#207484 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Should tags be their own plugin?
+1 for sure! - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=135292messageID=207483#207483 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jive Forum in Struts Zone
I would be happy to help make this happen. Someone just needs to provide me with access to the zone, right? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=73585messageID=138342#138342 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] JSF/JSP EL # vs. OGNL EL #
Yes, this was something I was not pleased about one bit. Fortunately, there are tricks you can use to disable this logic and stick w/ 2.0 or even 1.2-style logic. I don't recall the specifics, but I think they are something along the lines of which doctype you use in web.xml. You may also be able to configure it via jsp-groups in web.xml. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=70741messageID=132632#132632 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Annotations and Archetype into the trunk for the 2.1.x series (was struts-annotations)
Ted, What annotations are we talking about? The annotations used for configuration, or something else? Pardon my ignorance on this, I just want clarification. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=70084messageID=132278#132278 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Showcase - quickstart
Yes, I believe QuickStart has since been removed in favor of encouraging mvn jetty:run or something similar. The file has been removed. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=70352messageID=132279#132279 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Annotations and Archetype into the trunk for the 2.1.x series (was struts-annotations)
Seems like bringing them in would make sense, especially if the people who are managing them say so. Since I don't experience the pain, I certainly can't vote -1. So I'm a +0-1 :) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=70084messageID=132295#132295 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Development Infrastructure (Re: [s2] Struts 2.0.7 Status)
Probably wouldn't be a bad idea to get a standalone instance of Forums 5.5 (coming out soon) set up for Struts. Email me if you want to get that going, or if you can provide me instructions for setting it up (zone login info, etc). - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=67039messageID=132299#132299 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Filter vs Servlet
There a lot of reasons. If you really want to know, try searching the webwork mailing list/forum archives, or ask here and I'll try to find time to explain. Otherwise, just keep trying to solve your problem and avoid using the Servlet - it's not recommended :) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=65940messageID=125896#125896 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.6 Quality
+1 for GA - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=65672messageID=125490#125490 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
+1 for GA - I'm using it in HostedQA now and it is working great. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=62617messageID=121464#121464 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Experimental Features
I use all of these with HostedQA. It's exciting to see that we've added a number of brave, new features since Struts 2.0.1. * codebehind plugin * zero configuration * REST-ful URLS * direct results As implemented, these features seem solid and useful, but I wonder if anyone has a chance to use them all beyond proof of concept examples. (Wendy?) If not, I would suggest that we consider documenting these features as experimental for Struts 2.0.2, until we have had a chance to put them to use ourselves in our own applications. Of course, one GA in a series is only the beginning, and we can soon bring out another 2.0.x that promotes the experimental features to mainstream. -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=52728messageID=120092#120092 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Pluggable URL building proposal
Tom, How is this coming along? I imagine that some of this work would also relate to the ActionMapper interface, since it does have some responsibilities for rendering out URLs. Keep us posted. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=59916messageID=119811#119811 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts2] Use a list/array of objects in JSP
That should work just fine. What kind of error do you get? What happens when you do: s:property value=objects/ - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=55942messageID=111476#111476 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts 2.0.2 status
Ted, Making XWork a more public project is not a problem - we just hadn't done so up until now due to no need. As for the names of the releases (RC, beta, 2.0.1.1.1.1, whatever you want...)... that is really easy to fix: just ask Rainer or whoever is doing the release :) OpenSymphony doesn't really have a lot of rules around this. The important thing is that XW is here to serve Struts, and everyone knows that. So if there are needs it isn't providing, I'm sure the gang will work to address them. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=55391messageID=111479#111479 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajax tags in 2.0.3 (was Struts 2.0.2 status - Ready to roll)
+1 I think in general the concept of themes for the AJAX stuff was a mistake. Instead, let's do stuff like: s:dojo-div.../ And make those tags part of an external plugin. That way we don't make migration from WebWork impossible, but we also fix a mistake we made with WebWork by trying to stuff too much functionality in to themes. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=56165messageID=111480#111480 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] XWork Status Quo
Ted, Your suggestions all sound very reasonable. Rainer and I would be happy to help set this up (I can do the forums/infrastructure, and I'm sure Rainer can help by giving releases more compatible version numbers in the future). - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=56191messageID=111481#111481 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.1 Quality
+1 for beta - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=46988messageID=95481#95481 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JXP Template support?
THANK YOU DON. You said it much better than I did. Honestly, guys, the reaction here is a little... odd. I wanted to engage the dialog of how we might address known issues. Unless you've used the Struts 2 tags, it probably is hard to provide any real constructive feedback on this particular subject. Don outlines the problems very nicely. Ted's suggestion of building our own template language is definitely something I've also thought about. I've always said the ideal template language that we could use for our UI tags would be: - JSP-like - No scripplet support - Fast - Very lightweight (not giving the feeling we're requiring or endorsing one language over another) JXP could be a possible solution. So could building one in house. Or, perhaps, we could fork JXP for our needs and do both. The point is there is a real issue here, as Don outlined, as we should discuss ways to approach the problem. I personally think that JXP is a very good start, so I'd prefer to look at that before building our own. It may have issues (character encoding support), but a lack of activity or developer support is not a concern for me. Solving our known problems is my only concern - we can work out the technical, license, and community issues later. Now, to address Don's comments directly: Problem #1 (performance) isn't a huge issue for me - I figure we can solve that. Problems #2 and #3 are my main issue, which is why my criteria points to a JSP-like syntax since most applications use JSP. Let's pose a hypothetical: What if we could work with the JXP guys (or guy, as the case may be - who cares) to: - Ensure that it was fast - Have it emulate JSP 2.0 syntax - Address any other technical issues (ie: charsets) I think at that point JXP might really be something we'd want to consider. The alternative is building our own from scratch or possibly by forking something like FreeMarker. Anyone know how difficult that would be? Patrick I think perhaps we are getting too deep into the solution when we don't understand or agree upon the problem. The purpose of the Struts tags is to provide a shortcut to create simple and complex output. The tags are usable in Velocity, Freemarker, and JSP. It does this by delegating to an independent component object model that defines the component as a Java object and uses Freemarker to do the actual rendering. Therefore, the advantages of the current system are: 1. Same tags in Velocity, Freemarker, and JSP 2. Easy to customize a tag's output by overriding its Freemarker template However, I do believe there are disadvantages: 1. Performance overhead of the Freemarker template engine, as opposed o pure Java rendering used by toolkits like the default JSF JSP tags 2. Yet another template engine and expression language to learn if you se JSP or Velocity 3. Little to no tool support for Freemarker Furthermore, if you look at our templates, most of them have little HTML output themselves, making them harder to read as they have more Freemarker syntax than HTML. Template engines generally do better when the markup greatly outweighs the template syntax. The above disadvantages are big enough to me that I'm interested in finding an alternative to Freemarker. I want something fast, intuitive, and requires little to no extra learning on the part of the developer. Freemarker seems like a great template language for general purpose web pages, but for our tags, I'd like to find something lighterweight. I don't have a solution myself, but as we discuss possible solutions, and I'm very happy we have an active discussion going, please keep in mind the problems we are trying to solve. Don - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=46468messageID=94463#94463 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JXP Template support?
Take a look at JXP: http://jxp.sourceforge.net/ This might be very close to the template language I have been looking for that is JSP-like, but has the advantages that FreeMarker and Velocity provide in that it can be loaded from the classpath. I've wanted to select something like this as the template language used by the UI tags (instead of FreeMarker). What do you guys think? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=46468messageID=93881#93881 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Confluence clear cache snippet plugins code access
Toby, I believe Ted can provide insight here. I gave him access to the plugin source, but I don't know what happened to it since or in what form it was installed. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=45766messageID=92846#92846 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Form label defaults (was Struts 2.0.1 release)
This is really good stuff, keep working to flesh it out fully. Take a look at
the Stripes i18n/validation scopes for an example of a well-done implementation.
Also, one thing I'd note: we do default the value attribute to the evaluation
of the name attribute already, so the question is all about defaulting the i18n
key.
For the short term, you can actually achieve this by just editing your
controlheader.ftl template and making a call out to
$stack.finValue(getText(...)), but of course we'd prefer to have best
practices as the default option.
Fair enough. So if I understand correctly, before we
commit something
in this regard, you'd like to consider and come to
consensus on the
correct approach for standardizing the lookup of
label names when the
'key' shortcut is used within the tags.
With this in mind, I've taken a look at able and have
found that it does
not internationalize anything. Because of this:
1) the tags are not a verbose as I have found them to
be in most situations.
2) there's no 'best practice' we can leverage from
able.
So, does anybody else have any thoughts on what this
convention should
look like? Don, through your examples below
(ActionClass.name,
ActionClass.method.name, name, etc. . .), are you
proposing those
conventions as individual possibilities or a
hierarchy of which the
first one found would be applied. The latter seems
like a good idea to
me. . .except for the fact that I would reorder it
and define the
rule/convention as:
For any key 'example.propertyName' provided as a
shortcut to any of the
ui tags, the label should be displayed based upon the
first of the
following which can be resolved:
1)
getText('ActionClass.actionMapping.example.propertyNam
e')
2) getText('ActionClass.example.propertyName')
3) getText('example.propertyName')
4) 'example.propertyName'
Let me know your thoughts,
David
Don Brown wrote:
This is a tricky one and will take more thought.
Currently, the value
attribute is optional, but how the name is used for
the label key is the
question - ActionClass.name,
ActionClass.method.name, name, etc.
I'd like to see how the Able project will handle
this one, as they are
looking to work over Struts using a comprehensive
convention-based
approach.
Don
David H. DeWolf wrote:
Sounds good to me too. . .
any hope of convincing one of you to apply this
(or a similar) patch
prior to the release:
https://issues.apache.org/struts/browse/WW-1458
Thanks,
David
Don Brown wrote:
I want to roll the Struts 2.0.1 release next
weekend, October 8. A
lot of changes have gone into the code since
2.0.0 and I'd like to
have a solid release that people can check out
after Ted and my talks.
I'm thinking we'll do this at the Sunday
hackathon since I believe
Ted, Wendy, and I will all be present. Any
objections?
Don
--
---
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
---
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
---
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
---
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=44702messageID=90791#90791
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] QuickStart
It works just fine. I suppose it could be its own maven module. What is the motivation for these questions? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=42012messageID=84084#84084 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IDEA weirdness
I wonder if the maven guys released a new version of the IDEA plugin with bugs. Were you re-running the mvn idea:idea command between each time you ran in to problems? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=42003messageID=84087#84087 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts Next != Struts Now (was Issues Upgrading ...)
Handwaving? Grab the code and fire it up. There are a few actions already set up (Login, Logout, Register, etc). On 8/30/06, Don Brown [EMAIL PROTECTED] wrote: Sure, each of these things, by themselves, could be debated and aren't strictly necessary, but taken as a whole, they represent a significant effort to make development easy. It is that overarching vision that I think we are lacking here, choosing rather to debate all these minor features, which will result in a framework that reflects its confused development. True. And to alleviate the confusion, we decided on an overarching vision that included two phases. Struts 2.0 is phase one. Able is a proposal for phase 2. AFAIK, Able-style configuration is still at the handwaving stage. If there is an Able example application available, I'd be happy to review it, so that I can see what we're talking about. In the meantime, let's retain the clear vision that Struts 2.0 is the compatibility release, and save the next generation configurations for phase 2. -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=41993messageID=84088#84088 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Maven build changes
Wendy, That's fine with me - is there any way to make the maven build include those instructions if the property isn't defined and the xwork profile is being used? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37836messageID=82949#82949 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Examples of dyanamic method invocation
I meant to do this last week - just to provide everyone with some more examples of the ! syntax in use: http://jira.openqa.org/secure/CreateIssue!default.jspa http://jira.openqa.org/secure/UpdateUserPreferences!default.jspa http://jira.openqa.org/secure/UserVotes!default.jspa http://jira.openqa.org/secure/UserWatches!default.jspa http://jira.openqa.org/secure/BrowsePersonalProject.jspa http://jira.openqa.org/secure/ViewUserIssueColumns!default.jspa http://jira.openqa.org/secure/admin/jira/TimeTrackingAdmin!default.jspa http://jira.openqa.org/secure/admin/ViewIssueColumns!default.jspa http://jira.openqa.org/secure/admin/util/JellyRunner!default.jspa http://jira.openqa.org/secure/admin/jira/SendBulkMail!default.jspa http://jira.openqa.org/secure/admin/jira/IndexAdmin.jspa http://jira.openqa.org/secure/admin/jira/IntegrityChecker!default.jspa http://jira.openqa.org/secure/admin/jira/LDAPConfigurer!default.jspa http://jira.openqa.org/secure/admin/jira/ViewPlugins!default.jspa http://jira.openqa.org/secure/admin/jira/ViewListeners!default.jspa http://jira.openqa.org/secure/admin/jira/ViewServices!default.jspa http://jira.openqa.org/secure/admin/jira/JiraSupportRequest!default.jspa http://forums.openqa.org/usersettings!default.jspa http://forums.openqa.org/annpost!default.jspa http://forums.openqa.org/post!default.jspa?forumID=3 http://forums.openqa.org/post!reply.jspa?messageID=10397 http://forums.openqa.org/pollpost!default.jspa?forumID=3 http://forums.openqa.org/edit!default.jspa?messageID=10397 http://forums.openqa.org/lock!default.jspa?threadID=3768 http://forums.openqa.org/delete!default.jspa?messageID=10397 http://forums.openqa.org/move!default.jspa?threadID=3768 http://forums.openqa.org/search!default.jspa?objID=f3 - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=41565messageID=82976#82976 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Examples of dyanamic method invocation
Yes, and making dynamic method invocation switchable doesn't affect anyone's ability to do any of this. Agreed. Could you please roll back r436991 and r436971 since without a switch, we cannot explore alternatives that don't require special-case code, nor can we suppress dynamic method invocation for applications that do not wish to use it. I'm happy to reintroduce a switch, but... - It won't be called compatibility switch, which implies something else that isn't the root cause for concern here. - It will be classified as a security switch. - It should be _off_ by default (meaning that it is the same as WW), considering how widely spread the usage is and how there is still serious discussion about even turning it off by default. I think that is the only fair outcome. Like I said in my previous posts, I strongly object to turning it off by default, as I believe there is a far greater number of users who rely on it than who avoid it, as evidenced by these URLs, Hani's recent message, Nick Hill's comments, and Ian Roughley's comments, as well as the open issue with the solution for the cancel button depending on dynamic method invocation via the method: parameter name prefix. Is that fair? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=41565messageID=82997#82997 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Examples of dyanamic method invocation
I think that's a fair outcome, but those URLs are a spurious argument. That's 2 apps, Jira and Jive, not a majority of all apps. Considering that part of why WebWork is where it is today is due to contributions and use by these companies, I'd be very wary to make anything they do not the default. Still, here's a few more: http://dev.carrentals.com/admin/search!input.jspa http://www.bigbark.net/register!input https://struts.hostedqa.com/forgotPassword!input http://www.formicary.net/site/search/Search!default.action http://www.atlassian.com/software/EvaluationDownload!default.jspa http://www.jivesoftware.com/support/login!default.jspa I also know it was heavily used in all the intranet apps I worked on at Cisco. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=41565messageID=83011#83011 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Examples of dyanamic method invocation
Done. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=41565messageID=83030#83030 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r437868 - in /struts/struts2/trunk/core/src/main/java/org/apache/struts2: StrutsConstants.java dispatcher/mapper/DefaultActionMapper.java
struts.core.disableDynamicMethodInvocation Is there a reason to add .core here? Darn - you caught my attempt to very subtly imply that disabling this feature disables something core to Struts. It certainly is in my opinion. :) We don't specify .core in any of the other property names. On that subject, do we need to specify all these settings as properties, or could they be specified in a struts.xml instead? It would be nice if we could configure everything in one place. Yes, I agree, we should do this. The only reason we had it split up before was because we didn't have a WebWork-specific DTD. But we have that now, thanks to Don, we I agree, we should change it. -Ted. On 8/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: plightbo Date: Mon Aug 28 15:39:12 2006 New Revision: 437868 URL: http://svn.apache.org/viewvc?rev=437868view=rev Log: Wendy has a sharp eye Modified: truts/struts2/trunk/core/src/main/java/org/apache/stru ts2/StrutsConstants.java truts/struts2/trunk/core/src/main/java/org/apache/stru ts2/dispatcher/mapper/DefaultActionMapper.java Modified: struts/struts2/trunk/core/src/main/java/org/apache/str uts2/StrutsConstants.java URL: http://svn.apache.org/viewvc/struts/struts2/trunk/core /src/main/java/org/apache/struts2/StrutsConstants.java ?rev=437868r1=437867r2=437868view=diff == --- struts/struts2/trunk/core/src/main/java/org/apache/str uts2/StrutsConstants.java (original) +++ struts/struts2/trunk/core/src/main/java/org/apache/str uts2/StrutsConstants.java Mon Aug 28 15:39:12 2006 @@ -123,5 +123,5 @@ public static final String STRUTS_SERVE_STATIC_BROWSER_CACHE = struts.serve.static.browserCache; /** Allows one to disable dynamic method invocation from the URL */ -public static final String STRUTS_DISABLE_DYNAMIC_METHOD_INVOCATIOn = struts.core.disableDynamicMethodInvocation; +public static final String STRUTS_DISABLE_DYNAMIC_METHOD_INVOCATION = struts.core.disableDynamicMethodInvocation; } -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=41607messageID=83081#83081 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Action ! Method syntax (was Freemarker transform name)
Following up to myself: I want to also make it clear that I'm not opposed to changing my way of doing things, but so far I haven't seen anything that seems any better than what I'm doing now. I'm happy to explain more about how the ! syntax is used with all my forms, so that alternative approaches can be proposed to me. Well, how about a proposal for something that does what you want but meets people's security concerns? Christ - I have proposed things, many times. Why are the words annotations and convention being ignored by everyone. Let's try one more time. 1) Convention-based protection: only allow methods of the form String doXxx() to be called via the request. 2) Annotation-based protection: only allow methods that are annotated with @Public to be called via the request. I'm implementing #2 right now. However, the introduction of doInput() in ActionSupport, the fact that the DefaultWorkflowInterceptor and ValidationInterceptors are configured to ingore the input method in webwork-default.xml, and the pattern being used all over the place in the Showcase should be enough evidence that this pattern has been one that has been quietly pushed forward for a long time to WebWork users. So it's not just that I personally use this style - the framework itself has been designed to accommodate this style. If we're going to remove !, we need to be ready to also change other parts of the framework to recommend the new approach. Umm... but didn't you add a lot of that? And the Showcase just copied what it found already. That's not proving it's a good way of doing things. There are lots of places in the code where changes have been made to accomodate the ! notation, usually to the detriment of the codebase and leading to unexpected bugs later. While I added much of it, parts were added by others. For example, the support for ww:submit method=cancel/ was added by Bob Lee. This is a great way to allow for cancel buttons without having to use javascript to change the form target. This would be impossible to do if multiple entry points per action were turned off. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40932messageID=82479#82479 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Action ! Method syntax (was Freemarker transform name)
Just to step back a moment, let's be clear that the original suggestion, which stemmed from the Rough Spots discussion, was that we experiment with using wildcards to provide the same functionality as the ! syntax. If that experiment provided fruitful, we would then, only only then, remove the hardwired ! in favor of a wildcard solution, that mimicked the same functionality, so that existing pages did not need to change. My understanding was that wildcards was much more about reducing configuration and introducing conventions rather than addressing any perceived issues about multiple entry points on the action. My own initial trial was successful. I was able to substitute a wildcard for the ! in a prior revision of the MailReader application, without changing the server pages. (One exception was a form that didn't specify an action, but I expect few people do that now.) Hopefully, others will make the same trial with their own applications. If we can use wildcards instead of the !, then we can take out excepton code, and focus on stabalizing the code for wildcards generally, instead of ! specifically. Right now, the switch serves two clear purposes. One it closes a security gap, or at least makes the gap optional. Two, it makes it possible for people to experiment with using wildcards in lieu of the bang construct. Now, along the way, in another discussion, I asked if using multiple methods was really a best practice, and the general answer was that alternate methods were considered an elegant and pragmatic practice, and clearly the best practice that anyone has defined. But that was a separate discussion. Yes, this is a best practice. And many people use and depend on being able to invoke those methods from URL constructs (either in the form of ! or with a parameter name such as method:cancel, which addresses cancel buttons on forms). As it stands, I think we are at the point where people need to put what we already have to the test. Can we use the simple, general purpose wildcards *we already have* to mimick the ! functionality? If not, why not? And, can you show us what we can't do in a working example? No, we cannot. The major problem that comes to mind is the cancel button. There is no reason for alarm or discord. The only thing that has a changed is a one-line setting in a properties file. Meanwhile, having the setting is closing a backdoor that some people might overlook, and it is helping us identify where the special-case code is now, so if we are able to *replace* the functionality with general-puroose code, we will know where to make the changes. -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40932messageID=82480#82480 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The importance of defaults
Related to the ! thread, but a more general concept that I want to bring up and underscore. This is my mini manifesto on why we can't treat the default options and settings in Struts lightly. These are all my opinions, but I think they are also fairly common sense. Goal: It should be our goal to ship Struts in a way that it is pre-configured with default settings that mimic the agreed upon styles and techniques by the very best Struts users and developers. This is critically important. Suppose we ship struts with all sorts of options turned off by default, but the core set of developers turn those options off in all our apps. What will happen is that the user base, who generally will not change the defaults, will use Struts under different constraints than the developers. A disconnected will form, and the users will push for changes that the developers will not understand or see in their daily development. We should tread very carefully whenever we talk about options and switches and say, well don't worry, they can turn it on if they want. If every developer is in agreement, then it is fine. But if, say, Ted or Don or Patrick doesn't agree, we need to really dig in to the heart of the issue. Because odds are that what is happening is that two very different styles of development are happening by different team members, and therefore the product isn't being optimized due to competing interests. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=41361messageID=82485#82485 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Action ! Method syntax (was Freemarker transform name)
I'm not 100% sure how that one works... does it depend on ! somehow? I've been stuck on an older release of WebWork for a while... foo!bar.action is the same thing as foo.action?method:bar=whatever It is defined in DefaultActionMapper. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40932messageID=82487#82487 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
Ted, My opinion on this is that the ! syntax should be used strictly as a URL pattern and not anywhere else. That means we shouldn't name files like foo!bar-validation.xml, but instead figure out another way to map it to a context. Currently, you can name those files foo-bar-validation.xml where foo is the class and bar is the context (ie: the action name). It might be time to instead re-evaluate the context being in the file name and instead allow for validation rules to be bound to the context and/or method invocation _inside_ the XML file. Ie: you'd have one foo-validation.xml and then in there you could have validation rules that only map to certain action aliases (contexts) or only when certain methods are being invoked. Make sense? PS: The reason I say the ! syntax should be strictly left to a URL pattern thing is that we should encourage people experimenting with their own ActionMapper any time they choose. They could, for example, change ! to be / so that it looks more like a path. We wouldn't want to bleed our the ! pattern to other parts of the application. On 8/2/06, Patrick Lightbody [EMAIL PROTECTED] wrote under [s2] Validation: One thing I'd add before Jason chimes in is that you can tie validation to the action name by naming the file ActionClass-actionName-validation.xml. But you still also must have the action class in the filename as well. OK, then to complete the idiom, do we support * ActionClass!alias-validation.xml to specify context-based validation for the alias command? And, do we support action name=Something!different class=somePackage.Something method=veryDifferent result input=veryDifferent.jsp / /action action name=Something class=somePackage.Something result input=Something.jsp / /action So that an action element could override the settings for selected !alias methods (and let the others fall-thru to a base action)? Is the ! idiom promoting a method to a command (which is to say action mapping)? If so, then I believe the idiom is not fully expressed. If the ! idiom is creating a virtual command, then shouldn't we be able to declare a static command using the same syntax, and/or tie other resources (like the validator) to the virtual command? Should the ! mean: if this command doesn't exist, look for a command by the name *!, with a method by the name !*, and then use command!method as the cannonical command name. I believe the fundamental question is * When we say Something!diffferent, do we mean to ** pass different as an implicit method= attribute to the Something command, or ** create a new ad-hoc Something!different command, that inherits settings from a Something command. -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] My - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135messageID=82511#82511 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
Agreed. On 8/25/06, Patrick Lightbody [EMAIL PROTECTED] wrote: Make sense? Yes. Since the validation files are acting like code-behinds, being able to bind to a code artifact, like the method, does make sense to me. I can understand why we would also want to bind to the action/context, but *not* being able to bind to the method makes the idiom seem incomplete. -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135messageID=82525#82525 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Retain the ! idiom but disable it by default
Done. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=41363messageID=82541#82541 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Action ! Method syntax (was Freemarker transform name)
I guess why I don't like this mentality is that we have these kinds of security holes all over the place. If you expose getters or setters that are unsafe in your action or _any_ of your model objects, you can get that problem. The fact is that with dynamic reflection that is controlled by URL requests/params, you should consider anything remotely close to the Action or its object graph to be considered unsafe until you've explicitly added your own security layer. To simply add this switch and give the impression that it is now safe would be very misleading. While I see your point that this one flag won't make everything 100% secure, at least with getters and setters, you know that's what they're designed to do. You can also control the setting of properties from the request params via the interceptor stack, including filtering out params you don't want set. You can't (currently) control the ! notation and what methods it can call. I'd say we need to group a bunch of security-related settings in the config and let people choose, but I'd agree with Ted that the more secure option should be the default, especially if we're talking about deprecating and removing the ! notation in the future. First off: we're *not* deprecating and removing the ! notation at this point. That is what this discussion is entirely about. Why not disable getters and setters by default too and require people pull out the request parameters by hand until they switch the security flag? Obviously because it makes no sense. It is core to working with actions. And I'm here to argue fervidly that the pattern of URLs like create!input is way too common in my applications to just turn off by default without some longer discussion. My goal is to make sure that the leaders of Struts have their styles of web development represented in a common set of defaults - it would be a big mistake for Struts and a big loss to the community if I went off with my own ActionMapper and never looked back. I've put forward alternatives, such as a convention (doXxx) or annotation (@ActionMethod) to indicate that methods can be called. But I'm currently very far from convinced that turning off that switch by default is a good idea at all. I'd like for Ted to respond to my proposed alternatives. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40932messageID=82257#82257 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Action ! Method syntax (was Freemarker transform name)
I need everyone to understand this: the goal should be for us (the project leaders) to agree on a style of development using Struts that we can all feel comfortable recommending as the default starting point. For example, I think the default starting point should be on that encourages limited interceptor stacks (relying on stack logic flags/conventions instead). I also think that ! is a very common technique and want to encourage it, or something like it. Following up to myself: I want to also make it clear that I'm not opposed to changing my way of doing things, but so far I haven't seen anything that seems any better than what I'm doing now. I'm happy to explain more about how the ! syntax is used with all my forms, so that alternative approaches can be proposed to me. However, the introduction of doInput() in ActionSupport, the fact that the DefaultWorkflowInterceptor and ValidationInterceptors are configured to ingore the input method in webwork-default.xml, and the pattern being used all over the place in the Showcase should be enough evidence that this pattern has been one that has been quietly pushed forward for a long time to WebWork users. So it's not just that I personally use this style - the framework itself has been designed to accommodate this style. If we're going to remove !, we need to be ready to also change other parts of the framework to recommend the new approach. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40932messageID=82287#82287 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Action ! Method syntax (was Freemarker transform name)
First off: we're *not* deprecating and removing the ! notation at this point. That is what this discussion is entirely about. Not YET... that's what the conversation was about as I read it... when, not if. It's not a when to me - it's an if and a why type of discussion. I really should just go and revert the previous changes that turned it off by default, since they were done without any consent on my end. Why not disable getters and setters by default too and require people pull out the request parameters by hand until they switch the security flag? Obviously because it makes no sense. It is core to working with actions. And I'm here to argue fervidly that the pattern of URLs like create!input is way too common in my applications to just turn off by default without some longer discussion. My goal is to make sure that the leaders of Struts have their styles of web development represented in a common set of defaults - it would be a big mistake for Struts and a big loss to the community if I went off with my own ActionMapper and never looked back. Turning off property setting is a spurious argument. It's the most common thing people want to do. The ! notation was always an advanced feature (hack). For my style of development, the flag will be turned off to make sure no-one's trying to use it. And I'm saying that it's not a hack nor an advanced thing. I literally use it for _every_ form. It's a very common thing, which leads me to... I've put forward alternatives, such as a convention (doXxx) or annotation (@ActionMethod) to indicate that methods can be called. But I'm currently very far from convinced that turning off that switch by default is a good idea at all. I'd like for Ted to respond to my proposed alternatives. So if you know the setting is there and you can turn it on, even if it's off by default, then where's the harm? We're just saying that for the new user, who isn't familiar with the ! notation, they don't get surprised when someone can hit any method on their action using the ! notation. You're missing my entire point, so I'll repeat it again: My goal is to make sure that the leaders of Struts have their styles of web development represented in a common set of defaults - it would be a big mistake for Struts and a big loss to the community if I went off with my own ActionMapper and never looked back. I need everyone to understand this: the goal should be for us (the project leaders) to agree on a style of development using Struts that we can all feel comfortable recommending as the default starting point. For example, I think the default starting point should be on that encourages limited interceptor stacks (relying on stack logic flags/conventions instead). I also think that ! is a very common technique and want to encourage it, or something like it. IMPORTANT: If we can't agree on a default starting point for all users, there is absolutely no way we'll have even close to the success of something like Rails (which is clearly the goal of the original Struts Ti proposal). - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40932messageID=82285#82285 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Whatever Struts ends up doing, we'll also do in XWork. On 8/22/06, Don Brown [EMAIL PROTECTED] wrote: I'd rather use java.util.logging than commons-logging, but I think both are overkill for a library. Of course, our library is an extension of the XWork library. Do we want to cooridnate what we do here with what XWork 2 does / should do? Otherwise, are not Commons Logging and Log4J going to come in through the XWork backdoor, bring all the same problems along? What does Spring do about logging? -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40994messageID=81971#81971 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Freemarker transform name
Ted, I'm still not yet on board with removing the ! syntax until we have a solid replacement. I don't think pointing to wildcards is enough, especially since you would have to create a wildcard for every namespace. That is more configuration than I'm willing to recommend to our users. I would, however, be open to introducing the type of action mapping and convention-based configuration I have put in to Able, while still also supporting struts.xml: http://svn.opensymphony.com/fisheye/browse/sandbox/able/src/main/java/com/opensymphony/able/webwork/AbleActionMapper.java?r=7 http://svn.opensymphony.com/fisheye/browse/sandbox/able/src/main/java/com/opensymphony/able/webwork/AbleConfiguration.java?r=4 But without something like the above, or with a way to use wildcards for multiple namespaces, I cannot readily agree to dropping the ! syntax. I know that the overriding concern is security. I have a few thoughts on that: 1) I would suggest reaching out to the big WebWork users (Jive, Atlassian, Google, others) to see if this is something that has concerned them in the past. My feeling is that it isn't a big concern, because they understand anything in an action is fair game to URL manipulators and that that has always been clearly understood. 2) Assuming we want to make method invocation more obvious, we could require an annotation or a convention such as as doXxx, such as RIFE does. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40884messageID=81481#81481 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Action ! Method syntax (was Freemarker transform name)
Sure, I agree with all of that. And I've said I'm opening to nailing this down more with conventions and/or annotations. I'm even open to a switch to turn it off. What I'm not open to is just removing/deprecating it entirely without addressing the fact that it is _widely_ used in a ton of applications and, at least in my case, I continue to use it as I find it very useful and not a security risk one bit. Removing it would really cause issues for me, so I want us to explore other ways to address the security aspect besides just taking it out by default. The reason this is so important to me is that we, the Struts development team, need to, as responsible leaders for the Struts community, do our best to all try to recommend the same style of web development to the users. If I'm off using ! syntax and the ActionMapper from Able, and Jason has a technique that involves 4 or 5 interceptor stacks, and Don is using a single stack but 100% wildcards, we're sending a bad message to the community. So let's dig deep and get to a consensus on what we think the right way to recommend working with Struts is. On 8/21/06, Don Brown [EMAIL PROTECTED] wrote: I know that the overriding concern is security. Here's the thing. Regardless of what we think, there are independant security organizations that review security issues for high profile frameworks. If we don't control the bang with a switch that defaults to off, we are liable to get pinged for this. Struts 1 was pinged for the way we handled cancel, and we had to come up with a fix. I doubt that trying to explain away a security risk by saying Altassian doesn't think it's a problem is going to result in the security alert being lowered. There is a also a fundamental ASF principle that Security is a mandatory feature. Regardless of whether we end up saying using the ! alias is acceptable, or even preferred, we should retain the switch that turns it on, so that teams make an informed decision as to its use. -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40932messageID=81539#81539 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Action ! Method syntax (was Freemarker transform name)
OK, that all sounds good. My only request would be then: can we un-deprecate the ! syntax and keep it on (by default), while still giving the option to turn it off and perhaps set up a Security conscience page on the wiki that catalogs all these switches? On 8/21/06, Patrick Lightbody [EMAIL PROTECTED] wrote: Sure, I agree with all of that. And I've said I'm opening to nailing this down more with conventions and/or annotations. I'm even open to a switch to turn it off. Which is where we are, right now, today. So let's dig deep and get to a consensus on what we think the right way to recommend working with Struts is. I'm all for that (or at least the right ways), and I think we all would agree that the switch isn't going to be removed unless we are all happy with whatever alternatives we find. As PMC members, we each have the unilateral right to veto a change to the codebase on technical grounds. If alternatives can't accomplish what the bang can accomplish, without bloating or obfuscating the configuration, then I think everyone would agree that would be a technical ground. (Or at least one of us would: if the technical ground isn't obvious, all you need is a second.) In my own mind, I never thought we'd remove the switch before phase 2, when there might be other breaks in backward compatiblity. Right now, the last thing I want to do is disenfranchise the WebWork community, because I want guys like Rainer over here helping me push out Struts 2.0.x releases. :) -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40932messageID=81550#81550 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Action ! Method syntax (was Freemarker transform name)
I guess why I don't like this mentality is that we have these kinds of security holes all over the place. If you expose getters or setters that are unsafe in your action or _any_ of your model objects, you can get that problem. The fact is that with dynamic reflection that is controlled by URL requests/params, you should consider anything remotely close to the Action or its object graph to be considered unsafe until you've explicitly added your own security layer. To simply add this switch and give the impression that it is now safe would be very misleading. On 8/21/06, Patrick Lightbody [EMAIL PROTECTED] wrote: OK, that all sounds good. My only request would be then: can we un-deprecate the ! syntax and keep it on (by default), while still giving the option to turn it off and perhaps set up a Security conscience page on the wiki that catalogs all these switches? I'd rather not get into the habit of treating security as an option that people can enable as an afterthought :) I'm fine with tabling the notion of deprecation for now, but people who want to use this syntax should have to make that choice by adding the switch to the struts.properties file. The key reason it is a security issue is because people don' t think about the consequences of a client being able to call any no-argument public method on any object that is serving as an Action, including all the super classes of that object. Since Actions can be POJOs now, it's very important that we lock these issues down, and open up the functionality only when someone makes that choice. Since teams migrating from WebWork will have to make other changes, this is the ideal time to introduce the switch, so that it just one other thing to do. -Ted. On 8/21/06, Patrick Lightbody [EMAIL PROTECTED] wrote: Sure, I agree with all of that. And I've said I'm opening to nailing this down more with conventions and/or annotations. I'm even open to a switch to turn it off. Which is where we are, right now, today. So let's dig deep and get to a consensus on what we think the right way to recommend working with Struts is. I'm all for that (or at least the right ways), and I think we all would agree that the switch isn't going to be removed unless we are all happy with whatever alternatives we find. As PMC members, we each have the unilateral right to veto a change to the codebase on technical grounds. If alternatives can't accomplish what the bang can accomplish, without bloating or obfuscating the configuration, then I think everyone would agree that would be a technical ground. (Or at least one of us would: if the technical ground isn't obvious, all you need is a second.) In my own mind, I never thought we'd remove the switch before phase 2, when there might be other breaks in backward compatiblity. Right now, the last thing I want to do is disenfranchise the WebWork community, because I want guys like Rainer over here helping me push out Struts 2.0.x releases. :) -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40 932messageID=81550#81550 -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. * http://www.husted.com/struts/ -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40932messageID=81572#81572 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: s2 nightlies for j4 compatibility
Any reason we can't use Maven itself to build the jars? I believe I had that working at some point. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40424messageID=81288#81288 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Snippet Macro
Ted, Can you email me the changed files? I'll get them checked in once I have them in my inbox. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37908messageID=81289#81289 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Random IDs for form elements - Why?
We should give them unique sequence IDs for each form. We should never encourage random numbers - that makes things much harder to automate for testing, which has always been a strong point for WebWork. Any chance you can make the change in WebWork 2.2.3 too before the release? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40158messageID=79909#79909 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Random IDs for form elements - Why?
You can always view the latest reports here: https://struts.hostedqa.com/project/7/session/suite/list I can set up email alerts to go to some list (which one?) as well. And of course, just let me know if you want a HostedQA account. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40158messageID=79910#79910 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Random IDs for form elements - Why?
Awesome work, Toby! - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40158messageID=79981#79981 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Random IDs for form elements - Why?
http://mail-archives.apache.org/mod_mbox/struts-commits/200608.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/struts-commits/200608.mbox/[EMAIL PROTECTED] A few questions: - What is FormButton.java? Is that new? - Why are we rendering random numbers? Why not something more predictable, such as a sequence that starts at zero on every page load? I ask because tm_jee's recent changes caused a test on HostedQA to fail, since the submit button ID is no longer predictable, and therefore no longer scriptable. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=40158messageID=79815#79815 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Convention over Configuration (was Validation)
Ted, while I have no opinion on case, I can say that my comments in these threads has been driven entirely from real world experience. This URL: https://struts.hostedqa.com/project/7/session/suite/list Maps, via conventions, to com.hostedqa.action.project.session.suite.ListAction So there, now you have a reason for deep paths, and a reason why today's simple wildcards won't work :) Patrick On 8/3/06, Patrick Lightbody [EMAIL PROTECTED] wrote: Don and I talked in-depth about using wildcards to do the style of conventions I am talking about, and we found that it would require a much more complex implementation of wildcards. Don, can you add to that? Why not focus on starting with conventions that are achievable with the wildcards we already have, and then expand on the wilcard capability best on actual experience, that *proves* a need for more complexity. I would also suggest that we only add more complexity grudgingly and only when *required* to do so, not simply to placate an arbitrary convention that happens, for no particular reason, to be popular. Case is a good example. Outside of the JavaBean design patterns, I believe Java itself is indifferent to case. If the language doesn't care, why should we? -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39339messageID=78118#78118 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Convention over Configuration (was Validation)
Heh - well, that's how this was implemented in the first place. I wrote my own ActionMapper. My point is that I have seen a lot of success with a combination of ActionMapper+Convention-based-configuration, and I think we should really think about pushing this to a broader set of users. I think Don and I agree though - implementing this stuff as wildcards would be very difficult. Our thought instead was to implement it as the recommended approach to get started, but then allow for all the standard overrides via XML that you can do today in WebWork, as well as wildcard support there. Then everyone wins. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39339messageID=78166#78166 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
Jason, I have to disagree with you on this. I've written a lot of WebWork apps and multiple aliases is rarely used (maybe 1-5% of the time for me). Perhaps you can give the common examples you come across so that we can understand your style better? I'm not suggesting that try to make it impossible to use multiple alaises. But I am suggesting that the Struts 2 group should recognize that multiple aliases are not a recommended practice, in the same way that chaining actions are not a recommended practice. I disagree. Multiple aliases is a pattern I recommend and it's very useful. CRUD screens in particular almost require it, otherwise you get lots of classes and deep hierarchies to try to make the classes as common as possible, when they could just be the same class. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135messageID=77958#77958 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
OK, I think I see where you are coming from. I guess we are coming across a difference of opinion, but let me explain how I would do the exact same thing: - Like you, I would have a single action class that has multiple methods to invoke (input, save, list, whatever) - I would not, however, have different stacks. In fact, I go just the opposite: I try to have one global stack for every action. In cases like yours where the stack needs to behave differently, I design the interceptor to look for an annotation or convention, much like today's WorkflowInterceptor and ValidationInterceptor do. - I would have one action configured (well, actually pulled in via convention) and then use foo!bar syntax. What do you think of that? Of course, my approach won't work with the efforts Don and Ted are pushing for: removing foo!bar syntax as a recommended option. Ted, Don: what would you guys do in the scenario Jason provided? I should point out that in my scenario, there is no need for any configuration - just some common conventions that tend to work very well (for me). I wouldn't even be happy doing a wildcard configuration for each entity, though I think that would be better than Jason's approach (assuming you could define a single stack with different behaviors). Jason, I have to disagree with you on this. I've written a lot of WebWork apps and multiple aliases is rarely used (maybe 1-5% of the time for me). Perhaps you can give the common examples you come across so that we can understand your style better? I think I posted this last week, but here's the Invoice CRUD action definitions: !-- Invoice CRUD Actions -- action name=listInvoice e class=com.eplus.app.invoice.action.InvoiceCrudAction method=list interceptor-ref name=listStack/ sult name=CRUD-list type=freemarker/template/eplus/metaDataList.ftl/re sult /action action name=editInvoice class=com.eplus.app.invoice.action.InvoiceCrudAction interceptor-ref name=editStack/ ction action name=saveInvoice class=com.eplus.app.invoice.action.InvoiceCrudAction method=save interceptor-ref name=crudStack/ ction action name=deleteInvoice class=com.eplus.app.invoice.action.InvoiceCrudAction method=delete interceptor-ref name=crudStack/ /action at for each entity in the system... - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135messageID=77972#77972 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Convention over Configuration (was Validation)
Don and I talked in-depth about using wildcards to do the style of conventions I am talking about, and we found that it would require a much more complex implementation of wildcards. Don, can you add to that? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39339messageID=77988#77988 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
I think you missed the main point I was trying to make, which is that the concepts of multiple stacks is something I avoid entirely. Instead, I believe in one stack that is capable of providing different behaviors based on conventions. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135messageID=77994#77994 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Free HostedQA account available
Wendy, Your account is set up - I'll follow up with details by email. I don't see the selenium profile in the Struts 2 poms - is this a 1.x thing for now? HostedQA doesn't need Selenium Core to be packaged in the webapp. It also can import HTML files used by Selenium Core (and generated by Selenium IDE), but it stores them on the server in its own custom format. If you think it is necessary to store tests in SVN with the code, we should talk and work out the requirements for such a feature and I'll get it in the queue. As for automating Selenium tests in general, Selenium Core isn't well-suited for the type of end-to-end automation you're looking for. However, Selenium Remote Control is and may be able to help. Though, in my very biased opinion, and as the creator of Selenium Remote Control, I'd really recommend just using HostedQA. It is a lot easier to set up (2 ant tasks) and supports a lot more features :) Patrick - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29580messageID=77584#77584 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
Ted, Good questions. Related to that - why is it than i18n resource bundles are tied to the action class rather than the _view_ (the view would tend to make more sense, I believe). This is the kind of stuff we should clean up with Struts 2. One thing I'd add before Jason chimes in is that you can tie validation to the action name by naming the file ActionClasss-actionName-validation.xml. But you still also must have the action class in the filename as well. Perhaps the best thing to do to address these little issues is to mock out what an ideal webapp would look like using ideal configurations/annotations. It won't work, of course, but it would be a great blueprint for what we should aim for. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135messageID=77586#77586 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
I would think an ideal application would have the following: - zero configuration (using conventions instead) for actions and results - overrides possible in struts.xml, including wildcards - result overrides via annotations if struts.xml is too verbose - annotations for validations and type conversion - overrides possible in xml - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135messageID=77604#77604 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Free HostedQA account available
To automate tests in HostedQA, just log in and import a test from Selenium IDE or create a new one. It will get run within 30 minutes of a checkin. HostedQA does have an import tool, so you could store the tests in HTML format in SVN. But there isn't an automatic way to import those in (yet). I will see what we can do about that. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29580messageID=77651#77651 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2 in Production?
I'm close to doing it for HostedQA... I've already done the integration on a branch, but I just haven't deployed it yet as I've been busy with other things. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39072messageID=77279#77279 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Application Array (was (WW-1388) Shopping Cart Example throws HTTP 500)
+1 On 7/26/06, Don Brown (JIRA) [EMAIL PROTECTED] wrote: I noticed this as well. If no one steps up to maintain it, I'm inclined to remove it competely. I'd like to minimize the number of example applications we maintain, and it seems like any advanced AJAX shopping cart could just as easily be part of the showcase app. I'd suggest we go with * A collection of independant use-case examples (Showcase) A realistic best-practices application (MailReader) A no-frills application template (Blank) And a Portlet example. Here's some application updates that I would like to do: * Migrate Showcase to a Cookbook format, so people can view the result and the code online. Add a shopping cart example if we can. ** http://planetstruts.org/struts-cookbook/ * Extend MailReader to include an alternative DAO that can be used with a SQL DBMS. * Extend MailReader to utilize other cool extensions, like Spring WebFlow, Struts Menu, and DisplayTag. We could also substitute MailReader with another likely application, with a more room to grow, like Caveat Emptor, if we can get past the licensing issues. Though, I'm also working on a port of a working model 1 application to Struts 2, which we might be able to use as a realistic, best practices example (in lieu of MailReader). * http://sectionxsports.com/ * http://opensource.atlassian.com/confluence/oss/display /sportsforge/Home We're trying to do this one right from the ground-up. Feel free to jump in and join the fun! -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=38520messageID=75996#75996 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Request parameter weirdness
Correct, the includeParams attribute needs to be set to 'none'. The URL tag isn't meant to be used with a query string. The best way to write this would be: s:url action=Welcome s:param name=request_locale value=en / s:url The reason is the url tag has this includeParams tag, which can automatically include all the query string parameters in the URL. The default value is GET, eaning all the GET parameters will be automatically included in the final URL, which is what we see here. Don Ted Husted wrote: So, in the MailReader app, we are changing the locale via a link like this: h3Language Options/h3 ul lia href=s:url action=Welcome?request_locale=en/English/a/li lia href=s:url action=Welcome?request_locale=ja/Japanese/a/li lia href=s:url action=Welcome?request_locale=ru/Russian/a/li /ul But, when the link is invoked, it starts rewriting the selected value back to all the links. (Try it and see.0 * http://planetstruts.org/struts2-mailreader/Welcome.do In the case of changing locales, this can negate changing it back since the current value is being written to the links. Is this the expected behavior? -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=38532messageID=75998#75998 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
With the understanding that this is an issue that needs to be treated carefully to avoid confusion, I think we should really give some serious thought to this. As someone who _has_ actually done annotation-based result mapping (I have setups with no xwork.xml - I can explain more if requested), I can say it still isn't pretty, especially when it comes to redirects and I want to parameterize some data in the redirect. I'm not saying I'm +1 on it (yet), but I think that Tim has a lot of good insight here as someone who has worked on (and created) a framework that works in this way. Similiarly, Don (and all Struts 1.x developers) have done the same thing. We shouldn't toss out their words so quickly. I'd like to see an official proposal of how this would work, including how we'd deal with subclassing ActionSupport (ie: ActionSupport wouldn't be able to provide a method signature for both execute methods). One option is to get rid of the need to subclass and push all the logic in ActionSupport in to parts of the API that Bob is working on. Patrick Being able to return Result instances from Actions doesn't necessarily mean the lack of reuse of Results. This is equivalent to saying that because it's Java code you can't reuse it. I didn't realize that XML was the solution to lack of reuse in OO ;) Seriously though, it's not uncommon in Stripes where multiple actions have the same resolution to simply factor that out to a single method or even a constant sometimes. Given your CRUD example there's no reason you couldn't setup a crud Action with multiple methods for add (), update() delete() etc. that also had abstract methods for the list-page result and the details-page result. Then not only would you have reuse of your Result information, but you'd have all your action/navigational information in one place and completely standardized across CRUD beans. The approach may not be for everybody, I understand. But sometimes f you let go of the XML and start doing things in code, you start to see different approaches that achieve the same goals. I'm sorry if hat sounds condescending. All I'm trying to do is make you think outside of the box you are in as a WW core developer (obviously, I have my own box, but that's another story...) -t On Jul 25, 2006, at 11:22 PM, Jason Carreira wrote: Could you give an example how multiple mappings for a single action is used with common CRUD actions? Don Ok, here's what our Invoice CRUD action mappings look like: action name=listInvoice class=com.eplus.app.invoice.action.InvoiceCrudAction method=list interceptor-ref name=listStack/ result name=CRUD-list type=freemarker/template/eplus/ metaDataList.ftl/result /action action name=editInvoice class=com.eplus.app.invoice.action.InvoiceCrudAction interceptor-ref name=editStack/ /action action name=saveInvoice class=com.eplus.app.invoice.action.InvoiceCrudAction method=save interceptor-ref name=crudStack/ /action action name=deleteInvoice class=com.eplus.app.invoice.action.InvoiceCrudAction method=delete interceptor-ref name=crudStack/ /action A better example of reusing the same action with the same method several times is our DomainObjectLister. We're still working out the entity meta-data we've been building, so I foresee this continuing to evolve, but it's pretty simple already. In the future you'll just need to configure it with the domain type. action name=getVendorRelationships class=com.eplus.lib.web.action.DomainObjectLister param name=domainClasscom.eplus.biz.catalog.mgmt.model.Ve ndorRelationship /param param name=visibleFieldsvendor.name/param param name=idFieldid/param param name=sortColumnvendor.name/param result name=success type=freemarker/template/ eplus/lists/domainObjectTable.ftl/result /action action name=getBuyerCatalogs class=com.eplus.lib.web.action.DomainObjectLister param name=domainClasscom.eplus.biz.catalog.mgmt.model.Bu yerCatalog/ param param name=visibleFieldsname,description/param param name=idFieldid/param param name=sortColumnname/param result name=success type=freemarker/template/ eplus/lists/domainObjectTable.ftl/result /action -- --- Posted via Jive Forums http://forums.opensymphony.com/thread.jspa? threadID=38338messageID=75787#75787 -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: [s2] Snippet Macro
The snippet binary is attached with a comment indicating the source and date. Our snippet macro is a lot more advanced than the one you linked to. It is based on that one, however. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37908messageID=75313#75313 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2.0.0 - Tag it and Roll it?
Sounds good to me, provided everyone is aware that 2.0.1 and 2.0.2 will likely have some large changes. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=38227messageID=75314#75314 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Tag prefixes
Nathan, I don't think tools will work for us for now because of the body tag requirements. Perhaps Velocity 1.5 will help? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37739messageID=74500#74500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Maven build changes
Yup, the xwork profile is very nice for when generating the IDEA projects. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37836messageID=74501#74501 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0.0 - STATUS
Would it be helpful if we set up a maven2.opensymphony.com which hosted the xwork snapshots? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37887messageID=74502#74502 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Standard procedure upon modification of XWork2 code that would affect Struts2
To follow up to my other forum post I just made - sounds like a maven2.opensymphony.com would fix this stuff. I'll get started on that. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37898messageID=74503#74503 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Snippet Macro
Ted - you have to ask me nicely. Just kidding. Basically, the snippet macro is currently located here: https://opensymphony.dev.java.net/source/browse/opensymphony/wiki/snippet/ I build it in IDEA (really ghetto, I know) and just upload the jar. The macro binary works in both the OpenSymphony and Struts wikis (see the SnippetMacro.java for the URLs that are encoded). I would say we should eventually make a copy of the snippet macro and check it in to the struts codebase. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37908messageID=74505#74505 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Tag prefixes
I think surl is fine. Not super pretty, but I'd rather use the prefix s for JSP, FM, and Velocity than come up with different prefixes for each and/or use the s2 prefix. My second choice would be the s2 prefix. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37739messageID=74102#74102 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Dojo widgets?
+1 to any side projects being at OpenSymphony. I think it will help keep the bond between Struts and OpenSymphony to continue to be a close one. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37238messageID=73877#73877 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OS Jive forum for USER list?
We could do this, though I think it would actually be better if we just created a forums instance for Struts in the first place. Can we use the Zone for that? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37671messageID=73874#73874 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test failures...
FYI - I'm working on a maven2 repo for opensymphony that will resolve this issue. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37086messageID=73119#73119 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Distribution contents?
This is a good question. I've wrestled with this a lot with WebWork. A few thoughts: - Does documentation have to be included in the release, or is connectivity good enough these days to let us get away with just pointing users to the wiki? - If we are to include a war file for the sample apps with the release, the release would become huge (hundreds of megabytes). That's because many of the same dependencies would be repeated in each war file. In WebWork, we encouraged quickstart and/or an Ant script to build the war file as needed. I'm open to changes from the webwork-style release... I never felt it was great. I just couldn't put together something better :) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=36838messageID=72466#72466 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Would like to remove Ant build from Struts 2
Ted, the javadocs problem may be the case, but remember we can get around those glitches by utilizing the ant plugin and doing that kind of stuff in Ant. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=36712messageID=72168#72168 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Taglib prefix
+1 - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=36623messageID=72169#72169 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Would like to remove Ant build from Struts 2
Probably, though I haven't looked in to it too much yet. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=36712messageID=72174#72174 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
+1 - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=35827messageID=70400#70400 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
My quick thoughts: I think realistically either of the following two outcomes are positive developments for everyone: 1) We move in the direction of Struts 2.0, which houses all SAF2 and Shale and get back for it being OK for folks to say, I use Struts. We've all said we want to work together closer, but it's just talk until we take action to do so. This strategy, as proposed by Don in this thread, would be the first step in taking action. 2) Shale becomes a TLP. We continue to share code and ideas where it makes sense, but that is entirely optional. This is effectively what we have now, except that it would be formalized. I would prefer option #1, but I know it could be hard to pull off. Either way, both are good routes to go down and would be healthy for the community. Patrick - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=34915messageID=68478#68478 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Upgrade Dojo toolkit
Just to add to what Jason already said: no one is suggesting getting rid of Dojo, just that we'd move the ajax theme as it exists today over to the new dojo theme and then the new ajax theme would be a simpler implementation based on DWR and possibly Prototype. When users need more, they are free to use the dojo theme and get their hands dirty with the Dojo framework, as Jason has done. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=34813messageID=68102#68102 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Removal of AroundInterceptor and doXXX support from xwork
+1 for removing them - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=34665messageID=67801#67801 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Renaming XWork packages (was Poll: What part of a Struts...)
How about com.opensymphony.xwork2? :) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=34229messageID=66656#66656 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Struts Action 2.0.0 Issues
Speaking of reviewing the commit messages... can we get FishEye set up? I'd love to use RSS to review the commits :) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=33879messageID=66381#66381 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Proposal: Remove explicit support for action!method syntax
Don, I'm totally in favor of that, but only if we make sure that struts-action-default.xml (originally webwork-default.xml) includes this pattern as a default. Does that seem fair? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=34032messageID=66382#66382 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action2] STATUS - Release Plan
Ted, The plan looks solid. There may be a few other things we might try to sneak in, but what you have there is definitely the core plan. Let me know if you need help with the snippet plugin - I have the source code and can deploy a new version if it is acting up or giving you trouble. Patrick - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=33460messageID=65332#65332 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SAF2] Default workflow
Dave,
I think you are thinking about this the same way we are. Bob Lee and I agreed
when we met up during JavaOne that there should be just one stack to handle 90%
of the needs of users. The actual logical differences in the stack (form submit
vs. view) should be handled by conventions and/or configuration (either XML
or annotations). Your marker interface, Submittable, represents that same line
of thought.
I'll ask Bob to comment on what his thoughts are around this.
Patrick
Hello all,
On this page:
http://wiki.apache.org/struts/StrutsActionRelease200
There is, under the new features heading a reference
to the
validation/workflow issues brought up on this page:
http://wiki.apache.org/struts/RoughSpots?action=show
Under the main list, item number 16, and under
Patrick's list, item
number 4 and 5, there is discussion of the default
workflow and its
relation to the idea of view vs. update requests to
the same action.
I haven't seen any discussion of this on the dev
list, and i'm wondering
if anyone is actively working on this and what
directions are being
considered. In trying to work this out for myself, i
came up with a
simple solution for the main use case, and i would
like to share it here
and ask for comments.
The main idea is that the Prepareable interceptor is
used to setup the
view, and another interceptor called
SubmittableInterceptor is added to
the end of the default interceptor stack and is used
to determine if a
form submission has occured. A marker interface
called Submittable
allows the user, via a boolean wasSubmitted method,
to determine how the
action will determine if a form submission has
occured, whether it be
the POST vs GET idea, the inclusion of a hidden flag
field, or the
presence of a submit or button parameter. It also has
a submit method
that can be used optionally to process the submission
and return a
result string.
The SubmittableInterceptor will see if wasSubmitted
returns true, and if
so, run the submit method. If the submit method
returns a result string,
the interceptor returns that, otherwise the
interceptor stack invocation
continues. If the form was not submitted, the
interceptor returns the
INPUT result, displaying the form, which has been
setup by Prepareable.
My BaseAction extends ActionSupport and implements
Submittable and
allows for the inclusion of the
SubmittableInterceptor into the default
stack, with default behavior that does nothing.
The Validate method of the action will also check
wasSubmitted to
determine if it should validate, this could be
eliminated by either
putting SubmittableInterceptor before the
DefaultWorkflowInterceptor or
by putting the SubmittableInterceptor logic in
DefaultWorkflowInterceptor.
The code:
[code]
public interface Submittable {
boolean wasSubmitted();
String submit();
}
[/code]
SubmittableInterceptor intercept method:
[code]
public String intercept(ActionInvocation invocation)
throws Exception {
Object action = invocation.getAction();
if (action instanceof Submittable) {
Submittable submittable = (Submittable) action;
if (submittable.wasSubmitted()) {
String submitResult = submittable.submit();
if (submitReturn != null !
submitReturn.equals()) {
return submitResult;
}
else {
return Action.INPUT;
}
return invocation.invoke();
public class BaseAction extends ActionSupport
implements Submittable {
public boolean wasSubmitted() {
return true;
}
public String submit() {
return null;
}
}
public class TesterAction extends BaseAction
implements Preparable,
ServletRequestAware {
private HttpServletRequest request;
public void setServletRequest(HttpServletRequest r)
{
this.request = r;
private String act = ;
private String name = ;
public String getAct() {
return this.act;
}
public void setAct(String s) {
this.act = s;
}
public String getName() {
return this.name;
}
public void setName(String s) {
this.name = s;
}
public void validate() {
if (wasSubmitted()) {
if (name.equals()) {
addFieldError(name, required);
}
}
}
public void prepare() {
// setup view
request.setAttribute(form_name, Test Form);
}
public boolean wasSubmitted() {
if (act.equals()) {
return false;
}
else {
return true;
}
}
public String submit() {
// allow execute to do business logic
return null;
}
public String execute() throws Exception {
// do business logic
return SUCCESS;
}
}
[/code]
--
---
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Posted via Jive Forums
Re: SAF2 Automatic AJAX Support
Frank, Thanks for taking the time to submit a patch - I've marked it for being fixed for 2.0, so we'll get to it soon. Patrick - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=33300messageID=65334#65334 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuous integration for Struts
OK - what's the consensus here then? I'd be happy to use vmbuild.apache.org. Or, I was planning on setting up opensource.hostedqa.com/continuum to donate to various projects. Or we can wait for Sean and James to work it out. I suppose having multiple ones can't hurt too much. Anyone have a preference? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=32366messageID=65338#65338 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Continuous integration for Struts
Do we have something like Continuum setup for Struts? If not, we should. What's the process to kick this off? Besides the unit tests we should be running frequently, I'd like to turn on nightly runs of HostedQA (the product my company has donated to Struts for doing end-to-end automated tests). Patrick - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=32366messageID=62726#62726 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
Let's leave XW at OpenSymphony for now - as we know there is a lot of work to be focussed on when moving a project to Apache and I'd rather not let that distract us from the core work that needs to be done on Struts. I say in 6 months or so we see about moving it, once we have a SAF 2.0 release out. With that said, I would only branch if we think that we're likely to do another release. Considering that some changes have been happening on trunk, it sounds like we would. So let's do the branch for 2.0 in CVS and just make sure everyone has that branch checked out as ../xwork relative to our struts-action checkout. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61911#61911 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
Sounds good to me. I can start the process of migrating to SVN. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61925#61925 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plexus Container 1.0-alpha-10-SNAPSHOT
Codehaus.org had a serious hardware problem and so the site is down. I'm not sure what a good suggested workaround is at this point. Perhaps someone who has that jar locally can post it up on a site so you can install it temporarily. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31441messageID=60916#60916 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Build broken
The builds of xwork are still being done all the time: http://maven.opensymphony.com/opensymphony/jars/ Perhaps our build is no longer picking up from that repo? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31357messageID=60921#60921 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Action2] STATUS - Documentation
The snippet macro is updated. You can use URLs in the following format: org.struts.apache.action2. (links directly to a class in the _core_ module only) action2/... (links from the root of the action2 trunk) We'll need to get all references to the webwork snippets switched over as the next step for the docs. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29760messageID=59616#59616 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Action2] STATUS - Documentation
We won't be able to use Atlassian's public server - our stuff is just too heavy duty. Contegix (not Contegrix :P) might be interested to help, but I imagine they would probably feel more interested if they were in a position that was more than just an emergency/temporary storage location (eg: official hosting provider for Struts - which I know is a much bigger issue). I'll ask Matthew Porter next week what his thoughts are. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29760messageID=59617#59617 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Separate lists for notifications vs. discussion
It looks like this is now basically done (the JIRA issue is complete). The final step will be to unsubscribe the address [EMAIL PROTECTED] from all lists except for the dev@ list. That will keep the forums synced on the OpenSymphony forums limited to just the discussions. I was trying to figure out how to do that myself, but I didn't have a lot of luck. Any hints? To make it easier to filter and sort messages, and to facilitate presenting the lists through alternate interfaces such as forums and RSS feeds, I propose that we do the following: * establish issues@struts.apache.org and direct JIRA emails to it * unsubscribe [EMAIL PROTECTED] (svn commit messages and Wiki diffs) from dev@ Initially, the subscriber lists for these two could be copied from dev@, so that current subscribers are not affected. (Except for ossibly needing to reconfigure mail filters.) Thanks, -- Wendy -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=27726messageID=59619#59619 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
