DO NOT REPLY [Bug 38374] - Validation always skipped with Globals.CANCEL_KEY
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38374. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38374 --- Additional Comments From [EMAIL PROTECTED] 2006-02-16 12:23 --- The original RequestProcessor is just as constrained in 1.3 by the fact that the process() method only throws IOException and ServletException (unless we wanted to wrap the whole contents of process() in a try catch). Yes, you're right. I tested everything with the new ComposableRequestProcessor, but not with the legacy RequestProcessor. So the legacy RP has not been tested against the applications at all. I'll update the legacy RP, reconfigure the applications locally, and run through all the tests again. The RP is the very core of the framework, and we should not just assume that it still works. I'm beginning to see supporting the original RP as a problem, since a lot of the testing is still manual, and now we have to do it all twice -- everytime we release any of the subprojects! If the new CRP seems to work well in 1.3.0, we should probably deprecate the legacy RP in 1.3.1, so that it could be removed in a 1.4 release. I'll also update the checklist to include testing applications using both versions. -Ted. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsClassicRelease130 by TedHusted
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by TedHusted: http://wiki.apache.org/struts/StrutsClassicRelease130 The comment on the change is: Add item about testing with legacy RP; Note #38374 for new RP only. -- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=36794 36794] || Document enhancement (Enhanced !DynaActionForm) || All || (./) || || [http://issues.apache.org/bugzilla/show_bug.cgi?id=37301 37301] || Document enhancement (Allow dynamic interface implementation) || All || (./) (n/a) || || [http://issues.apache.org/bugzilla/show_bug.cgi?id=37730 37730] || Enhanced !DynaActionForms cannot be correctly deserialized || All || (./) (removed) || - || [http://issues.apache.org/bugzilla/show_bug.cgi?id=38374 38374] || Validation always skipped with Globals.CANCEL_KEY || Action|| (./) || + || [http://issues.apache.org/bugzilla/show_bug.cgi?id=38374 38374] || Validation always skipped with Globals.CANCEL_KEY (as to Composable Request Processor only)|| Action|| (./) || OTHER TODO @@ -120, +120 @@ || '''#''' || '''Description''' || '''Status''' || || 1. || Announce plan to dev@ list; link from roadmap page || (./) || || 2. || Review/Resolve Outstanding Bugs || (./) || - || 3. || Update Release Notes || _ || + || 3. || Update Release Notes || (./) || || 4. || Check Dependencies || (./) || || 5. || Update to version 1.3.0 build.xml, project.xml, release-notes.xml, and the MANIFEST.MF || (./) || @@ -151, +151 @@ || 1. || Run Unit Test targets || (./) || || 2. || Run Cactus Tests (see below) || _ || || 3. || Play test bundled applications (TC 5.0.x) || (./) || + || 3b. || Play test with legacy Request Procssor || (./) || === Cactus Tests === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing Parameters to ActionForward from Action
Bryan, I am totaly new to ajax. can u suggest me any get started kind of tutorial. Thanks, Siva - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=18280messageID=36339#36339 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38374] - Validation always skipped with Globals.CANCEL_KEY
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38374. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38374 --- Additional Comments From [EMAIL PROTECTED] 2006-02-16 14:37 --- I'll update the legacy RP Actually, I'd rather not update the legacy RP to support InvalidCancelException. If people want access to features new to 1.3, they can use the new RP. I tested the applications against the legacy RP, and the new behavior degrades gracefully, which seems sufficient for the 1.3.0 distribution. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38374] - Validation always skipped with Globals.CANCEL_KEY
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38374. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38374 --- Additional Comments From [EMAIL PROTECTED] 2006-02-16 14:57 --- May I suggest putting a feature in 1.2.9 and then having it gone in 1.3.0 would not be considered graceful, but a surprise? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r378250 - in /struts/action/trunk: conf/java/struts-config_1_3.dtd src/java/org/apache/struts/action/Action.java xdocs/userGuide/release-notes.xml
Author: husted Date: Thu Feb 16 06:12:52 2006 New Revision: 378250 URL: http://svn.apache.org/viewcvs?rev=378250view=rev Log: Opt-In Cancel Handler * Update release notees * Update Action.isCancelled Javado * Also update the controller documentation in the DTD to reflect the new default processor Modified: struts/action/trunk/conf/java/struts-config_1_3.dtd struts/action/trunk/src/java/org/apache/struts/action/Action.java struts/action/trunk/xdocs/userGuide/release-notes.xml Modified: struts/action/trunk/conf/java/struts-config_1_3.dtd URL: http://svn.apache.org/viewcvs/struts/action/trunk/conf/java/struts-config_1_3.dtd?rev=378250r1=378249r2=378250view=diff == --- struts/action/trunk/conf/java/struts-config_1_3.dtd (original) +++ struts/action/trunk/conf/java/struts-config_1_3.dtd Thu Feb 16 06:12:52 2006 @@ -538,7 +538,7 @@ processorClass The fully qualified Java class name of the RequestProcessor subclass to be used with this module. - [org.apache.struts.action.RequestProcessor] + [org.apache.struts.chain.ComposableRequestProcessor] tempDir Temporary working directory to use when processing file uploads. Modified: struts/action/trunk/src/java/org/apache/struts/action/Action.java URL: http://svn.apache.org/viewcvs/struts/action/trunk/src/java/org/apache/struts/action/Action.java?rev=378250r1=378249r2=378250view=diff == --- struts/action/trunk/src/java/org/apache/struts/action/Action.java (original) +++ struts/action/trunk/src/java/org/apache/struts/action/Action.java Thu Feb 16 06:12:52 2006 @@ -351,6 +351,11 @@ * an strongActionForm/strong's codevalidate()/code method will * have been skipped by the controller servlet./p * + * p Since Action 1.3.0, the mapping for a cancellable Action must also have + * the new cancellable property set to true. If cancellable is not set, and + * the magic Cancel token is found in the request, the standard Composable + * Request Processor will throw an InvalidCancelException. /p + * * @param request The servlet request we are processing * @return codetrue/code if the cancel button was pressed; * codefalse/code otherwise. Modified: struts/action/trunk/xdocs/userGuide/release-notes.xml URL: http://svn.apache.org/viewcvs/struts/action/trunk/xdocs/userGuide/release-notes.xml?rev=378250r1=378249r2=378250view=diff == --- struts/action/trunk/xdocs/userGuide/release-notes.xml (original) +++ struts/action/trunk/xdocs/userGuide/release-notes.xml Thu Feb 16 06:12:52 2006 @@ -22,13 +22,40 @@ titleRelease Notes (since 1.2.8)/title /properties body -section name=6.1 Release Notes - Version 1.3.0-dev +section name=6.1 Release Notes - Version 1.3.0 + +subsection +p +strongSPECIAL NOTE ON UPGRADING - README FIRST!/strong +- If you use the standard +strongCANCEL BUTTON/strong +in your application +and validate is set to true for that mapping, you +strongMUST/strong +also specify cancellable=true in the mapping, otherwise, +an InvalidCancelException will be thrown if the Cancel button is +used. See the new +a href=#opt-inOpt-In Cancel Handling/a +feature for more. +/p +p +source +lt;action path=/ActionThatCanBeCancelled +validate=true +strongcancellable=true/strong +... + lt;/action +/source +/p +/subsection + a name=release_notes/ subsection name=Introduction p This section contains release notes for changes that have taken -place to Struts Classic since +place to the seven new subprojects known as Struts Classic +since a href=release-notes-1.2.8.htmlVersion 1.2.8/a . To keep up-to-date on all changes to Struts, subscribe to @@ -70,7 +97,7 @@ dependencies. /p p -You can also access to the Struts source repository and +You can also access to the Apache Struts source repository and change logs directly through both
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
I've now tested the applications with the legacy RP and updated the Release Notes as to the new Opt-In Cancel Handler. As this point, I'd rather not update the legacy RP to support Opt-In Cancel Handling. If we make any further changes to this feature, or any other new feature, we'd have to maintain the code in two places. As long as the behavior gracefully degrades, it seems reasonable to me to add new features to the new RequestProcessor and leaving the legacy RP alone (unless the 1.2.x branch is also going to be released - but no one has volunteered to do that). If people want access to features new to 1.3, they can use the new RP. If the new CRP passes muster and remains the default for 1.3.1, we should move the legacy RP to extras and deprecate it. If this change prompts anyone to change their vote, please chime-in now. A release plan is a majority vote, so we need three binding +1s from PMC members and more binding +1s than -1s. A +1 here is on the tagging the repository. A quality vote would follow once the test builds are posted. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Ted Husted [EMAIL PROTECTED] wrote: I've now tested the applications with the legacy RP and updated the Release Notes as to the new Opt-In Cancel Handler. As this point, I'd rather not update the legacy RP to support Opt-In Cancel Handling. If we make any further changes to this feature, or any other new feature, we'd have to maintain the code in two places. As long as the behavior gracefully degrades, it seems reasonable to me to add new features to the new RequestProcessor and leaving the legacy RP alone (unless the 1.2.x branch is also going to be released - but no one has volunteered to do that). If people want access to features new to 1.3, they can use the new RP. If the new CRP passes muster and remains the default for 1.3.1, we should move the legacy RP to extras and deprecate it. My view is that this is security hole that we are fixing, not adding a new feature. I also think that the original RequestProcessor and TilesRequestProcessor offer people a way of upgrading to 1.3 and use tried and tested code - without having to adopt the CoR implementation. Since I have implemented the Cancellable behaviour in the 1.2.x branch, then either it needs also applying to the 1.3 branch or that change needs to be reversed. We probably should release a Struts 1.2.9 to fix this issue and the DOS attack issue and I am willing to do that - probably have time in a couple of weeks. If this change prompts anyone to change their vote, please chime-in now. A release plan is a majority vote, so we need three binding +1s from PMC members and more binding +1s than -1s. A +1 here is on the tagging the repository. A quality vote would follow once the test builds are posted. I realize the plan vote and quality vote are separte issues, but IMO the DOS attack bug is v.serious - you can stop a whole web app from working using it - and I don't understand why were not fixing it in 1.3.0. IMO 1.3.0 is never going to be more than a beta with this DOS attack bug - or with the original request processor cancellable security hole. Both are really bad. Niall -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On Thu, February 16, 2006 9:45 am, Niall Pemberton said: My view is that this is security hole that we are fixing, not adding a new feature. I also think that the original RequestProcessor and TilesRequestProcessor offer people a way of upgrading to 1.3 and use tried and tested code - without having to adopt the CoR implementation. Since I have implemented the Cancellable behaviour in the 1.2.x branch, then either it needs also applying to the 1.3 branch or that change needs to be reversed. We probably should release a Struts 1.2.9 to fix this issue and the DOS attack issue and I am willing to do that - probably have time in a couple of weeks. +1 to Niall's comments, and therefore a non-binding -1 to tagging the repository... I don't see the point in even simply tagging if there are two outstanding security issues. By the way, I didn't catch the DOS hole... can someone point me at the appropriate ticket? Niall Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Non-binding +1 to tagging the repository. Sorry for the late response. Greg On Feb 16, 2006, at 8:15 AM, Ted Husted wrote: A release plan is a majority vote, so we need three binding +1s from PMC members and more binding +1s than -1s. A +1 here is on the tagging the repository. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing Parameters to ActionForward from Action
Shameless self-promotion: http://www.omnytex.com/articles :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 8:37 am, shiiva said: Bryan, I am totaly new to ajax. can u suggest me any get started kind of tutorial. Thanks, Siva - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=18280messageID=36339#36339 - 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]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
At 10:06 AM -0500 2/16/06, Frank W. Zammetti wrote: On Thu, February 16, 2006 9:45 am, Niall Pemberton said: My view is that this is security hole that we are fixing, not adding a new feature. I also think that the original RequestProcessor and TilesRequestProcessor offer people a way of upgrading to 1.3 and use tried and tested code - without having to adopt the CoR implementation. Since I have implemented the Cancellable behaviour in the 1.2.x branch, then either it needs also applying to the 1.3 branch or that change needs to be reversed. We probably should release a Struts 1.2.9 to fix this issue and the DOS attack issue and I am willing to do that - probably have time in a couple of weeks. +1 to Niall's comments, and therefore a non-binding -1 to tagging the repository... I don't see the point in even simply tagging if there are two outstanding security issues. I think it's fine if Struts 1.3.0 is understood to not be expected to reach GA status. I think we should go ahead and cut the release, and expect that it will be beta at best. I don't think the issues Niall raised are things that are unheard of in a beta. We don't seem to have actually narrowed in on a process which lets us cut releases as frequently as we thought we would when we adopted the Apache numbering scheme, but by the ideal process, it's not a real big deal to put the tag on and push the thing out the door. If people agree with some of the recent concerns about the API, like the naming and responsibility of the ActionContext class, then they could vote to mark the release merely Alpha -- but that doesn't mean there shouldn't be a release. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: By the way, I didn't catch the DOS hole... can someone point me at the appropriate ticket? http://issues.apache.org/bugzilla/show_bug.cgi?id=38534 If you drop the 1.2 Branch version of upload.jsp into the Struts 1.2.8 version of the examples webapp - you can see it in action: http://svn.apache.org/viewcvs.cgi/struts/action/branches/STRUTS_1_2_BRANCH/web/examples/upload/ I've patched the 1.2.x branch for this bug, but held off fixing it in 1.3 at Ted's request. Niall Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
A whole-hearted +1 and an AMEN to boot! Don Joe Germuska wrote: I think it's fine if Struts 1.3.0 is understood to not be expected to reach GA status. I think we should go ahead and cut the release, and expect that it will be beta at best. I don't think the issues Niall raised are things that are unheard of in a beta. We don't seem to have actually narrowed in on a process which lets us cut releases as frequently as we thought we would when we adopted the Apache numbering scheme, but by the ideal process, it's not a real big deal to put the tag on and push the thing out the door. If people agree with some of the recent concerns about the API, like the naming and responsibility of the ActionContext class, then they could vote to mark the release merely Alpha -- but that doesn't mean there shouldn't be a release. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/11/06, Ted Husted [EMAIL PROTECTED] wrote: OK, we're back down to two patches that could be applied this weekend. * http://wiki.apache.org/struts/StrutsClassicRelease130 After resolving these items, I'd like to tag and roll the 1.3.0 release on Monday Feburary 13. There would be a 1.3.0 release for each of the seven dwarfs, and a Library ZIP file with just the JARS utilized by all seven. (Except the Servlet and JSTL JARs, unless we can redistribute these too.) Again, this is not a vote on the quality of the release, only whether to tag the trunk with the marker STRUTS_1_3_0. My vote is +1 for the plan. However with the code as it stands at the moment (re Bug #38534 and Bug #38374) I will be voting beta for the quality. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
If someone is going to manage a 1.2.9 release, then, yes, it would make sense for someone to make the necessary changes to 1.3 before we mark it GA. (It just isn't going to be me.) But, if we are doing this because it's a security hole (and I don't agree it is), then we should also patch and re-release Struts 1.1, which many more people are using. The behavior has existed from day one; it's not specific to 1.2. Or, if we are saying that 1.2 makes 1.1 obsolete, then perhaps we should focus on stablizing Struts 1.3 so as to make 1.2 obsolete too. As to any other changes, if Wendy doesn't mind, and someone wants to make those and also help finish up on the 1.3.0 release, I'm not going to argue. But, I would have to remove my name as release co-manager, since I just don't have any more time to spend on 1.3.0 right now. If someone else can do it, that would be great, it's just that I can't. If some people feel these patches are a problem, then we can always keep Action 1.3.0 as a test-build, until someone has time to apply them and roll an Action 1.3.1 (note that the other six subprojects would *not* have to tagged and rolled again, only the one we change). The important thing, I think, is to get past the point having to release everything all at once. Then we can address any other issues in an agile, release-often, way. Otherwise, it will always be something, and a week will turn into a month, which turns into another quarter. -Ted. On 2/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: My view is that this is security hole that we are fixing, not adding a new feature. I also think that the original RequestProcessor and TilesRequestProcessor offer people a way of upgrading to 1.3 and use tried and tested code - without having to adopt the CoR implementation. Since I have implemented the Cancellable behaviour in the 1.2.x branch, then either it needs also applying to the 1.3 branch or that change needs to be reversed. We probably should release a Struts 1.2.9 to fix this issue and the DOS attack issue and I am willing to do that - probably have time in a couple of weeks. If this change prompts anyone to change their vote, please chime-in now. A release plan is a majority vote, so we need three binding +1s from PMC members and more binding +1s than -1s. A +1 here is on the tagging the repository. A quality vote would follow once the test builds are posted. I realize the plan vote and quality vote are separte issues, but IMO the DOS attack bug is v.serious - you can stop a whole web app from working using it - and I don't understand why were not fixing it in 1.3.0. IMO 1.3.0 is never going to be more than a beta with this DOS attack bug - or with the original request processor cancellable security hole. Both are really bad. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Ted Husted [EMAIL PROTECTED] wrote: If someone is going to manage a 1.2.9 release, then, yes, it would make sense for someone to make the necessary changes to 1.3 before we mark it GA. (It just isn't going to be me.) But, if we are doing this because it's a security hole (and I don't agree it is), then we should also patch and re-release Struts 1.1, which many more people are using. The behavior has existed from day one; it's not specific to 1.2. Or, if we are saying that 1.2 makes 1.1 obsolete, then perhaps we should focus on stablizing Struts 1.3 so as to make 1.2 obsolete too. Yes we should patch and release 1.1 as well, but I don't have any interest in working on 1.1. As to any other changes, if Wendy doesn't mind, and someone wants to make those and also help finish up on the 1.3.0 release, I'm not going to argue. But, I would have to remove my name as release co-manager, since I just don't have any more time to spend on 1.3.0 right now. If someone else can do it, that would be great, it's just that I can't. Its down to whether you're hoping 1.3.0 makes GA quality or not. If we want to give it a chance of GA then we should fix them now. If we just want to get a milestone out there then carry on. I don't mind either way. If some people feel these patches are a problem, then we can always keep Action 1.3.0 as a test-build, until someone has time to apply them and roll an Action 1.3.1 (note that the other six subprojects would *not* have to tagged and rolled again, only the one we change). Good point and probably all the more reason for carrying on with things as they stand. Niall The important thing, I think, is to get past the point having to release everything all at once. Then we can address any other issues in an agile, release-often, way. Otherwise, it will always be something, and a week will turn into a month, which turns into another quarter. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On Thu, February 16, 2006 10:34 am, Joe Germuska said: If people agree with some of the recent concerns about the API, like the naming and responsibility of the ActionContext class, then they could vote to mark the release merely Alpha -- but that doesn't mean there shouldn't be a release. The one problem I see with this is that many people are not going to take into consideration the release mechanism, they are simply going to see a new version of Struts and jump on it. Especially as long as it has been since the last version, I think people will be more inclined to do that. Thinking more about the security issues, regardless of what severity you ascribe to them, I think this potentially does a disservice to the user community. Joe makes a good point... I have no problem with a 1.3 release per se, indeed I was pushing for it some weeks ago, but properly labeling it is very important IMO. To me, a beta denotes a release that you believe is ready for GA, and you just want to get feedback to confirm that. alpha denotes that you believe there probably are problems yet to be resolved. In that light, what Joe said makes sense, the vote should be for alpha. Does that make sense to anyone? The bottom line to me is there are some outstanding issues yet to be resolved one way or another, and I would want to be careful of giving people the wrong impression about the release, so an alpha mark becomes more important with that in mind. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Ted Husted wrote: If some people feel these patches are a problem, then we can always keep Action 1.3.0 as a test-build, until someone has time to apply them and roll an Action 1.3.1 (note that the other six subprojects would *not* have to tagged and rolled again, only the one we change). The important thing, I think, is to get past the point having to release everything all at once. Then we can address any other issues in an agile, release-often, way. Otherwise, it will always be something, and a week will turn into a month, which turns into another quarter. +1 to this action plan. I'm in the camp of considering the two security bugs a requirement for a GA level release, but getting the 'seven dwarfs' out the door would at least clear some room in the workshop ;-) L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[shale][patch] Fix incorrect EL expression syntax in mailreader app
Index: mailreader/src/web/subscription.jsp
===
--- mailreader/src/web/subscription.jsp (revision 378284)
+++ mailreader/src/web/subscription.jsp (working copy)
@@ -88,9 +88,9 @@
h:panelGroup
h:message id=hostMessages
for=host
- rendered=#{state.mode == 'CREATE'/
+ rendered=#{state.mode == 'CREATE'}/
h:outputText value=
- rendered=#{state.mode != 'CREATE'/
+ rendered=#{state.mode != 'CREATE'}/
/h:panelGroup
%-- Third row --%
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[shale][patch] Fix incorrect EL expression syntax in sql-browser sample
Index: sql-browser/src/web/query.jsp
===
--- sql-browser/src/web/query.jsp (revision 378284)
+++ sql-browser/src/web/query.jsp (working copy)
@@ -43,7 +43,7 @@
value=#{messages['sqlbrowser.dataSource']}/
h:selectOneMenu id=dataSource
- value=#{query.dataSource
+ value=#{query.dataSource}
f:selectItems value=#{appbean.dataSources}/
/h:selectOneMenu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Ted Husted [EMAIL PROTECTED] wrote: If someone is going to manage a 1.2.9 release, then, yes, it would make sense for someone to make the necessary changes to 1.3 before we mark it GA. (It just isn't going to be me.) But, if we are doing this because it's a security hole (and I don't agree it is), then we should also patch and re-release Struts 1.1, which many more people are using. The behavior has existed from day one; it's not specific to 1.2. Or, if we are saying that 1.2 makes 1.1 obsolete, then perhaps we should focus on stablizing Struts 1.3 so as to make 1.2 obsolete too. If we think this is serious enough to warrant a 1.2.9 release, then it makes little sense to me to tag 1.3.0 without it. Otherwise, all we're saying is hurrah, we tagged the tree, but oh, you probably don't want to use this because there's a serious problem we know about that we didn't feel like taking the extra time to fix. As for 1.1, personally, I _do_ see 1.2 as making 1.1 obsolete, so I don't see a need to update that as well. And I would expect 1.3 to make 1.2obsolete in time, too. -- Martin Cooper As to any other changes, if Wendy doesn't mind, and someone wants to make those and also help finish up on the 1.3.0 release, I'm not going to argue. But, I would have to remove my name as release co-manager, since I just don't have any more time to spend on 1.3.0 right now. If someone else can do it, that would be great, it's just that I can't. If some people feel these patches are a problem, then we can always keep Action 1.3.0 as a test-build, until someone has time to apply them and roll an Action 1.3.1 (note that the other six subprojects would *not* have to tagged and rolled again, only the one we change). The important thing, I think, is to get past the point having to release everything all at once. Then we can address any other issues in an agile, release-often, way. Otherwise, it will always be something, and a week will turn into a month, which turns into another quarter. -Ted. On 2/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: My view is that this is security hole that we are fixing, not adding a new feature. I also think that the original RequestProcessor and TilesRequestProcessor offer people a way of upgrading to 1.3 and use tried and tested code - without having to adopt the CoR implementation. Since I have implemented the Cancellable behaviour in the 1.2.x branch, then either it needs also applying to the 1.3 branch or that change needs to be reversed. We probably should release a Struts 1.2.9 to fix this issue and the DOS attack issue and I am willing to do that - probably have time in a couple of weeks. If this change prompts anyone to change their vote, please chime-in now. A release plan is a majority vote, so we need three binding +1s from PMC members and more binding +1s than -1s. A +1 here is on the tagging the repository. A quality vote would follow once the test builds are posted. I realize the plan vote and quality vote are separte issues, but IMO the DOS attack bug is v.serious - you can stop a whole web app from working using it - and I don't understand why were not fixing it in 1.3.0. IMO 1.3.0 is never going to be more than a beta with this DOS attack bug - or with the original request processor cancellable security hole. Both are really bad. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reasons for 1.3 release
How Struts committers justify the reason for 1.3 release? What is the point in 1.3 considering that WebWork / 2.0 already has interceptors and other goodies? People need time to learn how to use CoR stuff. While they learn, WebWork will push 1.x out of the window. Am I wrong? Maybe 1.3 branch should contain only bugfixes? Another way to look at 1.3 is that some early adopters use 1.3 nightlies for quite some time already. These adopters do not need a lot of docs/samples in official release since they already are using this version. For them, official 1.3.x release will mean adoption by management. So, one might think that 1.3 is intended mostly for early adopters to please their management. Everybody else will eventually switch from 1.2 directly to 2.0. Thus, 1.3 might be seen as a release not really intended for general public. Do I get it all wrong? Apache Struts web page talks about two frameworks meaning Shale and Action, it does not differentiate between Classic and 2.0. From an outsider standpoint, does 1.3 worth investment for someone who have not used its nightlies for a year or so? One of the reasons for WebWork merger was that WebWork has almost everything that has been planned for 1.3 and 1.4. What is the point t continue 1.x development then? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On Thu, February 16, 2006 12:34 pm, Martin Cooper said: As for 1.1, personally, I _do_ see 1.2 as making 1.1 obsolete, so I don't see a need to update that as well. And I would expect 1.3 to make 1.2obsolete in time, too. I don't disagree, but isn't it true that 1.3 won't make anything obsolete, the WW merger will? I mean, one could almost at this point ask what's the point of putting 1.3 out at all, given that the WW merger is the future of Struts, right? -- Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
[Slightly OT] Has 1.3 proper docs explaining how CoR works? Has CoR changed since last autumn? Does CoR MailReader reflect all cool CoR features? I am sorry, I just seem to have crawled from under the rock, still using 1.2.x branch. Would be great if someone pointed out to the docs (on Apache site) about CoR usage. The old link to CoR MailReader shows 14 month-old sources. I presume that CoR is the major improvement in 1.3 and should be presented/advertised/documented in a manner that a caveman can understand. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
We must have hit submit at the exact same time Michael :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 12:39 pm, Michael Jouravlev said: How Struts committers justify the reason for 1.3 release? What is the point in 1.3 considering that WebWork / 2.0 already has interceptors and other goodies? People need time to learn how to use CoR stuff. While they learn, WebWork will push 1.x out of the window. Am I wrong? Maybe 1.3 branch should contain only bugfixes? Another way to look at 1.3 is that some early adopters use 1.3 nightlies for quite some time already. These adopters do not need a lot of docs/samples in official release since they already are using this version. For them, official 1.3.x release will mean adoption by management. So, one might think that 1.3 is intended mostly for early adopters to please their management. Everybody else will eventually switch from 1.2 directly to 2.0. Thus, 1.3 might be seen as a release not really intended for general public. Do I get it all wrong? Apache Struts web page talks about two frameworks meaning Shale and Action, it does not differentiate between Classic and 2.0. From an outsider standpoint, does 1.3 worth investment for someone who have not used its nightlies for a year or so? One of the reasons for WebWork merger was that WebWork has almost everything that has been planned for 1.3 and 1.4. What is the point t continue 1.x development then? - 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]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: Its down to whether you're hoping 1.3.0 makes GA quality or not. If we want to give it a chance of GA then we should fix them now. If we just want to get a milestone out there then carry on. I don't mind either way. In six years, we've never had a new minor version make GA on the first release. The 1.2 series came close, we made GA in three tries. The 1.1 series took three betas and a release candidate. I don't expect that 1.3 would be much different. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
From a Struts user standpoint, I'm am very interested in a 1.3.x GA release. I have legacy Struts applications that lost funding, save the occastional bug fix, and I want a stable Struts that has the Commons Chain request processor and the ability to pass multiple runtime parameters to Struts Actions that only Struts 1.3 has. Yes, the WebWork 2-based Struts Action 2.0 is coming and yes, I think it will be technically superior to 1.3 in most every way, but it doesn't exist as far as my legacy Struts applications are concerned. In fact, I plan to bundle Struts Action 1.3 with Struts Action 2.0 so that users like myself can upgrade to the latest Struts without having to rewrite code or worry about things breaking. Just because there is something more shiny, doesn't mean everyone will jump to use it. Don On 2/16/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: We must have hit submit at the exact same time Michael :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 12:39 pm, Michael Jouravlev said: How Struts committers justify the reason for 1.3 release? What is the point in 1.3 considering that WebWork / 2.0 already has interceptors and other goodies? People need time to learn how to use CoR stuff. While they learn, WebWork will push 1.x out of the window. Am I wrong? Maybe 1.3 branch should contain only bugfixes? Another way to look at 1.3 is that some early adopters use 1.3 nightlies for quite some time already. These adopters do not need a lot of docs/samples in official release since they already are using this version. For them, official 1.3.x release will mean adoption by management. So, one might think that 1.3 is intended mostly for early adopters to please their management. Everybody else will eventually switch from 1.2 directly to 2.0. Thus, 1.3 might be seen as a release not really intended for general public. Do I get it all wrong? Apache Struts web page talks about two frameworks meaning Shale and Action, it does not differentiate between Classic and 2.0. From an outsider standpoint, does 1.3 worth investment for someone who have not used its nightlies for a year or so? One of the reasons for WebWork merger was that WebWork has almost everything that has been planned for 1.3 and 1.4. What is the point t continue 1.x development then? - 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]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Martin Cooper [EMAIL PROTECTED] wrote: If we think this is serious enough to warrant a 1.2.9 release, then it makes little sense to me to tag 1.3.0 without it. Otherwise, all we're saying is hurrah, we tagged the tree, but oh, you probably don't want to use this because there's a serious problem we know about that we didn't feel like taking the extra time to fix. All I'm saying is that I have no extra time. If someone else does, then please step up and lend a hand. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Ted Husted wrote: On 2/16/06, Martin Cooper [EMAIL PROTECTED] wrote: If we think this is serious enough to warrant a 1.2.9 release, then it makes little sense to me to tag 1.3.0 without it. Otherwise, all we're saying is hurrah, we tagged the tree, but oh, you probably don't want to use this because there's a serious problem we know about that we didn't feel like taking the extra time to fix. All I'm saying is that I have no extra time. If someone else does, then please step up and lend a hand. That's part of my reason for +1'ing a 1.3.0 release, even if it's never promoted (as a whole) from test release; Ted's put a ton of work into getting to this point. If a 1.3.0 release happens now, it'll presumably take less time and effort to incrementally address remaining issues and release updates of just the action sub-project, compared to postponing the 1.3.0 release and having to repeat much of the testing and prep work that's just been done. Just my 2 cents... L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Thu, February 16, 2006 12:34 pm, Martin Cooper said: As for 1.1, personally, I _do_ see 1.2 as making 1.1 obsolete, so I don't see a need to update that as well. And I would expect 1.3 to make 1.2obsolete in time, too. I don't disagree, but isn't it true that 1.3 won't make anything obsolete, the WW merger will? I mean, one could almost at this point ask what's the point of putting 1.3 out at all, given that the WW merger is the future of Struts, right? You'll note that I put obsolete in quotes. What I mean is that I see no reason that anyone would want to start a new project using 1.1 when we have 1.2 GA releases. Similarly, once 1.3 goes GA, it doesn't make much sense to start a new project with 1.2. Beyond that, it's a matter of how many versions we want to (and have the energy to) support. The WW merger won't make anything obsolete by itself. It will provide a new choice for people to use on their projects, and we hope to encourage them to migrate to the new Struts 2. Yes, this will eventually make the Struts 1 line obsolete in a more real sense, but the Struts 1 line is not going to go away for a very long time. As for the point of releasing 1.3 at all, which I think you are actually asking rather than almost asking, ;-) it brings a new way of working with the Struts 1 line, and a new way of customising it, that could be highly beneficial to many developers. I know that I'm not about to back off to 1.2.8 on my current project, since I'm getting a lot out of 1.3, but I'm also sufficiently invested in that that I'm not about to switch horses and move to WebWork instead. Now, I could be alone, but I strongly suspect I'm not. ;-) -- Martin Cooper -- Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On Thu, February 16, 2006 1:09 pm, Martin Cooper said: As for the point of releasing 1.3 at all, which I think you are actually asking rather than almost asking, ;-) it brings a new way of working with the Struts 1 line, and a new way of customising it, that could be highly beneficial to many developers. Hehe :) No, I'll stick with *almost* asking because I've been onboard with 1.3 for a long time, even though I'm not currently using it, the benefits of a CoR-based design is completely obvious IMO (enough so that I've done two projects now that used CoR without actually using 1.3). I wouldn't ask *now* if releasing it makes sense :) Almost... I know that I'm not about to back off to 1.2.8 on my current project, since I'm getting a lot out of 1.3, but I'm also sufficiently invested in that that I'm not about to switch horses and move to WebWork instead. Now, I could be alone, but I strongly suspect I'm not. ;-) I doubt your alone either... likewise with me, I'm on 1.2.6 at the moment, and it completely suits my needs for the time being, so I'm not in any rush to upgrade to anything either (I probably could if I wanted, but I'd have some fighting to do, given the corporate environment I work in). I'm thinking more of progress... if everyone agrees WW is the future (and that *seems* to be the general concensus), 1.3 becomes less important IMO... those that want to use it anyway are probably already doing so, but I also know tons of people wait for a GA release, or *have* to wait for a GA release, and if 1.3 isn't going to make that milestone for some time, or arguably ever, and if the WW merger happens before 1.3.x goes GA, then what was the point to putting effort them all along instead of directly into the WW merger? Oops... I didn't ask that... I *almost* asked that ;) LOL OTOH, I would feel bad for Ted, Wendy and others who have put in good work on 1.3 lately, so if for that reason alone the release should happen. The reward for the effort is the release itself, and I appreciate that. Eh, I've taken this whole thing OT, sorry about that... you all realize by now I never say with less than 1,000 words something that only need 10 to begin with :) -- Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r378336 - /struts/shale/trunk/sql-browser/src/web/query.jsp
Author: craigmcc
Date: Thu Feb 16 10:50:37 2006
New Revision: 378336
URL: http://svn.apache.org/viewcvs?rev=378336view=rev
Log:
Fix a typo in a value binding expression.
Submitted by: Ryan Lubke Ryan.Lubke AT sun.com
Modified:
struts/shale/trunk/sql-browser/src/web/query.jsp
Modified: struts/shale/trunk/sql-browser/src/web/query.jsp
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/sql-browser/src/web/query.jsp?rev=378336r1=378335r2=378336view=diff
==
--- struts/shale/trunk/sql-browser/src/web/query.jsp (original)
+++ struts/shale/trunk/sql-browser/src/web/query.jsp Thu Feb 16 10:50:37 2006
@@ -43,7 +43,7 @@
value=#{messages['sqlbrowser.dataSource']}/
h:selectOneMenu id=dataSource
- value=#{query.dataSource
+ value=#{query.dataSource}
f:selectItems value=#{appbean.dataSources}/
/h:selectOneMenu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale][patch] Fix incorrect EL expression syntax in sql-browser sample
Thanks Ryan. Interesting that the mis-typed version actually worked in both
1.1 implementations :-).
Craig
On 2/16/06, Ryan Lubke [EMAIL PROTECTED] wrote:
Index: sql-browser/src/web/query.jsp
===
--- sql-browser/src/web/query.jsp (revision 378284)
+++ sql-browser/src/web/query.jsp (working copy)
@@ -43,7 +43,7 @@
value=#{messages['sqlbrowser.dataSource']}/
h:selectOneMenu id=dataSource
- value=#{query.dataSource
+ value=#{query.dataSource}
f:selectItems value=#{appbean.dataSources}/
/h:selectOneMenu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Ted Husted [EMAIL PROTECTED] wrote: On 2/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: Its down to whether you're hoping 1.3.0 makes GA quality or not. If we want to give it a chance of GA then we should fix them now. If we just want to get a milestone out there then carry on. I don't mind either way. In six years, we've never had a new minor version make GA on the first release. The 1.2 series came close, we made GA in three tries. The 1.1 series took three betas and a release candidate. I don't expect that 1.3 would be much different. Same even on 1.0 ... it took two point releases to get it right. -Ted. Craig
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere New page: Describe Vandekeere here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- - Describe Vandekeere here. + body bgcolor=#CC Describe Vandekeere here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing Parameters to ActionForward from Action
Another shameless plug: The easiest to use ajax implementation on earth. No tag logic to learn, no new JavaScript syntax to add to your own, just strait access to your plain old Java objects. There is video training and documentation available at http://www.xoscript.org . I am working on an ActionClass that will allow you to integrate Struts into the next version of xoscript (xml scripting objects), but it is not ready yet. Bryan LaPlante -- Original Message --- From: Frank W. Zammetti [EMAIL PROTECTED] To: dev@struts.apache.org Cc: dev@struts.apache.org Sent: Thu, 16 Feb 2006 09:59:29 -0500 (EST) Subject: Re: Passing Parameters to ActionForward from Action Shameless self-promotion: http://www.omnytex.com/articles :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 8:37 am, shiiva said: Bryan, I am totaly new to ajax. can u suggest me any get started kind of tutorial. Thanks, Siva - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=18280messageID=36339#36339 - 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] --- End of Original Message --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing Parameters to ActionForward from Action
Woo-hoo, dueling AJAX toolkits! ;) LOL ... http://javawebparts.sourceforge.net/javadocs/javawebparts/taglib/ajaxtags/package-summary.html Pretty darned easy too :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 3:01 pm, [EMAIL PROTECTED] said: Another shameless plug: The easiest to use ajax implementation on earth. No tag logic to learn, no new JavaScript syntax to add to your own, just strait access to your plain old Java objects. There is video training and documentation available at http://www.xoscript.org . I am working on an ActionClass that will allow you to integrate Struts into the next version of xoscript (xml scripting objects), but it is not ready yet. Bryan LaPlante -- Original Message --- From: Frank W. Zammetti [EMAIL PROTECTED] To: dev@struts.apache.org Cc: dev@struts.apache.org Sent: Thu, 16 Feb 2006 09:59:29 -0500 (EST) Subject: Re: Passing Parameters to ActionForward from Action Shameless self-promotion: http://www.omnytex.com/articles :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 8:37 am, shiiva said: Bryan, I am totaly new to ajax. can u suggest me any get started kind of tutorial. Thanks, Siva - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=18280messageID=36339#36339 - 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] --- End of Original Message --- - 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]
Re: Reasons for 1.3 release
On 2/16/06, Don Brown [EMAIL PROTECTED] wrote: From a Struts user standpoint, I'm am very interested in a 1.3.x GA release. I have legacy Struts applications that lost funding, save the occastional bug fix, and I want a stable Struts that has the Commons Chain request processor and the ability to pass multiple runtime parameters to Struts Actions that only Struts 1.3 has. Yes, the WebWork 2-based Struts Action 2.0 is coming and yes, I think it will be technically superior to 1.3 in most every way, but it doesn't exist as far as my legacy Struts applications are concerned. In fact, I plan to bundle Struts Action 1.3 with Struts Action 2.0 so that users like myself can upgrade to the latest Struts without having to rewrite code or worry about things breaking. Can I rephrase the above as: 1.3 is a bugfix + some internal surgery release for legacy Struts apps in case you want to perform a mild refactoring on them? Can I also assume that you recommend using WebWork / 2.0 for new projects? What is your outlook on future of 1.3 branch after it released as GA? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing Parameters to ActionForward from Action
You know what would be cool for the javawebparts implementation. Make a tag called snippets or something, have it work like MessageResource where you could store things such onclick and other events and then be able to mark up your HTML with something that feels like bean:write property... where the property name would be replaced with your ajax call necessary to process the event. Is this your implementation? Do you have a discussion form for it? Bryan LaPlante -- Original Message --- From: Frank W. Zammetti [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Cc: Struts Developers List dev@struts.apache.org Sent: Thu, 16 Feb 2006 15:05:46 -0500 (EST) Subject: Re: Passing Parameters to ActionForward from Action Woo-hoo, dueling AJAX toolkits! ;) LOL ... http://javawebparts.sourceforge.net/javadocs/javawebparts/taglib/ajaxtags/package-summary.html Pretty darned easy too :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 3:01 pm, [EMAIL PROTECTED] said: Another shameless plug: The easiest to use ajax implementation on earth. No tag logic to learn, no new JavaScript syntax to add to your own, just strait access to your plain old Java objects. There is video training and documentation available at http://www.xoscript.org . I am working on an ActionClass that will allow you to integrate Struts into the next version of xoscript (xml scripting objects), but it is not ready yet. Bryan LaPlante -- Original Message --- From: Frank W. Zammetti [EMAIL PROTECTED] To: dev@struts.apache.org Cc: dev@struts.apache.org Sent: Thu, 16 Feb 2006 09:59:29 -0500 (EST) Subject: Re: Passing Parameters to ActionForward from Action Shameless self-promotion: http://www.omnytex.com/articles :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 8:37 am, shiiva said: Bryan, I am totaly new to ajax. can u suggest me any get started kind of tutorial. Thanks, Siva - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=18280messageID=36339#36339 - 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] --- End of Original Message --- - 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] --- End of Original Message --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing Parameters to ActionForward from Action
On 2/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You know what would be cool for the javawebparts implementation. Make a tag called snippets or something, have it work like MessageResource where you could store things such onclick and other events and then be able to mark up your HTML with something that feels like bean:write property... where the property name would be replaced with your ajax call necessary to process the event. Is this your implementation? Do you have a discussion form for it? http://www.jroller.com/page/javadujour?entry=prep_tag_as_a_view Great minds think alike? ;-) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing Parameters to ActionForward from Action
I'm not sure I quite understand the suggestion, but please either join the JWP mailing list and bring it up there, or post a message to the forum (on the SourceForge page), or even submit a feature request. We are always trolling for new ideas :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 3:21 pm, [EMAIL PROTECTED] said: You know what would be cool for the javawebparts implementation. Make a tag called snippets or something, have it work like MessageResource where you could store things such onclick and other events and then be able to mark up your HTML with something that feels like bean:write property... where the property name would be replaced with your ajax call necessary to process the event. Is this your implementation? Do you have a discussion form for it? Bryan LaPlante -- Original Message --- From: Frank W. Zammetti [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Cc: Struts Developers List dev@struts.apache.org Sent: Thu, 16 Feb 2006 15:05:46 -0500 (EST) Subject: Re: Passing Parameters to ActionForward from Action Woo-hoo, dueling AJAX toolkits! ;) LOL ... http://javawebparts.sourceforge.net/javadocs/javawebparts/taglib/ajaxtags/package-summary.html Pretty darned easy too :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 3:01 pm, [EMAIL PROTECTED] said: Another shameless plug: The easiest to use ajax implementation on earth. No tag logic to learn, no new JavaScript syntax to add to your own, just strait access to your plain old Java objects. There is video training and documentation available at http://www.xoscript.org . I am working on an ActionClass that will allow you to integrate Struts into the next version of xoscript (xml scripting objects), but it is not ready yet. Bryan LaPlante -- Original Message --- From: Frank W. Zammetti [EMAIL PROTECTED] To: dev@struts.apache.org Cc: dev@struts.apache.org Sent: Thu, 16 Feb 2006 09:59:29 -0500 (EST) Subject: Re: Passing Parameters to ActionForward from Action Shameless self-promotion: http://www.omnytex.com/articles :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 8:37 am, shiiva said: Bryan, I am totaly new to ajax. can u suggest me any get started kind of tutorial. Thanks, Siva - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=18280messageID=36339#36339 - 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] --- End of Original Message --- - 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] --- End of Original Message --- - 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]
Re: Reasons for 1.3 release
Once Struts Action 2.0 is stable, yes, I'd recommend it for new development. Even now, I'd recommend WebWork 2.2.1 for new development since migration to Action 2 will be trivial. Still, I see Action 1.3 living a long, full life even with its older sibling taking the spotlight. Heck, look at how WebWork 1 is still going strong and it has a small fraction of the user base Struts Action 1 has. I see many more GA releases to come from the Action 1 branch. Don Michael Jouravlev wrote: Can I rephrase the above as: 1.3 is a bugfix + some internal surgery release for legacy Struts apps in case you want to perform a mild refactoring on them? Can I also assume that you recommend using WebWork / 2.0 for new projects? What is your outlook on future of 1.3 branch after it released as GA? - 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]
Re: Passing Parameters to ActionForward from Action
On 2/16/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 2/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You know what would be cool for the javawebparts implementation. Make a tag called snippets or something, have it work like MessageResource where you could store things such onclick and other events and then be able to mark up your HTML with something that feels like bean:write property... where the property name would be replaced with your ajax call necessary to process the event. Is this your implementation? Do you have a discussion form for it? http://www.jroller.com/page/javadujour?entry=prep_tag_as_a_view Ugh, now when I read Brian's idea again, mine is not exactly the same. And it is not even about Ajax, it is about large solid tags, like, say html:form tag. I would prefer to use a regular HTML form tag, substituting some attributes with dynamic data generated by taglib. I will try it for my project first, if it works out, I will try to refactor Struts html: taglib, maybe it will be interesting for some. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
Can I rephrase the above as: 1.3 is a bugfix + some internal surgery release for legacy Struts apps in case you want to perform a mild refactoring on them? Can I also assume that you recommend using WebWork / 2.0 for new projects? What is your outlook on future of 1.3 branch after it released as GA? The change from Struts 1.x to Struts 2.x is likely to be rather dramatic, and many people may be more ready to use Struts 1.3, which should be essentially backwards compatible with Struts 1.2 and earlier apps than they are to learn a substantially new development paradigm. Others will never bother to touch Struts 1.3 and will have already started using WebWork. There is a broad spectrum of users out there. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
On 2/16/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 2/16/06, Don Brown [EMAIL PROTECTED] wrote: From a Struts user standpoint, I'm am very interested in a 1.3.x GA release. I have legacy Struts applications that lost funding, save the occastional bug fix, and I want a stable Struts that has the Commons Chain request processor and the ability to pass multiple runtime parameters to Struts Actions that only Struts 1.3 has. Yes, the WebWork 2-based Struts Action 2.0 is coming and yes, I think it will be technically superior to 1.3 in most every way, but it doesn't exist as far as my legacy Struts applications are concerned. In fact, I plan to bundle Struts Action 1.3 with Struts Action 2.0 so that users like myself can upgrade to the latest Struts without having to rewrite code or worry about things breaking. Can I rephrase the above as: 1.3 is a bugfix + some internal surgery release for legacy Struts apps in case you want to perform a mild refactoring on them? You can, of course, and you just did, but it wouldn't be accurate. ;-) Amongst other things, 1.3 brings a clean way of implementing your action mappings as chains of commands instead of using actions. That alone makes it stand out from 1.2. I like it a lot. At the same time, you can still use actions if you want to, which makes it a great platform ifor when you need to be able to reuse some of the work you've put in on 1.2 or earlier applications. Can I also assume that you recommend using WebWork / 2.0 for new projects? What is your outlook on future of 1.3 branch after it released as GA? I think that's going to depend on peoples' comfort levels and schedules. Most Struts users today probably have never looked at WebWork. They know that things are going to change as WebWork morphs into Struts 2. Maybe they're ready to make the leap to WebWork now, and go with the flow as it morphs. Or maybe they're more comfortable sticking with what they know for now - the Struts 1 line - until Struts 2 solidifies. To each his own. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing Parameters to ActionForward from Action
I'm with you. I don't like using substitute html tags. They never take into account that tags now a days can have expando properties that become part of the html DOM. Bryan LaPlante -- Original Message --- From: Michael Jouravlev [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Thu, 16 Feb 2006 12:32:48 -0800 Subject: Re: Passing Parameters to ActionForward from Action On 2/16/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 2/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You know what would be cool for the javawebparts implementation. Make a tag called snippets or something, have it work like MessageResource where you could store things such onclick and other events and then be able to mark up your HTML with something that feels like bean:write property... where the property name would be replaced with your ajax call necessary to process the event. Is this your implementation? Do you have a discussion form for it? http://www.jroller.com/page/javadujour?entry=prep_tag_as_a_view Ugh, now when I read Brian's idea again, mine is not exactly the same. And it is not even about Ajax, it is about large solid tags, like, say html:form tag. I would prefer to use a regular HTML form tag, substituting some attributes with dynamic data generated by taglib. I will try it for my project first, if it works out, I will try to refactor Struts html: taglib, maybe it will be interesting for some. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- End of Original Message --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
On 2/16/06, Martin Cooper [EMAIL PROTECTED] wrote: Amongst other things, 1.3 brings a clean way of implementing your action mappings as chains of commands instead of using actions. That alone makes it stand out from 1.2. I like it a lot. At the same time, you can still use actions if you want to, which makes it a great platform ifor when you need to be able to reuse some of the work you've put in on 1.2 or earlier applications. Backward compatibility is great. Considering chain of commands, do you really think that someone who supports a legacy app, will get to refactor it with chain? (Unless this someone already did it a year ago using nightly build ;-) ). I mean, how the learning curve for 1.3 CoR compares with learning curve for WebWork and interceptors? Therefore I have doubts that CoR will be used widely, outside of early adopters' circle. But I am glad that it finally is about to make it officially. So, how about clean docs/samples on using CoR? (I asked about this in another thread). What about up-to-date MailReader? To my shame, I have not looked into CoR since my last surge of interest in September last year. Frankly, I am pretty happy with 1.2.x (or maybe I am just lazy). The docs/samples will be the major factor for adoption among Struts 1.2.x public. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
On 2/16/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 2/16/06, Martin Cooper [EMAIL PROTECTED] wrote: Amongst other things, 1.3 brings a clean way of implementing your action mappings as chains of commands instead of using actions. That alone makes it stand out from 1.2. I like it a lot. At the same time, you can still use actions if you want to, which makes it a great platform ifor when you need to be able to reuse some of the work you've put in on 1.2 or earlier applications. Backward compatibility is great. Considering chain of commands, do you really think that someone who supports a legacy app, will get to refactor it with chain? (Unless this someone already did it a year ago using nightly build ;-) ). I mean, how the learning curve for 1.3 CoR compares with learning curve for WebWork and interceptors? Therefore I have doubts that CoR will be used widely, outside of early adopters' circle. But I am glad that it finally is about to make it officially. The chain stuff is actually available in 1.2.x as well, as an add-on package, so it's not exactly new news. It's been available for 2-1/2 years now. It's just that it's not as cleanly integrated in 1.2 as it is in 1.3. I was actually talking about forwards compatibility, rather than backwards compatibility. If I'm building a new app using 1.3, and I realise that I need some of the same functionality that I built into an earlier 1.2 app, I can, assuming I structured my actions properly, simply pick up my existing actions and drop them into my 1.3 app, even if the rest of the app is built using chains. But even for someone who's working on a legacy app, moving to 1.3 will allow them to use chains for new parts of the application if they want to, leaving the rest using actions. The learning hump for using chains is very, very low. So, how about clean docs/samples on using CoR? (I asked about this in another thread). What about up-to-date MailReader? Volunteers are always welcome. ;-) -- Martin Cooper To my shame, I have not looked into CoR since my last surge of interest in September last year. Frankly, I am pretty happy with 1.2.x (or maybe I am just lazy). The docs/samples will be the major factor for adoption among Struts 1.2.x public. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
Martin, going OT just a bit... how are you using CoR now? Are you simply implementing your Actions as Commands instead, or are you actually composing your Actions out of a number of Commands? Or, are you simply altering the RP chain and still using Actions (or maybe making them Commands technically part of the RP chain)? I ask because I've dene two apps now where I used Struts 1.2.6 and my own CoR implementation from JWP, and the way I did it was to have a single Action that fires off a chain. But, in 95% of the cases, the chain was really just a single Command, so arguably there wasn't much benefit. I think CoR is a great pattern, I've used it with great success, but I'm not as sure how it fits into Struts *outside* the composable RP, which is a *perfect* application for it. Just curious how you (and/or others) are already using it. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 4:20 pm, Martin Cooper said: On 2/16/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 2/16/06, Martin Cooper [EMAIL PROTECTED] wrote: Amongst other things, 1.3 brings a clean way of implementing your action mappings as chains of commands instead of using actions. That alone makes it stand out from 1.2. I like it a lot. At the same time, you can still use actions if you want to, which makes it a great platform ifor when you need to be able to reuse some of the work you've put in on 1.2 or earlier applications. Backward compatibility is great. Considering chain of commands, do you really think that someone who supports a legacy app, will get to refactor it with chain? (Unless this someone already did it a year ago using nightly build ;-) ). I mean, how the learning curve for 1.3 CoR compares with learning curve for WebWork and interceptors? Therefore I have doubts that CoR will be used widely, outside of early adopters' circle. But I am glad that it finally is about to make it officially. The chain stuff is actually available in 1.2.x as well, as an add-on package, so it's not exactly new news. It's been available for 2-1/2 years now. It's just that it's not as cleanly integrated in 1.2 as it is in 1.3. I was actually talking about forwards compatibility, rather than backwards compatibility. If I'm building a new app using 1.3, and I realise that I need some of the same functionality that I built into an earlier 1.2 app, I can, assuming I structured my actions properly, simply pick up my existing actions and drop them into my 1.3 app, even if the rest of the app is built using chains. But even for someone who's working on a legacy app, moving to 1.3 will allow them to use chains for new parts of the application if they want to, leaving the rest using actions. The learning hump for using chains is very, very low. So, how about clean docs/samples on using CoR? (I asked about this in another thread). What about up-to-date MailReader? Volunteers are always welcome. ;-) -- Martin Cooper To my shame, I have not looked into CoR since my last surge of interest in September last year. Frankly, I am pretty happy with 1.2.x (or maybe I am just lazy). The docs/samples will be the major factor for adoption among Struts 1.2.x public. - 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]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- + link href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / body bgcolor=#CC Describe Vandekeere here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- link href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / - body bgcolor=#CC Describe Vandekeere here. + Describe Vandekeere here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- link href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / - Describe Vandekeere here. + bodyDescribe Vandekeere here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- - link href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / + headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css //head + + bodyDescribe Vandekeere here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css //head + bodyp + Text can be written here - bodyDescribe Vandekeere here. + /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css //head - bodyp + bodypText can be written here/p - Text can be written here - - /p - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css //head - bodypText can be written here/p + bodyp + Text can be written here + + /p + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css //head - bodyp + bodyFONT COLOR=#ccText can be written here/FONT - Text can be written here - - /p - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css //head - bodyFONT COLOR=#ccText can be written here/FONT + Text can be written here + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38255] - [Standalone Tiles\ Add Application Listener
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38255. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38255 --- Additional Comments From [EMAIL PROTECTED] 2006-02-16 22:42 --- Created an attachment (id=17721) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17721action=view) TilesListener with same functionality as TilesServlet Here's a TilesListener I created with the same functionality as TilesServlet. I didn't write a test for it, but I was able to replace my TilesServlet with this listener and it all worked. In web.xml: context-param param-namedefinitions-config/param-name param-value/WEB-INF/tiles-config.xml/param-value /context-param ... listener listener-classorg.apache.tiles.listener.TilesListener/listener-class /listener This could use some polishing for sure, but it works! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/Vandekeere The comment on the change is: This is not a sandbox. Please, experiment with Wiki in a sandbox. -- - headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css //head + deleted - Text can be written here - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38255] - [Standalone Tiles\ Add Application Listener
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38255. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38255 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- - headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css //head + Describe Vandekeere here. - Text can be written here - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- + link href=stylesheet.css rel=stylesheet type=text/css / + Describe Vandekeere here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- - link href=stylesheet.css rel=stylesheet type=text/css / + link href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / Describe Vandekeere here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- - link href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / + headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / - + /head Describe Vandekeere here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / /head - Describe Vandekeere here. + Text can be written here. + + Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec ullamcorper commodo elit. Duis vel massa pulvinar orci tempor pharetra. Quisque ac dui. Etiam ac ligula. Duis nunc pede, ornare vel, feugiat eget, dignissim a, nulla. Suspendisse potenti. Aliquam risus risus, laoreet sit amet, gravida sed, malesuada ut, massa. Fusce congue adipiscing magna. Mauris lectus. Fusce vel arcu vitae lorem sollicitudin imperdiet. Nullam ligula. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nullam sollicitudin. Curabitur condimentum egestas urna. Ut urna felis, sagittis in, ultrices sit amet, suscipit eu, felis. Morbi volutpat. Pellentesque lacus. Donec congue. + + Nam accumsan tincidunt nisi. Morbi ultricies quam id diam. Suspendisse potenti. Sed pede enim, placerat nec, cursus ac, elementum at, arcu. Nulla laoreet. Maecenas ornare mi non sapien volutpat ullamcorper. Quisque risus purus, laoreet vel, hendrerit vel, rutrum non, nisi. Etiam sem urna, interdum nec, auctor vel, congue ac, metus. Ut feugiat tortor a nibh. In vitae nisl id ipsum gravida molestie. + + Praesent nulla mauris, congue blandit, tempor non, faucibus sit amet, dolor. Vivamus at enim. Fusce convallis turpis. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Aenean semper dignissim pede. Mauris purus purus, vehicula in, nonummy id, ultricies eu, quam. Sed mauris leo, elementum in, tincidunt in, dignissim in, augue. Proin consequat semper nunc. Donec quis mauris. Phasellus vel eros sed urna auctor sagittis. Aliquam condimentum luctus magna. Sed non mi sit amet massa feugiat hendrerit. Suspendisse ultricies justo a lacus. Praesent gravida, diam vitae blandit interdum, magna dolor commodo augue, ut posuere nibh lacus sit amet arcu. Vestibulum fringilla malesuada lectus. Fusce vel arcu. Vestibulum quis tortor vitae lorem congue fringilla. + + Nam pretium cursus est. Quisque volutpat dui vitae nisi. Pellentesque risus lacus, facilisis eu, scelerisque vel, egestas sagittis, lacus. Donec ut augue. Sed augue turpis, bibendum eu, convallis eu, pulvinar sed, felis. Vivamus elit mauris, suscipit in, ornare quis, porta ac, lectus. Proin nibh. Mauris sit amet justo. Etiam eleifend malesuada dolor. Nulla facilisi. Proin tortor purus, gravida at, tincidunt non, tempor a, nisi. Nam aliquam, enim sit amet ultricies ultrices, tellus dolor vestibulum risus, quis vestibulum orci leo sit amet justo. Phasellus condimentum justo non magna nonummy lobortis. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Donec eros justo, fermentum sed, nonummy nec, rhoncus eu, urna. Cras arcu. Ut tempus lorem. + + Cras feugiat tellus ut dui. Vivamus non felis. Morbi congue. Donec tortor arcu, posuere et, sagittis in, lacinia nec, mi. Quisque eget nisl nec eros pellentesque egestas. In ac justo. Nulla mollis. Suspendisse metus erat, elementum in, semper et, consequat sit amet, orci. Vestibulum porta purus ut mi. Nam quis nisi. + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- + /!\ '''Edit conflict - other version:''' headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / /head Text can be written here. @@ -15, +16 @@ Cras feugiat tellus ut dui. Vivamus non felis. Morbi congue. Donec tortor arcu, posuere et, sagittis in, lacinia nec, mi. Quisque eget nisl nec eros pellentesque egestas. In ac justo. Nulla mollis. Suspendisse metus erat, elementum in, semper et, consequat sit amet, orci. Vestibulum porta purus ut mi. Nam quis nisi. + /!\ '''Edit conflict - your version:''' + headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / + /head + Describe Vandekeere here. + + /!\ '''End of edit conflict''' + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/Vandekeere The comment on the change is: Please, experiment in the sandbox: http://moinmoin.wikiwikiweb.de/WikiSandBox -- + deleted - /!\ '''Edit conflict - other version:''' - headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / - /head - Text can be written here. - - Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec ullamcorper commodo elit. Duis vel massa pulvinar orci tempor pharetra. Quisque ac dui. Etiam ac ligula. Duis nunc pede, ornare vel, feugiat eget, dignissim a, nulla. Suspendisse potenti. Aliquam risus risus, laoreet sit amet, gravida sed, malesuada ut, massa. Fusce congue adipiscing magna. Mauris lectus. Fusce vel arcu vitae lorem sollicitudin imperdiet. Nullam ligula. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nullam sollicitudin. Curabitur condimentum egestas urna. Ut urna felis, sagittis in, ultrices sit amet, suscipit eu, felis. Morbi volutpat. Pellentesque lacus. Donec congue. - - Nam accumsan tincidunt nisi. Morbi ultricies quam id diam. Suspendisse potenti. Sed pede enim, placerat nec, cursus ac, elementum at, arcu. Nulla laoreet. Maecenas ornare mi non sapien volutpat ullamcorper. Quisque risus purus, laoreet vel, hendrerit vel, rutrum non, nisi. Etiam sem urna, interdum nec, auctor vel, congue ac, metus. Ut feugiat tortor a nibh. In vitae nisl id ipsum gravida molestie. - - Praesent nulla mauris, congue blandit, tempor non, faucibus sit amet, dolor. Vivamus at enim. Fusce convallis turpis. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Aenean semper dignissim pede. Mauris purus purus, vehicula in, nonummy id, ultricies eu, quam. Sed mauris leo, elementum in, tincidunt in, dignissim in, augue. Proin consequat semper nunc. Donec quis mauris. Phasellus vel eros sed urna auctor sagittis. Aliquam condimentum luctus magna. Sed non mi sit amet massa feugiat hendrerit. Suspendisse ultricies justo a lacus. Praesent gravida, diam vitae blandit interdum, magna dolor commodo augue, ut posuere nibh lacus sit amet arcu. Vestibulum fringilla malesuada lectus. Fusce vel arcu. Vestibulum quis tortor vitae lorem congue fringilla. - - Nam pretium cursus est. Quisque volutpat dui vitae nisi. Pellentesque risus lacus, facilisis eu, scelerisque vel, egestas sagittis, lacus. Donec ut augue. Sed augue turpis, bibendum eu, convallis eu, pulvinar sed, felis. Vivamus elit mauris, suscipit in, ornare quis, porta ac, lectus. Proin nibh. Mauris sit amet justo. Etiam eleifend malesuada dolor. Nulla facilisi. Proin tortor purus, gravida at, tincidunt non, tempor a, nisi. Nam aliquam, enim sit amet ultricies ultrices, tellus dolor vestibulum risus, quis vestibulum orci leo sit amet justo. Phasellus condimentum justo non magna nonummy lobortis. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Donec eros justo, fermentum sed, nonummy nec, rhoncus eu, urna. Cras arcu. Ut tempus lorem. - - Cras feugiat tellus ut dui. Vivamus non felis. Morbi congue. Donec tortor arcu, posuere et, sagittis in, lacinia nec, mi. Quisque eget nisl nec eros pellentesque egestas. In ac justo. Nulla mollis. Suspendisse metus erat, elementum in, semper et, consequat sit amet, orci. Vestibulum porta purus ut mi. Nam quis nisi. - - /!\ '''Edit conflict - your version:''' - headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / - /head - Describe Vandekeere here. - - /!\ '''End of edit conflict''' - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- + Describe Vandekeere here. + + CategoryTemplate - /!\ '''Edit conflict - other version:''' - headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / - /head - Text can be written here. - - Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec ullamcorper commodo elit. Duis vel massa pulvinar orci tempor pharetra. Quisque ac dui. Etiam ac ligula. Duis nunc pede, ornare vel, feugiat eget, dignissim a, nulla. Suspendisse potenti. Aliquam risus risus, laoreet sit amet, gravida sed, malesuada ut, massa. Fusce congue adipiscing magna. Mauris lectus. Fusce vel arcu vitae lorem sollicitudin imperdiet. Nullam ligula. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nullam sollicitudin. Curabitur condimentum egestas urna. Ut urna felis, sagittis in, ultrices sit amet, suscipit eu, felis. Morbi volutpat. Pellentesque lacus. Donec congue. - - Nam accumsan tincidunt nisi. Morbi ultricies quam id diam. Suspendisse potenti. Sed pede enim, placerat nec, cursus ac, elementum at, arcu. Nulla laoreet. Maecenas ornare mi non sapien volutpat ullamcorper. Quisque risus purus, laoreet vel, hendrerit vel, rutrum non, nisi. Etiam sem urna, interdum nec, auctor vel, congue ac, metus. Ut feugiat tortor a nibh. In vitae nisl id ipsum gravida molestie. - - Praesent nulla mauris, congue blandit, tempor non, faucibus sit amet, dolor. Vivamus at enim. Fusce convallis turpis. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Aenean semper dignissim pede. Mauris purus purus, vehicula in, nonummy id, ultricies eu, quam. Sed mauris leo, elementum in, tincidunt in, dignissim in, augue. Proin consequat semper nunc. Donec quis mauris. Phasellus vel eros sed urna auctor sagittis. Aliquam condimentum luctus magna. Sed non mi sit amet massa feugiat hendrerit. Suspendisse ultricies justo a lacus. Praesent gravida, diam vitae blandit interdum, magna dolor commodo augue, ut posuere nibh lacus sit amet arcu. Vestibulum fringilla malesuada lectus. Fusce vel arcu. Vestibulum quis tortor vitae lorem congue fringilla. - - Nam pretium cursus est. Quisque volutpat dui vitae nisi. Pellentesque risus lacus, facilisis eu, scelerisque vel, egestas sagittis, lacus. Donec ut augue. Sed augue turpis, bibendum eu, convallis eu, pulvinar sed, felis. Vivamus elit mauris, suscipit in, ornare quis, porta ac, lectus. Proin nibh. Mauris sit amet justo. Etiam eleifend malesuada dolor. Nulla facilisi. Proin tortor purus, gravida at, tincidunt non, tempor a, nisi. Nam aliquam, enim sit amet ultricies ultrices, tellus dolor vestibulum risus, quis vestibulum orci leo sit amet justo. Phasellus condimentum justo non magna nonummy lobortis. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Donec eros justo, fermentum sed, nonummy nec, rhoncus eu, urna. Cras arcu. Ut tempus lorem. - - Cras feugiat tellus ut dui. Vivamus non felis. Morbi congue. Donec tortor arcu, posuere et, sagittis in, lacinia nec, mi. Quisque eget nisl nec eros pellentesque egestas. In ac justo. Nulla mollis. Suspendisse metus erat, elementum in, semper et, consequat sit amet, orci. Vestibulum porta purus ut mi. Nam quis nisi. - - /!\ '''Edit conflict - your version:''' - headlink href=http://www.buro2.be/confusion/stylesheet.css; rel=stylesheet type=text/css / - /head - Describe Vandekeere here. - - /!\ '''End of edit conflict''' - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- Describe Vandekeere here. - - CategoryTemplate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by Vandekeere
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Vandekeere: http://wiki.apache.org/struts/Vandekeere -- - Describe Vandekeere here. + What could be the problem with our encounter on a text? + It could be too fix; it could be exactly what we donât want our project to become. Letâs avoid the division in Concept and Process and letâs edit it as a wave of thoughts between you and me. We already have so much in our interstice. Letâs just show it as a flux or a flow. + Thatâs the only way not to loose all the precious inputs we gave the project. We arrived from different ways and keep the diversity in order to enrich the organic structure and make our reciprocal activation not a simply death end. + Letâs edit a text divided just by spaces and letâs forget the titles. Letâs edit a text that progress in all the interesting direction that we have already activated. + The text is an object and the medium of writing has implications on how we think and on how ideas are produced. In order to this the text is one of the objects produced but not the only or final one. In order to develop what and how we think we have to find different approaches to every point we make. In this case the text is an ongoing dialogue, it is a process that not only goes forwards but also backwards, to the left and to the right, up and down and somewhere else. There will be questions and some answers, but also not fully expressed ideas. These aspects can continually be rewritten, completed or even erased - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsRelease12 by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/StrutsRelease12 The comment on the change is: Redundant page -- + deleted - This page is redundant see StrutsUpgrade - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of MerryChristmas by MichaelJouravlev
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/MerryChristmas
The comment on the change is:
Orphaned; offtopic
--
- Navigation Trail: HomePage / StrutsProjectPages
+ deleted
- Thank you James Turner for this wonderful Christmas poem.
-
- {{{
- James Turner wrote:
-
- With apologies to Clement Clarke Moore
-
- 'twas the night before Christmas, and all 'cross the world.
- Not a user was typing, the code was all curled.
- The patches were entered and each file was checked in,
- In hopes that 1.2 New Years would bring.
- The coders were nestled all snug by their LANs.
- With visions of post-release features and plans.
- When up on the screen there appeared such a sight.
- I opened the e-Mail, sent that very night.
-
- Quickly I read the contents of the letter,
- With each word, my mood became better and better.
- From craigmcc at apache dot org.
- Subject: Let's ship it with no more reorg.
- He went on to say that each package was done.
- And called their names out like each one was his son.
-
- Ship DynaForms, Taglibs, Controller and Actions.
- Ship EL and Tiles with no further distractions.
- To the centers of business and learning they'll ship.
- Now download and install using dialup and SLIP.
-
- And as he was ending his RELEASE-NOTES.TXT
- With nary a sign he was bothered or vexed.
- He added one note, which I read with delight.
- MVC use to all, and to all a good night!
- }}}
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of Vandekeere by GeorgeDinwiddie
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by GeorgeDinwiddie: http://wiki.apache.org/struts/Vandekeere -- + '''Do you realize that everytime you edit this you are spamming a mailinglist?''' + + Please do your experimentation on http://moinmoin.wikiwikiweb.de/WikiSandBox rather than here. + What could be the problem with our encounter on a text? It could be too fix; it could be exactly what we donât want our project to become. Letâs avoid the division in Concept and Process and letâs edit it as a wave of thoughts between you and me. We already have so much in our interstice. Letâs just show it as a flux or a flow. Thatâs the only way not to loose all the precious inputs we gave the project. We arrived from different ways and keep the diversity in order to enrich the organic structure and make our reciprocal activation not a simply death end. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of NewPage by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/NewPage The comment on the change is: Orphaned page -- - emptyemptyempty! + deleted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of ActionMessagesTool by MichaelJouravlev
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/ActionMessagesTool
The comment on the change is:
Orphaned; no documentation besides, just a big chunk of code.
--
- July 24, 2003
+ deleted
- Here is an updated version of the ActionMessagesTool, compatible with Struts
1.1 ... it now calls the new .getMessageResources() in StrutsUtils.
-
- Any comments are welcome on the Velocity Developer's List
velocity-dev@jakarta.apache.org.
-
- Marinó A. Jónsson
-
-
- {{{
- { { {
-
- package org.apache.velocity.tools.struts;
-
- import java.util.ArrayList;
- import java.util.Iterator;
- import java.util.Locale;
-
- import javax.servlet.http.HttpServletRequest;
- import javax.servlet.http.HttpSession;
- import javax.servlet.ServletContext;
-
- import org.apache.struts.util.MessageResources;
- import org.apache.struts.action.ActionMessage;
- import org.apache.struts.action.ActionMessages;
-
- import org.apache.velocity.app.Velocity;
- import org.apache.velocity.tools.struts.StrutsUtils;
- import org.apache.velocity.tools.view.context.ViewContext;
- import org.apache.velocity.tools.view.tools.ViewTool;
-
- /**
- {{{ * pView tool to work with the Struts action messages./p
- *
- * pThis class is equipped to be used with a toolbox manager, for example
- * the ServletToolboxManager included with VelocityViewServlet. This class
- * implements interface ViewTool, which allows a toolbox manager to pass the
- * required context information./p
- *
- * pThis means this tool should only be used in the request scope./p
- *
- * @author a href=mailto:[EMAIL PROTECTED]Gabe Sidler/a
- * @author a href=mailto:[EMAIL PROTECTED]Nathan Bubna/a
- *
- * @version $Id: ActionMessagesTool.java,v 1.1 2003/07/22 06:09:22 nbubna Exp
$
- */ }}}
- public class ActionMessagesTool implements ViewTool
- {
-
- {{{/** A reference to the Struts message resources. */
- protected MessageResources resources;
-
- /** A reference to the user's locale. */
- protected Locale locale;
-
- /** A reference to the queued action messages. */
- protected ActionMessages actionMsgs;
-
-
- /**
- * Default constructor. Tool must be initialized before use.
- */
- public ActionMessagesTool()
- {}
-
-
- /**
- * Initializes this tool.
- *
- * @param obj the current ViewContext
- * @throws IllegalArgumentException if the param is not a ViewContext
- */
- public void init(Object obj)
- {
- if (!(obj instanceof ViewContext))
- {
- throw new IllegalArgumentException(Tool can only be initialized
with a ViewContext);
- }
-
- ViewContext context = (ViewContext)obj;
- HttpServletRequest request = context.getRequest();
- HttpSession session = request.getSession(false);
- ServletContext application = context.getServletContext();
-
- this.locale = StrutsUtils.getLocale(request, session);
- this.resources = StrutsUtils.getMessageResources(request,
application);
- this.actionMsgs = StrutsUtils.getActionMessages(request);
- }
-
-
- /*** Public Methods ***/
-
- /**
- * pReturns codetrue/code if there are action messages queued,
- * otherwise codefalse/code./p
- */
- public boolean exist()
- {
- if (actionMsgs == null)
- {
- return false;
- }
- return !actionMsgs.isEmpty();
- }
-
-
- /**
- * pReturns true if there are action messages queued for the specified
- * category of messages, otherwise codefalse/code./p
- *
- * @param property the category of messages to check for
- */
- public boolean exist(String property)
- {
- if (actionMsgs == null)
- {
- return false;
- }
- return (actionMsgs.size(property) 0);
- }
-
-
- /**
- * Returns the number of action messages queued.
- */
- public int getSize()
- {
- if (actionMsgs == null)
- {
- return 0;
- }
- return actionMsgs.size();
- }
-
-
- /**
- * Returns the number of action messages queued for a particular
property.
- *
- * @param property the category of messages to check for
- */
- public int getSize(String property)
- {
- if (actionMsgs == null)
- {
- return 0;
- }
- return actionMsgs.size(property);
- }
-
-
- /**
- * Returns the set of localized action messages as an
- * codejava.util.ArrayList/code of code
[Struts Wiki] Update of BenefitsOfStruts by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/BenefitsOfStruts The comment on the change is: Orphaned; no content. -- - Superceded by StrutsBenefits + deleted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of BuildingStrutsFromSource by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/BuildingStrutsFromSource The comment on the change is: Orphaned; no content. -- - Superceded by StrutsBuildingFromSource + deleted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[shale][patch] Simple patch to get the AJAX example working properly
Without this patch, I received javascript errors in Firefox.
-
Index: use-cases/src/web/ajax/zipCode.jsp
===
--- use-cases/src/web/ajax/zipCode.jsp (revision 378284)
+++ use-cases/src/web/ajax/zipCode.jsp (working copy)
@@ -33,8 +33,8 @@
// from the zip code menu.
function zipChanged(zip) {
- sendRequest(%= request.getContextPath() % +
-
dynamic/remoting$business/cityAndStateForZip.faces +
+ sendRequest(%= request.getContextPath() % +
+
/dynamic/remoting$business/cityAndStateForZip.faces +
?zip= + escape(zip),
processZipCodeSelection);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of ChristopherHamilton by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/ChristopherHamilton The comment on the change is: Orphaned; empty; offtopic (personal email) -- + deleted - ##language:en - == Christopher Hamilton == - Email: [[MailTo(chamiltonhyphenapache AT SPAMFREE compucafe DOT com)]] - - - - CategoryHomepage - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
On 2/16/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Martin, going OT just a bit... how are you using CoR now? Are you simply implementing your Actions as Commands instead, or are you actually composing your Actions out of a number of Commands? The latter. I have no Action classes at all, and each action mapping corresponds to a chain. There are some chains, as you describe below, that degenerate to a single command, but most don't. I also have at least one case where I have a special-purpose catalog that I look up (from within a command) based on certain request characteristics, and invoke a chain from that catalog to handle part of the request. This is all AJAX-driven. No JSP, no Tiles, etc. Or, are you simply altering the RP chain and still using Actions (or maybe making them Commands technically part of the RP chain)? Yes, I'm modifying the RP chain in both my 1.3 and 1.2+chain apps, primarily for stuff that needs to be centralised, such as authorisation, error / exception handling, and some specialised cancellation handling. I ask because I've dene two apps now where I used Struts 1.2.6 and my own CoR implementation from JWP, and the way I did it was to have a single Action that fires off a chain. But, in 95% of the cases, the chain was really just a single Command, so arguably there wasn't much benefit. In my 1.2+chain app, which does use JSP Tiles, a very common pattern is a chain that has a command to save some state, followed by one or more commands to load data for subsequent presentation. This allows me to reconfigure the user's path through the app just by reconfiguring the chains and forwards, without having to touch any Java code. My 1.3 app has something similar in some ways, but it gets too complicated to try to explain here. -- Martin Cooper I think CoR is a great pattern, I've used it with great success, but I'm not as sure how it fits into Struts *outside* the composable RP, which is a *perfect* application for it. Just curious how you (and/or others) are already using it. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 4:20 pm, Martin Cooper said: On 2/16/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 2/16/06, Martin Cooper [EMAIL PROTECTED] wrote: Amongst other things, 1.3 brings a clean way of implementing your action mappings as chains of commands instead of using actions. That alone makes it stand out from 1.2. I like it a lot. At the same time, you can still use actions if you want to, which makes it a great platform ifor when you need to be able to reuse some of the work you've put in on 1.2 or earlier applications. Backward compatibility is great. Considering chain of commands, do you really think that someone who supports a legacy app, will get to refactor it with chain? (Unless this someone already did it a year ago using nightly build ;-) ). I mean, how the learning curve for 1.3 CoR compares with learning curve for WebWork and interceptors? Therefore I have doubts that CoR will be used widely, outside of early adopters' circle. But I am glad that it finally is about to make it officially. The chain stuff is actually available in 1.2.x as well, as an add-on package, so it's not exactly new news. It's been available for 2-1/2 years now. It's just that it's not as cleanly integrated in 1.2 as it is in 1.3. I was actually talking about forwards compatibility, rather than backwards compatibility. If I'm building a new app using 1.3, and I realise that I need some of the same functionality that I built into an earlier 1.2app, I can, assuming I structured my actions properly, simply pick up my existing actions and drop them into my 1.3 app, even if the rest of the app is built using chains. But even for someone who's working on a legacy app, moving to 1.3 will allow them to use chains for new parts of the application if they want to, leaving the rest using actions. The learning hump for using chains is very, very low. So, how about clean docs/samples on using CoR? (I asked about this in another thread). What about up-to-date MailReader? Volunteers are always welcome. ;-) -- Martin Cooper To my shame, I have not looked into CoR since my last surge of interest in September last year. Frankly, I am pretty happy with 1.2.x (or maybe I am just lazy). The docs/samples will be the major factor for adoption among Struts 1.2.x public. - 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]
[Struts Wiki] Update of DAO by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/DAO The comment on the change is: Ophaned, empty, meaningless. -- - ##language:en + deleted - - Email: [[MailTo(you AT SPAMFREE example DOT com)]] - - ... - - - CategoryHomepage - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
On 2/16/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: I think CoR is a great pattern, I've used it with great success, but I'm not as sure how it fits into Struts *outside* the composable RP, which is a *perfect* application for it. Just curious how you (and/or others) are already using it. Ted has some good use case examples in his Agility stuff. One simple scenario is where you want to reuse fine grained commands that allocate resources, without the actual processing logic having to know where it came from (and you're not using a dependency injection framework). Consider a Filter (in the Commons Chain sense, a Command that gets control on the way in and on the way out) that injects a JDBC Connection (or a Hibernate session, or whatever) into the Context object. You'd do that part in the execute() method, then clean up in postprocess() on the way back out. This would be configured into a chain in front of the particular Command that actually performs your business logic -- and its reusable for all commands that need a Connection handed to them. Need some more resources? Add some more fine grained reusable decoarator commands to allocate and release them. This pattern, of course, can be used today in a Struts 1.x action ... or in the action equivalent of any other framework too (JSF, WebWork, whatever). And, it's not even web specific ... you can design your whole business logic layer out of chains. Craig
[Struts Wiki] Update of StrutsIDEGuides by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/StrutsIDEGuides The comment on the change is: Added link to otherwise orphaned page. -- === Current Versions === + * [EclipseIDEExampleProblems] * StrutsEclipse31 * [StrutsIDEA5] * StrutsNetBeans41 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of ErrorsTool by MichaelJouravlev
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/ErrorsTool
The comment on the change is:
Orphaned; no docs, only the code.
--
- July 24, 2003
+ deleted
- Here is an updated version of the ErrorsTool, compatible with Struts 1.1 ...
I only had to change .empty() to .isEmpty() and call the new
getMessageResources() in StrutsUtils.
-
- Any comments are welcome on the Velocity Developer's List
velocity-dev@jakarta.apache.org.
-
- Marinó A. Jónsson
-
-
- {{{
- { { {
-
- package org.apache.velocity.tools.struts;
-
- import java.util.ArrayList;
- import java.util.Iterator;
- import java.util.Locale;
-
- import javax.servlet.http.HttpServletRequest;
- import javax.servlet.http.HttpSession;
- import javax.servlet.ServletContext;
-
- import org.apache.struts.util.MessageResources;
- import org.apache.struts.action.*;
-
- import org.apache.velocity.app.Velocity;
- import org.apache.velocity.tools.view.context.ViewContext;
- import org.apache.velocity.tools.view.tools.ViewTool;
-
-
- /**
- {{{ * pView tool to work with the Struts error messages./p
- *
- * pThis class is equipped to be used with a toolbox manager, for example
- * the ServletToolboxManager included with VelServlet. This class implements
- * interface ViewTool, which allows a toolbox manager to pass the required
- * context information./p
- *
- * pThis class is not thread-safe by design. A new instance is needed for
- * the processing of every template request. This means this tool should
- * only be used in the request scope, not application or session scopes./p
- *
- * @author a href=mailto:[EMAIL PROTECTED]Gabe Sidler/a
- *
- * @version $Id: ErrorsTool.java,v 1.4 2003/05/28 00:17:15 nbubna Exp $
- */ }}}
- public class ErrorsTool implements ViewTool
- {
-
- {{{// - Properties
---
-
- /**
- * A reference to the ServletContext
- */
- protected ServletContext application;
-
-
- /**
- * A reference to the HttpServletRequest.
- */
- protected HttpServletRequest request;
-
-
- /**
- * A reference to the HttpSession.
- */
- protected HttpSession session;
-
-
- /**
- * A reference to the Struts message resources.
- */
- protected MessageResources resources;
-
-
- /**
- * A reference to the user's locale.
- */
- protected Locale locale;
-
-
- /**
- * A reference to the queued action messages.
- */
- protected ActionErrors errors;
-
-
-
- // - Constructors
-
-
- /**
- * Default constructor. Tool must be initialized before use.
- */
- public ErrorsTool()
- {}
-
-
- /**
- * Initializes this tool.
- *
- * @param obj the current ViewContext
- * @throws IllegalArgumentException if the param is not a ViewContext
- */
- public void init(Object obj)
- {
- if (!(obj instanceof ViewContext))
- {
- throw new IllegalArgumentException(Tool can only be initialized
with a ViewContext);
- }
-
- ViewContext context = (ViewContext)obj;
- this.request = context.getRequest();
- this.session = request.getSession(false);
- this.application = context.getServletContext();
-
- resources = StrutsUtils.getMessageResources(request, application);
- locale = StrutsUtils.getLocale(request, session);
- errors = StrutsUtils.getActionErrors(request);
- }
-
-
- // - View Helpers
-
-
- /**
- * pReturns codetrue/code if there are action errors queued,
- * otherwise codefalse/code./p
- */
- public boolean exist()
- {
- if (errors == null)
- {
- return false;
- }
-
- return !errors.isEmpty();
- }
-
-
- /**
- * pReturns true if there are action errors queued for the specified
- * category of errors, otherwise codefalse/code./p
- *
- * @param property the category of errors to check for
- */
- public boolean exist(String property)
- {
- if (errors == null)
- {
- return false;
- }
- return (errors.size(property) 0);
- }
-
-
- /**
- * Returns the number of action errors queued.
- */
- public int getSize()
- {
- if (errors == null)
- {
- return 0;
- }
-
- return errors.size();
- }
-
-
- /**
- * Returns the number of action errors
[Struts Wiki] Update of FrontPageOriginal by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/FrontPageOriginal The comment on the change is: Orphaned; not used. -- + deleted - ##language:en - #pragma section-numbers off - = Welcome to the Apache Struts Wiki = - - This wiki has just been set up as part of the [wiki:ApacheGeneral:FrontPage big Apache Wiki Farm]. It does not contain anything yet. - - = 'Special' Wiki pages = - - '''TitleIndex''' - A list of all pages on this wiki. - - '''HelpContents''' - A basic guide to the MoinMoin wiki (including information about wiki syntax). - - '''WordIndex''' - A list of all the words that appear in the titles of the pages on this wiki, with links to pages that include that word. - - '''FindPage''' - A full-text search of the wiki. - - '''WantedPages''' - All the broken links -- a list of all the pages on this wiki that are linked to, but do not exist. - - '''OrphanedPages''' - All pages on this wiki that are not linked to from anywhere else (and are thus very hard to reach). - - '''RandomPage''' - Generates a list of 75 random pages on this wiki. - - '''PageSize''' - Generates a graph and some statistics about the sizes of pages on this wiki. - - '''EventStats/HitCounts''' - Generates a graph of page views and page visits. - - '''EventStats/UserAgents''' - Generates a graph of the web browsers used in visiting this page. - - '''SystemInformation''' - Shows basic information about this wiki installation, the extensions it has installed, etc. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of HowToReadAnXMLFileForEachUserRequest by MichaelJouravlev
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/HowToReadAnXMLFileForEachUserRequest
The comment on the change is:
Orphaned; offtopic (question posted to wiki instead of mailing list)
--
- Describe HowToReadAnXMLFileForEachUserRequest here.
+ deleted
- I want to read a a large XML config file for each request that comes to the
ActionServlet. The system we have now is we have a customized ActionServlet.
And I am instantiating myXmlClass in the process method. And I call a method
called myXmlClassObject.getXMLAttributeFor the current Action class.
- What is the recommended way to do this.
-
- Currently my code look like this
-
- //MyActionServlet.java
-
- init()
- {
- //perform initialization()
- super.init()
- }
-
- process()
- {
- //do stuff
- instantiate myXmlClass (which has a _saxparser.parse() method)
-
- myXmlClassObject.getMyAttribute()//some data base calls underneath it for
some logging stuff
- //do stuff
- }
- }
-
- Should I make a static object of myXmlClass in my actionServlet.
- Should I put myXmlClass into session, and check for each request whether this
object exists in session, if not create it.
-
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of MessageTool by MichaelJouravlev
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/MessageTool
The comment on the change is:
Orphaned; no docs, only the code.
--
- July 24, 2003
+ deleted
- Here is an updated version of the MessageTool, compatible with Struts 1.1 ...
it now calls the new .getMessageResources() in StrutsUtils.
-
- Any comments are welcome on the Velocity Developer's List
velocity-dev@jakarta.apache.org.
-
- Marinó A. Jónsson
-
-
- {{{
- { { {
-
- package org.apache.velocity.tools.struts;
-
- import java.util.List;
- import java.util.Locale;
-
- import javax.servlet.http.HttpServletRequest;
- import javax.servlet.http.HttpSession;
- import javax.servlet.ServletContext;
-
- import org.apache.struts.util.MessageResources;
- import org.apache.struts.action.*;
-
- import org.apache.velocity.app.Velocity;
- import org.apache.velocity.tools.view.context.ViewContext;
- import org.apache.velocity.tools.view.tools.ViewTool;
-
-
- /**
- {{{ * pView tool that provides methods to render Struts message
resources./p
- *
- * pThis class is equipped to be used with a toolbox manager, for example
- * the ServletToolboxManager included with VelServlet. This class implements
- * interface ViewTool, which allows a toolbox manager to pass the
- * required context information./p
- *
- * pThis class is not thread-safe by design. A new instance is needed for
- * the processing of every template request. This means this tool should
- * only be used in the request scope, not application or session scopes./p
- *
- * @author a href=mailto:[EMAIL PROTECTED]Gabe Sidler/a
- *
- * @version $Id: MessageTool.java,v 1.3 2003/05/28 00:17:15 nbubna Exp $
- */ }}}
- public class MessageTool implements ViewTool
- {
-
- {{{// - Properties ---
-
- /**
- * A reference to the Struts message resources.
- */
- protected MessageResources resources;
-
-
- /**
- * A reference to the user's locale.
- */
- protected Locale locale;
-
-
-
- // - Constructors
-
-
- /**
- * Default constructor. Tool must be initialized before use.
- */
- public MessageTool()
- {
- }
-
-
- /**
- * Initializes this tool.
- *
- * @param obj the current ViewContext
- * @throws IllegalArgumentException if the param is not a ViewContext
- */
- public void init(Object obj)
- {
- if (!(obj instanceof ViewContext))
- {
- throw new IllegalArgumentException(Tool can only be initialized
with a ViewContext);
- }
-
- ViewContext context = (ViewContext)obj;
- HttpServletRequest request = context.getRequest();
- HttpSession session = request.getSession(false);
- ServletContext application = context.getServletContext();
-
- this.resources = StrutsUtils.getMessageResources(request,
application);
- this.locale = StrutsUtils.getLocale(request, session);
- }
-
-
-
- // - View Helpers
-
-
- /**
- * Looks up and returns the localized message for the specified key.
- * The user's locale is consulted to determine the language of the
- * message.
- *
- * @param key message key
- *
- * @return the localized message for the specified key or
- * codenull/code if no such message exists
- */
- public String get(String key)
- {
- if (resources == null)
- {
- Velocity.error(Message resources are not available.);
- return null;
- }
- return resources.getMessage(locale, key);
- }
-
-
- /**
- * Looks up and returns the localized message for the specified key.
- * Replacement parameters passed with codeargs/code are
- * inserted into the message. The user's locale is consulted to
- * determine the language of the message.
- *
- * @param key message key
- * @param args replacement parameters for this message
- *
- * @return the localized message for the specified key or
- * codenull/code if no such message exists
- */
- public String get(String key, Object args[])
- {
- if (resources == null)
- {
- Velocity.error(Message resources are not available.);
- return null;
- }
-
- // return the requested message
- if (args == null)
- {
- return resources.getMessage(locale, key);
- }
- else
- {
- return
[Struts Wiki] Update of ModelingNotes by MichaelJouravlev
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/ModelingNotes
The comment on the change is:
Orphaned; Not really a wiki page, just a scratchpad.
--
- Modeling Notes
+ deleted
- This is a scatchpad page that tries to describe the Struts workflow in
generic form, and then reconstruct a generic configuration file to match the
description. This is a brainstorming document only.
-
-
-
- On startup, controller parses configuration and deploys the decorator
objects, including the handlers, as its ControllerConfig object.
-
- The configuration elements are decorators that are used to create and manage
other objects. At runtime, the target objects may be passed a reference to its
decorator. The object can then alter its behavior according to the properties
of its decorator. If the target object is a singleton, the decorator lets us
reuse the object without changing its member properties.
-
- A reference to the servlet's ControllerConfig is placed in application scope,
using upper-case versions of the servlet-name and config-name properties as the
attribute name {$SERVLET-NAME.$CONFIG-NAME}.
- If an attribute by this name already exists, a servlet exception must be
thrown.
- At runtime, container passes request to controller (servlet). Controller
passes both get and post requests to its processor object.
-
- Processor matches URI with handler's matchPath property. (This is the handler
decorator, not its target object.)
- If no path matches, processor checks for the default-handler before
surrendering request back to container.
- Processor checks for secure attribute and the security role and throws an
exception if user is not authorized to access this handler.
-
- Processor obtains a copy of the handler (decorator) and passes it the details
of this request event. A reference to the handler is placed in the request
(under the default token: HANDLER). If so configured by the controller, the
processor also obtains a reference to the standard locale object in the user's
session.
-
- If a handler already exists in the request, it is set to to the new handler's
previous property. The new object then replaces the old in the request.
-
- {A reference collection of the handlers (decorators) is deployed at
startup. The processor refers to this collection when creating a new copy of
the handler for a request. When a handler (later) refers to other handler, a
reference from the collection may be returned to avoid unnecessary object
creates. The handlers have a locked property which indicate whether they are
global singletons (locked) or local to this request (not locked).}
-
- By default, the controller will maintain a standard locale object in the
user's session (LOCALE).
- The processor may be configured to place additional helper beans in every
request. The helper beans must have a zero-arguments constructor and a handler
property.
-
- If the handler specifies an input decorator, the processor obtains the
input-object and, if appropriate, calls the input bean's reset, populate, and
validate methods, passing each method a reference to the handler for this
request.
- The handler encapsulates details such as a reference to the pending request
(which includes the handler instance.)
- To obtain the input-object, processor first checks to see if there is already
an object under the name and scope specified by the input decorator. Otherwise,
a new input-object is instantiated.
-
- If the input-object's locked property is true, processor will not call reset
or populate (but may still call validate).
- If the handler's validateInput property is false, validate on the input bean
is not called.
-
- The validate method can examine the input-object's properties (populated from
the request). If messages are generated, the method can pass a queue of errors
to the handler.
- If validate returns false, the processor uses the specified input-location to
complete this cycle. If the input-location is non-null, the processor uses its
path (or handler-name) to return a URI to the controller. If null is returned,
the response is considered complete.
-
- Processor obtains the handler-object and any helper bean. When a
handler-object is specified, the processor calls the object's dispatch method,
passing it the handler for this request. The dispatch method returns a location
or null.
- If the handler (decorator) specifies a forward-path property or redirect-path
property instead of a handler-object, a servlet-forward or servlet-redirect is
performed instead of calling the handler-object. One of these three must be
specified.
-
- When a non-null location is return, the processor uses its match-path to
return a URI to the controller. If null is
[Struts Wiki] Update of NewTilesTool by MichaelJouravlev
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/NewTilesTool
The comment on the change is:
Orphaned; just a big chunk of code.
--
- 16. October 2003
+ deleted
- A new version of the TilesTool that utilizes the { { { RequestDispatcher } }
} to correctly render alternative formats such as JSP. Thus it is now possible
to put e.g. JSP resources into Velocity tiles definitions.
-
- The changes are based on the URL importation logic found in { { { JSTL
ImportSupport-tag } } } by Shawn Bayern.
-
- Note: This version differs from the original in that each velocity tile in a
given layout has it's own velocity context - where in the previous version all
the velocity tiles in a given layout shared the same velocity context.
-
- Note: This version is contingent on the very latest build of { { {
VelocityViewServlet } } } for rendering JPSs ... older versions will throw { {
{ IllegalStateExceptions } } }.
-
- Any comments are welcome on the Velocity Developer's List
velocity-dev@jakarta.apache.org.
-
- Marinó A. Jónsson
-
-
- To expand a little more on what Marino said: Mixed tile definitions, based
on a velocity template are now possible.
- i.e
- {{{
- { { {
- {{{ definition name=Vtest
- path=/TableBased.vm !-- note a velocity layout file
is used --
- put name=header
-value=/header.jsp/
- put name=footer
-value=/footer.jsp/
- put name=body
-value=/center/listThemes.vm/
- put name=rail
-value=/rail.xtp/
- /definition
- } } }
- }}}
- Matthew Payne
-
- {{{
- { { {
- /*
- {{{ * The Apache Software License, Version 1.1
- *
- * Copyright (c) 2003 The Apache Software Foundation. All rights
- * reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in
- *the documentation and/or other materials provided with the
- *distribution.
- *
- * 3. The end-user documentation included with the redistribution, if
- *any, must include the following acknowlegement:
- * This product includes software developed by the
- *Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowlegement may appear in the software itself,
- *if and wherever such third-party acknowlegements normally appear.
- *
- * 4. The names The Jakarta Project, Velocity, and Apache Software
- *Foundation must not be used to endorse or promote products derived
- *from this software without prior written permission. For written
- *permission, please contact [EMAIL PROTECTED]
- *
- * 5. Products derived from this software may not be called Apache
- *nor may Apache appear in their names without prior written
- *permission of the Apache Group.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
- * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
- * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
- * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
- * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- *
- *
- * This software consists of voluntary contributions made by many
- * individuals on behalf of the Apache Software Foundation. For more
- * information on the Apache Software Foundation, please see
- * http://www.apache.org/.
- */ }}}
-
- package org.apache.velocity.tools.struts;
-
- import java.util.Stack;
- import java.util.Map;
- import java.util.Locale;
- import javax.servlet.http.HttpServletRequest;
- import javax.servlet.http.HttpServletResponse;
- import javax.servlet.http.HttpServletResponseWrapper;
- import javax.servlet.http.HttpSession;
- import
[Struts Wiki] Update of PythonLanguage by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/PythonLanguage The comment on the change is: Orphaned; offtopic. -- + deleted - ##language:en - Python is a dynamic object-oriented language. - Links: - * http://www.python.org/ - * [wiki:EfnetPythonWiki:FrontPage #python Wiki] - * http://python.faqts.com - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of ComposableRequestProcessor by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/ComposableRequestProcessor The comment on the change is: Moved one paragraph from the orphaned RequestProcessor/Composable page. -- Other notes on the ComposableRequestProcessor are welcomed! + + Ted Husted made a pretty good case for a composable chain of processors on the mailing list. For now, just a pointer: http://marc.theaimsgroup.com/?l=struts-devm=105472470724762w=2 + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
I think CoR is a great pattern, I've used it with great success, but I'm not as sure how it fits into Struts *outside* the composable RP, which is a *perfect* application for it. Just curious how you (and/or others) are already using it. This is my opinion too. I think the CoR is made for the Struts internal processing only but some people are testing it out, as Ted said and Martin admitted to, as an end point for action processing. From my perspective, it's clear what the intention of CoR is by its design and use, but since it was never explicitly spelled out how it is used in Struts, I have to defer to other opinions too. But unless I am wrong, I think it's strongly geared towards the RP and not actions. That's why I said, ActionContext should be InternalActionContext. If Struts 1.4+ is going to have actions without a subclass or interface, you want a method signature like: public void execute(ActionContext cxt); Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RequestProcessor/Composable by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/RequestProcessor/Composable The comment on the change is: Ophaned; relevant content moved to ComposableRequestProcessor. -- - Ted Husted made a pretty good case for a composable chain of processors on the mailing list. For now, just a pointer: http://marc.theaimsgroup.com/?l=struts-devm=105472470724762w=2 + deleted - This strategy has been adopted for Struts 1.3.x, and embodied in a class called ComposableRequestProcessor. Further discussion of that class and its responsibilities can be found in the Wiki at ComposableRequestProcessor. - - See also RequestProcessor/SingleInterface - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
On 2/16/06, Paul Benedict [EMAIL PROTECTED] wrote: I think CoR is a great pattern, I've used it with great success, but I'm not as sure how it fits into Struts *outside* the composable RP, which is a *perfect* application for it. Just curious how you (and/or others) are already using it. This is my opinion too. I think the CoR is made for the Struts internal processing only but some people are testing it out, as Ted said and Martin admitted to, as an end point for action processing. From my perspective, it's clear what the intention of CoR is by its design and use, but since it was never explicitly spelled out how it is used in Struts, I have to defer to other opinions too. But unless I am wrong, I think it's strongly geared towards the RP and not actions. In Struts 1.3, you can do: action path=/MyAction catalog=MyCatalog command=MyCommand/ or, if you use the default catalog, as I do for my mappings: action path=/MyAction command=MyCommand/ I'd say that's geared towards actions. -- Martin Cooper That's why I said, ActionContext should be InternalActionContext. If Struts 1.4+ is going to have actions without a subclass or interface, you want a method signature like: public void execute(ActionContext cxt); Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reasons for 1.3 release
Martin, you may have to reel back to my first email about this. The context exposes so much of the Struts internal data that it is obvious, to me, that it's not supposed to be an end point processing. What good is having the end point changing the action servlet? Probably no good which is why I am making the case there probably needs to be 2 action contexts. One for the RP, another for the end point. Right now ActionContext exposes too much, in my opinion, for a public API. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Laurie Harper wrote: Ted Husted wrote: On 2/16/06, Martin Cooper [EMAIL PROTECTED] wrote: If we think this is serious enough to warrant a 1.2.9 release, then it makes little sense to me to tag 1.3.0 without it. Otherwise, all we're saying is hurrah, we tagged the tree, but oh, you probably don't want to use this because there's a serious problem we know about that we didn't feel like taking the extra time to fix. All I'm saying is that I have no extra time. If someone else does, then please step up and lend a hand. That's part of my reason for +1'ing a 1.3.0 release, even if it's never promoted (as a whole) from test release; Ted's put a ton of work into getting to this point. If a 1.3.0 release happens now, it'll presumably take less time and effort to incrementally address remaining issues and release updates of just the action sub-project, compared to postponing the 1.3.0 release and having to repeat much of the testing and prep work that's just been done. Oops. Ted and others have put... Sorry, didn't mean to allocate the blame^H^H^H^H^H^H credit to just Ted. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of SecureStrutsLinkTool by MichaelJouravlev
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/SecureStrutsLinkTool
The comment on the change is:
Orphaned; just a big chunk of code.
--
- July 29, 2003
+ deleted
- SecureStrutsLinkTool is a substitute for StrutsLinkTool intended for those
who use the SSL Extensions with Struts 1.1. Simply switch class names in
toolbox.xml and you're set.
-
- [http://sslext.sourceforge.net More info on Struts SSL Extensions]
-
- Any comments are welcome on the Velocity Developer's List
velocity-dev@jakarta.apache.org.
-
- Marinó A. Jónsson
-
-
- {{{
- { { {
-
- package org.apache.velocity.tools.struts;
-
- import javax.servlet.*;
- import javax.servlet.http.*;
-
- import org.apache.velocity.app.Velocity;
- import org.apache.velocity.tools.view.tools.LinkTool;
- import org.apache.velocity.tools.struts.StrutsUtils;
-
- import org.apache.struts.config.ForwardConfig;
- import org.apache.struts.config.ModuleConfig;
- import org.apache.struts.action.SecurePlugIn;
- import org.apache.struts.config.SecureActionConfig;
- import org.apache.struts.Globals;
-
- /**
- {{{ * pTitle: SecureStrutsLinkTool/p
- * pDescription: Tool to be able to use Struts SSL Extensions with
Velocity/p
- * pIt has the same interface as StrutsLinkTool and can function as a
substitute if Struts 1.1 and SSL Ext are installed. /p
- * @author Marinó A. Jónsson
- * @version 1.0
- */ }}}
- public class SecureStrutsLinkTool
- {{{extends LinkTool {
-
- private static final String HTTP = http;
- private static final String HTTPS = https;
- private static final String STD_HTTP_PORT = 80;
- private static final String STD_HTTPS_PORT = 443;
-
- /**
- * pReturns a copy of the link with the given action name
- * converted into a server-relative URI reference. This method
- * does not check if the specified action really is defined.
- * This method will overwrite any previous URI reference settings
- * but will copy the query string./p
- *
- * @param action an action path as defined in struts-config.xml
- *
- * @return a new instance of StrutsLinkTool
- */
- public SecureStrutsLinkTool setAction(String action) {
- String link = StrutsUtils.getActionMappingURL(application, request,
action);
- return (SecureStrutsLinkTool) copyWith(this.computeURL(request,
application, link));
- }
-
- /**
- * pReturns a copy of the link with the given global forward name
- * converted into a server-relative URI reference. If the parameter
- * does not map to an existing global forward name, codenull/code
- * is returned. This method will overwrite any previous URI reference
- * settings but will copy the query string./p
- *
- * @param forward a global forward name as defined in struts-config.xml
- *
- * @return a new instance of StrutsLinkTool
- */
- public SecureStrutsLinkTool setForward(String forward) {
-
- ForwardConfig fc = StrutsUtils.getForwardConfig(forward, request,
application);
-
- if (fc == null) {
- Velocity.warn(In method setForward( + forward +
- ): Parameter does not map to a valid forward.);
- return null;
- }
-
- StringBuffer url = new StringBuffer();
- if (fc.getPath().startsWith(/)) {
- url.append(request.getContextPath());
- url.append(StrutsUtils.getForwardURL(request, fc));
- }
- else {
- url.append(fc.getPath());
- }
-
- return (SecureStrutsLinkTool) copyWith(this.computeURL(request,
application, url.toString()));
- }
-
- public static String computeURL(HttpServletRequest request,
ServletContext app, String link) {
-
- StringBuffer url = new StringBuffer(link);
-
- String contextPath = request.getContextPath();
-
- if (SecurePlugIn.getAppSslExtEnable(app)
- url.toString().startsWith(contextPath)) {
-
- // Initialize the scheme and ports we are using
- String usingScheme = request.getScheme();
- String usingPort = String.valueOf(request.getServerPort());
-
- // Get the servlet context relative link URL
- String linkString =
url.toString().substring(contextPath.length());
-
- // See if link references an action somewhere in our app
- SecureActionConfig secureConfig = getActionConfig(request, app,
linkString);
-
- // If link is an action, find the desired port and scheme
- if (secureConfig != null
-
