Re: STR-2864: actionId name checking
In ActionServlet, there's some code that runs after all the config has been read that does some checking of config values (mostly null checking). Maybe your checking is a better fit there. Hubert On 9/25/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I forgot to add the code that makes sure there are no slashes in the actionId name. First, should I only exclude slashes? Or should I only allow letters and numbers? Second, where should the checking go? I notice there is no pattern checking in any of the Config classes; so this will be blazing a new trail :-) ... I'd like to put the it in the setter of ActionConfig.setActionId and throw an IllegalArgumentException when violated. Thoughts? In the absence of any feedback, I will take this approach. Paul - 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: Private Actions Mappings?
I'm not sure it's a common enough need to justify being built into the core. For something like this, I'd be content with an app-specific extension and using to mark private actions. On 9/6/06, Paul Benedict <[EMAIL PROTECTED]> wrote: For a lack of a better subject line. Let me explain. I have some actions which are not supposed to be accessed by users. They are mostly for internal uses within the program. Specifically, I like to include many actions on a page and build a poor-man's portlet. So what I have, architecturally speaking, is one action whose view triggers a whole bunch of other actions. My thoughts lead me to this: while it is very low probability that these included action paths can be guessed at, I nevertheless do not enjoy it being above zero. I propose adding a new attribute which dictates when an action may be invoked. I do not have a favorite choice among my ideas, but here they are: 1) A public attribute; defaults to true. 2) A private attribute; defaults to false. 3) A dispatcher attribute; defaults to all; allows request|include|forward|error (like the filter dispatcher attribute of web.xml) For my needs, I want to be able to say which action mappings may not be directly accessed; they must be forwarded to or included by. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fixing Jira tickets
On 7/25/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: If you refer to the issue number in the commit message, it should show up on the 'Subversion Commits' tab on the issue after a little while. I don't think that's working right now, though. We probably need to open a ticket with infrastructure to get Jeff or someone to fix it. Thanks. Looks like it's working: https://issues.apache.org/struts/browse/STR-2917 Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fixing Jira tickets
The last time I fixed a bug, we were still using Bugzilla. Anything I need to know before marking a Jira ticket as fixed? For instance, how do they get linked to an svn commit? Is it in the commit message? Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2.0.0 - Tag it and Roll it?
On 7/24/06, Ted Husted <[EMAIL PROTECTED]> wrote: -1 on changing the versioning scheme. But, I would be open to something like * Struts 2.0 == "WebWork transtional release" * Struts 2.1 == "new API release" * Struts 3.x == "phase 2 - the best of breed release" ...with pointers on what to consider if users should upgrade or not, and a clear explanation of what to expect in the near future. This could address Tim's initial concern (which I think is valid): "Users who don't keep completely up to date with the latest goings on will see this as the latest and greatest and start migrating to it, only to have a very rude surprise when large changes occur in 2.1, or a 3.0 arrives months later." Those three lines above, listing 2.0, 2.1 and 3.x, could be communicated on the front page, on a simple table. This would be similar to how Tomcat explains why they have three versions. Very straightforward and easy to digest. Hubert IMHO, all the users, including ourselves, are served best when we release early and release often. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.3.5 Quality
I found these issues: 1.) ForwardConfig inheritance doesn't work when trying to inherit global forwards. There's code to handle it within the config objects, but they're not being triggered at app startup. 2.) Arbitrary properties don't get copied when creating ActionRedirect objects based on an existing ForwardConfig. Anyone have any objections if I reuse BaseConfig.inheritProperties() to fix this? Both issues affect features that weren't in the 1.2.x line, so people upgrading from a previous GA release won't be affected. I'll put in fixes within the week. Hubert On 7/23/06, Ted Husted <[EMAIL PROTECTED]> wrote: The Struts 1.3.5 Test Build is available to evaluate for release quality. The release plan is available on the wiki: * http://wiki.apache.org/struts/StrutsActionRelease135 The test build, including checksums and signatures, has been deployed to: * http://people.apache.org/builds/struts/1.3.5/ Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three +1s and more +1s than -1s. Please remember that a binding +1 for GA implies that you intend to support the release with patches and posts to the user list. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1 (and possibly Struts 2) terminology: what is Action/Command
I just call them action methods, no matter what form they take. They can be S1's Action.execute(), a method that EventActionDispatcher calls, a Command implementation, a POJO method, whatever. They're all in response to . Well, okay, so some of them are GET calls. But sticking to the term "action" or "action method" gives me consistency. Hubert On 7/18/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: On 7/18/06, Ted Husted <[EMAIL PROTECTED]> wrote: > On 7/18/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > >Does anyone have better term for Action/Command? > > In other places, I refer to such things casually as "handlers". People > have often used this word on the list to distinguish between the > action mapping and the Action class (handler). What if I use dispatch-type action/command? How do I call methods that correspond to events? Presently I call them "event handlers" or "handler methods". Another choice is to keep "handlers" for methods as in "event handlers", and to call Action/Command collectively as... command, like Martin Fowler does [1] or like MSDN defines Front Controller pattern [2]. [1] http://www.martinfowler.com/eaaCatalog/frontController.html [2] http://msdn.microsoft.com/practices/apptype/webapps/default.aspx?pull=/library/en-us/dnpatterns/html/DesFrontController.asp Michael. - 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]
Shale mailing lists [was: Shale Validation Framework Issue]
It's interesting that I learned about the new Shale lists over at the
MyFaces lists instead of here at the Struts lists.
Hubert
-- Forwarded message --
From: Matthias Wessendorf <[EMAIL PROTECTED]>
Date: Jul 7, 2006 1:32 PM
Subject: Re: Shale Validation Framework Issue.
To: MyFaces Discussion
Maybe this question is better addressed on the *new* shale user list
On 7/7/06, Alex Yakushev <[EMAIL PROTECTED]> wrote:
Hello everybody!
I am a new in Shale Validation Framework. Actually I got an error then form
submitted.
2006-07-07 13:52:21,401 [http-80-Processor23] WARN
org.apache.commons.validator
.ValidatorResources - Form 'org.apache.shale.validator.minFloatValue' not
found
for locale 'en_US'
2006-07-07 13:52:21,401 [http-80-Processor23] ERROR
StandardWrapper[/RPTCService
sManagement:Faces Servlet] - Servlet.service() for servlet Faces Servlet
threw e
xception
java.lang.NullPointerException
at
org.apache.shale.validator.CommonsValidator.getArgs(CommonsValidator.
java:621)
at
org.apache.shale.validator.CommonsValidator.getMethodParamNames(Commo
nsValidator.java:585)
at
org.apache.shale.validator.CommonsValidator.loadMethodParamValues(Com
monsValidator.java:715)
at
org.apache.shale.validator.CommonsValidator.validate(CommonsValidator
.java:798)
at
javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.
java:157)
at javax.faces.component.UIInput.validateValue(UIInput.java:312)
at javax.faces.component.UIInput.validate(UIInput.java:353)
at javax.faces.component.UIInput.processValidators(UIInput.java:183)
at
javax.faces.component.UIComponentBase.processValidators(UIComponentBa
se.java:624)
at
javax.faces.component.UIComponentBase.processValidators(UIComponentBa?
That is wrong with my code?
Seems, information from custom-rules.xml file loaded properly, but it is
looks like minFloatValue method can not findound.
INFO: Loading validation rules file from /WEB-INF/custom-rules.xml
2006-07-07 13:52:16,714 [http-80-Processor24] WARN
org.apache.myfaces.renderkit
.html.util.ReducedHTMLParser - Invalid tag found: unexpected input while
looking
1. /WEB-INF/web.xml
org.apache.shale.validator.VALIDATOR_RULES
/org/apache/shale/validator/validator-rules.xml,
/WEB-INF/custom-rules.xml
2. /WEB-INF/custom-rules.xml
http://jakarta.apache.org/commons/dtds/validator_1_2_0.dtd";>
3. /WEB-INF/faces-config.xml
mot.resource.shale_messages
en
en
4. ValidationUtil Class.
package test.jobmaintenance;
public class ValidationUtil
implements java.io.Serializable
{
public static boolean isMinFloatValue(Object value1)
{
System.out.println("++ RECEIVED VALUE1 "+value1);
return false;
}
}
5. JSP Page.
I will be appreciating for any feed back.
Alex.
--
View this message in context:
http://www.nabble.com/Shale-Validation-Framework-Issue.-tf1907955.html#a5222352
Sent from the MyFaces - Users forum at Nabble.com.
--
Matthias Wessendorf
futher stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
On 7/5/06, James Mitchell <[EMAIL PROTECTED]> wrote: Believe me, I'm not trying to discount the 1.x development. I have stated as much on several threads. Also, I have many 1.x apps to support, and I think my recent work on getting the 1.2.x and 1.3.x nightlies back online proves my commitment to both of those lines. I will be doing more as time allows. Oops, apologies. I'm aware of your stand on this and didn't intend to imply you meant otherwise. The last thing I want to do is discount anyone's contributions. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
That assumes all the development and support effort go towards one framework, Struts 2. If we're still actively supporting and developing the Struts 1.x line, then references to "Struts" should include a qualification of which Struts framework is meant. Hubert On 7/5/06, James Mitchell <[EMAIL PROTECTED]> wrote: IMHO "Struts" means the latest/current developmentin other words...SAF2, struts2, 2.x, I think we should just say "Struts", but clarify only if we mean an older version. I mean, we do that now with everything else. If someone has a question about Struts, and it happens to pertain to 1.0 or 1.1, they usually say so. Same goes for other libraries/frameworks. Just my $0.02 -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WW/SAF2 i18n & Cintoo Messages
Ahh, ok. Thanks for clarifying that. I was not able to follow that discussion to the end. (Looks like I'm not the only one.) Hubert On 6/30/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 6/30/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: > It looks like it requires Java 5. Has there been a decision to move > SAF2 to Java 5? * http://wiki.apache.org/struts/StrutsActionRelease200 "The platform for SAF 2.0.x is Java 1.5, with Java 1.4 compatibity provided by Retroweaver." -T. - 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: WW/SAF2 i18n & Cintoo Messages
Actually, I take that back -- the sample code on their page uses Java 5. I don't know if the library itself requires it. Hubert On 6/30/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: It looks like it requires Java 5. Has there been a decision to move SAF2 to Java 5? Hubert On 6/30/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > From memory (WW in Action) there seems to be similar concepts in > Cintoo messages that WW/SAF2 has - but I was hoping someone who knows > would comment. > > The license is Apache 2 and it looks good to me - is this something > that SAF2 would benefit from or is that area already well covered? > > http://messages.cintoo.org/ > http://www.infoq.com/news/Cintoo-Messages-1.0-i18n > http://www.theserverside.com/news/thread.tss?thread_id=41116 > > Niall > > - > 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: WW/SAF2 i18n & Cintoo Messages
It looks like it requires Java 5. Has there been a decision to move SAF2 to Java 5? Hubert On 6/30/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: From memory (WW in Action) there seems to be similar concepts in Cintoo messages that WW/SAF2 has - but I was hoping someone who knows would comment. The license is Apache 2 and it looks good to me - is this something that SAF2 would benefit from or is that area already well covered? http://messages.cintoo.org/ http://www.infoq.com/news/Cintoo-Messages-1.0-i18n http://www.theserverside.com/news/thread.tss?thread_id=41116 Niall - 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: Proposal for Struts 1.x: support for portlet-like components
I like the functionality that this provides. If I ever get to work on another Struts 1 project, I would certainly like to use this. That said, I'm -0 to integrating it, but I won't stand in the way if other committers accept it. I think though that it works well enough without being integrated into the core. With the Extras subproject, what we've done lately is extract things out instead of bundle them in the core. The same can apply to this feature. I think it'll make an excellent subproject that can be distributed along with the main download, like taglibs and tiles integration, and it'll still get the attention it deserves without negatively affecting its potential. Hubert On 6/26/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: I want to stress out that what I suggest is not a framework ;) I did try to make the standalone library independent of Struts for various reasons. Still, its concept is quite foriegn to a Struts user, in comparison to the principle of having code in Action and view in JSP. Integrating this idea fully into Struts changes very little in current Struts development cycle: there is Action that handles events, there is JSP that displays a view. That is it. No new concepts to users if they already know what a dispatch action is. Two or three tags that I implemented are totally optional. Therefore accepting the component model integrated into Struts core, and developing with it is much easier than using a standalone library. Comparing my enhancement to Tiles, I believe that Tiles is quite rich in functionality and has its own learning curve. On contrary, my enhancement fits current Struts coding and configuration conventions very neatly. Current and future users will not be affected, but for those who would like to have components out of the box, this functionality will be available. Why not? So, the reasons for including this enhancement into the core: * Struts can be called a component framework (or a hybrid action/component framework). * User's actions that manage components will be clean and tidy, no need to instantiate dispatchers or to manually handle component-related stuff, no plumbing code. On the other hand, I do not want to hamper 1.3.5 release plan, I don't want to fork off /struts/action/trunk/core as well. So having this enhancement as an extension project in /struts/action/trunk will work for me. This way I will be able to make isolated updates to the code without affecting 1.3.5 functionality (will I?). Maybe later we will return to this duscussion considering including the extension into 1.4 core :) Michael. On 6/26/06, Don Brown <[EMAIL PROTECTED]> wrote: > Ok, I see your points of leveraging known code and frameworks, but according to > your last article, what you developed isn't tied to Struts at all and can be > used with pure JSP. If that is the case, perhaps it would be better for this > component framework to have its own project and be treated similar to what we > are planning for Tiles. I'm fine with the event dispatching part of your > proposal, but I'm not convinced a new component framework should be added to > Struts Action 1 core. > > Don > > Michael Jouravlev wrote: > > Don, thanks for replying. See inline. > > > > On 6/25/06, Don Brown <[EMAIL PROTECTED]> wrote: > >> Interesting...I can see you have put a lot of time and thought into > >> this. My first pass seems to find this a cross between the portlet api > >> and JSF. What I saw missing from the articles and wiki pages is a > >> higher level justification: > >> - Why not just use portlets? > > > > Firstly, what I suggest IS portlets :) because the term "portlets" is > > not copyrighted. Ok, ok, I know you mean JSR-168 portlets. Still, I > > think it is not fair to consider only JSR-168 portlets to be real > > portlets. > > > > JSR-168 requires to set up portal engine and it imposes porltet API. > > Nothing like this is imposed on Struts components. Java code is > > basically the same, JSP code contains couple of enhanced tags. > > tag is optional. Other tags that I created are > > optional too. > > > > On Java side, the same Struts action can control both page component > > as well as a normal web resource (dispatch-style). So, with very > > little change for a user he gets a whole new functionality and revival > > for old codebase. > > > >> - Why not just use JSF? > > > > Because I use Struts, meaning Struts Action Framework 1. Why should I > > switch my framework just to get something that I can have without > > switching? I don't think that JSF/ICEFaces can do more than improved > > Struts. If I will be switching I'd choose GWT. Or maybe even Laszlo. > > Something really different. > > > >> - Why should Struts the project include another non-standard component > >> framework? > > > > What do you mean by component framework? The tags? They are optional. > > The code? It is the same. The Javascript? Yes, it does not use more > > well-known libraries like Dojo or DWR or P
Re: Proposal for Struts 1.x: support for portlet-like components
On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: Integrating html2 would be nice too. It uses Ajax as well, so the two engines can be combined into one. In relation to html2, I am curious about how important client-side validator is. I mean, comparing Ajax roundrip to amount of Javascript preloaded for client-side validation, does it really make sense? And if a form is filled out correctly, this validator code is not used at all. The thing about html2 is that it relies on Niall's validatorjs extension [1] which has not gone beyond being a JCV enhancement proposal [2]. I haven't followed the development of JCV closely but so far I haven't seen an indication that the enhancement will be implemented. The last time I asked, JCV needed more volunteers to make more things happen (like this enhancement). I almost volunteered, but my OSS time has shrunk to zero since that time. Them that do the work make the decisions as Ted always says, and this is a solid example of that. Anyway, html2 was an experiment on my part. I was curious about what we can have if we were given free reign over the Struts tags. The idea of a third-party Struts tag library had been floated around a couple of times on the list and this was my attempt at scratching that itch. One of the things we could do was support non-standard HTML tags which would help those developing applications that are IE-only (which would describe all the apps I've worked on in all the assignments I've had). So, being integrated into the existing Struts tags was never a goal. As for the Ajax-only validation support, I'm with Frank. If we can provide client-side support, let's do so. For those who aren't familiar with it, the html2 Ajax validation calls ActionForm.validate() if the form isn't using Validator. Hubert [1] http://niallp.pwp.blueyonder.co.uk/validatorjs.html [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=32343 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
On 6/22/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: P.S. I was at a Sun "java roadshow" this week - they were putting out the message that Shale is the next Struts I've seen this several times. People should clarify what they mean by this. Is it more like "The Queen is dead. Long live the Queen." or "Kobe is the next Michael / Wade is the next Kobe". HA! Who am I kidding? Of course they mean the former. If Shale becomes TLP or a MyFaces project, then it'll be the latter. Which, IIRC, is what Craig intends. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
On 6/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: This is going to be short, both because I'm on a deadline and because I think the important points have already been covered. I'm not in favor of distributing Shale as a library behind a Struts 2 that promotes the Action 2 controller. Shale's story from the beginning has been that it is based on JSF. Where is lives is less of a concern, but I'd be happy either as a TLP or as part of MyFaces. I'm very glad that Shale was accepted here and given time to grow and develop a community, but I think it's time to find a new home. I'd like to see Struts (the project) return to a focus on building a great Action framework, and let Shale continue to explore what can be done with JSF. -- Wendy Thanks, Wendy, for finding the words I needed to express my own view! Now I won't have to write them up. I'm +1 to Wendy's views above. All of them. (Yes, I'm on a deadline, too). Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Towards a stable 1.3 release
On 3/31/06, Ted Husted <[EMAIL PROTECTED]> wrote: > If Hubert did have time to drop the plug-in now, that would be a > reasonable first step. Then, we can integrate into a 1.4 DTD, if > that's what we want to do. We did the same sort of thing with opt-in > Cancel Handling. We "patched" 1.2 and then made the DTD change in 1.3. This is also what I had in mind. Integrating FormDef features into Struts would take more work and much more time. IMO, that change would be enough for a change in version number. While I've thought about what an integrated FormDef would look like, I still don't have the full concept figured out. > A big reason that we average 24 months between releases is because > people tend to say, "Let's add this one more thing. It won't take > long." And, then it always does take much longer that we imagine. And this is what I'd like to avoid. Hubert (It's a very busy Friday for me at work so I'm not able to chime in as much as I would like.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Towards a stable 1.3 release
While I would be very much willing to bring FormDef in, I wouldn't want to hold up a 1.3 GA release because of it. This would take at least a few more weeks. For one thing, FormDef doesn't have methods that work with ActionContext yet, and Commands as Actions is one of the biggest new features of 1.3. If we bring in FormDef as just another plugin, there's no reason we can't bring it in later as part of another GA 1.3 download. If we integrate FormDef into struts-config.xml, then that's a much bigger change that 1.3 shouldn't have to wait for. Hubert On 3/31/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > On 3/31/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > I don't even know that we need a 1.3.1 build yet. > > 1.3.1 has EventActionDispatcher while 1.3.0 doesn't. I don't know > about other features. This may cause misunderstanding during upgrade, > since 1.2.9 contains EventActionDispatcher as well so 1.3.0 would have > a "hole". Why don't you either add EventActionDispatcher into 1.3.0, > or skip 1.3.0 altogether and move on to 1.3.1. > > Also, please consider FormDef as part of core distro. It is pretty > slick and nicely written piece of code. It should not take a lot of > effort to rename packages and to include it into standard distro. > Reformatting the docs also should be simple, Hubert wrote very concise > docs. > > Having waiting this long, new Struts release should be significantly > different (as in: better) than previous ones, and not only internally. > 13 months *is* long. The fact that 1.3 is being released with about > the same interval as prior versions is the reason for talking about > stagnation (I don't want to start this flame war again, I just say > what I see from where I stand). Struts has been good to me and I found > ways to work around it shortcomings, but not everyone is that patient. > > My feeling is that aside of technology purists when people say "Struts > sucks" they often mean how Struts handles input data type > conversion/validation and how it preserves (or not) entered values > between requests. Considering that more and more Struts users discover > niceties of dynabeans, FormDef comes as missing element of the > picture. For some users it can be a bigger reason for upgrade to 1.3 > than internal changes in request processor. > > There is another related product, StrutsLive! . I think it is > Apache-licensed so you may want to take a look. It seems like a > comprehensive solution, but looks heavier than Hubert's and I am not > sure is it really better (and how much better) to warrant its > inclusion into Struts. I prefer to have things as simple as possible > ;) > > Michael. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SV: Struts 1.3 and Internationalization
On 3/30/06, Joe Germuska <[EMAIL PROTECTED]> wrote: > Martin makes a good point -- even my suggestion about how to populate > non-string properties of ActionForms doesn't address displaying them > -- the form tags don't know enough to apply any locale sensitive > formatting when refilling a field. This might be something which > could be worked out, but it makes this a bigger issue. > > I think it would be great to integrate FormDef into Struts. > > Can anyone explain how WebWork handles this? I've read about the > advanced conversion services, which look good, but I haven't quite > seen how it handles re-displaying values in the case of conversion > errors, and I've run out of time to trace through the code to figure > it out for myself at the moment. > > Joe FormDef can handle the formatting and parsing of these fields. It's not a replacement for ActionForms, it works using them, by taking care of their configuration, formatting (prepopulation), and parsing (upon form submission). In order to handle formatting and parsing, you need to tell FormDef what format (or converter) you want to use, and that means configuration. So if people were interested, there's two ways to look at this: add FormDef as a totally independent plugin with its own XML, like Validator and Tiles, or really integrate it, adding elements to struts-config. Like Joe, I'm also interested in how WebWork handles this, especially locale-specific field formats (number, dates, etc). I haven't reached that chapter in WWIA yet. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SV: Struts 1.3 and Internationalization
On 3/29/06, Joe Germuska <[EMAIL PROTECTED]> wrote: > I started to believe this, but now I disagree. > > It is only solvable with the current code if your application runs in > one Locale. Struts does not provide a way to register instantaneous > conversion parameters (like the current Locale) -- registering a > converter with ConvertUtils has application-wide (actually JVM-wide) > scope, and would not be correct in the case that the same application > was handling floats that would have different decimal separators (to > use Hermod's example). > > The active locale must be passed in to RequestUtils.populate(...), > and in this case, compatibility seems like a lame excuse. > > Here's where the action happens: > > entrance to RequestUtils.populate(...): > http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#341 > > The actual place where ActionForm properties are set: > http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#451 > > I see no reason why all this code couldn't be pushed to a method > which takes a locale as an argument, and this method amended to call > that one with the system default locale. I would agree if we weren't recommending that people use Strings in the ActionForm [1]. What I'm saying is that your form should have String values and RequestUtils.populate() will populate it whatever your user typed in, and then in your Action you can use BeanUtils or FormDef to properly parse that into your business object typed field. You can see this in action in the locale.war demo of FormDef [2]. > Joe Hubert [1] "... properties used with the html:text tag should still be String properties." http://struts.apache.org/struts-action/userGuide/building_controller.html#dyna_action_form_classes [2] http://www.rabago.net/struts/formdef/downloads.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.3 and Internationalization
This is a BeanUtils issue. It comes into play after you get your ActionForm inside your Action.execute(), and you call BeanUtils.copyProperties() to copy your form field's String value onto your business object's field. You can look at BeanUtils' converters and registering locale-aware ones. Of course, for me, I use FormDef to handle formatted inputs like these. This is a user-list topic and should probably move there. Hubert On 3/29/06, Hermod Opstvedt <[EMAIL PROTECTED]> wrote: > Hi > > Not quite - If you have an html:text field, and enter a number with a comma > as decimal separator, and then try to access it in your action from the form > it will be null. Just go ahead and try it. As far as I remember, the "wont > touch" reasoning had to do with some code deep down in Struts not being able > to access the locale from the request, and adding support would mean no > backward compatibility. Correct me if I am wrong. It is quite some time > since I ran into this (1.2.2 or something), and I solved it by hacking the > html:text tag and some other places I do not remember. > > Hermod > > > -Opprinnelig melding- > Fra: Don Brown [mailto:[EMAIL PROTECTED] > Sendt: 29. mars 2006 22:50 > Til: Struts Developers List > Emne: Re: Struts 1.3 and Internationalization > > Struts, from the beginning has taken internationalization very seriously. > You are probably referring to the validation > of numeric values. This was a longstanding struts issue that has been > resolved since Struts 1.2.7. There are new > validators that will serve your interests. > > Don > > Hermod Opstvedt wrote: > > Hi > > > > What's the status of the Struts 1.3 branch with respect to > > internationalization? In the 1.2 branch this was a "won't touch" issue. > What > > I am thinking about is amongst other things the ability to use comma as > > decimal separator. Or is still "English only, please". > > > > Also, and I know this is the wrong forum, does anybody know if validator > > know supports "ALL" the struts specified resource bundles (including > I18N). > > > > Hermod > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebWork renaming strategy *revised*
On 3/24/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > So, "Struts", "Struts Action 2", "ti" and "a" instead of "WebWork", > "WebWork", "webwork" and "ww". New name system is definetely an > improvent consistency-wise. :) "a:" was my suggestion. It'd only make sense paired with "Action 2" and "action2". If the package is called "ti", I'd suggest "ti:" as prefix. Then maybe "Struts Ti" instead of "Struts Action 2". Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebWork renaming strategy *revised*
On 3/24/06, Ted Husted <[EMAIL PROTECTED]> wrote: > I don't see the problem with Action2 either. Hopefully, we will > someday see an Action3 and Action4 too. > > But, regardless of what I think, I would suggest that we wait a few > days and give the other new committers a chance to chime in. Ian > indicated a preference for saf, and the other new committers might > have a preference too. +0. Or +1 if I had time to volunteer. I could live with action2 as well. Now that I'm seeing this renaming from this perspective though, I'm wishing some of it mentions WebWork. In fact I wish we could do something like org.apache.struts.webwork. I don't know how that would look like, though. - com.opensymphony.webwork package -> org.apache.struts.webwork - WebWork* classes -> WebWork* - WebWork in comments, documentation -> Struts WebWork - webwork. as the configuration properties prefix -> webwork. - ww: tag prefix -> ww: That's my 2c. Like tm jee (TJ?), I'd be okay with any naming strategy the community settles on. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebWork renaming strategy
On 3/24/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > On 3/24/06, Don Brown <[EMAIL PROTECTED]> wrote: > > I've renamed the WebWork packages, and both the code compiles and all > > tests pass correctly. However, as I start with the greater renaming > > task, I thought I'd propose a strategy and get some feedback on it: > > > > - WebWork* classes -> Action2* classes > > - WebWork in comments and documentation -> Struts Action 2 > > - webwork in comments, documentation, and as a properties prefix -> action2 > > - ww: tag prefix -> a2 > > > > What does everyone think? Did I miss anything? I know the '2' seems > > unnecessary, but it does match our package name > > (org.apache.struts.action2), which is necessary so that Action 2 and > > Action 1 apps can live side-by-side. > > ww: --> a2: looks kind of ugly. Struts is not Audi ;) I suggest using > something like "st:" or "st2:" for prefixes. Or even keep them as > "ww:", why not? "ww:" stands out pretty nice. Or in today's world of one letter prefixes, "a:". Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > compatibility is not that difficult to maintain in reality. > > for project developers there are just 3 simple rules to follow: > - no point release (1.3.1 to 1.3.2) should ever break a working, > outward facing API > - all minor versions (1.3.x to 1.4.x) should deprecate working, > outward facing APIs before removing (release foo in 1.3.x, deprecate > in 1.4.x, and remove no sooner than 1.5.x, if at all). > - all major versions (1.x.x to 2.x.x) are free to break or change > whatever they wish. > > assuming developers respect these well-established patterns, then > users worried about compatibility and dependencies and unwilling to > track all project changes, there are only three simple rules: > - point release versions that go GA are always safe to upgrade > - watch for deprecations when upgrading minor version numbers > - expect things to break with a major version upgrade One of the problems is when a point release change in one package relies on a specific point release change in another package. If struts-action-1.3.2 adds some new functionality, and struts-taglib-1.3.1 uses this new functionality, a user who is using struts-action-1.3.1 can't just plug in struts-taglib-1.3.1 without upgrading the action jar as well. Throw in several jars each with several versions each, and a user wanting to upgrade just enough to get one specific feature, but not to all the newest jars, and you can understand where the confusion can come from. Hubert Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Clay build failure
On 2/28/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 2/28/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > > > I'm having trouble compiling Shale Clay. > > > I am seeing the same thing, but only with *very* recent bits. A build with > sources from early this afternoon seems to compile fine. Maybe there was > something strange in Hubert's integration this afternoon? Will investigate > further. > > Craig > > Here's one of the errors: > > > > compile: > > [javac] Compiling 83 source files to > > E:\svn\shale-snapshot\clay-plugin\target\classes > > [javac] > > > > E:\svn\shale-snapshot\clay-plugin\src\java\org\apache\shale\clay\component\LoadBundle.java:97: > > incompatible types > > [javac] found : java.lang.Object > > [javac] required: java.lang.String > > [javac] String resolvedBasename = tagUtils.eval(basename); > > [javac]^ > > > > I see a similar problem in ClayAmalgam, also. > > > > Thanks, > > Wendy Yeah, this would be my fault. I was only compiling core-library. I'll get this fixed. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Action Friends 1.3.0 MVC
+1! Hubert (Better late than ...) On 2/24/06, Ted Husted <[EMAIL PROTECTED]> wrote: > I'd like to nominate Wendy Smoak as the Most Valuable Committer in > making the release of the new 1.3.0 builds possible. > > Along with James Mitchell, Wendy did the thankless scutwork of taking > the Maven builds from prototype to production. Without her tireless > efforts, we'd still be kilometers away from the 1.3.0 milestones. A > lot of us worked on code, and a lot of us worked on documentation, but > without infrastructure, nothing else matters. > > Here's my +1. > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Commons Validation support
I suppose I should clarify that I tried this out last night and it
worked for me.
To make it work, I had to cheat with the ValidatorTag subclass and
move the call to createValidator() from the doStartTag() to the
doEndTag(), by overriding doStartTag() to do nothing, and calling
super.doStartTag() in the doEndTag() method.
I used the usecases sample app's validator test page to try it, and
used the updated date validator that came with JCV 1.2.0. I was able
to use an updated date validator with "datePattern" (non-strict)
support.
Hubert
On 2/23/06, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> A teammate of mine was looking at Shale's support for Commons
> Validator, and I noticed that the validation parameters are specified
> as tag attributes:
>
> type="floatRange"
> min="10"
> max="1000"
> arg="#{messages['prompt.amount']}"
> server="true"
> client="true"/>
>
> This would, of course, limit the possible params that can be
> specified. Can we change it to something like this instead?
>
> type="floatRange"
> arg="#{messages['prompt.amount']}"
> server="true"
> client="true">
>
>
>
>
> Hubert
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[shale] Commons Validation support
A teammate of mine was looking at Shale's support for Commons Validator, and I noticed that the validation parameters are specified as tag attributes: This would, of course, limit the possible params that can be specified. Can we change it to something like this instead? Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept WebWork 2 Merger Incubator Proposal
On 1/24/06, Don Brown <[EMAIL PROTECTED]> wrote: > http://wiki.apache.org/struts/WebWork2Incubator > > = PROJECT PROPOSAL = > > WebWork 2: A Java web application development framework +1 Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Extends with validate or unknown
(Apologies for the late reply; I've been offline.)
On 1/3/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> Given
>
> name="RegisterForm"
> validate="false"
> ...
> />
>
> extends="/Register"
> validate="true"
> .../>
>
> The value of validate remains false.
>
> We probably have the same problem with "unknown", which is tjhe other boolean.
>
> Evidentally, the test wants to be sure that extends does not step on
> any values already set.
Correct.
> Except for the two booleans, we otherwise test
> for null, and this strategy seems sound, since we don't have a
> mechanism for setting a null from a configuration file.
>
We also have boolean props in other config classes.
The problem is not only with booleans, but with ints as well (like
FormPropertyConfig's "size"). If there are String props which need to
distinguish between null and an empty String, the problem is there as
well.
Right now, this is a limitation of the "extends" functionality.
("Can't reset a field to a default value once a base config sets it")
> I've only started to think about this, but wanted to fire something
> off in case someone saw an obvious solution.
If we solve this for booleans and ints, shouldn't String fields be
allowed to go back to default values as well?
> -Ted.
>
Hubert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Dialogs and Convention over Configuration
On 12/21/05, David Geary <[EMAIL PROTECTED]> wrote: > So, this guy's comments finally got me thinking: do we really need an XML > config file for Shale Web Flow? If we could do away with that artifact, we > could make web flow even easier to use and differentiate ourselves further > from Spring Web Flow. > > Off the top of my head, I don't see why we couldn't define dialog structure > with filesystem conventions and flow with custom tags in JSP pages. For > example, by default, a root dialog directory named WEB-INF/dialogs (users > could override with a context init param) could hold subdirectories that > represent individual dialogs. Each JSP page would represent a view. Each JSP > page could have a single custom tag that specifies the transitions out of > the page (similar in spirit to moving metadata from XML files to annotations > in Java code). > > For those that prefer explicit configuration, we can still provide the XML > option, but it would be nice to give users the choice. > > Thoughts? > > > david > Convention over Configuration need not be limited to Dialog and Flow. I think there are opportunities for C/C in faces-config.xml as well, and wouldn't mind helping out there. I was going to work on a plugin that did C/C for struts-config, but now I don't know if there'd still be any interest in that. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] jsf-commons??
On 12/12/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > The shared code in tomahawk is primarily for building components > better and easier. It certainly makes the most sense to keep this > code with Tomahawk since it's an integral part of all tomahawk > components. Some of the code that's an integral part of Struts are in commons, such as BeanUtils and Chain. If the shared code is not tomahawk/myfaces specific, then this sounds like more reason to put this in a "commons"-type package. It sounds like anyone out there building in-house components might be able to use the package. It might benefit as well from the additional exposure. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FAQs
+1 Hubert On 12/3/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > Having recently discovered the Maven FAQ plugin, I'm thinking that we might > want to use that for the Struts FAQs, rather than maintaining them by hand. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Milestones proposal: Step 1 (revised)
On 12/1/05, Don Brown <[EMAIL PROTECTED]> wrote: > If we add the "TBD" milestone, I encourage everyone to only add tickets to it > if > it is a clear, reachable goal that we want to achieve. While I'm afraid it > will > attract stagnant tickets no one cares about, I understand some folks find it > useful, and I'm usually wrong anyways :) Maybe we can agree that if a ticket has had no progress for 12 or 18 or 24 mos, it should be reviewed and possibly marked WONTFIX / INVALID. > Next, I see the following steps: > > Step 2: > - Move closed tickets included in soon-to-be-released projects to their > milestone. > - Wade through TBD tickets and assign to milestones > > While I like Martin's idea of only putting tickets to milestones when someone > commits to resolving them I thought this was your idea? (#3 on your initial proposal) http://www.nabble.com/-PROPOSAL-Target-tickets-to-milestones-and-use-as-roadmap-p1711361.html > Perhaps we could start > using the "Assigned" field more often to mark which ones have been taken up > and > which are just hanging. ...or the combination of "Assigned" and a milestone means that committer plans to resolve the ticket for the specified milestone. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
On 11/30/05, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> Maybe jira has something smarter, but I found a maven feature recently
> working on Commons Resources - you can specify an "issue" number in
> the change log and attribute credit ("due-to") and as long as you have
> the issue tracking *format* configured in your project.properties it
> will automatically generate a link and "thanks to" text.
>
> This is what it looks like:
> http://tinyurl.com/9qjq5
>
> This is what it generates:
> http://jakarta.apache.org/commons/resources/changes-report.html
>
> Niall
Oh that's right. I remember seeing you use those in the commit
messages, but I didn't follow through to figure out where they ended
up.
On 11/30/05, Don Brown <[EMAIL PROTECTED]> wrote:
> Yeah, I've been using that changes thing with stxx for years now. I believe
> it
> started with Forrest. Anyways, sure, that would work too, although I'd prefer
> even the xml to be automatically generated. What if we went back to having a
> commit message template that could be parsed for info like this?
I wouldn't mind that. "went back" - I didn't know there was one before.
Hubert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Ted proposed before that we collect them into a "wish list" type of page on the wiki. I don't know if it still makes sense now if we'll be adopting WW anyway. If it does, though, we could start with http://issues.apache.org/bugzilla/show_bug.cgi?id=5739, maybe devote one section (or page) to it, to keep track of specific instances that need attention, and get them checked off one by one. Hubert On 11/30/05, Don Brown <[EMAIL PROTECTED]> wrote: > Personally, I agree, although I know there are those that see them still as a > valuable source of ideas. By emphasizing Milestones, though, they will fade > into the background. > > I'd be in favor of a "Probably Never" resolution though :) > > Don > > > Niall Pemberton wrote: > > On 11/30/05, Don Brown <[EMAIL PROTECTED]> wrote: > > > >>JIRA is already on Apache servers. > >> > >>But back to the topic, what do folks think of the proposal to target > >>tickets to > >>milestones and use them for release planning? I think we should start > >>immediately by creating upcoming milestones, and going through all our old > >>tickets and assigning them to the new milestones. This would go a long way > >>to > >>folks wondering what exactly was in 1.3.0. > > > > > > +1, but what we could probably do with is closing down tickets that > > have been open too long and are never going to be realistically done - > > can we have a "Probably Never" target? > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
On 11/30/05, Don Brown <[EMAIL PROTECTED]> wrote: > > And a big thank you for the +1's :) Any more? > > Don > +1. Any chance we can come up with a way to automatically collect the information that we've started to put in the release notes as well? The table consisting of SVN revision # and bugzilla (jira?) ticket number, shown here http://struts.apache.org/struts-action/userGuide/release-notes-1.2.8.html . I'm not familiar with Jira to know if they have a field for a VCS revision #, but in any case maybe your screen scraper can collect this info somehow. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r332894 - in /struts: build/trunk/project.xml core/trunk/src/java/org/apache/struts/action/DynaActionFormClass.java core/trunk/xdocs/userGuide/building_controller.xml
On 11/13/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Well I initially proposed it back in September and took the lack of > objections to imply agreement... At that point, it was an enhancement request from a user. It got one response from a committer which suggested an alternative approach. > > Given the size of the new dependency, can this be made configurable so > > that only the users who want to use this feature be required to add > > the 276k jar? After all, the original reason for the enhancement was > > to support "reusable components that must access form beans". IMO, > > this would really limit the audience that this feature targets. > > Well, that's the use case that prompted me but I think it simplifies the > use of dyna beans in any circumstance where you want to reference its > properties in a JSP. > > I could rework things to check for CGLIB in the classpath and revert to > the traditional behaviour if it's unavailable, though the documentation > would then need caveats about downloading/installing CGLIB to get the > functionality. > > L. Several items are "optional" even now. commons-validator, jakarta-oro, commons-fileupload, antlr. In each case, you'd have to use specific features before they become required. This change requires the new jar even if an app decides not to use the new feature. I guess I'm just not convinced that the new dependency is worth it, especially to something as basic as using DynaActionForm. This is why I'd +1 Joe's and Niall's suggestions. In either case, I'm hoping I can avoid having to include this in my app if I don't need the feature it provides. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r332894 - in /struts: build/trunk/project.xml core/trunk/src/java/org/apache/struts/action/DynaActionFormClass.java core/trunk/xdocs/userGuide/building_controller.xml
> New Revision: 332894 > > > + cglib > + cglib-nodep > + 2.1_3 > + http://cglib.sourceforge.net/ > + > +true > + > + I apologize as well for only commenting now. I didn't realize an agreement had already been made to add a new dependency to support this feature. Given the size of the new dependency, can this be made configurable so that only the users who want to use this feature be required to add the 276k jar? After all, the original reason for the enhancement was to support "reusable components that must access form beans". IMO, this would really limit the audience that this feature targets. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reset in BeanValidatorForm?
My question is more "Does it make sense?". My understanding is that BeanValidatorForm is intended to wrap POJO beans: The reset() implementation for DynaActionForm works by reading the FormPropertyConfig for the bean. In the case above, it doesn't look like we'll have any to read. Are users allowed to configure fields through anyway? Hubert On 11/12/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Hubert Rabago wrote: > > I just checked in reset support for DynaActionForm as discussed in an > > earlier thread. [1] > > > > Do we need reset in BeanValidatorForm as well? > > > > Hubert > > > > [1] http://marc.theaimsgroup.com/?t=11291425412&r=1&w=2 > > It strikes me that it would make sense for all form beans supplied with > Struts to respect the new flag for consistency, so I'd say add it to > BeanValidatorForm as well. > > L. > > > - > 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]
reset in BeanValidatorForm?
I just checked in reset support for DynaActionForm as discussed in an earlier thread. [1] Do we need reset in BeanValidatorForm as well? Hubert [1] http://marc.theaimsgroup.com/?t=11291425412&r=1&w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Action Framework ?
On 11/12/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > Thoughts on calling the core of the original framework "Action"? Last call! > > -Ted. +1. I like it much better than classic. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating AJAX into Struts
On 11/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > You are right, multiwindow thing breaks this idea. Maybe I could > introduce a flag "this formbean was submitted to" and remove only > submitted beans. Or flag "this form bean was processed"... Got a > better idea by any chance? Sorry, I don't. I gave up on that a long time ago. I just tried to reduce my use of session variables. :) Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating AJAX into Struts
On 11/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > I don't agree with you. I don't mind agreeing to disagree. :) > Eclipse is an empty hangar, which can be > filled up with tools, benches and other machinery. You use each > machine as it is supposed to be used, and you use the hangar just to > transport parts from one machine to another, or to provide some basic > stuff like electricity, ventilation, etc. Actually, Eclipse already comes with plenty. The plugins make a difference, of course. If I had to use Eclipse, I would at least use it with plugins. Some people have to use Struts. Plugins might make their experience more pleasant, so why not use them? > Struts is not a container, it is a framework. It not only provides > features, it imposes a certain way of using them. For example, Struts > Dialogs is an add-on library, but it uses Struts in a way kinda > opposite to "official" rules. A framework can't anticipate every need users will have. If someone needed functionality that Struts Dialogs provided, why not use it? > It is hard for people to use a library > if it is not endorsed by Struts dev team, and even behaves in a > different manner? Even harder for them to make a mind shift. This is what I'm talking about. It's a matter of, uhm, "marketing". With Eclipse, they made it so using plugins is not only accepted, but expected. Why should it be different with Struts? > Speaking > about me, I want not just to provide an add-on library for Struts, but > to change the way Struts applications are written. Yep, I am that > arrogant :-) I cannot do this simply providing an add-on. Sure you can. The add-on I'm playing with right now would allows me to have a POJO action by replacing two Commands on chain-config.xml and adding a third one to put the ActionContext in a ThreadLocal variable. Then a fourth one to populate said Action (POJO or not) with values from the form bean to make it look like WebWork. That's an 18 kb jar file, but a big change in how you can write your Struts action classes. > The problem > here, that I need to convince core devs themselves that my approach is > better ;-) An add on that's independent of the main distro but is used by a lot of people can be pretty convincing. :) > Same with other core technologies like flow. HTML2 is on a fence, > maybe better suited for an add-on. FormDef somewhat changes the usage > of forms too, so it has to be officially endorsed for users to ebrace > it. At least as an optional way, if not the "one and only" proper way. Well, I don't know if any other committer has ever used FormDef. Some of them haven't even heard of it before. It hasn't stopped people from using it, though. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating AJAX into Struts
On 11/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> > > I added a "scenario" attribute to element, and on each
> > > request I am going to check session and to clean all form beans that
> > > do not correspond to action's scenario ("scenario" attribute can
> > > enlist several scenarios that action participates in). It would be
> > > simpler to define scenario for themselves, but I think it
> > > is easier for developer to think in terms of grouped actions, not
> > > grouped forms.
> >
> > What happens if the user uses multiple windows?
>
> Nothing different from having multiple windows of a regular action
> with session-scoped form. As long as action was called, form is used,
> so no reason to dispose it. Or am I missing something?
>
> Michael.
Say I have Window A doing Scenario A. From there I open up another
window and for whatever reason end up exploring Scenario B. If I
submit either window, the one I didn't submit gets its session object
hosed.
Hubert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating AJAX into Struts
Oops, I was actually replying to this part: > I wish I could > remember what it was, but I don't. On 11/11/05, Hubert Rabago <[EMAIL PROTECTED]> wrote: > On 11/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Hell, it's quite possible I simply didn't think it through enough to > > realize the simple solution :) > > I remember. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating AJAX into Struts
On 11/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Hell, it's quite possible I simply didn't think it through enough to > realize the simple solution :) I remember. You had something you wanted to modify in BaseHandlerTag. Niall's validatorjs extension modifies a base class, too: BaseFieldTag. html2 modifies both - BaseFieldTag and BaseHandlerTag. :) Well, it's still a fork, so that might really bother you. Me, I just wanted to see what it would look like, how much code the fork contained, etc. Turned out to be much less than I anticipated. Of course, html2 doesn't really do much. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating AJAX into Struts
On 11/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> Please keep this in mind
> if you will work on action/form combo :)
Why not make sure by taking a look at what I'm doing and maybe working
on it, too?
Oh, waitasec, I've no plans yet of nominating what I'm doing into the
core, so if that's a requirement for you, well, I understand.
> I added a "scenario" attribute to element, and on each
> request I am going to check session and to clean all form beans that
> do not correspond to action's scenario ("scenario" attribute can
> enlist several scenarios that action participates in). It would be
> simpler to define scenario for themselves, but I think it
> is easier for developer to think in terms of grouped actions, not
> grouped forms.
What happens if the user uses multiple windows?
Hubert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating AJAX into Struts
On 11/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > Oops, am I blind or what? Hubert, this is awesome! Thank a > bunch, I would like to, er..., purloin this stuff for my use :-) Sure, have fun! Be aware though that there's a lot of, uhm, "opportunities for improvement" here. I've already thought of a few the past week. (There's some that are shouting very loudly in my mind right now.) > In your samples actionFormDemo.do does ajax only, while > validatorDemo.do and customHandlingDemo.do perform client javascript > and then submit the form (non-ajax). I believe that both approaches > can be combined easily, so after client verified some basic rules, the > form would be sent to server in separate request and if something is > wrong, the errors will be displayed with ajax, right? Yup. > Stuff like this should be included in the Core ;-) Uhm, well no. Read the disclaimers. :) I keep hoping that I can find a way for people to get more comfortable about using extras that don't come with the Struts download. Sure there are some lost causes out there, such as those whose bosses don't even want them to use the EL tags because they're not part of "The Distribution". However, one of the big plusses of Struts is the amount of third party libraries that support it. I mean, c'mon, people say great things about Eclipse, saying its plugins make it very powerful. And JSF gets praise for being highly extensible. So how come we don't take advantage of the Struts plugins and extensions? Whoo. Sorry. I think that got built up for some time now. Anyway, like I said when I first announced this thing. I wouldn't mind continuing to work on this add-on if people wanted. Of course, now my time is going to this other thing we talked about a few weeks before: http://marc.theaimsgroup.com/?l=struts-dev&m=112930650012896&w=2 (It's funny. At that time I said "yeah, but I'm working on this Struts+AJAX thing right now".) Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating AJAX into Struts
On 11/10/05, Stephan Heilner <[EMAIL PROTECTED]> wrote: > The benefit of validating forms this way, is that you won't have to > actually post the form to validate it. You can have real-time > validation (done with java) and not have to reload the page. I also played around with this idea, just as an experiment. I put the results of my experiment at http://www.rabago.net/struts/html2/ html2 tags will use Validator javascript support on the client if the form has it, or will call the ActionForm's validate() through a nAJAX call if it doesn't. Either way, you'd get your validation done without submitting the whole form. (Uhm, nAJAX cause it's not an async call.) On 11/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Unfortunately, the idea was not especially well-recieved when I offered > to continue the work and make it a real, official part of the Struts > taglibs I was (still am) among those who think that we don't need it to be made part of the struts download to be useful. You could use html2 just by including its jar and changing the TLD URI you specify in your JSP: http://www.rabago.net/struts/html2/#tlds Then again, html2 may not be the best example for this, since I wasn't really attempting to reach the widest audience and get mass acceptance, so I guess I don't blame you if you're not convinced. :) Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Core Library versioning
"Struts Classic" keeps making me think "That's not the version I want -- I want Struts Modern". On 11/3/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > VW was making Bug/Beetle for 50 years or so, it acquired Classic > status sometimes in 60-ies, before Golf/Rabbit was introduced ;-) Well, no one's calling today's VW Bug "Beetle Classic" (although I liked the year 2000 model nickname "Y2KBug"). "Beetle Classic" makes me think "Herbie". Same thing happens when I hear/read "Struts Classic". It makes me think "Struts 1.0". > P.S. I'd rather see some progress in cloth washer design, seems that > it froze in 50-ies. And from what you said earlier, it's what they now call "classic". Again supporting my opinion. Calling 1.3 Struts Classic means "it's the same old Struts", with the emphasis on "same old", implying that there's something else, another version out there that isn't "old" and "classic". Well, what we have now is "Struts Modern", with the new flexible CoR request processor, where you can use Commands instead of Actions. Really doesn't deserve to be called "Classic" IMO. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Core Library versioning
On 11/3/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > This way it's always clear which distro a none-core subproject release > > works with. > > (i.e. you can't be sure about using taglib-1.3.1.2 with core-1.3.0, > > but you're sure that taglib-1.3.0.4 will work) > > I like this. 1.3.1 does not necessarily mean that it has improvements > over 1.3.0.15. It just means, that it was retested with 1.3.1 core. Yup. And it gives us something to base another distro on. > But Hubert, seems that your naming convention about Core being _part_ > of distro will not fly. Well, the distro is for those who like one download that does what the 1.2.x downloads do. That'd be core + taglib + tiles + apps etc. It'll be like the Ant download. > P.S. I see nothing wrong with Classic. It calls things what they really are. To me it's a matter of perception. Struts Classic makes me think "the version you can still use if you don't want the newer version with the newer architecture". Kinda like tomcat 5 vs. tomcat 5.5. We don't have a Struts.Next yet. Once we do, then let's call the current codebase "Classic". Otherwise it's just misleading. IMO. > Michael. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Core Library versioning
What about this. Struts 1.3.0 Distro - struts-core-1.3.0 - struts-taglib-1.3.0 - struts-tiles-1.3.0 - struts-el-1.3.0 - struts-apps-1.3.0 - struts-site-1.3.0 - struts-extras-1.3.0 Subprojects can have their own independent release numbers all being 1.3.0.x, with the "1.3.0" dictated by struts-core. Once we release struts-core-1.3.1, the other subprojects jump to 1.3.1. This way it's always clear which distro a none-core subproject release works with. (i.e. you can't be sure about using taglib-1.3.1.2 with core-1.3.0, but you're sure that taglib-1.3.0.4 will work) Subprojects that get added to the main distro assume the same versioning rules. Come to think of it, we could start BSF and scripting as 1.2.7.0 if they depend on 1.2.7. This way they'd start off with the same rules already, and everyone'll know you can use them with 1.2.7. In any case, I'm glad we're getting rid of "Classic". Hubert On 11/3/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > On 11/2/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > > I started to do that, but the idea was to also include the new > > subprojects, like Scripting and Flow and Faces, which would start at a > > 1.0.0 release. It seemed consistant to start with 1.0.0. > > I missed the decision to include BSF, Flow and Faces. I don't think > they belong in this distribution-- they have declared dependencies on > Struts 1.2.7 and prior. > > But I still think I'm working on Struts 1.3, so see below. :) > > > And, it's *VERY* important that people realize that Struts Core > > LIbrary is *not* a product, it's a distribution of products, like a > > Linux distribution. That was already becoming a problem with the > > Struts Classic moniker. > > After five years, the concept of Struts as a product is not going to > go away so easily. > > Whether we call it 'Classic' or 'Core Library' or something else, I > really think it needs to have 1.3 in the name and contain the 1.3.x > versions of the sub-projects that make up what people think of as > "Struts" (plus any new additions that come along.) > > What about versioning as 1.3_01 and just sequentially number them as > 'builds' of Struts Core Library 1.3? As Craig mentioned, we're > stating that this particular combination of sub-project versions is > known to work together. > > -- > Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: View helpers a.k.a. "inverted" views
On 10/14/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > > > Or the other way around. Request or session-scoped actions that have > > instance variables that get populated from the incoming action. I've > > done the request/session-scoped action before, and with BeanUtils or > > FormDef, populating the instance fields is easy. Combine this with > > DispatchAction or ActionDispatcher and you've gone back to The Object > > which combine data and methods. > > > > Hubert > > I am all in either for one or another. I am thinking of doing it > myself. Hubert, maybe you could share some code of yours ;-) if you > already went down this path. Well, if you check out the msg I sent to the Struts + AJAX thread over at user@, you'll see where my time is going right now. However, I meant to write a demo app illustrating this very concept for some time now, and now that someone has expressed interest, I think I'll go ahead with it. > But I don't want things *replacing* things. The point of maintaining > Struts Classic is to keep compatibility, while enhancing it. I hope, > that this new context object or whatever you call it, will not > deprecate what we have now, because a lot of people depend on it. > > Michael. > The data+behavior action I've used did replace the CreateAction part of the chain (and led me to http://svn.apache.org/viewcvs?rev=209987&view=rev), but that was about it. I specified the scope using the that Joe introduced. The updated validator behavior I'm playing with uses a forked set of taglibs. I haven't modified much, so I may get away with overriding certain tags instead, but for my POC I just went ahead and copied everything right away. The itch needed scratching ASAP. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: View helpers a.k.a. "inverted" views
On 10/14/05, Ted Husted <[EMAIL PROTECTED]> wrote: > On 10/13/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > Instead, Action and ActionForm should be combined into one object, which > > can be: > > * stateful, if needed > > * can be accessed from JSP > > * can be automatically populated > > * contaned lifecycle methods (via interface, like in Shale) > > * can respond to input events (like DispatchAction) > > The question is getting there from here -- without leaving anyone > behind. One reason we're changing the request processor is give people > more flexibility in deciding how things work. As it stands, these sort > of changes are slated for the Struts 1.5.x series. > > * http://struts.apache.org/milestones.html > > A simple way to accomplish some of this is to put an execute method on > an ActionForm and then have the Action delegate to the ActionForm. > > -Ted. Or the other way around. Request or session-scoped actions that have instance variables that get populated from the incoming action. I've done the request/session-scoped action before, and with BeanUtils or FormDef, populating the instance fields is easy. Combine this with DispatchAction or ActionDispatcher and you've gone back to The Object which combine data and methods. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reset for DynaActionForm
Apologies, I'm on my way out. I only wanted to respond to a couple of items, below: On 10/12/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > No, what I'm saying is Struts doesn't distinguish between the two > > (AFAIK). However, you seem to. > > I do, but Struts don't. You have said before, that reset() is called > only when form is submitted. So I asked you, how Struts knows that a > form was submitted? Via the action mapping. "/edit" doesn't call reset(), "/save" does. > reset() is always called when request is serviced by an action. Actually, reset() is called only when the mapping specifies a form. Which should mean that the form should be populated with values coming from request parameters. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reset for DynaActionForm
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 12, 2005 5:44 PM
> To: Struts Developers List
> Subject: Re: Reset for DynaActionForm
>
> Right now, a lot of Java web applications flit from action to action.
> We migth use one action to display the page the first time,
> and then submit to another action after the form is filled
> out, and so forth.
In Struts, this is because if an action mapping requires a form, the
values have to be there when that mapping is called. Again, from my
example:
When the form is first shown ("/edit"), Struts doesn't call reset().
> But, another popular paradigm, going back to the Perl days,
> is to keep submitting back to the same URI. The first time
> the page is retrieved, it is by GET. After that, it is
> submitted back by POST (aka PostBack).
In our case, we can do this with maybe a DispatchAction. Still, it'd
trigger a call to populate the form, which again makes a call to
reset() (to clear those checkboxes) necessary.
> Apparently, Michael wants to do something simliar with Struts
> Dialogs, which seems reasonable to me, if there's a
> reasonable way to do it.
Yeah, I've thought that the reason I'm not understanding Michael is
because the use case is specific for Struts Dialogs. It doesn't seem
to make sense with the usual "show the prepopulated form" + "submit
the user modified form" that I'm used to.
> -Ted.
Hubert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reset for DynaActionForm
I'm still trying to understand why the distinction is important. :) Someone help me! Hubert On 10/12/05, Ted Husted <[EMAIL PROTECTED]> wrote: > We'd pretty much have to go with (2), I think. > > The reset flag seems all right, especially if you can distingish > between GET and POST, as Micheal was asking. This would jive well with > the new form feature that makes it easy to submit back (or post back) > to the same action. > > I would not consider the DTD locked at this point. > > -Ted. > > On 10/12/05, Hubert Rabago <[EMAIL PROTECTED]> wrote: > > Does anyone have any opinion on this? > > http://issues.apache.org/bugzilla/show_bug.cgi?id=37057 > > > > I would like to tackle this problem, but both solutions I can think of > > have gotchas. Is it too late for a DTD change in 1.3? > > > > Hubert > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > HTH, Ted. > http://www.husted.com/poe/ > > - > 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: Reset for DynaActionForm
Yeah, I like the second, too. Which can of worms are you talking about, though? The DTD change? I was thinking, since we don't have a release yet, it ain't locked yet. Right? Hubert On 10/12/05, Don Brown <[EMAIL PROTECTED]> wrote: > I like the second, I suppose, but it does open up a can of worms :/ > > Don > > Hubert Rabago wrote: > > Does anyone have any opinion on this? > > http://issues.apache.org/bugzilla/show_bug.cgi?id=37057 > > > > I would like to tackle this problem, but both solutions I can think of > > have gotchas. Is it too late for a DTD change in 1.3? > > > > Hubert > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reset for DynaActionForm
Does anyone have any opinion on this? http://issues.apache.org/bugzilla/show_bug.cgi?id=37057 I would like to tackle this problem, but both solutions I can think of have gotchas. Is it too late for a DTD change in 1.3? Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple Struts Config / Multiple Validator Config
I haven't used multiple validations.xml files, but the behavior you described with multiple struts-config matches what I would expect. I don't know exactly what would be needed to make validator work the way you're expecting to, but it would likely require some cooperation from ValidatorResources. Hubert On 9/16/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: > I had always assumed that (within the same module) I could break up my > validations.xml with my form definitions, for the same locale split accross > several files. But the way it works is that subsequent formsets just > overwite the ones already loaded. Validator and Constant definitions work > fine - they all get merged togther. Is this the intended/expected behaviour. > I would have expected them to all get merged. > > Also, I thought that if I split up the struts-config I could have a > validator plugin definition in each of them associated with different parts > of the "broken" up validations.xml - but it appears that the last Validator > Plugin to run will overwite anything previous ones have loaded. Again is > this the intended/expected behaviour? > > The way it works now, you can only have the Validator plugin defined once > even if you have multiple struts-config.xml for the same module and you can > only break up your form validations into different files for each Locale. > > Is this correct or have I missed something? > > Niall > > > > - > 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]
On DynaForms (was: Re: DO NOT REPLY [Bug 33066] - Lazy Validator Action Form)
> --- Additional Comments From [EMAIL PROTECTED] 2005-09-09 22:18 --- > I'm personally -0 against adding this patch, mainly because I think we should > get rid of those confusing sister classes altogether. I wanted to get some opinion on a related issue. Someone posted a ResettableDynaForm patch for FormDef (https://formdef.dev.java.net/issues/show_bug.cgi?id=2) and while I agree that this is something that the framework should handle (unsure which framework should handle it, though), I'm uncomfortable with the idea of a ResettableDynaForm because then I'd have to worry about all the other sister classes. (This one just extends DynaActionForm.) I'm surprised I haven't encountered this problem before. Is there a common solution I'm not aware of? If there aren't any, is there something we can do to fix it? > They should be moved to > some sort of "extras" subproject or something far away from the main > framework. Either move them or consolidate them somehow. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 Release - Next Steps
On 8/27/05, Ted Husted <[EMAIL PROTECTED]> wrote: > If you still have that list you mentioned, Hubert, you can post it here: > > * http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 Done. /h - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error info (was: A concern about object maint...)
On 8/25/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > > I'm sure that's part of it -- but in my book, even just telling > people which file has the problem would help a lot; at least, in my > case, where we make a myriad of config files to make things easier to > manage. There are also probably just rules of XML such that the > parser may legitimately consider the problem to be someplace other > than where you do -- but it would still be better than nothing. > > And the other thing, were we could add context and experience to > "interpret" exceptions thrown from libraries instead of just passing > them through or lightly wrapping them -- that could do a huge amount > for usability. > > Joe Agreed. While I was disappointed in what I saw with my casual tests, my thought then was to share my findings and see (1) where it could be improved, and (2) which parts we deem valuable and helpful enough to incorporate. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error info (was: A concern about object maint...)
On 8/25/05, Hubert Rabago <[EMAIL PROTECTED]> wrote: > I'll revisit the work I've already done one of these days and share my > observations. ...but don't let me keep you from working on this! If you have the itch then by all means go ahead and take it on! Hubert > > On 8/25/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > > One small thing we could do is go through everywhere there is a > > SAXException caught and add code to specifically catch a > > SAXParseException and use the several properties of that type to > > provide considerably more information than we do now. > > SAXParseException can tell you exactly the file name (system ID), > > line number and column where a syntax error occurred. This could > > help a lot when debugging config file problems. > > > > Similarly, there are other places where we throw through exceptions > > from underlying Commons libraries where we could strategically catch > > common exceptions which throw people (like a lookup exception for an > > tag) and wrap them with contextual information based on > > years of experience. > > > > It's hard, because when you've been doing this for a while, you can > > forget how you learned to decode some of the messages -- but I've > > been helping a few people get up to speed on Struts again recently > > and it has brought some of this to the foreground. > > > > Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error info (was: A concern about object maint...)
(Moving to dev.) I already started to take a look at this sometime ago. (In fact, I had to make sure I didn't check in changes I shouldn't while I was working on those deprecations.) The thing I ran into was, the result I'd get wasn't always fully reliable. If a forward of an action had a problem, for instance, the line number I'd get would sometimes be the one where the closing tag was at. It may be that the reliability of the line number we get would depend on the SAX parser implementation in use. I'll revisit the work I've already done one of these days and share my observations. Hubert On 8/25/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > One small thing we could do is go through everywhere there is a > SAXException caught and add code to specifically catch a > SAXParseException and use the several properties of that type to > provide considerably more information than we do now. > SAXParseException can tell you exactly the file name (system ID), > line number and column where a syntax error occurred. This could > help a lot when debugging config file problems. > > Similarly, there are other places where we throw through exceptions > from underlying Commons libraries where we could strategically catch > common exceptions which throw people (like a lookup exception for an > tag) and wrap them with contextual information based on > years of experience. > > It's hard, because when you've been doing this for a while, you can > forget how you learned to decode some of the messages -- but I've > been helping a few people get up to speed on Struts again recently > and it has brought some of this to the foreground. > > Joe > > > > > At 9:22 AM -0500 8/25/05, Hubert Rabago wrote: > >On 8/25/05, Kade Jeevan Kumar <[EMAIL PROTECTED]> wrote: > >> > >> Whenever if i get any exception due to lack of co-ordination > >>between my JSP form and ActionForm the error messages are not in a > >>proper debuggable way. Sometimes, if something goes wrong with the > >>code it doesn't intimate me with proper error message, but common > >>to all errors it gives me "bean-util exception" > >> > >> If i want to fix the needed error in any of the JSP i need to go > >>through struts-config.xml, tiles-def.xml, and then get the related > >>JSP and then fix it out. > >> > > > >There's a good chance that you'll encounter this same situation with > >any framework that uses XML config files. However, I agree (and I'm > >not the only committer that does) that Struts can do a better job > >providing information when something goes wrong (like, say, which > >action forward it couldn't find). I've made some tiny changes to > >provide more information about an error condition in some situations, > >but for the most part, I'd have to wait until somebody reports > >something in particular before I'll know where to look. I've been > >looking at the situations reported in > >http://issues.apache.org/bugzilla/show_bug.cgi?id=5739 and the issues > >that were linked to it in one way or another. (Now all I need is a > >bit more free time.) If you encounter something in particular that > >you think Struts can do something about, file an enhancement request. > >And if you could, some patches as well. :) Actually, I really > >wouldn't mind test cases I can use, or even a very small zip > >containing files I can use to recreate the error (and help me verify > >I've fixed it). Sometimes the time consuming part is writing the > >sample app to show me I'm done. > > > >Hubert > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > 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: 1.3.0 Release - Next Steps
On 8/23/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > I should be able to wrap up the distribution issues while Hubert wraps > up the deprecations, and I would expect we'd have something rolled and > ready for review by the end of the month -- just in time for Labor Day > weekend in the US. :) Deprecations are done, unless anyone finds something I missed. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 Release - Next Steps
On 8/22/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > From: "Hubert Rabago" <[EMAIL PROTECTED]> > > I don't remember having a release notes document for 1.3.0, though. > > Are you going to set one up? :) > > It's there already: site/xdocs/userGuide/release-notes.xml Oh, you mean that one! Well, with 1.2.7 I remember putting changes on the release notes after the change was made. At least during the latter part. Not sure how it gets started for a particular version, and this one is for 1.2.7 and doesn't contain any 1.3.0 changes that were not backported. > I remember looking at it, but I don't know how you're getting the results of > a Bugzilla search into an html table. (For the release notes or for the > Wiki. Anyone want to share the secret?) I always did it by hand. If anyone's doing it automatically, then they better let me know, too. :) Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 Release - Next Steps
I don't have the list of deprecated items removed with me now, and in any case, the list I was keeping needs to be reformatted anyway, so I'll work on that this week. I think we're gonna wanna share this list, right? :) I don't remember having a release notes document for 1.3.0, though. Are you going to set one up? :) Hubert On 8/22/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > Thanks, Wendy. It sounds like the ball is back in my court :) > > And, many thanks to Hubert for knocking off the rest of the > deprecations over the weekend. > > -T. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre
Welcome to the team! Looking forward to more of your contributions! Hubert On 8/21/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > -- Original message -- > > > Please join me in welcoming Gary vanMatre as a new Struts committer. > > Gary has been quite busy proposing code for the "Clay" plug-in on > > Shale, and has also been supportive on the dev and user mailing lists > > (for both Struts and MyFaces) ... we look forward to his energy being > > available to the entire Struts project as well. > > > > Welcome, Gary! (And now you can process some of your own outstanding > > code diffs :-). > > This is a great honor for me to be a member of such a elite group. I'm ready > to jump into the work being done in Shale but also interested in lending a > hand in Struts classic as that's what currently pays the bills for me. > > Thank you, > Gary > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test JSPs
I'm removing some deprecated tags and am trying to find references to them. Since they're not being run now, can I check in my changes to the tags? Hubert On 8/21/05, James Mitchell <[EMAIL PROTECTED]> wrote: > Those tests were originally part of the suite of Cactus tests that > someone created and I added to. They almost completely cover the > entire set of tags, however, they are pretty dated. > > Are you wanting to fix the tests to align with recent changes? > > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > Consulting / Mentoring / Freelance > EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > Yahoo: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: jmitchtx > > > > On Aug 21, 2005, at 11:09 AM, Hubert Rabago wrote: > > > There are test JSPs in > > /taglib/trunk/src/webapp/org/apache/struts/taglib/html. How are these > > being used? I remember running Maven builds on taglib and not seeing > > tests that use these (not that I knew what I was looking for). There > > are deprecated tags that I'm removing that are being referenced by > > some of these tags. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Test JSPs
There are test JSPs in /taglib/trunk/src/webapp/org/apache/struts/taglib/html. How are these being used? I remember running Maven builds on taglib and not seeing tests that use these (not that I knew what I was looking for). There are deprecated tags that I'm removing that are being referenced by some of these tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 Release - Next Steps
Oh, btw, ResponseUtils has a filter() method that's been deprecated for 1.2.x because the functionality was moved to TagUtils. Now that TagUtils is in another project, the filter code is back in ResponseUtils. It's still marked deprecated, and someone asked why in the javadoc. If no one objects, and no one does it before me, I'll be removing the deprecated tag on this method. Hubert On 8/15/05, Hubert Rabago <[EMAIL PROTECTED]> wrote: > For deprecations, it's a good news/bad news thing. > > Core deprecations are done. There is one item that is left because I > wasn't sure if now is the right time to remove it. The method is > DynaActionFormClass.clear(). From what I can find, this was > deprecated 14 months ago. It's easy to take out if that's what we > should do now (no references to it that I can find), otherwise we can > just update the javadoc to state when it'll be taken out. Checking my > copies of old Struts, it was deprecated by 1.2.1, but I'm not sure > about 1.2.0, and I'm also not sure about timeframes. If it was > deprecated by 1.2.0, we remove them now. What if it was only > deprecated by 1.2.1? Anyway, like I said, this is a quick fix. > > I say "core deprecations" because that's where I usually spend time > at. For some reason I didn't look for deprecated items in taglibs/el. > I found a few items there yesterday afternoon, and they look like > deprecated attributes that need to be removed. They could be as > simple are deleting code, so if anyone out there feels like it, they > should go ahead and work on those. If not, I can take a look at them > one of these weeknights. > > Tiles, I haven't even checked yet. Anybody here willing to work on that? > > Hubert > > > On 8/15/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > How are we doing on mavenizing the web site and removing the deprecations? > > > > When these two items are stable, I'll apply the remaining patches and > > try rolling a distribution. > > > > -Ted. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 Release - Next Steps
For deprecations, it's a good news/bad news thing. Core deprecations are done. There is one item that is left because I wasn't sure if now is the right time to remove it. The method is DynaActionFormClass.clear(). From what I can find, this was deprecated 14 months ago. It's easy to take out if that's what we should do now (no references to it that I can find), otherwise we can just update the javadoc to state when it'll be taken out. Checking my copies of old Struts, it was deprecated by 1.2.1, but I'm not sure about 1.2.0, and I'm also not sure about timeframes. If it was deprecated by 1.2.0, we remove them now. What if it was only deprecated by 1.2.1? Anyway, like I said, this is a quick fix. I say "core deprecations" because that's where I usually spend time at. For some reason I didn't look for deprecated items in taglibs/el. I found a few items there yesterday afternoon, and they look like deprecated attributes that need to be removed. They could be as simple are deleting code, so if anyone out there feels like it, they should go ahead and work on those. If not, I can take a look at them one of these weeknights. Tiles, I haven't even checked yet. Anybody here willing to work on that? Hubert On 8/15/05, Ted Husted <[EMAIL PROTECTED]> wrote: > How are we doing on mavenizing the web site and removing the deprecations? > > When these two items are stable, I'll apply the remaining patches and > try rolling a distribution. > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forwardPattern+contextRelative vs. forwardPattern+module
Oops, typo.
Fixed "path" of original ForwardConfig below.
On 8/12/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> For those interested, here's some relevant code about the test that's failing:
>
> TestMockBase.java, setUpThirdApp() method
> // Configure global forward declarations
> moduleConfig3.addForwardConfig
> (new ForwardConfig("contextForward",
>"/forward",
>false, // No redirect
>"/context")); // Specify module
>
-- "contextForward" used to be configured like this:
moduleConfig3.addForwardConfig
(new ForwardConfig("contextForward",
"/context/forward",
false, // No redirect
true)); // Context relative
>
> junit.framework.ComparisonFailure: contextForward value
> Expected:/context/forward
> Actual :/forwarding/context/forward
>
Hubert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
forwardPattern+contextRelative vs. forwardPattern+module
I was changing some tests which were using contextRelative and ran
into this junit failure:
junit.framework.ComparisonFailure: contextForward value
Expected:/context/forward
Actual :/forwarding/context/forward
at
org.apache.struts.util.TestRequestUtils.testForwardURL3(TestRequestUtils.java:554)
...
RequestUtils.forwardURL() ignored forwardPattern when a request was
contextRelative, but still applied it even when a module was
specified. So, FYI, I'll be updating the tests to reflect this.
This means that, even though you're changing modules, the
forwardPattern of the module that owns a particular forward is still
applied.
Hubert
For those interested, here's some relevant code about the test that's failing:
TestMockBase.java, setUpThirdApp() method
ModuleConfigFactory factoryObject = ModuleConfigFactory.createFactory();
moduleConfig3 = factoryObject.createModuleConfig("/3");
context.setAttribute(Globals.MODULE_KEY + "/3", moduleConfig3);
// Instantiate the controller configuration for this app
ControllerConfig controller = new ControllerConfig();
moduleConfig3.setControllerConfig(controller);
// Configure the properties we will be testing
controller.setForwardPattern("/forwarding$M$P");
// Configure global forward declarations
moduleConfig3.addForwardConfig
(new ForwardConfig("contextForward",
"/forward",
false, // No redirect
"/context")); // Specify module
-- "contextForward" used to be configured like this:
moduleConfig3.addForwardConfig
(new ForwardConfig("contextForward",
"/forward",
false, // No redirect
true)); // Context relative
TestRequestUtils.java, testForwardURL3() method
request.setAttribute(Globals.MODULE_KEY, moduleConfig3);
request.setPathElements("/myapp", "/3/action.do", null, null);
ForwardConfig forward = null;
String result = null;
// redirect=false, module=/context
forward = moduleConfig3.findForwardConfig("contextForward");
assertNotNull("contextForward found", forward);
result = RequestUtils.forwardURL(request, forward, null);
assertNotNull("contextForward computed", result);
assertEquals("contextForward value", // THIS IS FAILING
"/context/forward",
result);
junit.framework.ComparisonFailure: contextForward value
Expected:/context/forward
Actual :/forwarding/context/forward
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts website
Agreed, this looks great! Not knowing much about Maven, I wasn't sure what would happen to the user guide and other such docs. Now I see I don't need to worry about those. Good work! Hubert On 8/9/05, James Mitchell <[EMAIL PROTECTED]> wrote: > Thanks for all the hard work Wendy. This looks great! > > Do you know how that affects the generation of the tld files? Or is it a > non-issue (meaning that hasn't changed) > > I am +1 for moving over to this approach. My +1 also means that I am > willing to help (which I guess I sort of already have ;) > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > Consulting / Mentoring / Freelance > EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: jmitchtx > > - Original Message - > From: "Wendy Smoak" <[EMAIL PROTECTED]> > To: "Struts Developers List" > Sent: Tuesday, August 09, 2005 3:28 AM > Subject: Struts website > > > > In keeping with the Maven-or-Ant thread, it's time to think about > > switching > > to the Maven-generated multi-project website. James has had the "basic" > > Maven-generated site available for a while now with the nightly builds. > > > > I made a start on integrating the existing site with Maven's, and posted > > the > > first draft here (also beside the nightly builds): > > > > http://svn.apache.org/builds/struts/maven/trunk/site-test/index.html > > > > For now all the menus are expanded so you can see what's there. The menu > > structure and navigation are still under construction. :) > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Classic 1.3.0 Critter Corral (was Re: 1.3.0 Release - Next Steps)
On 8/8/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > * Remove deprecations prior to 1.3.0 release > * http://issues.apache.org/bugzilla/show_bug.cgi?id=35953 > > Hubert, will you still be able to handle this? (Pretty please ..) > I have most of these done. AFAIK, the only item I haven't removed yet is the contextRelative field of ForwardConfig. I should be able to get that by the end of the week. H > > -Ted. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 Release - Next Steps
The fewer than expected time I got to work on this was spent on the list of bugs. I got about a quarter from the list, including two duplicates and a worksforme. The rest are items I just didn't get time to work on, or in an area I'm not that familiar with, or items that other people already had a headstart with so perhaps they might like a chance to resolve it. There's a few there I think should be marked as enhancements (one of which I just marked as such), and even then perhaps be closed after updating documentation to tell users to watch out for those cases (like 35389 and 35477). I can take on the deprecated items that need to be removed. Please note that this involves the ActionError class. Also note that not all cases are just delete-n-commit, but the one case I've seen that isn't so far shouldn't be a big deal. I think I'll have a couple nights this week, but not any significant amount of extended periods. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug list in release plan
The list of bugs I included in the release plan didn't include tiles, shale, struts-faces, and the sandbox. Previous release plans included shale and struts-faces, with their status marked "N/A". Do we do the same for 1.3.0? Btw, there are 18 bugs in the list now. If I add the components I skipped, the list grows to 36. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 -- stalled
I'll help out where I can. I posted a checklist that's copied from 1.2.7. Hopefully that'll help you get started with the team-style checklist you're planning. I don't expect a lot of free time today but will set aside time tomorrow morning and on sunday. Hubert On 7/29/05, Ted Husted <[EMAIL PROTECTED]> wrote: > I suppose I could step up and do it. I'll post a release plan > checklist later today. > > Something that's worked for me in the past is to take a team approach > to releases. There's no reason why one person has to do every point on > the checklist. I'll modify the list so that different people can sign > up for different tasks, if they like, and I'll do the rest. > > -Ted. > > On 7/28/05, James Mitchell <[EMAIL PROTECTED]> wrote: > > It looks like I won't have the time that I thought I had to get 1.3.0 > > cut and rolled out any time soon. My day job is heating up and the > > kids soccer season starts up very soon. I'm also running 2 local > > user groups (web-atlanta and jboss-atlanta) and participating in a > > new architects group (IASA). > > > > I wish I had more time to do this, but I just don't have the time I > > need to do it right. If someone else wants to take the reigns and > > run, I'd be very appreciative.Wendy? > > > > > > > > -- > > James Mitchell > > Software Engineer / Open Source Evangelist > > Consulting / Mentoring / Freelance > > EdgeTech, Inc. > > http://www.edgetechservices.net/ > > 678.910.8017 > > AIM: jmitchtx > > Yahoo: jmitchtx > > MSN: [EMAIL PROTECTED] > > Skype: jmitchtx > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > HTH, Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2 docs -> 1.3 docs
On 7/17/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > As far as I can tell, the Maven-generated site does not currently get > published (except possibly through the svn web interface.) > I'm referring to these docs: http://svn.apache.org/builds/struts/maven/trunk/docs/multiproject/struts-core/index.html Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.2 docs -> 1.3 docs
I haven't seen where the user guide and other docs go in the Maven generated site. What's going to happen to them? Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] New Struts committer: Wendy Smoak
Congratulations, Wendy! Hubert On 7/15/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > Please join me in welcoming Wendy Smoak as a new Struts committer. Wendy > has been a tremendous asset to the Struts community for several years now, > providing unflagging support to the user base as well as invaluable input > and feedback to the development team. We look forward to her continued > contributions as a committer. > > Welcome, Wendy! > > PMC vote: 7 +1, 2 +0. > > -- > Martin Cooper > > - > 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]
Transient ActionServlet in Action class
I would like to commit the change illustrated below this message, but
I'm checking first if anybody would object. This should provide add'l
flexibility in the handling of Action classes.
Hubert
Index: apache/struts/action/Action.java
===
--- apache/struts/action/Action.java(revision 179983)
+++ apache/struts/action/Action.java(working copy)
@@ -93,7 +93,7 @@
/**
* The servlet to which we are attached.
*/
-protected ActionServlet servlet = null;
+protected transient ActionServlet servlet = null;
Index: apache/struts/chain/commands/servlet/CreateAction.java
===
--- apache/struts/chain/commands/servlet/CreateAction.java (revision
179983)
+++ apache/struts/chain/commands/servlet/CreateAction.java (working copy)
@@ -65,13 +65,15 @@
if (action == null) {
log.info("Initialize action of type: " + type);
action = (Action) ClassUtils.getApplicationInstance(type);
-ServletActionContext saContext =
(ServletActionContext) context;
-ActionServlet actionServlet = saContext.getActionServlet();
-action.setServlet(actionServlet);
actions.put(type, action);
}
}
+if (action.getServlet() == null) {
+ServletActionContext saContext = (ServletActionContext) context;
+ActionServlet actionServlet = saContext.getActionServlet();
+action.setServlet(actionServlet);
+}
return (action);
Index: apache/struts/action/RequestProcessor.java
===
--- apache/struts/action/RequestProcessor.java (revision 179983)
+++ apache/struts/action/RequestProcessor.java (working copy)
@@ -296,10 +296,13 @@
return (null);
}
-instance.setServlet(this.servlet);
actions.put(className, instance);
}
+if (instance.getServlet() == null) {
+instance.setServlet(this.servlet);
+}
+
return (instance);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionConfig/ActionMapping question
I'm not aware of the motivations behind the newer config objects. The closest I have to a clue is someone mentioning in a previous email that the config objects were supposed to just hold data from the struts-config.xml file. If that's still the case, then (1) we should reduce the logic placed there (2) stop adding more methods with more logic. What that means is more util-type classes to hold the logic and pass config classes to them. For (1), an obvious target would be the config inheritance. They can be moved to a separate class which will contain all inheritance logic. The findForward(String) type methods would move to a separate class also. Of course, all this hangs on the reason we have the newer "config" API in the first place. Can anyone point me to a thread or provide some clarification? Hubert On 5/31/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > I've generally been attempting to code to the newer "config" APIs > instead of the older not-quite-deprecated forms, and I just hit > something I didn't expect; I don't know whether it qualifies as a bug > or just my own misunderstanding. > > When one has an object of type "ActionConfig", there is a method, > "findForwardConfig". This method looks in the actionConfig's map of > ForwardConfig objects and returns a match or null. > > However, there is no method which captures the behavior of > ActionMapping.findForward(String), which searches not only the local > collection of ForwardConfig objects but also the global scope. > > Should ActionConfig have a method which does something like this? I > would propose altering the behavior of findForwardConfig to also go a > "global" search as a fallback, because I believe the name "find*" > implies more behavior. If there is need for a method which only > searches the local scope, I would propose that method be named > "getForwardConfig(String)" > > Is this too incompatible to introduce directly as described? Does > there need to be a new method which behaves as > "ActionMapping.findForward" but which presumably returns ActionConfig > instead of ActionMapping? My assumption is that vanishingly few > people write to the newer APIs; maybe I'm wasting my time doing it > myself. > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Struts 1.2.7 (General Availabilty)
Thanks, Niall ! Hubert On 5/26/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > Hooray! Many thanks, Niall, for driving this one. > > -- > Martin Cooper > > > On 5/26/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > The Struts team is pleased to announce the release of Struts 1.2.7 for > > General Availability. This release includes new functionality, as well as > > numerous fixes for bugs which were reported against the previous release, > > and supersedes the earlier 1.2.4 version as the latest official release of > > Struts from The Apache Software Foundation. > > > > The binary, source and library distributions are available from the Struts > > download page: > > > > http://struts.apache.org/download.cgi > > > > The Release Notes are available on the Struts web site at: > > > > http://struts.apache.org/userGuide/release-notes.html > > > > -- > > Niall Pemberton > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
On 5/26/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > > I'm not sure how you can be burned by not having direct access to a > member while there are getters and setters available. My mistake. The cases that keep flashing in my head provided getters (if even that) but no setters. In those cases, I had problems because the superclass would use the instance without going through the getter, so even if I overrode the getter, I couldn't make the change the behavior of the superclass. Hubert > On the other > hand, making a member directly accessable severely curbs the ability > to change the class implementation without breaking backwards > compatibility. Suppose at some point that you decide you don't want to > keep a reference to the member in the class, but retrieve it on the > fly. Or perhaps you decide that you want to keep the reference in a > cache of weak references. You're hosed, because any code that used > that member is now broken. > > This is something that I really dislike in a lot of the Struts code. > For much of it, it's no doubt too late to change. However, I'd very > much prefer that we don't continue to exacerbate the problem. > > -- > Martin Cooper > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tiles] Subproject Questions
I agree as well. Hubert On 5/26/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > I would also vote for "org.apache.tiles" - my guess it would be more > > platable to other frameworks if there isn't a "struts" in the name. It might > > make people think there was a struts dependency with "struts" in the package > > name. Also, if the consensus is to move out as a TLP in the future, then > > there wouldn't be a need to change package names at that point. > > Excellent points. I agree with that reasoning. > > sean > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
If I understood what you're saying, then yes, that's how all other config fields are, and I'll probably change 'properties' to conform to that (unless someone else beats me to it). Hubert On 5/26/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote: > Hubert Rabago wrote: > > > Yes, but it doesn't mean I'm not open to other ideas. In this case, > > I started out reading from everywhere that fields should be private, > > and everything should go through accessors (even subclasses). But I've > > been burned by that restriction LOTs of times (in some cases, I had > > to rebuild entire libraries to get access to the fields I needed), so > > I'll need some convincing. If private fields are what's best, how come > > every other config field is protected? > > i suppose a middle ground would be to keep the properties object > protected but provide and use only accessor methods within struts? > > > :) > > riyaz > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
On 5/26/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote: > > at the moment the getProperties() returns the Map object. no necessity > for the 2 accessor methods getProperty,setProperty > The getProperties()/setProperties() accessors are protected and are for subclasses. The getProperty()/setProperty() accessors are public, for use by everyone else. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
On 5/26/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote: > Hubert Rabago wrote: > > my intention here was to have _all_ the accessor methods of "properties" > in BaseConfig - i guess it can be a hinderance when the classes a > changing rapidly as u've mentioned. i think of it as a 'cleaner' way :) > That's what we have now, accessors of "properties" in BaseConfig. In fact, that's the only way to access them, which goes against the convention set by most (if not all) other config objects. Other config objects declare their fields as protected, allowing custom subclasses to access those fields directly. I'll probably change "properties" in BaseConfig to follow this convention. > > eg: pass the childConfig to the ParentConfig instead of the passing the > parentConfig (baseConfig) to the childConfig. It took me a while to understand what you were saying here, but I think I finally get it. I'm not opposed to the idea, but stepping back, I'm not entirely convinced that one is cleaner than the other. We've been discussing this only from the perspective of copying arbitrary properties of config objects held by an ActionConfig. The rest of the config objects have been doing "child-inherits-from-parent" as well. If "parent-sets-child-values" is truly that much better, I'd want to use that for the rest of the config objects. Not just when copying full config, but also when extending overridden configs. > > again, extending classes would have limited access to the properties object. This point is independent of "parent-sets-child-values" vs. "child-inherits-from-parent". Whichever wins out there, doesn't convince me that superclasses should forbid subclasses from accessing fields. > > it comes down to the first point u made. :) ie: > > > I'm not sure I want to forbid config subclasses from accessing > > their properties directly. I've come across several libraries > > and frameworks which used "private" all throughout and made it > > difficult if not impossible for me to customize certain behavior. > > different ways of thinking ;) > Yes, but it doesn't mean I'm not open to other ideas. In this case, I started out reading from everywhere that fields should be private, and everything should go through accessors (even subclasses). But I've been burned by that restriction LOTs of times (in some cases, I had to rebuild entire libraries to get access to the fields I needed), so I'll need some convincing. If private fields are what's best, how come every other config field is protected? Hubert > riyaz > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
On 5/25/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote:
>
> just a thought.
>
> ie, not expose the "properties" object (as it is) by the
> getProperties,setProperties methods.
I'm not sure I want to forbid config subclasses from accessing
their properties directly. I've come across several libraries
and frameworks which used "private" all throughout and made it
difficult if not impossible for me to customize certain behavior.
(I'm still running into those issues with the app I inherited
here in my day job.)
The 'properties' field was initially declared as protected when
it was only in ActionConfig. The goal was to reduce the likelihood
that subclasses would be needed. Now that it's in a class that's
intended to be subclassed, I wonder why it became private. Joe?
> by my last viewing of the Config
> classes, only ActionConfig uses "properties" and needs to change for
> this - not much.
We also need it in FormBeanConfig.
> get/setProperties can be replaced by
>
> void inheritProperties(childConfig) {
> // for each "xx" property in (parent) class
> // if childConfig.getProperty("xx") == null
> // copy the arbitrary property
> }
>
>
> imho, i think this is a good way to do this, provides separation between
> BaseConfig and its extending classes
BaseConfig already has an "inheritProperties(BaseConfig)" method, doing just
what you've outlined. This is used by subclasses when extending another
config object, not to be confused with the need to "copy" another config
object, which is when ActionConfig and FormBeanConfig needs access to the
properties field.
Hubert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
On 5/25/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
> I was wondering about this:
>
> > BeanUtils.copyProperties(copy, baseHandler);
> > this.addExceptionConfig(copy);
> >-
> >+copy.setProperties(baseHandler.getProperties());
> >+
>
> doesn't the strategy you implemented clobber properties which are
> set on the extending/copy? Shouldn't this process somehow honor
> properties which were already set in the copy? I think it should go
> through the list of property names in the baseHandler and, where the
> property is not already defined in the copy, in those cases it should
> copy them.
>
This part of the code executes when the extending config object
(ActionConfig in this case) isn't overriding baseHandler:
// Do we have this handler?
ExceptionConfig copy =
this.findExceptionConfig(baseHandler.getType());
if (copy == null) {
// We don't have this, so let's copy it
copy = (ExceptionConfig) RequestUtils
.applicationInstance(baseHandler.getClass().getName());
BeanUtils.copyProperties(copy, baseHandler);
this.addExceptionConfig(copy);
copy.setProperties(baseHandler.getProperties());
} else {
// process any extension that this config might have
copy.processExtends(getModuleConfig(), this);
}
Hubert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG FormBeanConfig.inheritFormProperties(): Implement inheritance of arbitrary config properties
Riyaz,
Thank you for reporting this. I believe I will get a chance to work
on this tonight.
Hubert
On 5/22/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote:
>
> Line : BeanUtils.copyProperties(prop, baseFpc) does not copy the
> arbitrary properties contained in the baseFpc's FormPropertyConfigs
>
> throwIfConfigured();
>
> // Inherit form property configs
> FormPropertyConfig[] baseFpcs = config.findFormPropertyConfigs();
> for (int i = 0; i < baseFpcs.length; i++) {
> FormPropertyConfig baseFpc = baseFpcs[i];
>
> // Do we have this prop?
> FormPropertyConfig prop =
> this.findFormPropertyConfig(baseFpc.getName());
>
> if (prop == null) {
>
> // We don't have this, so let's copy it
> prop = (FormPropertyConfig) RequestUtils
> .applicationInstance(baseFpc.getClass().getName());
>
> BeanUtils.copyProperties(prop, baseFpc);
> this.addFormPropertyConfig(prop);
> }
>
> }
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug:
Key/value properties were just added last week to config objects other
than Action. Supporting inheritance for them is next on my plate, and
in fact I'm hoping to get to them today (was unavailable the past
couple of weeks for Struts work).
I'm -1 on copying config instances between elements. Each config has
had its own instance of related config objects and I wouldn't know
what problems might arise by sharing instances. We may also have a
hard time keeping track of which instances are being shared and which
are not. Aside from that, I fear that after sharing instances, we'd
next want to "optimize the config objects by sharing similarly
configured elements declared in struts-config". Leave me out of that
one.
Hubert
On 5/16/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote:
>
>
>
> if (prop == null) {
> // We don't have this, so let's copy it
> prop = (FormPropertyConfig)RequestUtils
>.applicationInstance(baseFpc.getClass().getName());
>
> BeanUtils.copyProperties(prop, baseFpc);
> this.addFormPropertyConfig(prop);
> }
>
>
>
> bug: key/value properties set in "baseFpc" is not copied to "prop"
>
> sol1: add inline code here
> sol2: add method to BaseConfig to inherit a parentConfig's properties
> and call from here/above. possible other similar cases in other configs.
>
> will submit patch, wondering which method is more suitable. ideas?
>
> ps: i can't understand y a new FormPropertyConfig instance is created
> :(. can't v just share the propConfig? it is readonly right?
>
> riyaz
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug:
Seems like the lists and Gmail are having communication problems -- my Gmail
messages don't seem the reach either list today. Apologies if this messages
gets to you twice.
Key/value properties were just added last week to config (objects other
than ActionConfig, which already supports inheritance for key-value
properties). Supporting inheritance for them is next on my plate, and
in fact I'm hoping to get to them today (was unavailable the past
couple of weeks for Struts work). It will most likely be similar to the
second solution you mentioned.
I'm -1 on copying config instances between elements. Each config has
had its own instance of related config objects and I wouldn't know
what problems might arise by sharing instances. We may also have a
hard time keeping track of which instances are being shared and which
are not. Aside from that, I fear that after sharing instances, we'd
next want to "optimize the config objects by sharing similarly
configured elements declared in struts-config". Leave me out of that
one.
Hubert
--- Riyaz Mansoor <[EMAIL PROTECTED]> wrote:
>
>
>
> if (prop == null) {
> // We don't have this, so let's copy it
> prop = (FormPropertyConfig)RequestUtils
>.applicationInstance(baseFpc.getClass().getName());
>
> BeanUtils.copyProperties(prop, baseFpc);
> this.addFormPropertyConfig(prop);
> }
>
>
>
> bug: key/value properties set in "baseFpc" is not copied to "prop"
>
> sol1: add inline code here
> sol2: add method to BaseConfig to inherit a parentConfig's properties
> and call from here/above. possible other similar cases in other configs.
>
> will submit patch, wondering which method is more suitable. ideas?
>
> ps: i can't understand y a new FormPropertyConfig instance is created
> :(. can't v just share the propConfig? it is readonly right?
>
> riyaz
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DTD 1.3
Thanks for pointing that out. I've update the DTD with the corrected comment. It now reads: extends The path of the action mapping configuration that this will inherit configuration information from. Hubert On 5/1/05, rmanchu <[EMAIL PROTECTED]> wrote: > > extends The name of the action mapping configuration that this > will inherit configuration information from. > > > actions extending actions. but what is the "name" referred here? > > the "name" attr determines the form right? > > is this implemented? > > thanx > riyaz > > - > 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]
