Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml
Craig R. McClanahan wrote: Quoting Jonathan Revusky <[EMAIL PROTECTED]>: [snip] First of all, as regards your statement above in which you refer to "someone else's website", I parse this to mean that you consider the jakarta.apache.org/struts website to be _yours_. As a matter of fact, it is not. It belongs to the Apache Software Foundation, a non-profit entity set up with a certain charter and that has received support from various organizations. You are parsing the sentence in a manner that was not intended. That's your problem, not mine. No, Craig. If you express yourself in such a way that a careful reader misinterprets what you said, it's your problem too. At the very least, it suggests that you did not express yourself clearly. Anyway, as I read on, it is not clear at all to me that I misinterpreted your statement. From this very message I am responding to, it seems that my interpreation was correct: you relate to the struts website as your personal site and it does not occur to you that you are subject to constraints relating to professionalism or ethics or even-handedness in the maintenance of the site. At least there is no sign of this. However, it's interesting to note that from a legal perspective, the Struts web site *is* my site, Well, you're just wrong about this and this can hardly be a matter of legitimate debate. From a legal perspective, the Struts web site is most certainly *not* _your_ site. The Struts web site belongs to the Apache Software Foundation, which is a separate juridical individual. You are a member of the ASF but you are not the ASF. IBM belongs to its shareholders, but if I own some shares (even a lot, like a 1% stake) if I say that, therefore, the ibm.com website is "mine", I would be misspeaking. It belongs to IBM, a separate juridical individual. So, basically, it is not *your* site. As a public service (my last here, I think) I'll clarify the concept further: if ASF has money in the bank, and you have check-writing privileges, it is still not *your* money. Moreover, there is an onus on you to spend the money responsibly that simply does not exist with your own personal checking account. By the same token, there is a very real difference between maintaining apache.org and maintaining a personal website that really does belong to *you*. along with Ted Husted and the other 100-odd Members of the Apache Software Foundation, who jointly own all of the intellectual property, software, and web content you see at apache.org. Therefore, if I *had* intended the interpretation you parsed, it would have been perfectly within my legal rights to do so. Yes, I suppose you would be within your legal rights to make such a statement -- since you can say what you want. However, the statement would still be erroneous. The Struts web site does not belong to you. That, and all of the related intellectual property belongs to ASF. You donated it. Just as you cannot have your cake and eat it too, you cannot donate your intellectual property to a separate juridical entity, and have it still be "yours". If you didn't quite understand this when you donated this stuff to ASF, that's a pity, but you should understand it next time round. However, here at Apache, we treat website content like we do any other change to the software. In particular, changes are subject to post-commit -1s for reasonable concerns (and Ted's is -- see next response). Craig, again I could be misparsing the above, but you seem to be saying that Ted's concerns are "reasonable" and the ones I have expressed are not. But frankly, you're kidding yourself. My reading of Ted's messages is that his concern is basically the same as what I have expressed -- the idea that you would use the fact that you are maintaining a part of the Apache.org website to retaliate against an individual for political speech that you disagree with. Anyway, I'm not going to debate this any further with you, I don't think. I don't think we can have a debate. It is becoming blatantly obvious that you do not really master the basic concepts that one would need to master in order to debate this issue. This was pretty much apparent in the text of the initial commit message. However, it became all the more apparent as you added further comments in the thread. Craig McClanahan (Among other things) Member, Apache Software Foundation Yes, among other things... :-( Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ Using FreeMarker with Struts: http://freemarker.org/docs/pgui_misc_servlet.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml
Steve Raeburn wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Jonathan Revusky Sent: November 13, 2003 2:24 PM To: [EMAIL PROTECTED] Or, really, to put it bluntly, I was not addressing you, Steve. If you wanted a private conversation, you should have emailed Craig directly. I made my points publicly by choice. I chose my words carefully. You had the right to reply. I simply stated that your reply was not helpful. I specifically took issue with the implicit arguments that Craig was making, and, since Craig, to my knowledge, never appointed you as his spokesman, you were not in a position to clear up the issue. PERSONALLY, Good, I see you are a quick study. You do realize that you can only legitimately speak for yourself. I think that linking to Basebeans now creates more confusion and doubt for Struts users than it does assistance. Well, this strikes me as utter nonsense. What you are saying amounts to the idea that you would reduce "confusion" by filtering such a list of links based on the political correctness of the individuals involved. Now, with with no such filtering, the situation is hardly "confusing", is it? Let's see... a page contains a list of companies that provide struts-related services. BaseBeans provides such services, and thus appears on the page. Now, if I am a Struts user in the market for such services, am I better served (and less "confused") by a list that is filtered based on the political correctness of the individuals providing the services? I think not. In fact, this is such obvious nonsense that, quite frankly, I doubt that you believe it yourself. And I already stated that I perceived a lack of honesty on your side of the dialogue, a definite smell of bad faith in the air. After all, Vic is saying that Apache has acted unlawfully, which might give potential users cause to not use Apache software, including Struts. I don't see why we should promote that. Promoting what? Look, if you disagree with Vic's statements, rebut the statements. What does this have to do with filtering a list of links of companies providing struts-related services based on the "political reliability" of the people providing said services? Moreover, the record is clear. Craig's commit message pretty clearly indicated that the removal was retaliation for Vic having made certain statements. Note the following extract: "not to benefit from the free advertising value of being visible on the Struts web site." The whole idea that somebody says things that you don't like, so you're going to try to retaliate against them makes me extremely uncomfortable. And note that the fact that few others express their discomfort does not necessarily mean it sets well with them... I would have a greater tendency to carefully consider any points that Vic raises in the future. That's your prerogative. Perhaps if you'd seen some of Vic's ramblings, as I have, you might think differently and be as tired of them as I am. Please check the mail archives before getting too upset on Vic's behalf. If you're accusing Vic of improper behavior, then don't vaguely point to the mail archives. Provide actual links. In any case, my position is that it's irrelevant anyway. It seems clear enough that there is an attempt to retaliate against someone for political speech that you disapprove of. I object to the idea of an attempt to retaliate against someone for speaking his mind. In terms of this basic principle, it is actually not important whether the political speech in question was coherent or were "ramblings", as you characterize them. There are 21 Struts committers, none of whom has objected to the web site update. That should speak volumes. Well, sure it speaks volumes. It would mean that they're a bunch of spineless toadies. Note that, if Ted Husted is a struts committer (that I don't know) then your statement is no longer true. Unless any of them have concerns I suggest we return the list to the business of discussing Struts development. Steve, as I said bluntly before, nobody was addressing you, yet you chose to enter the thread nonetheless. And I have already suggested that your entering the thread was most unhelpful. Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ Using FreeMarker with Struts: http://freemarker.org/docs/pgui_misc_servlet.html Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml
what Vic has to say. I cannot know for sure, but that is the conclusion that I tentatively draw and I somehow doubt that I can be the only person with that reaction. Steve, I'm not really acquainted with you or with Vic, but your engaging in this kind of ad-hominem stuff and other examples of illegitimate discourse tends to reduce your credibility in my eyes and consequently, I would have a greater tendency to carefully consider any points that Vic raises in the future. In any case, I am not satisfied with this answer. In particular, I would like Craig to explain this business about how it is hypocritical for Vic to be receiving the benefit of being linked on the Struts site when he has voiced criticism of ASF. It is very hard for me to interpret such twisted statements in a generous manner. But unless Craig actually appointed you as his spokesman/advocate, I think you should let Craig clarify what he meant by that and whether he stands by that statement. Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ Using FreeMarker with Struts: http://freemarker.org/docs/pgui_misc_servlet.html Steve -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Jonathan Revusky Sent: November 13, 2003 10:45 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml Craig R. McClanahan wrote: Quoting Vic Cekvenich <[EMAIL PROTECTED]>: Was that called for Craig? Yep. Maybe putting in the4 context of ... ASF was accused of stealing designs, and Vic decided to presure ASF? http://www.mail-archive.com/general%40jakarta.apache.org/msg 08432.html Feel free to go make your case on someone else's website. As an external observer (I keep one eye on various forums in this application space) I cannot help but make certain comments. First of all, as regards your statement above in which you refer to "someone else's website", I parse this to mean that you consider the jakarta.apache.org/struts website to be _yours_. As a matter of fact, it is not. It belongs to the Apache Software Foundation, a non-profit entity set up with a certain charter and that has received support from various organizations. If the website in question were your personal website (which it is not) then there would be no issue whatsoever in terms of removing material on the basis of arbitrary, personal considerations. In terms of one's own personal website, one can be as petty and arbitrary as one wishes. However, if you are maintaining the Struts-related material on apache.org, on behalf of ASF, I think one should be subject to certain constraints related to professional ethics, and one's behavior should not be petty and arbitrary, subject to personal animosities and so on. Let me develop this a bit further. Presumably the BaseBeans site was linked in the first place because it was considered to be something potentially of interest to the Struts community. It stands to reason. What other reason would there be to link it? Correct me if I'm wrong. Now, as far as I can see, a legitimate reason to remove the link would be the determination that the BaseBeans site is no longer potentially of interest to the Struts community. However, BaseBeans, as far as I know, continues to offer the same products and/or services that it offered when originally linked. If the site was potentially of interest to Struts users when it was linked, it would seem that nothing has occurred to change that. Any 3rd party observer would draw the conclusion from this that Mr. Cekvenich made statements in a certain context that rubbed you the wrong way, so you are removing the link in retaliation. In other words, the decision was based on purely personal or political grounds, not on any objective basis. So the link was and continues to be of interest (at least potentially) to Struts users. (That's why it was initially linked and nothing has changed.) And now, you want users who visit this page not to see the link -- that is potentially of interest to them -- because of a personal or political conflict with Mr. Cekvenich. The link might be potentially beneficial to a Struts user who is interested in the services that Mr. Cekvenich's company offers. However, since that would also benefit Mr. Cekvenich, an individual towards whom you are not hiding animosity, you prefer for the link not to be there. I can only speak for myself but this gives me a very bad impression. It is suggestive of a lack of professionalism, a lack of ethics, and also even a lack of consciousness of these kinds of issues. By that, I mean that you even state in a CVS commit commment that will be publicly visible that this was the basis of your decision to remove the link. This is my honest reaction, I hope I am expressing myself clearly. If there is anything about the above that is unclear to you, feel free to request clarifi
Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml
in the Middle East. Is it hypocritical of me to benefit from a research grant funded by the U.S. government? Well, look, it's clear enough that I think that your case is very very weak logically and ethically. We're not acquainted, but, in my experience, people in your spot will start to bluster and engage in ad-hominem types of responses. I would make the friendly suggestion that you think carefully about how you respond to this. I think you have already caused some damage to your own good name, but you should be careful about making matters worse. On the other hand, you really do have to respond. For one thing, you really seem to be accusing another man of being a hypocrite. If you cannot back up that assertion, common decency says that you should retract the statement. And quite humbly. You can minimize the damage. After all, we all make mistakes. Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ Using FreeMarker with Struts: http://freemarker.org/docs/pgui_misc_servlet.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A Custom tag using and validation ...
I have made some more modifications to the LabelTag to make it more extensible. The way the tag works now is: doStartTag() -> starts the span (if styles are applied) doAfterBody() -> Determines which label to use (from the resource bundle or from the body content.) doEndTag() -> ends the span (if styles are applied) Styles are still applied based on whether there is an error associated with the property. If anyone wants to use an '*' or any other symbol to the right or left of the label, just override the start or end tag. Erik: If you want, you can use just one attribute by overriding the setKey method and passing the key to the super's setProperty method; Thanks for helping refine this, Jonathan -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 2:56 PM To: Struts Developers List Subject: Re: A Custom tag using and validation ... On Wednesday, June 25, 2003, at 02:01 PM, David Graham wrote: > Struts doesn't have the luxury of living in one development shop. I > understand your need for customizations for your particular conventions > but we can't force them on others. So, we'll be ok as long as the > Struts > version provides some basic useful functionality and allows easy > subclassing. Agreed! And +1 The main point I wanted to make here, just to clarify, is for us to always consider avoiding duplication and to clearly denote where we are doing so and why which you have done nicely. LabelTag is something Struts needs in some form or another... keep up the good work folks! Erik - 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: A Custom tag using and validation ...
Hey guys, I have modified the LabelTag in my patch to use a key if provided. If no key is provided, the body content will be displayed. -or- Password Check it out at http://issues.apache.org/bugzilla/show_bug.cgi?id=20784 hth, -Jonathan -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 2:56 PM To: Struts Developers List Subject: Re: A Custom tag using and validation ... On Wednesday, June 25, 2003, at 02:01 PM, David Graham wrote: > Struts doesn't have the luxury of living in one development shop. I > understand your need for customizations for your particular conventions > but we can't force them on others. So, we'll be ok as long as the > Struts > version provides some basic useful functionality and allows easy > subclassing. Agreed! And +1 The main point I wanted to make here, just to clarify, is for us to always consider avoiding duplication and to clearly denote where we are doing so and why which you have done nicely. LabelTag is something Struts needs in some form or another... keep up the good work folks! Erik - 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: Form field styling/error reporting - Alternate solution [Long]
>That's great if all I was worrying about was the label. I also don't think >styles should necessarily be put in property files, formatting / >presentation information should be kept as it's own resource, separate from >the data it's applied to. The enhancement is not in any way limited to labels. Every input type (checkboxs, text boxes, textareas, etc...) would benifit from the same minor code change to the BaseHandlerTag. Once this change was made, all the end-developer would have to do is set up styles/error styles in a properties file (whichever one they want). There would be zero change to how the gui developer would use the struts custom tags. I don't care (nor to i want to limit) which bundle the user wants to store the style info in. But I do feel putting it in a bundle is the way to go. Being able to give locale specific error styles will always be more helpful than locking the user into a single set of styles. >I don't have a problem with how the current Struts form tags are >implemented, but when you take a form as a whole, and mix in >formatting/layout/presentation,etc info that might be replicated from JSP to >JSP, couple with a desire to make non-engineers responsible for maintaining >them (w/o writing Java code). Using something as flexible as XSLT was a >better solution than trying accomplish the same with a set of changes to JSP >tags. A main idea behind custom tags is to encapsulate complicated java code so the gui developers dont have to worry about it. IMHO, asking gui developers to start writing XSLT is equiv to putting that straight java code back in the pages. >>As far as the text descriptions of the errors, this is already handled by >> really well. >Yes, but I'm not changing those descriptions, I'm merely providing more >control over how you can place them relative to the field they are for, as >well as the style that is applied to the label or field associated with the >error. I think straight html is always gonna be the way to go here. I don't see the benifit to saying 'put my error message after this label' or 'put my message after this input field'. I think that is too much control and is better left to the developer to put that tag where they want it. Jonathan -Original Message- From: DeRose Jonathan [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 11:02 AM To: Struts Developers List Subject: RE: Form field styling/error reporting - Alternate solution [Long] >-Original Message- >From: Mike Jasnowski [mailto:[EMAIL PROTECTED] >Sent: Wednesday, June 25, 2003 9:55 AM >To: Struts Users Mailing List >Subject: Form field styling/error reporting - Alternate solution [Long] >The technique centers around the use of XSLT to process what appears between >the start and end tags. The project I'm working had a similar >requirement of being able to highlight field labels, also possibly highlight >the field itself, as well as place a custom error message above the row. We >also wanted to allow flexibly layout and formatting of the form elements. > An initial reaction might be to create a set of form tags that were >knowledgable about form errors and provided means to style based on form >errors. If this meets your requirements then that's all well. But if you >wanted to apply this style to fields themselves, then you might end up >adding this feature to all form element types. Additionally, the placement >of field level error messages at a location not directly after the field >while maintaining the flexibility to layout and present the other field >elements complicates this somewhat. The BaseHandlerTag currently controls what styles tags use to display themselves. Making a small modification to the prepareStyles() method will get you control over every input type there is. In addition, by creating a new LabelTag that extends BaseHandlerTag, it is covered under the changes as well. If you set up what styles/error styles to use in the resource bundle, page developers get all of the error handling functionality with no changes to the jsps they write. As far as the text descriptions of the errors, this is already handled by really well. Jonathan - 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: A Custom tag using and validation ...
>> IMHO, I think it is a better idea to 'wrap' whatever text >> a user wants to use, however they want to generate it. >> >> Ex: >> First Name: >> -or- >> > property='firstName'/> >It's reasonable to allow the user to specify a lookup key or use >the tag's body text. >David I think the compromise of using a key or the body text of the message is a great idea. For that there are two things to consider 1)Displaying the messages from the resource bundle and, 2)Provide error handling for the labels The first can be handled by extending the MessageTag fairly easily. The second can be handled by extending the BaseHandlerTag (provided we use the enhancment to allow error handling there, which I'm a big fan of =) This could be accomplished by having MessageTag extend BaseHandler instead of BodyTagSupport, which would have to be done carefully, but is in no way difficult. Jonathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Form field styling/error reporting - Alternate solution [Long]
>-Original Message- >From: Mike Jasnowski [mailto:[EMAIL PROTECTED] >Sent: Wednesday, June 25, 2003 9:55 AM >To: Struts Users Mailing List >Subject: Form field styling/error reporting - Alternate solution [Long] >The technique centers around the use of XSLT to process what appears between >the start and end tags. The project I'm working had a similar >requirement of being able to highlight field labels, also possibly highlight >the field itself, as well as place a custom error message above the row. We >also wanted to allow flexibly layout and formatting of the form elements. > An initial reaction might be to create a set of form tags that were >knowledgable about form errors and provided means to style based on form >errors. If this meets your requirements then that's all well. But if you >wanted to apply this style to fields themselves, then you might end up >adding this feature to all form element types. Additionally, the placement >of field level error messages at a location not directly after the field >while maintaining the flexibility to layout and present the other field >elements complicates this somewhat. The BaseHandlerTag currently controls what styles tags use to display themselves. Making a small modification to the prepareStyles() method will get you control over every input type there is. In addition, by creating a new LabelTag that extends BaseHandlerTag, it is covered under the changes as well. If you set up what styles/error styles to use in the resource bundle, page developers get all of the error handling functionality with no changes to the jsps they write. As far as the text descriptions of the errors, this is already handled by really well. Jonathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A Custom tag using and validation ...
>> 1) Putting an '*' into a label for required fields assumes people want >> an >> '*', maybe they want a '(R)' or maybe they want something else entirely >> (perhaps an image...). >> >> 2) Putting an '*' after a label for required fields assumes people want >> an '*' after the label. Perhaps they want the '*' before the label or >> after the actual input field. Consider the label 'Name:' with three text >> boxes for first, last, and middle. First and last might be required but >> middle is not. There is no clear way to mark first and last but not middle with >> this enhancement. >The required field marking should be a tag attribute. My point is more that no assumption should be made on: 1)What symbol should be used to show required fields, and 2)Where that symbol should be placed. I think that if you want to show a symbol for required fields, the only thing a tag should do is show the symbol. As for where you define what that symbol is; I think it should be in a resource bundle, that way it can be 'R' for your english required and 'N' for your spanish nessicito (if that is in fact what they like) This gives you the flexibility to do the following: -or- First Name: -or- >> 3) Forcing people to use the ResourceBundle to display labels requires a >> lot >> more effort for applications that have no internationalization >> requirements. >> For many web applications, html text is enough and does not require a >> heavy >> resource bundle to maintain or keep in memory. >It does not require "a lot more effort" to use a resource bundle. One >main reason Struts was created in the first place was to i18n applications >easily. Many existing Struts tags require resource bundle keys and we >should not allow new tags to just print out non-internationalized text. I disagree, while for many applications using a resource bundle is a great thing, for many others the resource bundle is unneeded overhead. I am currently working on a 300+ page web application that will never need to display other languages. To use RB's to display each and every label on each and every page is more work to manage, is overhead to keep in memory, and does take more time to load on each page. IMHO, I think it is a better idea to 'wrap' whatever text a user wants to use, however they want to generate it. Ex: First Name: -or- *Note* I dont see the above printing out a symbol for required fields, to get that you would need... (or put it wherever else you would want it) Thanks, Jonathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A Custom tag using and validation ...
Hi, I think Struts should be as flexible/extensible as is possible/practical. With that in mind, and after reading about this enhancement I have the following concerns: 1) Putting an '*' into a label for required fields assumes people want an '*', maybe they want a '(R)' or maybe they want something else entirely (perhaps an image...). 2) Putting an '*' after a label for required fields assumes people want an '*' after the label. Perhaps they want the '*' before the label or after the actual input field. Consider the label 'Name:' with three text boxes for first, last, and middle. First and last might be required but middle is not. There is no clear way to mark first and last but not middle with this enhancement. 3) Forcing people to use the ResourceBundle to display labels requires a lot more effort for applications that have no internationalization requirements. For many web applications, html text is enough and does not require a heavy resource bundle to maintain or keep in memory. --- If there is a strong desire for an asterisk tag, why not just have a tag that takes a property and prints out an asterisk if it is required? Or even better, set up whatever symbol you want to show for required fields in the resource bundle, and then use that. EX: ApplicationResources.properties html.required=* -or- html.required=(R) -or- html.required= --- I have proposed an enhancement that I think offers more flexibility from the error handling perspective: * It allows for error styles, error classes, and error ids for labels AND for all of the input elements. (You could make the label 'Name:' red and bold, or you could make the name text box highlighted in red, or both) It allows developers to set up these styles once in the ResourceBundle and be used over the entire application html.text.styleClass=text_input html.text.errorStyleClass=red_text_input * It allows you to group errors (a single error for 'SSN' can make the 'SSN:' label bold and highlight all three text inputs). * The label tag wraps whatever specific label you want to use, whether it is a message from the ResourceBundle or just plain HTML. It does not handle pre-marking required fields--however I don't think any output should be hard-coded into Struts, where a modification of the tag (see above) to a more general one would do the trick and be a good addition. I feel this offers the kind of flexibility and extensibilty that I think Struts needs. Please check out this enhancement at http://issues.apache.org/bugzilla/show_bug.cgi?id=20784 Thanks, Jonathan -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 10:41 PM To: Struts Developers List Subject: Re: A Custom tag using and validation ... > Even if its not added to Struts (and there is a reason not to - it > relies on naming conventions FormName.fieldName - which seem reasonable > > to me, but aren't mandated by Struts), its all yours to use. It makes > sense to put it in some kind of sandbox or "goodies"/contrib area of > the Struts codebase though. Erik, I really like the idea of the tag and I've added my suggestions for improvement to the bug report. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18015 > > > Also, just a query, Does your tag extend MessageTag ? > > Is it a good idea to do that ? > > > > No, it doesn't. See here: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/struts/ > struts-resume/src/web/org/appfuse/webapp/taglib/ > LabelTag.java?rev=HEAD&content-type=text/plain > > I personally do not find it worthwhile to extends Struts tags. They > are not designed as I would have designed them (subclassses not > exposing some parent class attributes in the TLD is *bad* IMHO) and the > attributes on the MessageTag are not needed for my label tag. All I > need is key, nothing else. I made some effort recently to refactor the tags into more appropriate chunks. While they're still not great for subclassing, they have improved. David > > Erik > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - 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]
A Question about Patches
I have a question about a patch I submitted, http://issues.apache.org/bugzilla/show_bug.cgi?id=20784 A quick summary for anyone who may have missed it: The enhancement provides lots of new functionality for error handling beyond writing out the errors. (Developers could use it to highlight errored inputs, create errors on a group of input elements, have their labels turn bold and red, and lots more... It is flexible and allows developers to set up these styles to whatever is suitable for their application, or leave them out completely. It is completely backwards compatible. I have received several positive replies from people both on the list and in private emails. I would like to know if there is anything I can do next. I apologize as I am new to collaboration in an open source environment. I do not want to push too hard, nor do I want to let this enhancement slip through the cracks. So if there is anything I can do to promote this enhancement/refine it/answer questions about it, I would love to do so. I think it would be a really great addition to Struts. Thanks for any help/insight, Jonathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
A question about file diffs...
I am trying to prepare patch files for the dynamic style declaration using
the resource bundle. I am using WinCvs and am having two different problems
with the diff reports it churns out...
1) The first is that it says there are changes to code I havent touched.
Example: cvs diff u BaseHandlerTag.java
@@ -881,9 +1019,9 @@
}
/**
- * Searches all scopes for the bean and calls BeanUtils.getProperty()
with the
+ * Searches all scopes for the bean and calls BeanUtils.getProperty()
with the
* given arguments and converts any exceptions into JspException.
- *
+ *
* @param beanName The name of the object to get the property from.
* @param property The name of the property to get.
* @return The value of the property.
I can fix most of these by adding i w, but the example on the jakarta site
says just a u is preferred.
http://jakarta.apache.org/site/source.html#Patches
-
2) The second problem is it picks up the wrong changes, this seems to happen
99% of the time with javadoc function headers.
Example: cvs diff u BaseInputTag.java
@@ -150,26 +145,6 @@
}
/**
- * Return the property name.
- */
-public String getProperty() {
-
-return (this.property);
-
-}
-
-/**
- * Set the property name.
- *
- * @param property The new property name
- */
-public void setProperty(String property) {
-
-this.property = property;
-
-}
-
-/**
* Return the number of rows for this field.
*/
public String getRows() {
If you took out all the code with - it would still be correct. But its
not the *correct* list of changes that were made.
-
This all leads to my question of what exactly are done with the diff
reports? If they are just read by developers trying to understand the
proposed changes, I think I would want to tinker a bit to make the report as
accurate as possible to the changes being made. If they are actually used in
a script to actually *make* the changes down the road, I need to not touch
the report.
Thanks for any insight,
Jonathan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Introduction and a proprosal to add new functionality to Struts: Automatic highlighting of errored form elements
I took my enhancement a step farther today and set it up to work with the ResourceBundle. With this new implementation it is possible to set the default styles you want to use once for the entire application. With this new implementation, you can set the styles to use in one place. Before, you would have to either 1)extend the tag library or 2)put the style attributes in each and every tag. I set it up so you can set default values to use for the following tags: checkbox, label(new), multibox, password, radio, select, text, & textarea The default values you can set are: style, styleClass, styleId, errorStyle, errorStyleClass, errorStyleId Example: = ApplicationResources.properties = errors.header=Errors Start: ... ... LabelTag.errorStyleClass=invalid_label LabelTag.styleClass=valid_label ... TextTag.errorStyleClass=invalid TextTag.styleClass=valid ... ... = test.jsp = Name: = output (if there IS an error on the name) = Name: = output (if there IS NOT an error on the name) = Name: If you set your own style attributes they would override the defaults set in the resource bundle: Name: I have the code working, but I wasn't sure if I was suppose to update the current enhancement ticket or close it and create a new one... -Jonathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Introduction and a proprosal to add new functionality to Struts: Automatic highlighting of errored form elements
Yes, that is part of the modifications I am proprosing.
The way I have set it up to work currently involves the creation of a new
LabelTag that would be used the following way.
(if the users extended the LabelTag and set up default values)
public class LabelTag extends the.struts.LabelTag {
public LabelTag() {
super();
super.setStyleClass(Constants.NORMAL);
super.setErrorStyleClass(Constants.ERROR);
...
}
Then it would be dumbed down to: (where input is the extended tag library)
I chose to keep presentation out of the bean library for two reasons:
* MessageTag currently does not specify any type of style, and I thought it
would be cleaner to keep it that way.
* By wrapping whatever they want with the new LabelTag, developers are not
locked in to using the MessageTag to get formatted messages.
-Jonathan
-Original Message-
From: Jeff Robertson [mailto:[EMAIL PROTECTED]
Sent: Monday, June 09, 2003 8:30 AM
To: 'Struts Developers List'
Subject: RE: Introduction and a proprosal to add new functionality to
Struts: Automatic highlighting of errored form elements
> -Original Message-
>
> A quick note, when I wrote 'automatic highlighting of errored form
> elements': it is only automatic if a style has been defined to use.
> Example:
> < html:text property="name" styleClass="valid"
> errorStyleClass="invalid" ...
> where 'valid' is the css style class to use normally and
> 'invalid' would be
> used if there was an error.
> if no errorStyleClass was defined, there would be no highlighting.
>
Do you also have an alternate style for the input's label text?
For instance, a form often looks like this:
If the "address" property fails validation, then one would normally expect
that the bean message (which probably just displays the word "Enter you
Address Here" or something) would be highlighted as well.
-
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: Introduction and a proprosal to add new functionality to Struts: Automatichighlighting of errored form elements
Thanks, I did not see anything in Bugzilla having to do with styles and validation errors, but it wasn't an exhaustive look and there is a lot to look through. I was going to submit the enhancement ticket but I did not see a way to attach any of the patch files to it. (I see the attach link on existing bugs, but not on the generate screen.) Am I supposed to create the ticket first and then come back and add the patch files? I am leaving town for the weekend so I will not be able to get back to this until Sunday evening, but if anyone wants a preview of what will be in the Bugzilla ticket, I put a link to the files below. When I do come back, I need to create new diff reports (I had originally done them in PVCS) and submit the ticket. Documentation + struts.jar http://64.70.191.174/scm/struts/jrd_struts_html_mod.zip 690k Documentation http://64.70.191.174/scm/struts/jrd_struts_html_mod_no_jar.zip 250k Thanks again, it's really exciting to be a part of this process, Jonathan -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 4:52 PM To: [EMAIL PROTECTED] Subject: RE: Introduction and a proprosal to add new functionality to Struts: Automatichighlighting of errored form elements This sounds interesting. You could create an enhancement ticket and attach patch files to it for us to review. I seem to remember this topic coming up before so you should search bugzilla and the list archives for relevant posts (we shouldn't offend anyone that already created a patch for this). David >I am very open to suggestions, but I do feel this change is a better fit >incorporated into the tag library as opposed to standing on top of it. >Inclusion requires signifcantly less code since contol of styles is >localized to the BaseHandlerTag. Extending the tags is a lot more code >(the >same code has to be repeated in each input-type tag) and more complex >(styles must be set over and over as attributes are set, rather than making >one adjustment after everything has been set. This is further complicated >due to not having control on the order that attributes get set.) > >A quick note, when I wrote 'automatic highlighting of errored form >elements': it is only automatic if a style has been defined to use. >Example: >< html:text property="name" styleClass="valid" errorStyleClass="invalid" >... >where 'valid' is the css style class to use normally and 'invalid' would be >used if there was an error. >if no errorStyleClass was defined, there would be no highlighting. > >-Jonathan > > >-Original Message- >From: James Mitchell [mailto:[EMAIL PROTECTED] >Sent: Friday, June 06, 2003 4:14 PM >To: Struts Developers List >Subject: Re: Introduction and a proprosal to add new functionality to >Struts: Automatic highlighting of errored form elements > > >Sounds like a nice 3rd party library. Are you open to suggestions? I have >a few ideas about this myself. > > >-- >James Mitchell >Software Developer/Struts Evangelist >http://www.struts-atlanta.org >770-822-3359 >AIM:jmitchtx > > >- Original Message - >From: "DeRose Jonathan" <[EMAIL PROTECTED]> >To: "Struts Developers List" <[EMAIL PROTECTED]> >Sent: Friday, June 06, 2003 4:05 PM >Subject: Introduction and a proprosal to add new functionality to Struts: >Automatic highlighting of errored form elements > > > > Hello, > > > > I have an idea that I would like to propose to the Struts community > > involving the HTML tag library; automatic highlighting of errored form > > elements. I have used Struts for a couple medium sized projects and >always > > extended the tags to get this functionality. After doing this two or >three > > times, I thought it would be great if Struts has this functionality >built > > in. > > > > I have gone through all the source and feel confident about the >changes > > that would need to be made. I have prepared documentation describing >all >of > > the details, but I wanted to post this first to introduce myself and my > > idea. If you guys would like to hear more, I would love to post my > > documentation for everyone to look at. > > > > Thanks, > > Jonathan R. DeRose > > > > > > > > - > > 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: Introduction and a proprosal to add new functionality to Struts: Automatic highlighting of errored form elements
I am very open to suggestions, but I do feel this change is a better fit incorporated into the tag library as opposed to standing on top of it. Inclusion requires signifcantly less code since contol of styles is localized to the BaseHandlerTag. Extending the tags is a lot more code (the same code has to be repeated in each input-type tag) and more complex (styles must be set over and over as attributes are set, rather than making one adjustment after everything has been set. This is further complicated due to not having control on the order that attributes get set.) A quick note, when I wrote 'automatic highlighting of errored form elements': it is only automatic if a style has been defined to use. Example: < html:text property="name" styleClass="valid" errorStyleClass="invalid" ... where 'valid' is the css style class to use normally and 'invalid' would be used if there was an error. if no errorStyleClass was defined, there would be no highlighting. -Jonathan -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 4:14 PM To: Struts Developers List Subject: Re: Introduction and a proprosal to add new functionality to Struts: Automatic highlighting of errored form elements Sounds like a nice 3rd party library. Are you open to suggestions? I have a few ideas about this myself. -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - Original Message - From: "DeRose Jonathan" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Friday, June 06, 2003 4:05 PM Subject: Introduction and a proprosal to add new functionality to Struts: Automatic highlighting of errored form elements > Hello, > > I have an idea that I would like to propose to the Struts community > involving the HTML tag library; automatic highlighting of errored form > elements. I have used Struts for a couple medium sized projects and always > extended the tags to get this functionality. After doing this two or three > times, I thought it would be great if Struts has this functionality built > in. > > I have gone through all the source and feel confident about the changes > that would need to be made. I have prepared documentation describing all of > the details, but I wanted to post this first to introduce myself and my > idea. If you guys would like to hear more, I would love to post my > documentation for everyone to look at. > > Thanks, > Jonathan R. DeRose > > > > - > 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]
Introduction and a proprosal to add new functionality to Struts: Automatic highlighting of errored form elements
Hello, I have an idea that I would like to propose to the Struts community involving the HTML tag library; automatic highlighting of errored form elements. I have used Struts for a couple medium sized projects and always extended the tags to get this functionality. After doing this two or three times, I thought it would be great if Struts has this functionality built in. I have gone through all the source and feel confident about the changes that would need to be made. I have prepared documentation describing all of the details, but I wanted to post this first to introduce myself and my idea. If you guys would like to hear more, I would love to post my documentation for everyone to look at. Thanks, Jonathan R. DeRose - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Javascript and input text box in a form
If you could spare me a moment: I have tried to work on this and the
javascript just won't address the right text input box.
So:
how do I emulate the following html and javascript with struts HTML tags?
Here is the script:
/// Airport City codes, for this SearchFares page ///
var airportListForm = "";
var airportListBox = "";
function openCityCodes(tbForm, tbBox) {
self.airportListForm = tbForm;
self.airportListBox = tbBox;
window.open('<%=request.getContextPath()%>/city_popper.html','CityCodes','wi
dth=400,height=415,resizable=yes');
}
function setAirportValue(airportCode) {
var box = eval("document." + airportListForm + "." +
airportListBox);
box.value = airportCode;
}
Here is working HTML code with the Javascript:
etc...
So the form is mainform and the text input name is departCity. This works.
Here is NON functional struts code: the error is
'document.bookingForm.bookingBean.departureCityCode' is null or not an
object. The form bean for /pnr/add/booking is bookingForm so this is the
name of the form. I am sure of that. But the name of the text box doesn't
work apparently:
Create Booking
Departure City Code:
etc
--
To unsubscribe, e-mail:
For additional commands, e-mail:
Re: Are form tags tied to beans?!!!
Actually, its not a struts-user question because the current design of form tags does not allow for dynamic attribute values, and this is the heart of the issue First consider that I get a collection of bean/value-objects from deep within the framework. Then consider that I want to loop through them and generate a form for each with a hidden field whos "value" attribute is the current index. I have no way (except for scriptlets) to get the current index into the "value" attribute. - Original Message - From: "Martin Cooper" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Jonathan" <[EMAIL PROTECTED]> Sent: Tuesday, July 31, 2001 2:28 AM Subject: Re: Are form tags tied to beans?!!! > Jonathan, > > First of all, this is really a struts-user question, rather than one for > developers... > > If there are fields you need to submit, but you don't want corresponding > values in the bean, then don't create bean properties for those fields. It's > as simple as that. > > There is no forced association between requests and beans. You can ignore > form beans if you want, and query the request directly for parameters. > > -- > Martin Cooper > > > - Original Message - > From: "Jonathan" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, July 30, 2001 2:32 PM > Subject: Are form tags tied to beans?!!! > > > I need to dynamically fill a form with values. The problem is that > and other form tags REQUIRE the attribute "property". > However, there may be fields that I submit that I DONT want to be values > in the bean. For example, I may want to add a hidden field that is NOT > a value in the bean, but merely a "flag" in the request. How is this > done in a clean way, considering that the form tags all require > "property" as an attribute, and that value must be a member value in a > bean? > > >
Re: Are form tags tied to beans?!!!
Yes I know, but I want some of the attributes to be dynamic - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, July 30, 2001 8:56 PM Subject: Re: Are form tags tied to beans?!!! > You can mix and match the html:form tags with the standard HTML form > tags. So, just code > The html:form tags are a handy way to prepopulate the HTML form elements > from a bean. But they are only a means to an end. If you don't need to > prepopulate the field, then you don't need to use a html:form tag. > > If for any reason you wanted to pass a "flag" bean to your form, to set > that dynamically, you could also pass a second form ActionForm bean. The > default is to use the bean tied to the Action path, but you can also > overide that on a tag by tag basis. > > > Jonathan wrote: > > > > I need to dynamically fill a form with values. The problem is that > > and other form tags REQUIRE the attribute "property". > > However, there may be fields that I submit that I DONT want to be > > values in the bean. For example, I may want to add a hidden field > > that is NOT a value in the bean, but merely a "flag" in the request. > > How is this done in a clean way, considering that the form tags all > > require "property" as an attribute, and that value must be a member > > value in a bean? >
Are form tags tied to beans?!!!
I need to dynamically fill a form with values. The problem is that and other form tags REQUIRE the attribute "property". However, there may be fields that I submit that I DONT want to be values in the bean. For example, I may want to add a hidden field that is NOT a value in the bean, but merely a "flag" in the request. How is this done in a clean way, considering that the form tags all require "property" as an attribute, and that value must be a member value in a bean?
The naming of attributes is confusing
Hello all. As I get deeper into using struts I am noticing how the naming of attributes seems needlessly vague. In the struts-config.xml for example. When marking up an action, why is the attribute name for the form bean called "name" instead of "beanName", and why is "validate" used instead of "validateBean". It seems unnecessarily ambiguous as to whether we are describing the action or the bean. This ambiguity continues in logic iterate tags and other tags as well. As a consequence, a user is not exactly sure to which object or concept an attribute pertains to. Does anyone know why Struts was desiged like this and continues to exist as such? Besides, xml was desiged to be descriptive. Why are we being vague?
Re: revised Diagrams
Is this clearer? - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] ; Jonathan Asbell Sent: Wednesday, July 11, 2001 10:54 AM Subject: Re: revised Diagrams Jonathan,Just a couple of suggestions:- in struts_function.gif, I think the flow is a little confusing. Attention isdrawn along the "Listening for requests..." up to the ActionServlet and toActions - but then where?! Not sure people (beginners, for sure) will see howone gets to the destination.jsp. Maybe an arrow to it would help? Alsoconfusing to have charts.jsp on lhs, and no destination for it on rhs. Howabout adding Request: www.mysite.com/destination.jsp to lhs too, and this endsup directly at destination.jsp on rhs (not sure what you'd do with charts.jsp -does it need to be there at all in this case?).- in ActionServlet.gif, can you move the top comment "Mappings, ActionForms andActions..." to the rhs of the ActionServlet - that was the flow of arrows on lhsis much clearer.Just my 2p worth,Cheers,DavePS Hope you had a good vacation!"Jonathan Asbell" <[EMAIL PROTECTED]> on 07/10/200109:28:01 PMPlease respond to [EMAIL PROTECTED]; Please respond to "Jonathan Asbell" <[EMAIL PROTECTED]>To: [EMAIL PROTECTED]cc: (bcc: David Hay/Lex/Lexmark)Subject: revised DiagramsTed and company:I read your suggestions and tried my best to include your changes withoutclouding its simplicity. In fact, it may seem more complicated now. Where Ifelt that it was getting too complicated I digressed from certain details whichI felt were better left to reading the user manual and "brochure". I didnt wanttoo much detail in these diagrams, but rather just a good feel for theframework. struts_function.gif
Re: requirements for path triggering actions
QUESTION - Jonathan Can someone tell me if there is a way to configure an action to match a path regardless of how deep it is in a directory? ANSWER - Ted No. There is not a way to do this, without changing the way Struts is programmed to behave. You could request a feature change in Bugzilla, and bring it up on the DEV list for discussion. == As I was experimenting with our struts app I ran into the situation where I wanted a generic "path-indifferent" name to trigger an action. For instance, in the following three cases: "/charts/display.do" "/news/display.do "/events/outdoors/display.do" I didnt care about anything except the existence of "display.do" ANYWHERE at the end of ANY path. In fact, isnt this exactly how the servlet is triggered with ".do" This is what I expected, and the current Struts design wont let me do this. Do you all think this is an important feature? I really would like it as it can give a sense that the behaviour is common, and saves me time in thinking about how to properly trigger that particular action I was wanting. > > Jonathan Asbell wrote: > > > > I think you may have misunderstood the problem. ".do" IS triggered, but the > > Struts mapping object registered under the "path" may not be found. In > > other words consider: > > > > "/charts/display.do" > > "/news/display.do > > "/events/outdoors/display.do" > > > > I want ANY occurence of "display.do" in the path to trigger a particular > > mapping > > > > - Original Message - > > From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]>; "Jonathan" <[EMAIL PROTECTED]> > > Sent: Wednesday, July 18, 2001 1:29 AM > > Subject: Re: requirements for path triggering actions > > > > > > > > > > > On Mon, 9 Jul 2001, Jonathan wrote: > > > > > > > Can someone tell me if there is a way to configure an action to match > > > > a path regardless of how deep it is in a directory? That is, I want > > > > "/display.do" to be triggered in each case below: > > > > > > > > "/charts/display.do" > > > > "/news/display.do > > > > "/events/outdoors/display.do" > > > > > > > > How can I accomplish this? > > > > > > > > > > The Servlet 2.2 (or 2.3) spec defines all the legal forms of > > > patterns, and can be downloaded at: > > > > > > http://java.sun.com/products/servlet/download.html > > > > > > For your purposes, you will find that the "*.do" pattern does indeed match > > > all of the above. The corresponding action paths should be > > > "/charts/display", "/news/display", and "/events/outdoors/display". > > > > > > Craig McClanahan > > > > > > > > > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ >
documentation - GOING ON VACATION
I will follow up with all of you about the documentation when I return in a few weeks.
Re: ActionMapping Workflows
Why not try enforcing some kind of composition. For instance, a workflow might have 5 steps. Separate the components themselves from the order in which they must be carried out. That is, if you must do 5 steps, then one "WorkflowObject" will be composed of 5 "StepObject" s. Upon completion of each step you will add the current step that you have completed to the WorkflowObject and then tell the WorkflowObject to check to see if all five steps have been added. If not, then send them to the next step. I think this is nothing new, as Actions, ActionMappings, and ActionForms kind of behave like this in a form wizard situation. However, maybe we can leverage the same objects by making "WorkflowObject" and "StepObject" interfaces, and make some of our homemade struts components implement these interfaces. - Original Message - From: "David Winterfeldt" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 10, 2001 4:04 PM Subject: Re: ActionMapping Workflows > What your thinking of may already do this, but I > thought I would mention this in case it didn't. If > you end up contructing a workflow using the actions, > it would be nice if it could be defined as a linked > list (or at least kept track of the last action). So > you wouldn't just go forward, but could be go back a > step too. This would be nice for multi-page forms > with a 'next' and 'previous' link so the JSP page > wouldn't have the links hardcoded. > > David > > --- Ted Husted <[EMAIL PROTECTED]> wrote: > > Something I have found generally useful is a > > "Resource Cache". This is > > just a hashtable in the session where I can > > (judiciously) tuck objects > > for future reference. In the case of a multiform > > workflow, each of the > > subforms could be saved to the cache, and then > > recalled as needed along > > the way. > > > > Of course, you could do the same with the session > > alone, but some > > containers get testy if you put too many objects in > > the session, and > > this also gives you the opportunity to do some > > oversight management in > > terms of how much gets cached. > > > > I first started to use this in relation to a > > "foreign key" strategy for > > my ActionForms, where they automatically cache the > > value of a property > > that another table may use as a foreign key. New > > forms then check the > > cache to pre-populate their own foreign keys. > > > > I also have a strategy where a form can be saved to > > the cache (using a > > special submit button) to be completed later. If the > > actor visits > > another form that is related to the first, when they > > return to the first > > form, the relation (foreign key) is automatically > > inserted. > > > > This would work even better in an EJB, where > > sessions can be > > automatically saved, or under 2.3 where we can have > > session listeners > > that could serialize the cache before the session > > expires. > > > > This could also be a good place to tuck a workflow > > stack, should one be > > needed. > > > > "Robbin L. Gratz" wrote: > > > > > > Another point that I believe is getting ignored on > > the workflow stuff is how > > > is data getting transferred between the different > > steps. In the system I > > > just worked on, we had a number of two or more > > step workflows that were used > > > within other larger workflows. The output from > > these "sub workflows" needed > > > to be captured along the way to accomplish the > > parent workflow. My thought > > > was to have a controlling action whose associated > > data/form object stores > > > the data retrieved from the various steps of a > > workflow, whether these steps > > > were individual actions or another workflow > > process. Any thoughts from > > > anyone or has someone solved this issue more > elegantly? > > > __ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ >
Re: ActionMapping Workflows
Can I ask how you all are thinking about bouncing around between steps in the workflow? Is it a stack that each step gets popped off? Arent workflow steps cyclical sometimes? Developers talk alot about graphing workflows but I have not read about the implementation. - Original Message - From: "Matthias Bauer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 10, 2001 9:12 AM Subject: Re: ActionMapping Workflows > Ok, that's fine with me and it makes pretty much sense. However, this will not > be enough to implement workflow completely. It is just a little step toward > workflow control as a whole, just the same as the simple workflow extension I > already proposed together with some code on this list. > > I think all this should be put together to come up with a reasonable concept how > to implement workflow, instead of multiple single efforts to implement some > single aspects only. > > Is there a team working on that? > > --- Matthias > > > > Ted Husted wrote: > > > I suppose storing the information in the session would work. Though, I > > imagine this means the state value would be hardcoded into the Java > > source. I'm working toward scripting workflows from within the > > ActionMappings, and would like to be able to reroute the flow without > > changing the Java source. > > > > The insert/update flow is one example. Another would be inserting one > > record and stopping, or inserting one record type and then another type > > (and another type). Like say, creating a new vendor account, and then a > > contact record for the account, and then a new stock item for the > > account. With a dynamic action path, you can script something like this > > from the ActionMappings alone, without modifying the JSPs or Java > > source. > > > > I'm also now thinking that, given a dynamic action path, the best place > > to represent it may be the ActionForward after all. This would change > > the struts-config in my last post to: > > > > > > >name="continue" > >path="/WEB-INF/pages/script/Form.jsp" > >request="true" > > actionPath="/script/Insert"/> > > > > > > which supports the idea of having an Action return various logical > > forwards, which could map to various forms, and being able to program > > where those forms submit back to, all from within the ActionMappings. > > > > Matthias Bauer wrote: > > > >>In the actions DisplayInsertAction or DisplayUpdateAction respectively, I store > >>a state value in session scope which is checked in ProcessAction and upon with I > >>decide whether to do an update or insert. > >> > >>With this pattern I do not really see the necessity to dynamically set the > >>action attribute in forms. > >> > >>Do I miss something? > >> > >>--- Matthias > >> > >>Ted Husted wrote: > >> > >> > >>>The general idea I'm playing with now is > >>> > >>>1) Extend ActionMappings with "request" and "actionPath" properties. > >>> > >>>2) Extend ActionServlet to place the ActionMapping in the request > >>>context if request=true. > >>> > >>>3) Extend html:form to check for ActionMapping.getActionPath() when the > >>>path is not specified. > >>> > >>>So in struts-config you could specify > >>> > >>>request="true" > >>>actionPath="/insertAction" > >>>parameter="insert" > >>> > >>>or > >>> > >>>request="true" > >>>actionPath="/updateAction" > >>>parameter="update" > >>> > >>>and have the appropriate path automagically appear in your html:form. > >>>The Action can then call getParameter() to determine whether it's > >>>suppose to insert or update the ActionForm data. Viola, no hidden > >>>fields! > >>> > > >
Re: *TED* - round 2 of documentation
ok
- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 10, 2001 6:14 AM
Subject: Re: *TED* - round 2 of documentation
> At some point someone proposes something in a final form that can be
> committed directly to the distribution.
>
> We're all volunteers here, and share suggestions about what we each
> would like, but what anyone actually does is up to the individual.
>
> Once something is done, and ready to ship, or at least test in a
> proposed final form, then we decide to commit it to the distribution.
>
> (At this point, the only document submitted is not in a final form,
> and so it's not possible to make a decision.)
>
> If you wanted to send me a Word document in a final form, I could
> convert it a PDF and make it publically available (if you agree that
> making this a PDF is a good idea).
>
> Jonathan Asbell wrote:
> > Ok so whats next?
> >
> > - Original Message -
> > From: "Ted Husted" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Sunday, July 08, 2001 10:30 AM
> > Subject: Re: *TED* - round 2 of documentation
> >
> > > We can hyperlink within a PDF. I was thinking it would be listed on
it's
> > > own above the Users Guide, so people would tend to read it first.
> > >
> > > Home
> > > Brochure (PDF)
> > > Users Guide
> > > Resources
> > > Who We Are
> > > Installation
> > > Release Notes (nightly)
> > > Release Notes (1.0)
> > > TODO list (1.1)
> > >
> > > But to keep the brochure non-technical, we should probably move the
> > > Struts Component overview into the Users Guide. Especially since you
> > > mentioned that this part wasn't helpful to your developers as part of
a
> > > quick start. ("Struts in a NY minute" ;-)
> > >
> > > I agree that the installation page should be refactored, but we might
to
> > > keep that separate from the brochure.
> > >
> > > As mentioned, I would especially like to see the installation
> > > instructions turned upside down, so that people are encouraged to
start
> > > with the WARs, Struts JAR, and the blank application before trying to
> > > build it from scratch. In practice, I'd say most people may write an
> > > application or three before needed to actually build Struts for
anything
> > > (if ever).
>
Re: *TED* - round 2 of documentation
Ok so whats next?
PS. see visual to be included in my explanation
- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 08, 2001 10:30 AM
Subject: Re: *TED* - round 2 of documentation
> We can hyperlink within a PDF. I was thinking it would be listed on it's
> own above the Users Guide, so people would tend to read it first.
>
> Home
> Brochure (PDF)
> Users Guide
> Resources
> Who We Are
> Installation
> Release Notes (nightly)
> Release Notes (1.0)
> TODO list (1.1)
>
> But to keep the brochure non-technical, we should probably move the
> Struts Component overview into the Users Guide. Especially since you
> mentioned that this part wasn't helpful to your developers as part of a
> quick start. ("Struts in a NY minute" ;-)
>
> I agree that the installation page should be refactored, but we might to
> keep that separate from the brochure.
>
> As mentioned, I would especially like to see the installation
> instructions turned upside down, so that people are encouraged to start
> with the WARs, Struts JAR, and the blank application before trying to
> build it from scratch. In practice, I'd say most people may write an
> application or three before needed to actually build Struts for anything
> (if ever).
>
> Jonathan Asbell wrote:
> >
> > One thing to think about is that it may be good to have links so a
reader
> > can jump around. I'm not sure if this can be done with PDF.
> >
> > Also, are you suggesting to make it downloadable AND part of the user
guide?
> > Thats fine if it can actually stand on its own without references to
other
> > parts of the user documentation.
> >
> > I still have to create some visuals for this stuff anyway. Also, I need
to
> > do an explanation of the "web.xml" and "struts-config.xml" file
contents,
> > and a very brief but clear, idot-proof, explanation of MVC and how it
fits
> > in struts. This way java develpers who are green behind the ears wont
run
> > away frustrated like they do with other packages and frameworks. The
whole
> > point is that we want EVERYONE to be able to use it and play with it.
With
> > that said, I think you just have to make sure that people can read this
> > basic information first
>
struts_function.gif
Re: *TED* - round 2 of documentation
One thing to think about is that it may be good to have links so a reader can jump around. I'm not sure if this can be done with PDF. Also, are you suggesting to make it downloadable AND part of the user guide? Thats fine if it can actually stand on its own without references to other parts of the user documentation. I still have to create some visuals for this stuff anyway. Also, I need to do an explanation of the "web.xml" and "struts-config.xml" file contents, and a very brief but clear, idot-proof, explanation of MVC and how it fits in struts. This way java develpers who are green behind the ears wont run away frustrated like they do with other packages and frameworks. The whole point is that we want EVERYONE to be able to use it and play with it. With that said, I think you just have to make sure that people can read this basic information first - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, July 08, 2001 9:54 AM Subject: Re: *TED* - round 2 of documentation > My vote would be to format this as an attractive Word document, convert > it to a PDF, and post it as the "Struts Brochure". Based on your > experience, we could move the Struts Component Overview into the User > Guide, leaving > > Struts aims to solve problems > > Literal explanation of Struts ... > > How it all works ... > > Activity Summary ... > > [ some diagram ] > > > -Ted. >
Re: About extensons support mechanism...
Craig could you explain a little more about " to *modify* what happens next? For example, let's say you wanted to implement "is the user logged on?" checking as an event listener. How would the listener indicate back to the framework that the request should be redirected to the logon page?.." I dont understand the problem completely - Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, July 07, 2001 9:09 PM Subject: Re: About extensons support mechanism... > > > On Sat, 7 Jul 2001, Martin Cooper wrote: > > > > Is what I describe above within the scope of the event/listener > > > todo for 1.1? I thought it might be, which is why I said > > > I was interested in tying the Extensions package into > > > the event/listener model work. > > > > I think this is a perfect candidate for the event/listener framework. The > > key is to decide what the interesting events are. This needs to be done > > outside the context of the current implementation as much as possible. > > > > I think the two concepts are related as well. "Extensions" would be a > perfectly natural way to configure your listeners. > > > What I mean by that is that we should not be looking at the code and saying > > "oh, there's an interesting method I'd like to hook into" so much as > > thinking "ah, it would be interesting to be told when this is about to > > happen or that has finished happening". If the code ends up needing some > > restructuring to accommodate that, then we should go ahead and make those > > changes. > > > > If we only look at the current implementation, then we will be looking with > > blinders on. There is a much greater risk that we will hinder the > > development of later extensions, by looking at what we have instead of > > thinking about what we really want. > > > > Another issue (and, frankly, the reason that I didn't include an > event/listener model earlier) is more complex -- what if a listener wants > to *modify* what happens next? For example, let's say you wanted to > implement "is the user logged on?" checking as an event listener. How > would the listener indicate back to the framework that the request should > be redirected to the logon page? > > One fairly radical idea I've considered is to not use events for this > purpose, but to treat the basic processing that the controller servlet > itself does as a workflow that can be scripted. That way, you could (in > effect) insert your own "processXxxx" type functions anyplace you like in > the standard workflow. Presumably, the scripting language for the > workflow would have mechanisms to support conditional processing to deal > with my question above. > > Given that, an event/listener model that merely notifies application logic > about things that are happening is still useful -- it's just not going to > be called on to serve this purpose. > > > -- > > Martin Cooper > > > > Craig >
Re: Struts 1.1 To-Do - RowSets
Why dont you wrap rowsets like you do with Multipart Request. ?? - Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, July 07, 2001 5:30 PM Subject: Re: Struts 1.1 To-Do - RowSets > > > On Sat, 7 Jul 2001, Ted Husted wrote: > > > "JDBC RowSet Support. Update all of the relevant tags to get and set > > attributes from a JDBC RowSet (or ResultSet) object ... " > > > > So, I'm itching to do something about this. I've been wrapping my > > RowSets up in iterators and conventional JB facades, but it's like way > > too much work. > > > > I'm just getting started so if anyone has any "whiteboard" notes they'd > > like to pass along, feel free. > > > > I've only got some thoughts that haven't ever made it into a document yet > ... > > The basic dream was that a page developer could use the and > friends type tags that they know and love, but the tag would be smart > enough to understand that a RowSet is treated like an array of JavaBeans, > with the columns being the properties. In an ideal world, the Action > could start out passing the RowSet, but change to an encapsulating > JavaBean, without the pages accessing this data needing to be changed. > > Conceptually, this can be accomplished in (at least) two different ways: > > * Extend BeanUtils/ConvertUtils/PropertyUtils to do the conversions > as necessary. Advantage: useful elsewhere besides in Struts-based > JSP pages. Disadvantage: makes a RowSet a "special case", so BeanUtils > and friends don't really treat all objects the same (the way that > they do now). > > NOTE: if you decide to go this way, I'd prefer that the work be > done on the commons version of these classes. I want to migrate > Struts 1.1 to these (as soon as I go create releases over there). > > * Extend all the appropriate tags (and include functionality in any > future tags) to do an appropriate "if this is a RowSet, do this; > otherwise use PropertyUtils as before" logic. Advantage: keeps > BeanUtils et. al. logically pure and simple. Disadvantage: there > are *lots* of tags that want this (although maybe we can abstract > it into RowSetUtils type functionality so it's pretty easy). > > An important consideration if you use real ResultSets is in how to ensure > that the ResultSet (and the corresponding Statement) are closed, and the > underlying connection returned to the connection pool. It might be best > to mandate the use of RowSet instead, so that we can use the > "detached" RowSet implementation. That way, the Action would copy the > data into the RowSet, and release the database resources, before > forwarding to the page. (Note to self -- check the redistribution terms > on the Sun CachedRowSet implementation). > > One more thing to think about at design time - even though it is not very > Model 2-ish, some folks are going to want to use things like the > "dbtags" library in jakarta-taglibs to encode their SQL queries inside > the page. It's worth at least a few minutes of thought to see if we can > cleanly interoperate with those sorts of mechanisms. > > > The original TODO included XML DOMs, but I thought I would start with > > ResultSet/RowSets. > > > > Makes sense. > > An additional complicating factor -- the JSP standard tag library is > likely to make an early access version of their reference implementation > available "real soon now", under the jakarta-taglibs project. I know that > accessing RowSets in a manner similar to this has been discussed -- we > might want to see if the problem has been solved already there before > investing lots of effort building it into the Struts tags. > > > -Ted. > > > > Craig > >
Re: *TED* - round 2 of documentation
I just wanted to keep the document in laymans terms as possible. Less experienced developers should be able to set up and use struts without getting lost in jargon and tech-talk. We just want them to participate because that increases Strut's user base and thus development effort. We should add MVC to this information somehow. However, for readers who are not experienced with oo patterns or architectures, such information can leave the individual feeling overwhelmed with information. I can do a piece on MVC which can tie in Craig's documentation with the documentation I previosly submitted. What would you like to do Craig? - Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Jonathan" <[EMAIL PROTECTED]> Sent: Saturday, July 07, 2001 4:50 PM Subject: Re: *TED* - round 2 of documentation > > > On Fri, 6 Jul 2001, Jonathan wrote: > > > Absolutely not. The user guide was really well written this time around. > > Kudos to Craig and others who wrote it. I think it should be one of the > > first things you read about Struts because it gets you there quick. I think > > it belongs somewhere with the user guide =) > > > > Perhaps this might be a "Welcome To Struts" or "What Is Struts" document > that someone would read *before* reading the user guide? As someone else > mentioned, maybe we could think of it as a "Product Data Sheet" type > document. > > If so, I think it needs to include at least something like the "MVC > Architecture" picture to visually clue people how the pieces fit together. > > Craig > > > > > > - Original Message - > > From: "Ted Husted" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Friday, July 06, 2001 8:51 AM > > Subject: Re: *TED* - round 2 of documentation > > > > > > > I don't disagree Jonathan. I'm just asking for suggestions as to where > > > we should place it in the context of the rest of the documentation. > > > Should it be part of the User Guide or something else? If something > > > else, what do we call it? > > > > > > Unless of course you're proposing that we drop the rest of the User > > > Guide and just offer this ;-0 > > > > > > Jonathan Asbell wrote: > > > > > > > > Hello Ted. I gave this documentation to the other developers in my > > group > > > > who do not know about Struts, and they said that they now understand > > what > > > > Struts is and how to approach using it. They got lost in the "Struts > > > > Components" section because they didnt have a picture to accompany the > > > > explanation, and because they were unfamiliar with Struts. They said > > that > > > > the section "How it all works" clarified how Struts behaves. > > > > The point being that the impedance from trying new tools lies in the > > > > time necessary to understand and configure it. Living in New York is > > great > > > > because it is the ultimate test for when something is too complicated: > > > > People wont take the time to use it. This type of outline gets would be > > > > users/developers started quick. In a few pages they know what Struts > > is, > > > > what it needs to run, and how it functions. Now they can go on, > > install, > > > > configure and develop with Struts with the user guide and this paper in > > hand > > > > and feel fairly confident in developing with it. > > > > > > > >
question about processPath() line item in ActionServlet
Gentlemen. In the ActionServlet's
processPath() method the below code exists.
processPath(HttpServletRequest request)
{
...
...
if ((period >= 0) &&
(period > slash))path = path.substring(0, period);
...
}
Shouldnt the code instead read:
if ((period >= 0) &&
(period > slash))path = path.substring(slash,
period);
Re: *TED* - round 2 of documentation
Absolutely not. The user guide was really well written this time around. Kudos to Craig and others who wrote it. I think it should be one of the first things you read about Struts because it gets you there quick. I think it belongs somewhere with the user guide =) - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 06, 2001 8:51 AM Subject: Re: *TED* - round 2 of documentation > I don't disagree Jonathan. I'm just asking for suggestions as to where > we should place it in the context of the rest of the documentation. > Should it be part of the User Guide or something else? If something > else, what do we call it? > > Unless of course you're proposing that we drop the rest of the User > Guide and just offer this ;-0 > > Jonathan Asbell wrote: > > > > Hello Ted. I gave this documentation to the other developers in my group > > who do not know about Struts, and they said that they now understand what > > Struts is and how to approach using it. They got lost in the "Struts > > Components" section because they didnt have a picture to accompany the > > explanation, and because they were unfamiliar with Struts. They said that > > the section "How it all works" clarified how Struts behaves. > > The point being that the impedance from trying new tools lies in the > > time necessary to understand and configure it. Living in New York is great > > because it is the ultimate test for when something is too complicated: > > People wont take the time to use it. This type of outline gets would be > > users/developers started quick. In a few pages they know what Struts is, > > what it needs to run, and how it functions. Now they can go on, install, > > configure and develop with Struts with the user guide and this paper in hand > > and feel fairly confident in developing with it. >
Re: *TED* - round 2 of documentation
Hello Ted. I gave this documentation to the other developers in my group who do not know about Struts, and they said that they now understand what Struts is and how to approach using it. They got lost in the "Struts Components" section because they didnt have a picture to accompany the explanation, and because they were unfamiliar with Struts. They said that the section "How it all works" clarified how Struts behaves. The point being that the impedance from trying new tools lies in the time necessary to understand and configure it. Living in New York is great because it is the ultimate test for when something is too complicated: People wont take the time to use it. This type of outline gets would be users/developers started quick. In a few pages they know what Struts is, what it needs to run, and how it functions. Now they can go on, install, configure and develop with Struts with the user guide and this paper in hand and feel fairly confident in developing with it. - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 06, 2001 5:03 AM Subject: Re: *TED* - round 2 of documentation > I think the first two sections might make for a nice product sheet for > developers to pass along to the suits. Like a hand-out you might pickup > at a tradeshow. A PDF would be very cool here. (I have the distiller and > so can make those here.) > > I like the idea of a Struts Components section, but I'm not sure where > it would go. It seems like it should be placed early in the > documentation outline, but the current User Guide focusses on the MVC > architecture, which makes a Struts component overview a better fit at > the end, perhaps as Chapter 5. Dunno. > > Personally, I'd like to see our entire approach to installation turned > upside down, so that people are encouraged to download the WARs first > and install those. Then do some development using only the Struts.jar, > and, finally, (if you really, really have to ;-) build Struts from > scratch. > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ >
Re: New name for Components / Extended Templates?
Please just make the name something that makes sense. Something that implies its function. - Original Message - From: "Deadman, Hal" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 28, 2001 10:22 AM Subject: RE: New name for Components / Extended Templates? > I agree with Martin. I had thought of bricks too but I think blocks is > somewhat related to the struts theme and doesn't have the negative > conotations of bricks. > > People that are already using the existing components code can continue to > use it under it's current name. Changing the name inside struts will allow > the code to be cleaned up and names changed to be consistent with struts. > It will be valuable to allow changes in the struts version without worrying > about breaking existing code. > > Hal > > -Original Message- > From: Martin Cooper [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 27, 2001 3:33 PM > To: [EMAIL PROTECTED] > Subject: Re: New name for Components / Extended Templates? > > > I think it would be a good idea to change the name now. That will reflect > its incorporation as part of Struts, and I also agree with your reasons for > not using "components" or "templates". > > Some other suggestions might be "elements" (although this might have a > similar problem to "components"), "braces" (a play on the "struts" theme), > or "bricks". > > Of the names you suggested, my pick would be "blocks". The other two have > the same problems as you mentioned for "components" and "templates". > > -- > Martin Cooper > > > - Original Message - > From: "Cedric Dumoulin" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, June 27, 2001 9:49 AM > Subject: New name for Components / Extended Templates? > > > > > > Components / Extended Templates framework will be added to Struts > > shortly. > > > > It is now the last chance to rename this framework if necessary. > > > > Primary idea of the framework was to allow building of JSP pages by > > assembling reusable pieces of code, called blocks or components. One of > > the aims is to provide a library of easily reusable components (like > > standard layouts, but also reusable menus, common login form, shopping > > card, ...). > > Templating mechanism is naturally done with the framework, but > > framework can also provide a starting point for reusable components. > > > > So what's wrong with name "components" ? Component is a broad term in > > English, and it may be confusing when people talk about Struts > > components in general. So maybe we should change actual Components > > framework name. > > > > Why not renaming "Components" to "templates" ? Framework allow more > > than templating, If we call it "templates", I am afraid that people > > identify framework > > with only the template mechanism, missing the ability to define reusable > > piece of pages. Also, this would break the actual templates > > implementation. > > > > After discussions with Ted Husted, we propose following alternatives > > : > > > > Framework name package name > > JSP pieces / Extended Templates > >(as a play on Java Faces ;-) jsp-pieces or pieces > > JSP Blocks jsp-blocks or blocks > > Dynamic Templates templates > > > > My preference goes to (JSP pieces / Extended Templates), jsp-pieces. > > > > I need your opinion on this renaming : > > > >* Do we really need to do it ? (A lot of peoples already use > > components. This could lead to troubles) > >* Which name do you prefer / propose ? > > > > Cedric > > >
Re: server-side, java-based validation rules for struts..
I thought that the point was to NOT have to use a property editor, but rather an xml file - Original Message - From: "Nick Afshartous" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, June 25, 2001 9:24 AM Subject: RE: server-side, java-based validation rules for struts.. > > Cook, Levi writes: > > IMHO, expressing rules using first class Java objects *can* be just as > > flexible as defining rules in an XML file. > > > > The analog to changing a value in an XML file is using a property editor to > > change values stored in a JavaBean (thus avoiding recompiling). The upside > > of this approach is simpler integration with visual editors (simply > > implement a property editor for your form-bean). > > > Ultimately, I feel this is > > where your less technical people can begin to contribute more effectivly. > > The other route requires hand-rolling a visual editor for your XML scheme > > and/or having your users learn quite a bit about the intricacies of your > > schema. > > Thanks Levi for pointing out that a property editor could be used. > Could one also add new rules and attributes dynamically with a > property editor ? > > Maybe the trickiest part for the users would be to learn the > syntax for rule expressions. In particular how to refer > to object attributes within a rule. > -- > > Nick > > >
Re: Logic tags and string properties
why dont you just change it to "isEmpty" or "emptyString" which everyone knows already? =) - Original Message - From: "Martin Cooper" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 25, 2001 1:19 AM Subject: Re: Logic tags and string properties > Picking up on an old thread here (because I'd like to go ahead and fix the > problem :-) ). > > If we add an 'empty' attribute to and , > what should the allowed values be? > > One option which occurs to me is that "empty='true'" would mean that the > condition is true if the property is an empty string, while "empty='false'" > would mean that the condition is false if the property is an empty string. > To preserve the existing semantics of these tags when the attribute is not > specified, 'empty' would default to 'true' for and 'false' > for . > > Is this what you had in mind? > > -- > Martin Cooper > > > - Original Message - > From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, May 23, 2001 9:29 AM > Subject: Re: Logic tags and string properties > > > > > > > > On Wed, 23 May 2001, Martin Cooper wrote: > > > > > It seems that it is not possible to use the logic tags to test "is this > > > property either null or an empty string?". Using , I can > > > determine that some value is present, but as far as I can tell, there is > no > > > way to test for an empty string. Specifying value="" for tags such as > > > notEqual seems to result in a complaint that a required attribute has > not > > > been specified. (Is this correct, or is this a bug in Resin, the > container > > > I'm using?) > > > > > > > This is ultimately due to a restriction on the way that > > > > > > > > works, which I copied in the BeanUtils and PropertyUtils classes. As the > > properties are being copied, if the input value is a zero length string, > > it is *not* copied. > > > > Changing this behavior now would be very likely to break existing code, so > > I think we need to deal with it. But, your question is more general in > > scope because the input beans could come from the application as well. > > > > > So, I had a couple of ideas for solving this, and I'd like to hear what > > > people think. > > > > > > 1) Modify the present and notPresent tags such that the empty string is > > > equivalent to null for the purposes of this test, if in fact the > specified > > > property is a String. This might break things, though - I'm not sure. > > > > > > 2) Define two new logic tags - perhaps empty and notEmpty - which define > > > emptiness as a property being either null or the empty string. Unlike > > > present and notPresent, these tags would only work with the name and > > > property attributes (i.e. not cookie, parameter, etc), since the others > > > don't really make sense distinct from present and notPresent. > > > > > > The second option appeals to me more, because it seems somewhat cleaner > than > > > muddying the definition of presence to include type-specific values. > > > > > > > A third option would be to add an "empty" attribute to the > > and tags, which tells them how to treat empty > > strings. The default, of course, would be the current behavior. > > > > > > > Comments, anyone? > > > > > > -- > > > Martin Cooper > > > > > > > > > > > > > > > > Craig > > > > > >
Re: javax.servlet.UnavailableException: Input/output error reading configuration from resource path /WEB-INF/struts-config.xml
I am not using the Struts jar because I am working with the source. So that
is probablt why it is happening, but I fixed it with Zhao's excellent tip!
=)
However, I think it should be designed somehow to look locally for the dtd
in this case. I have seen alot of talk about this dtd issue in the last few
weeks which is an indicator that a clearer explanation and minor code tweak
are probably warranted. It is not clear what the deafualt is, what happens
with a struts.jar and without one, and where the dtd must reside. etc,etc.
- Original Message -
From: "Sukachevin, Stoehr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 22, 2001 6:30 AM
Subject: RE: javax.servlet.UnavailableException: Input/output error reading
configuration from resource path /WEB-INF/struts-config.xml
> But the XML parser that the Digester uses should be able to get the dtd
from
> struts.jar.
>
> Is struts.jar in your weblogic classpath or in your web app? I have no
> problems when struts.jar is in the weblogic classpath for v5.1 SP9. Not
> sure about when it is in a web app's lib directory, though.
>
> -- Stoehr
>
>
> -Original Message-
> From: zhaoj [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 21, 2001 11:55 PM
> To: [EMAIL PROTECTED]; Jonathan Asbell
> Subject: Re: javax.servlet.UnavailableException: Input/output error
reading
> configuration from resource path /WEB-INF/struts-config.xml
>
>
> This is a common problem when configuring struts on weblogic. Reason is
that
> the parser could not fetch the
> file(http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd) from the
> web.
> The easiest way is to alter the request to your local file.
> For example:
> FROM:
>"-//Apache Software Foundation//DTD Struts Configuration
1.0//EN"
> "http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd>
>
> TO:
>"-//Apache Software Foundation//DTD Struts Configuration
1.0//EN"
>
>
"file:///c:/bea/wlserver6.0/config/Wcom/applications/mydomain/WEB-INF/struts
> -config_1_0.dtd>
>
> -Zhao
>
> - Original Message -
> From: Jonathan Asbell
> To: [EMAIL PROTECTED]
> Sent: Friday, June 22, 2001 10:40 AM
> Subject: javax.servlet.UnavailableException: Input/output error reading
> configuration from resource path /WEB-INF/struts-config.xml
>
>
> Any one know why I am getting this Exception in Weblogic 6?
>
> I have gotten this Exception before, erased the tmp war files, and all was
> ok. Now erasing the tmp war doesnt help. It happens inside the Digester
in
> the below method, on the line "getParser().parse(input, this);"
> --
--
> --
> public Object parse(InputStream input) throws IOException, SAXException {
> getParser().parse(input, this);
> return (root);
> }
> --
--
> --
>
> I have verified that the input stream is not null and is in fact valid,
> pointing to the correct file "/WEB-INF/struts-config.xml". I have also
> verified that the Digester is not null and is valid.
>
> THIS IS THE
>
EXCEPTION---
> --
> resolveEntity('-//Apache Software Foundation//DTD Struts Configuration
> 1.0//EN', 'http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd')
> Not registered, use system identifier
> resolveEntity('-//Apache Software Foundation//DTD Struts Configuration
> 1.0//EN', 'http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd')
> Not registered, use system identifier
> javax.servlet.UnavailableException: Input/output error reading
configuration
> from resource path /WEB-INF/struts-config.xml
> at
> org.apache.struts.action.ActionServlet.init(ActionServlet.java:416)
> at javax.servlet.GenericServlet.init(GenericServlet.java:258)
>
Re: Struts 1.1 TODO List -- Event and Listener Model
That is what I was saying yesterday Levi, when I mentioned:
"One thing I may suggest is that maybe you dont need to be explicit with the
type of listeners, and just register listeners"
Since we dont know and really will never know what kind of listeners we will
need because it may be specific to an app, maybe the validators should just
take some kind of generic Listeners or Events interface, or both.
.
- Original Message -
From: "Levi Cook" <[EMAIL PROTECTED]>
To: "struts-dev" <[EMAIL PROTECTED]>
Sent: Friday, June 22, 2001 3:26 AM
Subject: Struts 1.1 TODO List -- Event and Listener Model
> I realize that the list of 1.1 Event Generators is semi-volatile until
> work-flow and validation fall into place. On the flip side, I think there
> might be a few "interesting" events we can identify now. For instance,
what
> do people think of the attached samples and models? What other events are
> people anticipating or hoping for?
>
> (forgive the mixed bag Javadoc/UML notation; ascii is rough :)
>
> java.util.EventObject
> |
> +-- org.apache.struts.action.ActionForm
> + addActionFormListener(ActionFormListener) : void
> + removeActionFormListener(ActionFormListener) : void
> - fireActionFormWasReset() : void
> - fireActionFormValidated() : void
>
> java.util.EventObject
> |
> +-- org.apache.struts.action.event.ActionFormEvent
> + ActionFormEvent(ActionForm source) <>
>
> java.util.EventListener;
> |
> +-- org.apache.struts.action.event.ActionFormListener <>
> + actionFormWasReset(ActionFormEvent) : void
> + actionFormValidated(ActionFormEvent) : void
>
>
> org.apache.struts.action.eventActionFormListener
> |
> +-- org.apache.struts.action.event.ActionFormAdaptor {
> + actionFormWasReset(ActionFormEvent) : void
> + actionFormValidated(ActionFormEvent) : void
>
>
> -- Levi
>
javax.servlet.UnavailableException: Input/output error reading configuration from resource path /WEB-INF/struts-config.xml
Any one know why I am getting this Exception in
Weblogic 6?
I have gotten this Exception before, erased the tmp
war files, and all was ok. Now erasing the tmp war doesnt help. It
happens inside the Digester in the below method, on the line
"getParser().parse(input, this);"
--
public Object parse(InputStream input) throws
IOException, SAXException { getParser().parse(input,
this); return (root);}
--
I have verified that the input stream is not null
and is in fact valid, pointing to the correct file
"/WEB-INF/struts-config.xml". I have also verified that the Digester is
not null and is valid.
THIS IS THE
EXCEPTION-
resolveEntity('-//Apache Software Foundation//DTD
Struts Configuration 1.0//EN',
'http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd') Not
registered, use system identifierresolveEntity('-//Apache Software
Foundation//DTD Struts Configuration 1.0//EN',
'http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd') Not
registered, use system identifierjavax.servlet.UnavailableException:
Input/output error reading configuration from resource path
/WEB-INF/struts-config.xml at
org.apache.struts.action.ActionServlet.init(ActionServlet.java:416)
at
javax.servlet.GenericServlet.init(GenericServlet.java:258)
Re: Opening up a thread on ALTERNATE SCOPES
Hello Paul. I didnt know anything about graphs. Thanks for explaining. So how do you make these graphs? How do you link things in this fashion. I am really interested. Any links you can send me about this? - Original Message - From: "Paul Speed" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 21, 2001 12:53 PM Subject: Re: Opening up a thread on ALTERNATE SCOPES > A graph is a data structure where nodes are linked together. One > node is linked to several other nodes and so on. A directed graph is > a graph where the links have a specific direction. A tree is a special > form of graph (usually directed) that only branches in one direction. > In other words, a child node will never link to something higher in > the tree. It only branches down. > > For workflow types of applications the nodes of a graph often represent > states in a workflow. The links between the nodes represent > transitions. Sometimes these transitions also have functionality > attached to them. It is often necessary to have circular workflows > or workflows that transition to another step outside of the normal > flow of the current "process". This makes a tree a poor data > structure to use since it cannot loop back on itself. > > Although, I now realize that since we aren't working from the same set > of definitions, I shouldn't have taken your "tree" reference to be so > specific. > > -Paul Speed > > Jonathan Asbell wrote: > > > > Can you describe what you mean by graph. Do you mean a HashMap or List? > > How do you "jump"? How do you go follow decisions and results? > > > > - Original Message - > > From: "Paul Speed" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, June 21, 2001 2:24 AM > > Subject: Re: Opening up a thread on ALTERNATE SCOPES > > > > > Just one small point... > > > > > > In all my (admittedly brief compared to some) travels through workflow > > > land, I've never had a workflow that was specifically tree. They all > > > end up forming a graph at some point. > > > > > > One could argue that you can just have jump points from one branch to > > > another, but in my experience, after many iterations the tree becomes > > > more of a hinderance than a boon as jump points become more frequent. > > > > > > It might be better to design it to be a graph structure from the > > > beginning. > > > > > > -Paul Speed > > > > > > Jonathan Asbell wrote: > > > > > > > > Since my needs are for web container persistence, let me make a > > suggestion > > > > in that area. > > > > An object called WorkflowPath could be created with configurable values > > > > sucked up from a file. The values could be some kind of tree, like a > > > > decision/process tree. The WorkflowPath object would be stored in > > > > application scope, or a custom scope as mentioned below in the original > > > > post, such as Sub-Application scope. When you begin a process you grab > > the > > > > WorkflowPath from the scope stored under a name like "loginWorkflow", > > and > > > > you would query it for the next step in the decision/process tree. It > > would > > > > be nice maybe to have a pointer as to where you are in the sequence of > > > > things. Anyone want to add to this? Anyone want to dis this? Are you > > all > > > > asleep on this warm New York Summer night? =) > > > > > > > > - Original Message - > > > > From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Wednesday, June 20, 2001 11:25 PM > > > > Subject: Re: Opening up a thread on ALTERNATE SCOPES > > > > > > > > > Jonathan Asbell wrote: > > > > > > > > > > > > Persistent storage is an option too. I was hoping, however to limit > > > > calls > > > > > > through the enterprise parts and database. > > > > > > > > > > Why? > > > > > > > > > > > You could argue that it belongs > > > > > > there because the database is the central location holding all data > > and > > > > > > information and therefore should hold workflow info, especially in > > the > > > > face > > > > > > of changing services/activities.
Re: server-side, java-based validation rules for struts..
So at some point you will gat a handle to the ActionForm (read "bean") and say: actionForm.addVetoableChangeListener(String propertyName,VetoableChangeListener listener) or actionForm.addVetoableChangeListener(VetoableChangeListener listener) or the third one which I dont totally understand. (please explain ;^> ) Also, please explain what the propertyName represents The best thing about this is that the associations between beans and their listeners is don all in one place (the xml file in our case). If you want to add listeners to a bean just add them to the file. One thing I may suggest is that maybe you dont need to be explicit with the type of listeners, and just register listeners. I 'm not sure, however, because I have not thought about the consequences of that yet. - Original Message - From: "Cook, Levi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 21, 2001 11:20 AM Subject: RE: server-side, java-based validation rules for struts.. > Yes, the end result is ActionForms with Listeners registered prior to the > ActionServlet populating our form with the users request values. > > Slightly more exact mechanics for registering the listeners are: > 1. Instantiate the form-bean > 2. Instantiate zero to many listeners > 3. Register each listener using one of following bean method naming > conventions: >addVetoableChangeListener(VetoableChangeListener listener) >addVetoableChangeListener(String propertyName, VetoableChangeListener > listener) >addVetoableChangeListener(VetoableChangeListener listener) > > A key abstraction here, is that neither object ever has an explicit > reference to the other. Said another way this provides loose coupling > between our action forms and their listeners. This supports the struts as a > framework concept by allowing the following: > > 1. The number (zero to many) of listeners may be unknown at compile-time, > and can vary throughout run-time. > > 2. Listener and form objects neet to be loosely coupled becuase we have no > way of predicting all the Listeners (eg. Validations) users could be > interested in. > > > Abstraction sure seems difficult to explain sometimes, thanks again for > helping me refine my explanation. > > Levi > > > > -Original Message- > > From: Jonathan [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 21, 2001 9:10 AM > > To: [EMAIL PROTECTED] > > Subject: Re: server-side, java-based validation rules for struts.. > > > > > > So you are saying that when an ActionForm is instantiated its > > associated listener(s) get shoved in (read "registered") via > > a set method on the ActionForm, and the Listener actually does > > the registering of itself in its constructor or something. > > > > So what you have is a bunch of ActionsForms with their > > listeners already registered. Did I get it? > > > > > > - Original Message - > > From: "Levi Cook" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, June 21, 2001 11:44 AM > > Subject: Re: server-side, java-based validation rules for struts.. > > > > > > > I guess that's the critical part, eh-- sorry for the hand-waving :) > > > > > > At this point, I see the Struts controller coordinating > > these "rules", > > based > > > on the contents of struts-config.xml: > > > 1. Instantiation of our form-bean as needed (no real > > change here). > > > 2. Instantiation of optional change-listeners* > > associated with our > > form. > > > (peek at the xml fragment below) > > > 3. Now, it can register the change-listener (aka > > > VetoableChangeListener), with our new form-bean. > > > note: addVetoableChangeListener > > > & removeVetoableChangeListener > > > adhere to a naming pattern established by the > > JavaBeans spec. > > > for more on this, see the last section on this page: > > > > > > > > > http://java.sun.com/docs/books/tutorial/javabeans/properties/constrained.htm > l > > > > > > Assuming that this is all happened smoothly, which I think > > is pretty safe, > > > that leaves the following main question: > > > -- What happens when Struts begins to populate our action form? > > > > > > A. Nothing, our users suddendly started getting everything > > "right", so our > > > Validators never complain about their input anymore. &g
Re: server-side, java-based validation rules for struts..
So you are saying that when an ActionForm is instantiated its associated
listener(s) get shoved in (read "registered") via a set method on the
ActionForm, and the Listener actually does the registering of itself in its
constructor or something.
So what you have is a bunch of ActionsForms with their listeners already
registered. Did I get it?
- Original Message -
From: "Levi Cook" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 11:44 AM
Subject: Re: server-side, java-based validation rules for struts..
> I guess that's the critical part, eh-- sorry for the hand-waving :)
>
> At this point, I see the Struts controller coordinating these "rules",
based
> on the contents of struts-config.xml:
> 1. Instantiation of our form-bean as needed (no real change here).
> 2. Instantiation of optional change-listeners* associated with our
form.
> (peek at the xml fragment below)
> 3. Now, it can register the change-listener (aka
> VetoableChangeListener), with our new form-bean.
> note: addVetoableChangeListener
> & removeVetoableChangeListener
> adhere to a naming pattern established by the JavaBeans spec.
> for more on this, see the last section on this page:
>
>
http://java.sun.com/docs/books/tutorial/javabeans/properties/constrained.htm
> l
>
> Assuming that this is all happened smoothly, which I think is pretty safe,
> that leaves the following main question:
> -- What happens when Struts begins to populate our action form?
>
> A. Nothing, our users suddendly started getting everything "right", so our
> Validators never complain about their input anymore.
> B. Our, the more probable route... our Validators start throwing
> PropertyVetoExceptions because our user's aren't any better at answering
> these questions than we are :)
>
> This point introduces the next responsibily I planned on handing the
> struts-controller: handling PropertyVetoExceptions. In short, I'd like it
to
> basically turn these exceptions into ActionErrors for us.
>
> Hope this sounds a little clearer, thanks for the feedback-- I think it
> greatly influences the ideas quality.
>
> Regards,
> Levi Cook
>
> > >
> > >
> > >
> > > > > property="creditCard"
> > > type="CreditCardValidator"
> > > />
> > >
> > >
> > >
>
> - Original Message -
> From: "Jonathan Asbell" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, June 21, 2001 4:42 AM
> Subject: Re: server-side, java-based validation rules for struts..
>
>
> > Levi, you lost me somewhere in your explanation from ."now have to
> > account for interacting with Struts-- That's where I see
> > java.bean.VetoableChangeListener."
> >
> > What are you passing to whom, and where are you instantiating and
> > registering things?
> >
> >
>
> > > public MyCCForm extends ActionForm {
> > > public setCreditCard(String newCreditCard) throws
> PropertyVetoException
> > {
> > > vcs.fireVetoableChange(CC_PROP_NAME, creditCard, newCreditCard);
> > > creditCard= newCreditCard;
> > > }
> > > public void
addCreditCardVetoableChangeListener(VetoableChangeListener
> > > lsnr) {
> > > vcs.addVetoableChangeListener(CC_PROP_NAME, lsnr);
> > > }
> > > private String creditCard;
> > > private static final String CC_PROP_NAME= "creditCard";
> > > private VetoableChangeSupport vcs= new VetoableChangeSupport(this);
> > > }
> > >
> > > public class CreditCardValidator implements VetoableChangeListener {
> > > public void vetoableChange(PropertyChangeEvent evt)
> > > throws PropertyVetoException
> > > {
> > > String creditCard= null;
> > > try {
> > > creditCard= (String) evt.getNewValue();
> > > }
> > > finally {
> > > if(StringValidator.isCreditCard(creditCard) == false)
> > > throw new PropertyVetoException("some.msg.key", evt);
> > > }
> > > }
> > > }
> > >
>
> > >
>
>
Re: Opening up a thread on ALTERNATE SCOPES
How are you dealing with scope. Do you use an adaptor to Session or ServletContext to hide the scope's implementation from the developer, or do you outright use a Session etc. - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 21, 2001 6:33 AM Subject: Re: Opening up a thread on ALTERNATE SCOPES > What I'm working on myself right now is a "ResourceCache" where I can > tuck things (like partially complete ActionForms) for future use. It's > just a hashtable right now, but the objects could also be wrapped if > additional properties were needed. > > I'm using it to do two things: (1) save partially completed ActionForms > for later use, and (2) save the current key values from ActionForms for > use on other forms. The idea being I can detour in the middle of > completing a form (save it to the cache), look something up on another > form (save the key to the cache), and go back and complete the form (pop > from the cache (restore and dispose), update key values from cache). > > I also started thinking of it as a cache, since if heavily used it might > need to be capped, so that older items were automatically disposed when > it was "full". > > > > Here's a wild idea that came up whilst explaining Struts to another > developer: > > How about scoped ActionMappings that pertain to a particular user, > perhaps loaded as part of a customization? > > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ > > > Jonathan Asbell wrote: > > > > Hello all. We were talking about workflow a few weeks ago and the > > conversation dissipated. I am trying to open it up again because I > > have found a need for more scopes, and a need to implement these new > > scopes in the next few months. I am interested specifically in how it > > can be implemented in Struts. Let me begin with the new scopes. > > > > 1) Workflow scope within an application > > Store values from the first step until the final step and then get rid > > of the values > > You could probably use an adaptor, hide implementation from the > > developer, and store this scope inside the "session" scope > > Example - within an application store a value Do Activity 1, then do > > Activity 2, then do Activity 3, then throw out the value > > > > 2) Workflow between applications (mentioned by Dan Connelly earlier) > > Store values from the first step until the final step and then get rid > > of the values > > You could probably use an adaptor, hide implementation from the > > developer, and store this scope inside the "application" scope > > Example - store a value and do Activity 1 in Application 1, then do > > Activity 2 in Application 2, then do Activity 3 in Application 3, then > > throw out the value > > > > 3) Sub-Application scope > > Store values that pertain to a sub-directory within an application > > You could probably use an adaptor, hide implementation from the > > developer, and store this scope inside the "session" or "application" > > scope though I'm not sure which would be more appropriate. > > Example - Your applcation is a magazine which has 4 different > > sections, and you want to store values only pertaining to each > > section. When you leave the section the value is not visible, and may > > or may not disappear (depending on what you want to do). >
Re: javax.servlet.include.path_info ????
Wow. I couldnt find this in the java docs. How would we otherwise know?
- Original Message -
From: "Sukachevin, Stoehr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 7:30 AM
Subject: RE: javax.servlet.include.path_info
> Check the Java Servlet Spec API. v2.2 says:
>
> When a servlet is being used from within an include, it is sometimes
> necessary for that servlet to know the path by which it was invoked and
not
> the original request paths. The following request attributes are set:
>
> javax.servlet.include.request_uri
> javax.servlet.include.context_path
> javax.servlet.include.servlet_path
> javax.servlet.include.path_info
> javax.servlet.include.query_string
>
> -- Stoehr
>
> -Original Message-
> From: Jonathan Asbell [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 21, 2001 12:20 AM
> To: [EMAIL PROTECTED]
> Subject: javax.servlet.include.path_info
>
>
> In the ActionServlet...
> javax.servlet.include.path_info
> Anyone know what this is or where it comes from?
>
> // For prefix matching, we want to match on the path info (if any)
> path =(String) request.getAttribute("javax.servlet.include.path_info");
>
Re: Opening up a thread on ALTERNATE SCOPES
you are an early bird ted! - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 21, 2001 7:31 AM Subject: Re: Opening up a thread on ALTERNATE SCOPES > Sorry, I should have said remove rather than pop. It's a hashtable, so > everything is accessed by a token name. > > Jonathan Asbell wrote: > > If you are pushing and popping how do you get to the bottom ones anyway? >
Re: server-side, java-based validation rules for struts..
Levi, you lost me somewhere in your explanation from ."now have to
account for interacting with Struts-- That's where I see
java.bean.VetoableChangeListener."
What are you passing to whom, and where are you instantiating and
registering things?
- Original Message -
From: "Levi Cook" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 20, 2001 10:02 PM
Subject: Re: server-side, java-based validation rules for struts..
> comments below...
>
> ----- Original Message -
> > From: "Jonathan" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, June 20, 2001 12:55 PM
> > Subject: Re: server-side, java-based validation rules for struts..
> >
> > Hello Levi.
> > I read your comment yesterday and went and read about constrained
> properties
> > and bound properties in section 7.4 of the java beans spec link you
sent.
> I
> > think people didnt answer because you didnt speak enough about what you
> are
> > suggesting in the context of what has already been developed. I think
the
> > "veto" idea is interesting, but it doesnt replace what is being
developed,
> > but rather only adds to it.
>
> I agree, this proposal is not a replacement for the things being developed
> to date.
> The main point is that the JavaBeans approach provides an established,
> proven
> framework for pluggable validation rules.
>
> That said, its certainly feasible that adopting this approach could ripple
> into existing work. In general, I think it will promote looser coupling
> between struts objects and validation rules.
>
> For instance, let's consider Dave W's Validator.validateCreditCard method.
>
> Its signature goes something like this:
>
> 0: public void validateCreditCard(
> 1: java.lang.Object bean,
> 2: ValidatorAction va,
> 3: Field field,
> 4: org.apache.struts.action.ActionErrors errors,
> 5: javax.servlet.http.HttpServletRequest request,
> 6: javax.servlet.ServletContext application
> 7:)
>
> Now, I like Dave's work quite a bit, and I don't want to sound like a
> critic.
> Nonetheless, there are several opportunities to reduce coupling in this
> method.
>
> I would refactor validateCreditCard into a simple utility method.
> eg. public static boolean isCreditCard(String ccNumber) {..}
>
> Once that's in place (and tested :), I now have to account for interacting
> with
> Struts-- That's where I see java.bean.VetoableChangeListener helping out.
> Basically I'd suggest doing the following (in whatever order you prefer):
>
> 1. Create my actionform
> 2. Create my VetoableChangeListener
> 3. Add my form & its change-listener/validator to struts-config
>
> >From there, I would expect Struts to handle the rest.. Where the rest is:
> 1. Call addCreditCardVetoableChangeListener() passing in a new
> instance of CreditCardValidator.
> 2. Catch any PropertyVetoExceptions throw by setCreditCard
> and turn them into ActionErrors.
> 3. Return the control to the user w/ there actual input values
> and a sensible message indicating how to correct the err.
>
> public MyCCForm extends ActionForm {
> public setCreditCard(String newCreditCard) throws PropertyVetoException
{
> vcs.fireVetoableChange(CC_PROP_NAME, creditCard, newCreditCard);
> creditCard= newCreditCard;
> }
> public void addCreditCardVetoableChangeListener(VetoableChangeListener
> lsnr) {
> vcs.addVetoableChangeListener(CC_PROP_NAME, lsnr);
> }
> private String creditCard;
> private static final String CC_PROP_NAME= "creditCard";
> private VetoableChangeSupport vcs= new VetoableChangeSupport(this);
> }
>
> public class CreditCardValidator implements VetoableChangeListener {
> public void vetoableChange(PropertyChangeEvent evt)
> throws PropertyVetoException
> {
> String creditCard= null;
> try {
> creditCard= (String) evt.getNewValue();
> }
> finally {
> if(StringValidator.isCreditCard(creditCard) == false)
> throw new PropertyVetoException("some.msg.key", evt);
> }
> }
> }
>
>
>
>
> property="creditCard"
> type="CreditCardValidator"
> />
>
>
>
>
> > It could be added of course. But the validations that have been
> developed
> > and discussed thus far go much farther than what the beans offer.
>
> The fact that they do go farther is one of the reasons I felt it was
> necessary
> find a slightly more abstract approach. Said another way,
Re: Proposed enhancement to
Can we please do this? Martin, can you send me what you have anyway because I want to use it if they wont include it =) - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 21, 2001 7:14 AM Subject: Re: Proposed enhancement to > I'm probably +1 on this. I'm just not sure when you would want to > specify the key dynamically. I'd also wonder if there's a need to > specify the key dynamically, do we need to offer the same for the bundle > too? > > > > Meanwhile, I also wonder if we should have "textKey" and "bundle" > attributes for the html:link and html:submit tags, so you could use the > < ... /> form instead something like />. This would be consistent with how and > work. > > Also, I should play with this myself first, but since we're talking > i18n, if I have internationalized a button, and have multiple buttons, > then HTTP is going to submit the i18n label as a value. How do I parse > that in the Action, can I do a reverse lookup in the resource based on > the actor's locale? Or am I overlooking something? > > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ > > Martin Cooper wrote: > > > > I posted this a few weeks ago as a patch, when it should more properly have > > been a proposal. Here, then, is the proposal: > > > > A problem with the current tag is that the only way to > > specify the message resource key dynamically is by using a JSP expression. > > This leads to the use of the following pattern: > > > > > type="java.lang.String"/> > > > > > > An alternative is to have the Action look up the key and set the resulting > > string value in the property for use on the JSP page via . This > > doesn't feel right, because the responsibility for looking up the > > appropriately localized text is then divided between the Action and the JSP > > page. > > > > By enhancing the tag to allow it to obtain the message > > resource key from a bean property, we can simplify the above example to: > > > > > > > > Here, the 'name' and 'property' attributes are used to obtain the message > > resource key from a bean. That key is then used as if it had been specified > > using the 'key' attribute. > > > > I believe this proposal would enhance the i18n functionality of Struts by > > allowing dynamic specification of messages, while delegating the resolution > > of the actual message text to the view. > > > > Comments? > > > > -- > > Martin Cooper >
Re: I would like to offer myself to help with documentation
Sure Ted. Thanx. My perspective always comes from assuming that the reader doesnt know much. People get confused and sidetracked with jargon, and struts can be used by less experienced people if explained correctly. I mean, dont we want the user base to grow so it can be developed better and faster =) We ant users to "get it". We dont have to explain MVC as much as we have to explain them about Struts. The sell is the framework and its capabilities. Lets talk to people in street English so when their superiors want to know about it its not too hard. After all, its the superiors who actually say yes or no to a technology, and many are afraid (it took 2 months for the senior engineer at my place to even LOOK at Struts, and he is no dummy) - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 21, 2001 6:52 AM Subject: Re: I would like to offer myself to help with documentation > I like the idea of a "brochure-size" introduction to Struts, and a > "quick-start" installation guide. I think this might make a useful > preamble to the User Guide. > > My favorite part is where you say: > > "Your company has decided" > > I think this would make a nice focal point for an introduction. After > all, the framework (like all applications) is really suppose to be > solving a given set of problems. But right now we seems to assume that > everyone knows what problems MVC is trying to solve, and go off from > there. > > So, I'm thinking starting out with something like > > "Your Web team wants add a new section to the site" ... > > "Your team leader decides that Scriplets are a Bad Thing" ... > > "Your Web Application must be internationlized" ... > > "Your application must be accessible to everyone using anything from > anywhere" ... > > "Your application must be J2EE compliant and make good use of Enterprise > Beans" ... > > I could try refactoring the draft, if you agree. > > -Ted. >
Re: Opening up a thread on ALTERNATE SCOPES
Ted, can you explain a little more about: "I also started thinking of it as a cache, since if heavily used it might need to be capped, so that older items were automatically disposed when it was 'full'. " If you are pushing and popping how do you get to the bottom ones anyway? - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 21, 2001 6:33 AM Subject: Re: Opening up a thread on ALTERNATE SCOPES > What I'm working on myself right now is a "ResourceCache" where I can > tuck things (like partially complete ActionForms) for future use. It's > just a hashtable right now, but the objects could also be wrapped if > additional properties were needed. > > I'm using it to do two things: (1) save partially completed ActionForms > for later use, and (2) save the current key values from ActionForms for > use on other forms. The idea being I can detour in the middle of > completing a form (save it to the cache), look something up on another > form (save the key to the cache), and go back and complete the form (pop > from the cache (restore and dispose), update key values from cache). > > I also started thinking of it as a cache, since if heavily used it might > need to be capped, so that older items were automatically disposed when > it was "full". > > > > Here's a wild idea that came up whilst explaining Struts to another > developer: > > How about scoped ActionMappings that pertain to a particular user, > perhaps loaded as part of a customization? > > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ > > > Jonathan Asbell wrote: > > > > Hello all. We were talking about workflow a few weeks ago and the > > conversation dissipated. I am trying to open it up again because I > > have found a need for more scopes, and a need to implement these new > > scopes in the next few months. I am interested specifically in how it > > can be implemented in Struts. Let me begin with the new scopes. > > > > 1) Workflow scope within an application > > Store values from the first step until the final step and then get rid > > of the values > > You could probably use an adaptor, hide implementation from the > > developer, and store this scope inside the "session" scope > > Example - within an application store a value Do Activity 1, then do > > Activity 2, then do Activity 3, then throw out the value > > > > 2) Workflow between applications (mentioned by Dan Connelly earlier) > > Store values from the first step until the final step and then get rid > > of the values > > You could probably use an adaptor, hide implementation from the > > developer, and store this scope inside the "application" scope > > Example - store a value and do Activity 1 in Application 1, then do > > Activity 2 in Application 2, then do Activity 3 in Application 3, then > > throw out the value > > > > 3) Sub-Application scope > > Store values that pertain to a sub-directory within an application > > You could probably use an adaptor, hide implementation from the > > developer, and store this scope inside the "session" or "application" > > scope though I'm not sure which would be more appropriate. > > Example - Your applcation is a magazine which has 4 different > > sections, and you want to store values only pertaining to each > > section. When you leave the section the value is not visible, and may > > or may not disappear (depending on what you want to do). >
Re: Opening up a thread on ALTERNATE SCOPES
Can you describe what you mean by graph. Do you mean a HashMap or List? How do you "jump"? How do you go follow decisions and results? - Original Message - From: "Paul Speed" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 21, 2001 2:24 AM Subject: Re: Opening up a thread on ALTERNATE SCOPES > Just one small point... > > In all my (admittedly brief compared to some) travels through workflow > land, I've never had a workflow that was specifically tree. They all > end up forming a graph at some point. > > One could argue that you can just have jump points from one branch to > another, but in my experience, after many iterations the tree becomes > more of a hinderance than a boon as jump points become more frequent. > > It might be better to design it to be a graph structure from the > beginning. > > -Paul Speed > > Jonathan Asbell wrote: > > > > Since my needs are for web container persistence, let me make a suggestion > > in that area. > > An object called WorkflowPath could be created with configurable values > > sucked up from a file. The values could be some kind of tree, like a > > decision/process tree. The WorkflowPath object would be stored in > > application scope, or a custom scope as mentioned below in the original > > post, such as Sub-Application scope. When you begin a process you grab the > > WorkflowPath from the scope stored under a name like "loginWorkflow", and > > you would query it for the next step in the decision/process tree. It would > > be nice maybe to have a pointer as to where you are in the sequence of > > things. Anyone want to add to this? Anyone want to dis this? Are you all > > asleep on this warm New York Summer night? =) > > > > - Original Message - > > From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, June 20, 2001 11:25 PM > > Subject: Re: Opening up a thread on ALTERNATE SCOPES > > > > > Jonathan Asbell wrote: > > > > > > > > Persistent storage is an option too. I was hoping, however to limit > > calls > > > > through the enterprise parts and database. > > > > > > Why? > > > > > > > You could argue that it belongs > > > > there because the database is the central location holding all data and > > > > information and therefore should hold workflow info, especially in the > > face > > > > of changing services/activities. However, must I consult the database > > or a > > > > db developer each time I want to add, change, or see anything? That is > > a > > > > time waster. > > > > > > Not really. I mean, I guess it's your design requirements. I would > > > want it to be that a user in a process (or a process itself) has no > > > requirement of 'immediate completion' - i.e. some part of the flow can > > > take a while. > > > > > > So then if the servlet container goes down, I don't care. No state > > > lost. > > > > > > > > > > > If you were not going to use persistent storage, how would you do it? > > > > > > For what I want to do, i can't really escape it. Somewhere, something > > > has to remember the state - assume the servlet container is going down > > > at some point... > > > > > > geir > > > > > > > - Original Message - > > > > From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Wednesday, June 20, 2001 10:17 PM > > > > Subject: Re: Opening up a thread on ALTERNATE SCOPES > > > > > > > > > Can I ask why you don't go with persistant storage, like a rdbms? I > > > > > have been thinking about workflow recently as well, although not > > > > > specifically w/in struts, and I believe that for the general solution, > > > > > where someone can come back a long time later and resume, or be it an > > > > > automated process, persistant storage would be required. > > > > > > > > > > geir > > > > > > > > > > > > > > > > Jonathan Asbell wrote: > > > > > > > > > > > > Hello all. We were talking about workflow a few weeks ago and the > > > > > > conversation dissipated. I am trying to open it up again because I > > > > > > h
javax.servlet.include.path_info ????
In the ActionServlet...
javax.servlet.include.path_info
Anyone know what this is or where it comes
from?
// For prefix matching, we want to match on
the path info (if any) path =(String)
request.getAttribute("javax.servlet.include.path_info");
Re: Opening up a thread on ALTERNATE SCOPES
Since my needs are for web container persistence, let me make a suggestion in that area. An object called WorkflowPath could be created with configurable values sucked up from a file. The values could be some kind of tree, like a decision/process tree. The WorkflowPath object would be stored in application scope, or a custom scope as mentioned below in the original post, such as Sub-Application scope. When you begin a process you grab the WorkflowPath from the scope stored under a name like "loginWorkflow", and you would query it for the next step in the decision/process tree. It would be nice maybe to have a pointer as to where you are in the sequence of things. Anyone want to add to this? Anyone want to dis this? Are you all asleep on this warm New York Summer night? =) - Original Message - From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 20, 2001 11:25 PM Subject: Re: Opening up a thread on ALTERNATE SCOPES > Jonathan Asbell wrote: > > > > Persistent storage is an option too. I was hoping, however to limit calls > > through the enterprise parts and database. > > Why? > > > You could argue that it belongs > > there because the database is the central location holding all data and > > information and therefore should hold workflow info, especially in the face > > of changing services/activities. However, must I consult the database or a > > db developer each time I want to add, change, or see anything? That is a > > time waster. > > Not really. I mean, I guess it's your design requirements. I would > want it to be that a user in a process (or a process itself) has no > requirement of 'immediate completion' - i.e. some part of the flow can > take a while. > > So then if the servlet container goes down, I don't care. No state > lost. > > > > > If you were not going to use persistent storage, how would you do it? > > For what I want to do, i can't really escape it. Somewhere, something > has to remember the state - assume the servlet container is going down > at some point... > > geir > > > - Original Message - > > From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, June 20, 2001 10:17 PM > > Subject: Re: Opening up a thread on ALTERNATE SCOPES > > > > > Can I ask why you don't go with persistant storage, like a rdbms? I > > > have been thinking about workflow recently as well, although not > > > specifically w/in struts, and I believe that for the general solution, > > > where someone can come back a long time later and resume, or be it an > > > automated process, persistant storage would be required. > > > > > > geir > > > > > > > > > > Jonathan Asbell wrote: > > > > > > > > Hello all. We were talking about workflow a few weeks ago and the > > > > conversation dissipated. I am trying to open it up again because I > > > > have found a need for more scopes, and a need to implement these new > > > > scopes in the next few months. I am interested specifically in how it > > > > can be implemented in Struts. Let me begin with the new scopes. > > > > > > > > 1) Workflow scope within an application > > > > Store values from the first step until the final step and then get rid > > > > of the values > > > > You could probably use an adaptor, hide implementation from the > > > > developer, and store this scope inside the "session" scope > > > > Example - within an application store a value Do Activity 1, then do > > > > Activity 2, then do Activity 3, then throw out the value > > > > > > > > > > > > 2) Workflow between applications (mentioned by Dan Connelly earlier) > > > > Store values from the first step until the final step and then get rid > > > > of the values > > > > You could probably use an adaptor, hide implementation from the > > > > developer, and store this scope inside the "application" scope > > > > Example - store a value and do Activity 1 in Application 1, then do > > > > Activity 2 in Application 2, then do Activity 3 in Application 3, then > > > > throw out the value > > > > > > > > > > > > 3) Sub-Application scope > > > > Store values that pertain to a sub-directory within an application > > > > You could probably use an adaptor, hide implementation from the > > > >
Re: Opening up a thread on ALTERNATE SCOPES
Thats fine. You would like the state of the workflow saved in spite of a server failure. The truth is we should figure out both situations anyway for both types of requirements: 1) storing state in a database 2) storing state in the web container - Original Message - From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 20, 2001 11:25 PM Subject: Re: Opening up a thread on ALTERNATE SCOPES > Jonathan Asbell wrote: > > > > Persistent storage is an option too. I was hoping, however to limit calls > > through the enterprise parts and database. > > Why? > > > You could argue that it belongs > > there because the database is the central location holding all data and > > information and therefore should hold workflow info, especially in the face > > of changing services/activities. However, must I consult the database or a > > db developer each time I want to add, change, or see anything? That is a > > time waster. > > Not really. I mean, I guess it's your design requirements. I would > want it to be that a user in a process (or a process itself) has no > requirement of 'immediate completion' - i.e. some part of the flow can > take a while. > > So then if the servlet container goes down, I don't care. No state > lost. > > > > > If you were not going to use persistent storage, how would you do it? > > For what I want to do, i can't really escape it. Somewhere, something > has to remember the state - assume the servlet container is going down > at some point... > > geir > > > - Original Message - > > From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, June 20, 2001 10:17 PM > > Subject: Re: Opening up a thread on ALTERNATE SCOPES > > > > > Can I ask why you don't go with persistant storage, like a rdbms? I > > > have been thinking about workflow recently as well, although not > > > specifically w/in struts, and I believe that for the general solution, > > > where someone can come back a long time later and resume, or be it an > > > automated process, persistant storage would be required. > > > > > > geir > > > > > > > > > > Jonathan Asbell wrote: > > > > > > > > Hello all. We were talking about workflow a few weeks ago and the > > > > conversation dissipated. I am trying to open it up again because I > > > > have found a need for more scopes, and a need to implement these new > > > > scopes in the next few months. I am interested specifically in how it > > > > can be implemented in Struts. Let me begin with the new scopes. > > > > > > > > 1) Workflow scope within an application > > > > Store values from the first step until the final step and then get rid > > > > of the values > > > > You could probably use an adaptor, hide implementation from the > > > > developer, and store this scope inside the "session" scope > > > > Example - within an application store a value Do Activity 1, then do > > > > Activity 2, then do Activity 3, then throw out the value > > > > > > > > > > > > 2) Workflow between applications (mentioned by Dan Connelly earlier) > > > > Store values from the first step until the final step and then get rid > > > > of the values > > > > You could probably use an adaptor, hide implementation from the > > > > developer, and store this scope inside the "application" scope > > > > Example - store a value and do Activity 1 in Application 1, then do > > > > Activity 2 in Application 2, then do Activity 3 in Application 3, then > > > > throw out the value > > > > > > > > > > > > 3) Sub-Application scope > > > > Store values that pertain to a sub-directory within an application > > > > You could probably use an adaptor, hide implementation from the > > > > developer, and store this scope inside the "session" or "application" > > > > scope though I'm not sure which would be more appropriate. > > > > Example - Your applcation is a magazine which has 4 different > > > > sections, and you want to store values only pertaining to each > > > > section. When you leave the section the value is not visible, and may > > > > or may not disappear (depending on what you want to do). > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Geir Magnusson Jr. [EMAIL PROTECTED] > > > System and Software Consulting > > > Developing for the web? See http://jakarta.apache.org/velocity/ > > > You have a genius for suggesting things I've come a cropper with! > > > > > -- > Geir Magnusson Jr. [EMAIL PROTECTED] > System and Software Consulting > Developing for the web? See http://jakarta.apache.org/velocity/ > You have a genius for suggesting things I've come a cropper with! >
Re: Opening up a thread on ALTERNATE SCOPES
Persistent storage is an option too. I was hoping, however to limit calls through the enterprise parts and database. You could argue that it belongs there because the database is the central location holding all data and information and therefore should hold workflow info, especially in the face of changing services/activities. However, must I consult the database or a db developer each time I want to add, change, or see anything? That is a time waster. If you were not going to use persistent storage, how would you do it? - Original Message - From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 20, 2001 10:17 PM Subject: Re: Opening up a thread on ALTERNATE SCOPES > Can I ask why you don't go with persistant storage, like a rdbms? I > have been thinking about workflow recently as well, although not > specifically w/in struts, and I believe that for the general solution, > where someone can come back a long time later and resume, or be it an > automated process, persistant storage would be required. > > geir > > > > Jonathan Asbell wrote: > > > > Hello all. We were talking about workflow a few weeks ago and the > > conversation dissipated. I am trying to open it up again because I > > have found a need for more scopes, and a need to implement these new > > scopes in the next few months. I am interested specifically in how it > > can be implemented in Struts. Let me begin with the new scopes. > > > > 1) Workflow scope within an application > > Store values from the first step until the final step and then get rid > > of the values > > You could probably use an adaptor, hide implementation from the > > developer, and store this scope inside the "session" scope > > Example - within an application store a value Do Activity 1, then do > > Activity 2, then do Activity 3, then throw out the value > > > > > > 2) Workflow between applications (mentioned by Dan Connelly earlier) > > Store values from the first step until the final step and then get rid > > of the values > > You could probably use an adaptor, hide implementation from the > > developer, and store this scope inside the "application" scope > > Example - store a value and do Activity 1 in Application 1, then do > > Activity 2 in Application 2, then do Activity 3 in Application 3, then > > throw out the value > > > > > > 3) Sub-Application scope > > Store values that pertain to a sub-directory within an application > > You could probably use an adaptor, hide implementation from the > > developer, and store this scope inside the "session" or "application" > > scope though I'm not sure which would be more appropriate. > > Example - Your applcation is a magazine which has 4 different > > sections, and you want to store values only pertaining to each > > section. When you leave the section the value is not visible, and may > > or may not disappear (depending on what you want to do). > > > > > > > > > > > > -- > Geir Magnusson Jr. [EMAIL PROTECTED] > System and Software Consulting > Developing for the web? See http://jakarta.apache.org/velocity/ > You have a genius for suggesting things I've come a cropper with! >
Opening up a thread on ALTERNATE SCOPES
Hello all. We were talking about workflow a few weeks ago and the conversation dissipated. I am trying to open it up again because I have found a need for more scopes, and a need to implement these new scopes in the next few months. I am interested specifically in how it can be implemented in Struts. Let me begin with the new scopes. 1) Workflow scope within an application Store values from the first step until the final step and then get rid of the values You could probably use an adaptor, hide implementation from the developer, and store this scope inside the "session" scope Example - within an application store a value Do Activity 1, then do Activity 2, then do Activity 3, then throw out the value 2) Workflow between applications (mentioned by Dan Connelly earlier) Store values from the first step until the final step and then get rid of the values You could probably use an adaptor, hide implementation from the developer, and store this scope inside the "application" scope Example - store a value and do Activity 1 in Application 1, then do Activity 2 in Application 2, then do Activity 3 in Application 3, then throw out the value 3) Sub-Application scope Store values that pertain to a sub-directory within an application You could probably use an adaptor, hide implementation from the developer, and store this scope inside the "session" or "application" scope though I'm not sure which would be more appropriate. Example - Your applcation is a magazine which has 4 different sections, and you want to store values only pertaining to each section. When you leave the section the value is not visible, and may or may not disappear (depending on what you want to do).
Re: server-side, java-based validation rules for struts..
Hello Levi. I read you rcomment yesterday and went and read about constrained properties and bound properties in section 7.4 of the java beans spec link you sent. I think people didnt answer because you didnt speak enough about what you are suggesting in the context of what has already been developed. I think the "veto" idea is interesting, but it doesnt replace what is being developed, but rather only adds to it. It could be added of course. But the validations that have been developed and discussed thus far go much farther than what the beans offer. We have been trying to actually build (and some have like Dave Winderfeldt) a bunch of validations for common problems like credit cards, emails, money etc. In fact the java beans spec doesnt address what is involved in validating an e-mail ,phone number etc., but rather a general concept in implementing something you have validated via some algorithm etc.etc. Check out some of the various posts about validation and you will see what I mean. ;^> - Original Message - From: "Cook, Levi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 20, 2001 3:48 PM Subject: RE: server-side, java-based validation rules for struts.. > I'm guessing my aforementioned ideas on validation fall into one of the > following categories: > > 1. its was a really bad idea, not worth commenting or elaborating on > 2. i didn't provide a clearly articulated idea to review > 3. they're fine and everyone's really busy, and i'm impatient > > I'll assume its items mostly 3, and will apologize in advance for seeming > impatient. > > However, does anyone care to comment on its viability?? > Should I proceed with making a more formal proposal?? > Does this miss the mark totally for framework based validation?? > > If I failed on item 2, what's missing?? (scope, applicability, etc..) > > Sorry to be a bug, I truly appreciate everyone's time and effort with > Struts. > > -- Levi > > > -Original Message- > > From: Levi Cook [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, June 19, 2001 11:58 AM > > To: [EMAIL PROTECTED] > > Subject: server-side, java-based validation rules for struts.. > > > > > > I believe its well established that Struts would benefit from a good > > validation framework (duh, right?). While there are a number of > > really good ideas floating around, some seem to be introducing > > unnecessary complexity (IMHO, of course) > > > > Getting to the point, I think constrained properties from the > > JavaBeans spec. provides a built in, flexible foundation for > > struts invoked validation. > > (http://java.sun.com/products/javabeans/docs/spec.html) > > > > key advantages: > > * support is provided by the standard java.beans package > > * it doesn't require learning anything proprietary (even though > > other solutions are very cool :) > > * its conceptually simple; ie. before accepting a new value, > > the bean/ActionForm's setter method(s) ensures its accepted by > > all registered listeners before commiting the value > > (java.bean.VetoableChangeListenter). > > * and finally, its wide open for extension (key since we can't > > predict all validation scenario's, right?) > > > > I also believe that integration with Struts could be pretty straight > > forward. In a nutshell, we could make 2 modifications ActionServlet: > > > > 1. Make it responsible for registering "change-listeners" > > 2. Make it handle PropertyVetoException(s) thrown by setter methods > > (primarily by turning them into ActionErrors) > > > > Prior to making a "formal" proposal for this, I thought it might be > > useful to consider the attached code fragments: > > > > Then again, maybe I'm way off and should be ignored- If I am, > > let me know.. > > > > Regards, > > Levi Cook >
Re: Client/Server Side Validation for Struts 1.1
Hello Christian. My answer would be that in "1.00@0,55" we would leave it as is and filter it. If after the filter (when it is in the format WE need) we could not validate it, than its not valid. The power must rely in the filter because WE, ABSOLUTELY, NEED TO VALIDATE IN OUR FORMAT. Therfore the filter must know about "@" characters etc. - Original Message - From: "Christian Cryder" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Jonathan Asbell" <[EMAIL PROTECTED]> Sent: Tuesday, June 19, 2001 11:12 AM Subject: RE: Client/Server Side Validation for Struts 1.1 > Hi Jonathan, > > Interesting question, and one we're still wrestling with in Barracuda too. I > see one possible problem with filtering then validating. > > Using your example below, what happens if the Brasilian values looks like > this: > 1.00@0,55 > The problem now becomes "how do we filter something that is invalid?" Do we > silently suppress the invalid @ character because we don't know what it is? > Or do we just leave it alone? Or what about something like this: > 1.00,05,5 > Which comma is the real one? > > The essence of filtering is that you are changing things that the user > entered to get them into a format that the software can understand (ie > Floats). In many cases, we can safely guess user intent, but in others it > becomes much more difficult. For instance, lets say I'm accepting a whole > dollar bid on an item (ie. no decimal points). What if the user enters > 10.00? If my filter tries to guess intent and silently skips the decimal > since its not a valid character for this value, it could conceivably convert > my ten dollar bid into a thousand dollar bid (by dropping the decimal). > Since the result of the filtering is a valid number, processing continues > and the bid is placed (and in many cases the user might not even realize > what just happened). > > Granted this is a contrived example, but I think it illustrates one of the > pitfalls of filtering. To be safe, any time you filter/adjust a value, you > really want to give the user a chance to verify that the adjustment you made > is correct. Often, however, that type of "hey is this what you meant?" isn't > real conducive to the app workflow. > > Just some food for thought... > Christian > > Christian Cryder [[EMAIL PROTECTED]] > Barracuda - MVC Component Framework for Webapps > http://barracuda.enhydra.org > > "What a great time to be a Geek" > > > > -Original Message- > > From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, June 19, 2001 6:20 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Client/Server Side Validation for Struts 1.1 > > > > > > This is what I'm saying. Lets not use your social security number as an > > example because it is only for the USA. Lets use money. In the > > USA we use > > 1,000.55 for one-thousand-fifty-five dolars. In Brasil they use 1.000,55. > > We would allow a user who lives in Brasil who also chose to view > > content in > > Portuguese to enter the number the way THEY understand. WE, on the other > > hand will have built a filter to change what they entered into the format > > which we work with (1,000.55 ) to validate it. This means ONE validation > > created for money, but a filter had to be created for users located in > > Brasil. The filter just changed their format to the format we need to > > process. When we decide to give this capability to another > > location/language > > we jjust create a filter and use the same validator. Of course the filter > > would have to work going TO the application from the presentation and from > > the application back to the presentation. > > > > If not, you have to do validations for a zillion different permutations of > > possibilities > > > > What do you think? > > > > - Original Message - > > From: "David Winterfeldt" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]>; "Jonathan Asbell" > > <[EMAIL PROTECTED]> > > Sent: Monday, June 18, 2001 11:01 PM > > Subject: Re: Client/Server Side Validation for Struts 1.1 > > > > > > > What do you mean by "converted into the format of the > > > system"? Do you mean the object and not the String > > > representation in the ActionForm? Or are you refering > > > to the part where I talk about associating a locale to > > > a phone number? > > > > &
Re: Client/Server Side Validation for Struts 1.1
This is what I'm saying. Lets not use your social security number as an example because it is only for the USA. Lets use money. In the USA we use 1,000.55 for one-thousand-fifty-five dolars. In Brasil they use 1.000,55. We would allow a user who lives in Brasil who also chose to view content in Portuguese to enter the number the way THEY understand. WE, on the other hand will have built a filter to change what they entered into the format which we work with (1,000.55 ) to validate it. This means ONE validation created for money, but a filter had to be created for users located in Brasil. The filter just changed their format to the format we need to process. When we decide to give this capability to another location/language we jjust create a filter and use the same validator. Of course the filter would have to work going TO the application from the presentation and from the application back to the presentation. If not, you have to do validations for a zillion different permutations of possibilities What do you think? - Original Message - From: "David Winterfeldt" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Jonathan Asbell" <[EMAIL PROTECTED]> Sent: Monday, June 18, 2001 11:01 PM Subject: Re: Client/Server Side Validation for Struts 1.1 > What do you mean by "converted into the format of the > system"? Do you mean the object and not the String > representation in the ActionForm? Or are you refering > to the part where I talk about associating a locale to > a phone number? > > Expand on what you were saying if this doesn't cover > it, but the initial validations would be to get > required fields filled in and in the correct format to > be converted to objects. For example, there would be > no reason to check that a social security number is in > your system until it is a well formed social security > number. Then you can convert your ActionForm to a > JavaBean with correct java types (java.util.Date, > etc.) and with the typed JavaBean you can then pass > that to a validation bean, an EJB, or any other server > side resource. And if you have a multi-tier > distributed system you would ideally want to get the > information filled in properly before you send it to > an EJB. > > Or if you mean that there are a lot of permutations > for phone numbers or dates, there are. If we model > things to take a pattern (MM/dd/ or (###) > ###-), then one type of class can perform the > validation/conversion based on the pattern. A date > can get converted to a date for checking if it falls > in a range, is within the last seven days, etc., but a > phone number is phone number and can't really be > converted into a standard format like a date. > > David > > --- Jonathan Asbell <[EMAIL PROTECTED]> wrote: > > Hi Dave. I really think (and tell me what you > > think) that all special > > formatting shoudl eventually be converted into the > > format of the system it > > is running on, THEN validated. Otherwise you have > > to design a gazillion > > permutations to validate. We could instead make > > various converters for each > > situation as needed, and one central validation > > package. > > > > - Original Message - > > From: "David Winterfeldt" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, June 18, 2001 2:26 PM > > Subject: RE: Client/Server Side Validation for > > Struts 1.1 > > > > > > > I've still been continuing work on the Struts > > > Validator > > (http://home.earthlink.net/~dwinterfeldt/) > > > in it's present form, but I've been thinking about > > the > > > discussion under this thread and the best way to > > > integrate these ideas with what I've done so far. > > It > > > seems like it is best to keep everything as > > separate > > > components and just make sure they work together. > > The > > > Mapper is separate. There should be a general > > > validation/transformation package that you can > > pass in > > > a String and it can create on object for you and > > throw > > > an Exception if it can't (based on > > java.text.Format as > > > you suggested). This package could then be used > > for > > > the Mapper, validation, and formatting. So you > > should > > > be able to define that a date should be > > "MM/dd/" > > > and this would be used for formatting of the date > > > object as it is converted to a String in the > > > ActionForm and also would be used for validation >
Re: Client/Server Side Validation for Struts 1.1
Hi Dave. I really think (and tell me what you think) that all special formatting shoudl eventually be converted into the format of the system it is running on, THEN validated. Otherwise you have to design a gazillion permutations to validate. We could instead make various converters for each situation as needed, and one central validation package. - Original Message - From: "David Winterfeldt" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 18, 2001 2:26 PM Subject: RE: Client/Server Side Validation for Struts 1.1 > I've still been continuing work on the Struts > Validator (http://home.earthlink.net/~dwinterfeldt/) > in it's present form, but I've been thinking about the > discussion under this thread and the best way to > integrate these ideas with what I've done so far. It > seems like it is best to keep everything as separate > components and just make sure they work together. The > Mapper is separate. There should be a general > validation/transformation package that you can pass in > a String and it can create on object for you and throw > an Exception if it can't (based on java.text.Format as > you suggested). This package could then be used for > the Mapper, validation, and formatting. So you should > be able to define that a date should be "MM/dd/" > and this would be used for formatting of the date > object as it is converted to a String in the > ActionForm and also would be used for validation and > after validation for the transformation back to a date > object. But as it was discussed, the way the standard > message resources work (from a region down to a > language) doesn't make sense for a phone number that > should be associated with region and has nothing to do > with the language. I was thinking that if resources > like phone numbers were loaded based on a location and > you could reference them from the validation.xml that > might work. > > depends="mask"> > > > > > The 'trans' prefix would represent that the value > should be retreived from the transformation resources > for the US phone number format. Or possibly if you > don't specify a country it would use the one from the > locale in session scope. > > David > > > --- Rey Francois <[EMAIL PROTECTED]> wrote: > > David, > > > > We don't generate any classes yet, but the intention > > would be to do so for > > ActionForms at a later stage. > > We would use a separate XML file, because the > > mapper-config.xml contains > > mappings, not bean definitions (mappings define > > many-to-many relationships > > between fields of several objects). > > I have of course the source for this mapper > > framework. If the decision was > > only mine I would be pleased to share it. I need to > > discuss this with other > > people within my company who should also be involved > > in this decision. I > > hope to get this sorted out this week... > > > > Are you still exploring solutions for a validation > > framework? > > > > Fr. > > > > -Original Message- > > From: David Winterfeldt > > [mailto:[EMAIL PROTECTED]] > > Sent: 15 June 2001 14:31 > > To: [EMAIL PROTECTED] > > Subject: RE: Client/Server Side Validation for > > Struts 1.1 > > > > > > I just wanted to put this out there to see what > > people > > think since I took the time to look at how Barracuda > > worked. I like the idea of not having two classes > > (ActionForm and a data bean), but I guess there will > > be a few different tools to autogenerate these as > > time > > goes by. Do you autogenerate classes based on the > > xml > > file? You have all the information in the xml file > > to > > make this possible, right? I think most of the > > issues > > you mention could be worked around, but you're > > Mapper > > idea is much more flexible. Is any source for what > > you've done available to look at or is it > > proprietary > > (I do have the xml file you sent to the list)? > > > > David > > > > --- Rey Francois <[EMAIL PROTECTED]> wrote: > > > David, > > > > > > A few remarks: > > > - I'm not sure that we should loose the value > > > entered by the user once the > > > transformation is done. Although I see the > > argument > > > that once transformed > > > the string value is most likely redundant, there > > may > > > be cases when it is > > > still useful. Also, unless you're able to make the > > > reverse transformation > > > and produce the exact same string as the user has > > > entered, further display > > > of the form may confuse a user when the displayed > > > fields differ from what he > > > has entered. I would be more in favor of an > > > ActionForm that is just a > > > placeholder for values entered by the user, like > > it > > > is at present. > > > - Having only one validator per property is a > > > limitation. We should be able > > > to have more than one like you already support in > > > your current framework. We > > > should also think about validation across several > > > fields. For example, in > > >
Re: The documentation, xml, and stylesheets
I am at a loss as to how to respond to this. You obviously work alone - Original Message - From: "Michael Westbay" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 18, 2001 8:27 PM Subject: Re: The documentation, xml, and stylesheets > Asbell-san wrote: > > > Mike, I am forced to work with xslt every day, [...] > > It sounds to me like you're one of those many people who majored in something > that had nothing to do with computers, then found yourself in the IT field. > I was a Computer Science major. I taught myself HTML, XML, SGML, XSL, and > the rest of the alphabet soup in my own time after work simply because I > found them fascinating. > > > [...] and each day I find a new > > reason to say "what in the WORLD do people see in this?!". It has its > > place in changing from schema to schema, but who want to get so deep into a > > technology which is very hard to control, and in complex schemas consumes > > more effort than it is worth to get what you want out of it. > > Let me venture another guess. You're working primarily with poorly > documented and or thought out DTDs that are ever changing as more > functionality is desired, leaving you to constantly update the style sheet > transforms to satisfy the whims of your boss. > > First of all, getting in deep with the technology gives one a better > understanding of it. I started learning HTML in 1995 armed with Mosaic and > my trusty vi editor. GUIs are nice, but IMHO, they separate the creator from > the underlying technologies too much. I'd rather know what's going on under > the hood. Why does a page render the way it does. Getting a good > fundamental knowledge of the low level technologies allows me to spot and fix > problems quickly. It also allows for better efficiency when using the > technologies. > > With a better understanding, the technologies are not hard to control. A > well written schema, even a very complex one (like DocBook) is well worth the > effort of getting a good understanding of the underlying technologies. > > As Winterfeldt-san pointed out, the whole XML/XSL bit it may be overkill for > a few scattered unrelated documents. But when the documentation starts > increasing, a well thought out schema for allowing flexible access to what > would be a mountian load of dead trees saves a great deal in the long run. > > I don't know if my evengilism of a technology can change your mind. We > obviously have very different backgrounds (I was the only one in my English > classes to turn in papers written in LaTeX [edited in vi, of course] - > everyone else used WordPerfect or [gasp!] a typewriter). And our jobs seem > to give different levels of satisfaction: I'd study this stuff on my own if > I didn't get to work with it anyway, whereas you're "forced to work with xslt > every day." > > I think it's great that you're volunteering to help with the documentation. > But I also think it's strange that you hadn't gone through what is there and > seen how it is generated from XML via XSLT. I would have expected some sort > of professional curiosity as to how others deal with documentation issues, > since that seems to be your line of work. But then, maybe it's me applying > my own drive to learn more ways of doing things to improve my own skills and > the way I do my job. (Sorry, I forget sometimes that not everyone takes a > job in the tech field by choice.) > > -- > Michael Westbay > Work: Beacon-IT http://www.beacon-it.co.jp/ > Home: http://www.seaple.icc.ne.jp/~westbay > Commentary: http://www.japanesebaseball.com/ >
Can someone resend the file I sent this morning
For some reason I did not receive at work the file I sent this morning called struts_doc.html. Can someone repost it to the list or resend it to me. [EMAIL PROTECTED]
rough draft of initial documentation
pleas comment on this initial rough draft. There is no color yet. Title: Struts is simply a package of java classes (components) which you integrate with a java enabled server, and which acts as a f Literal explanation of Struts Struts is simply a package of java classes (components) which you integrate into a java enabled server and use for developing web applications. It functions as a framework for building web applications and makes the following advantageous capabilities possible: · Provides a central organizational structure for building, controlling, and extending web applications · Enables clean separation between the code used for presentation and the code used for function · Built-in internationalization (capability of input and display in multiple languages) · Built-in and extensible authentication and validation · Allows modular development and easy integration with new components (including enterprise components) Struts is based on the java servlets and java server pages(jsp) technologies. It uses a collection of its own jsp tag classes to create presentations centered around a unique servlet, the ActionServlet, which determines a course of action and a resulting presentation. Specific requests coming from a users activity in the presentation layer trigger the servlet to call upon specific classes you have created to handle a desired activity. Jump to requirements and installation Jump to Struts details Struts aims to solve problems which developers continuously face in building, managing, changing, and extending web applications: The lack of a central point of control and organization Adding new sections to a site means creating a lot of web pages and programming new functionality as well. How will you link to the new section from the old sections, and how will you link between the areas of the new section? Will you recreate each presentation page in its entirety from scratch? Thats a lot of copying and pasting. Wouldnt it be nice to create the presentation(design) pages by re-using some common pieces you have already created (a template). It would be a great advantage to create any new logic and be able to configure how all the pages in the site are connected all in one place. When this capability can be accomplished changes can be made without needing to reprogram. Presentation pages can be created and changed faster. You will be able to make these changes at single points saving yourself from the wasted time and mistakes involved in copying and pasting the same code over and over and over. Intermixing of presentation and programming code When a development team permits the mixing of the programmers functional code (java) and the designers presentation code (html etc.) within the same document, a precarious situation is created. In this scenario designers have to be concerned about the effects of the functional code affecting their designed page, and programmers have to spend time helping designers understand and prevent the altering of the functional code which has been mixed in with the design so as to prevent the potential breaking of functionality and presentation. If these areas are separated then designers can focus on the presentation without worrying about effecting functionality, and programmers can focus on functionality without worrying about effecting presentation. Difficulty in developing applications with multi-language support Your company has decided to serve users who are native speakers of Spanish, Japanese, and Portuguese. Everything from the Welcome message to the instructions , error messages, money, and dates need to be displayed in the language and format of the user. How will you handle all of this without extensive programming efforts? What pieces will programmers have to create to make this an easy task for the designers to use, and for the programmers to change? Having this capability is a requirement. Making this capability easy to utilize and alter for your own needs is ideal. Having all of this capability without having to actually create it translates into a lot of time saved on creation and programmatic management. Giving designers and translators the ability to add languages and change displayable text and images without the intervention of programmers, means programmers dont have to spend their time intervening, coding, and changing text at all on behalf of the designers. Most applications dont have a complete pre-existing means of Authentication and Validation Every application needs to be able to prevent unauthorized access to certain pages or resources. Every application needs to validate what users enter, like phone numbers, e-mails, and credit cards. Most developers end up programming this type of validation over and over, starting from scratch. Some have developed basic validation packages if they have been involved in t
Documentation wish list repository
Hi Craig. Could we put together a repository of the documentation wish list items. It would be unreasonable for me to be searching through e-mails to do this - Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 16, 2001 5:12 PM Subject: Re: I would like to offer myself to help with documentation > > > On Sat, 16 Jun 2001, Jonathan wrote: > > > Hello all. > > It seems that there is a back log of documentation to do and I would like to > > offer to help with it as I am very good at explaining things. It also helps > > me understand the framework in a deeper way. However, because I am still > > relatively green with Struts (3 months) I will need to correspond with some > > of you outside of the list to get questions answered (I dont want to clutter > > up the list with these questions). I can complete sections according to > > when you want them, or I can do it in the order I want. > > > > Sounds great! This is a good place to talk about what the docs should > include. > > On my personal wish list: > > * High-quality UML diagrams covering all aspects of the architecture > of Struts (especially sequence diagrams of how requests are handled). > Anybody know some good+cheap tools for this purpose? > > * Tutorials (and example webapps) for a few common design idioms, such as > a wizard-type multipage dialog. Although, maybe we ought to wait on > this particular one if we're going to add pager-type tags. > > * Examples of extending the controller servlet to initialize your own > application resources. > > * Examples that integrate some other commonly available tag libraries > (such as those in jakarta-taglibs). However, I'm not personally a > huge fan of using the DB tags, because it can encourage you to stray > away from MVC :-). > > * Step-by-step how to construct a web app. Yes, this covers a lot of > ground that is not Struts-specific, but this would clear up a lot of the > complexity faced by new developers. A good starting point might be the > "Application Developer's Guide" that ships with Tomcat (disclaimer: I > wrote it, so don't be too hard on me :-). > > * Completed "package.html" files for the remaining packages (used as > Developer's Guide links in the documentation). > > * A comprehensive example that uses Data Acess Objects to talk to a > relational database. Ted's got some good starts here, but I'm thinking > more about a "real" application -- perhaps something like the > FAQ-O-MATIC idea, but written based on Struts? > > * A comprehensive example that uses EJBs to delegate business logic to > session beans, and persistence logic to entity beans. Obviously not > everyone will be able to run this, but you can at least look and see > how such an app could be constructed. > > A couple of things to think about before we start writing docs that will > be out of date quickly: > > * I'm planning to migrate to jakarta-commons versions of the shareable > pieces of Struts that have migrated there, including: Bean Utils, > Digester, DBCP (connection pool), Collections classes, and Message > Resources. Docs are still welcome in all of these areas, but they > should probably be done in jakarta-commons instead of here. > > * The JSP Standard Tag Library will have an early access version of their > tags available in the near future. There will be some significant > overlap with our tags in the struts-bean and struts-logic libraries, > and an expression language for nested property access that will be > similar to (but not identical) to ours. We'll want to think in the > long run about making sure that Struts interoperates nicely with > these tags. Because they will be standard, JSP page compilers will > be able to generate optimized code for them. > > * A little further down the pike, the result of the JavaServer Faces > (JSR-127) effort to create a standard GUI Component Model for web apps > will be in early access. At that time, I'll want to build some app > examples that use JSF as the user interface, but interact with the > rest of the Struts framework. NOTE: I am on the expert group for > JSR-127, so you can rest assured that the two technologies will play > together nicely! > > > If this is ok with you all and you are interested, please send me an email > > at mailto:[EMAIL PROTECTED] > > > > Let us all salute the Sixers on their valiant effort last night > > > > > I was rooting for them (being from Portland and a Trail Blazers fan, you > can imagine how I feel about the Lakers :-). Alas, it was a tremendous > effort, but for naught ;-(. > > Craig > >
Re: I would like to offer myself to help with documentation
does someone have an example they can shoot to me of the xml and xsl used in documentation. - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 17, 2001 6:05 AM Subject: Re: I would like to offer myself to help with documentation > Jonathan wrote: > > It would be nice if it was just simple. Stylesheets are not. Why dont we > > just use html > > Half the time, I think just to make my life more difficult ;-) > > The other half, I think so that we can > > * Ensure formatting consistency, > * Change the look without editing the content, > * Generate navigational constructs (though we could use more of this), > * and, practice what we preach. > > Most, if not all, of the Jakarta sub-project Web sites are based on XML. > > Personally, I believe there's a desperate need for more XML editing > tools. Everyone please keep posting any XML links you find here, and > I'll start a list. > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ >
Re: The documentation, xml, and stylesheets
Mike, I am forced to work with xslt every day, and each day I find a new reason to say "what in the WORLD do people see in this?!". It has its place in changing from schema to scema, but who want to get so deep into a technology which is very hard to control, and in complex schemas consumes more effort than it is worth to get what you want out of it. - Original Message - From: "Michael Westbay" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 17, 2001 7:45 PM Subject: Re: The documentation, xml, and stylesheets > Jonathan-san wrote: > > > Yea, but now I will have to learn the dtd and create complex stylesheets. > > Gentlemen. if I may be frank, this is an excercise in technical > > masturbation. If I ever want to redo it all.than I will. Stylesheets > > do not help, and those that have had to use them know exactly what I am > > talking about. > > I use them. And the more I use them, the more I like them. Just look at the > power behind the current Struts' documentation xml, namely DTD and the user > manuals for the tags get generated from a single XML file. The next logical > step is to have that XML file generated from JavaDoc, so that if the > specification of a tag changes, the change can easily be reflected in the DTD > and manual without having to edit external documents. > > I'm currently looking at the idea of creating pages in XML that generate JSP > pages (with Struts tags among others) and help HTML files. The help files > can also be processed with FOP for a PDF manual. One source, multiple > integrated, cross referenced outputs. > > No, it isn't easy. But for building a complex system where source and > documentation may be managed together, it's a very powerful tool. > > MS Word attachments and mail in HTML format (70% of the spam I recieve) get > filtered to /dev/null. I won't touch them. (Why does Outlook's HTML > messages take up to 32 times the plain text size?) In fact, lot of messages > got filtered the past couple of weeks since. Even though most of you have > HTML mail turned off, Outlook assumes that when replying to an HTML message, > you want to send in HTML format, too. Judging form the headers in my spam > log, I belive that Mozilla is equally guilty, so I'm not just picking on MS. > > Should proper mail netiquitte be included on the mail subscription page? The > FAQ that comes periodically in the DocBook mailing list spells out proper > quoting technique (snip-quote-reply) rather nicely, and establishes policies > for attachments and cross posting. > > -- > Michael Westbay > Work: Beacon-IT http://www.beacon-it.co.jp/ > Home: http://www.seaple.icc.ne.jp/~westbay > Commentary: http://www.japanesebaseball.com/ >
The documentation, xml, and stylesheets
Yea, but now I will have to learn the dtd and create complex stylesheets. Gentlemen. if I may be frank, this is an excercise in technical masturbation. If I ever want to redo it all.than I will. Stylesheets do not help, and those that have had to use them know exactly what I am talking about. - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 17, 2001 6:05 AM Subject: Re: I would like to offer myself to help with documentation > Jonathan wrote: > > It would be nice if it was just simple. Stylesheets are not. Why dont we > > just use html > > Half the time, I think just to make my life more difficult ;-) > > The other half, I think so that we can > > * Ensure formatting consistency, > * Change the look without editing the content, > * Generate navigational constructs (though we could use more of this), > * and, practice what we preach. > > Most, if not all, of the Jakarta sub-project Web sites are based on XML. > > Personally, I believe there's a desperate need for more XML editing > tools. Everyone please keep posting any XML links you find here, and > I'll start a list. > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ >
Re: [ANNOUNCEMENT] Struts 1.0 (Final) Released
Can we make a repository for all this stuff. It is not easy to have to scan all emails and put things together from that - Original Message - From: "Martin Cooper" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 17, 2001 2:48 PM Subject: Re: [ANNOUNCEMENT] Struts 1.0 (Final) Released > Yep, that looks good (but Struts' instead of Strut's). > > -- > Martin Cooper > > > - Original Message - > From: "Ted Husted" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, June 17, 2001 3:07 AM > Subject: Re: [ANNOUNCEMENT] Struts 1.0 (Final) Released > > > > How about: > > > > < ... /> > > > > * Utility classes for XML parsing, automatic JavaBean population, and > > internationalization of prompts and messages. > > > > Strut's support for internationalization builds on top of the Java > > Locale API, and has made it a popular choice for applications worldwide. > > Struts contributors include developers from Australia, France, Russia, > > and other parts of the globe. > > > > < ... /> > > > > I'm thinking of adding a "News" section to the Web site, where we can > > store such things. > > > > Martin Cooper wrote: > > > Ted, > > > Looks good. I'd like to see a little more "visibility" for the > > > internationalization capabilities in Struts, though. In my experience, > > > that's something that catches peoples' attention, because they know > they'll > > > have to do it one day, and knowing that the framework comes with built > in > > > support is a big plus. Perhaps you could add a fourth bullet that says > > > something about how the content of a page can be obtained from resources > > > based on the user's locale, or something like that. > >
Re: I would like to offer myself to help with documentation
I knowbut Ive been corrupted ;^> - Original Message - From: "Martin Cooper" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 16, 2001 10:23 PM Subject: Re: I would like to offer myself to help with documentation > I did, and it is, but it's not free. XML Cooktop is. :-) > > -- > Martin Cooper > > > - Original Message - > From: "Jonathan" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, June 16, 2001 7:04 PM > Subject: Re: I would like to offer myself to help with documentation > > > > Try xml spy. Thats a real good one > > - Original Message - > > From: "Martin Cooper" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, June 16, 2001 5:17 PM > > Subject: Re: I would like to offer myself to help with documentation > > > > > > > I've just started playing around with a free XML tool called XML > Cooktop. > > > It's pretty cool. You can load up the XML file in one tab of a window, > the > > > XSL in another, and switch to a third tab to see the result of applying > > the > > > XSL to the XML. It works just fine with the Struts docs and stylesheets, > > > including the tld stylesheet. However, it is Windows only. > > > > > > I got it from http://www.xmleverywhere.com/cooktop/. > > > > > > -- > > > Martin Cooper > > > > > > > > > - Original Message - > > > From: "Ted Husted" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Saturday, June 16, 2001 9:46 AM > > > Subject: Re: I would like to offer myself to help with documentation > > > > > > > > > > Depending on the length you should send them inline, or post them > > > > someplace for others to download. Or, if you want to send them to me, > > > > I'll post them on my Struts page. > > > > > > > > I'd be a little nervous about distributing MS Word documents myself, > > > > given the critters they can hide. > > > > > > > > The final drafts that we have to post to the Struts Web site need to > be > > > > in the XML format you would find in the source distribution. (Which is > > > > admittedly a serious pain.) > > > > > > > > Jonathan wrote: > > > > > > > > > > ok. Should I send MS word drafts to the dev list for review? > > > > > > > > > >
Re: I would like to offer myself to help with documentation
Try xml spy. Thats a real good one - Original Message - From: "Martin Cooper" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 16, 2001 5:17 PM Subject: Re: I would like to offer myself to help with documentation > I've just started playing around with a free XML tool called XML Cooktop. > It's pretty cool. You can load up the XML file in one tab of a window, the > XSL in another, and switch to a third tab to see the result of applying the > XSL to the XML. It works just fine with the Struts docs and stylesheets, > including the tld stylesheet. However, it is Windows only. > > I got it from http://www.xmleverywhere.com/cooktop/. > > -- > Martin Cooper > > > - Original Message - > From: "Ted Husted" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, June 16, 2001 9:46 AM > Subject: Re: I would like to offer myself to help with documentation > > > > Depending on the length you should send them inline, or post them > > someplace for others to download. Or, if you want to send them to me, > > I'll post them on my Struts page. > > > > I'd be a little nervous about distributing MS Word documents myself, > > given the critters they can hide. > > > > The final drafts that we have to post to the Struts Web site need to be > > in the XML format you would find in the source distribution. (Which is > > admittedly a serious pain.) > > > > Jonathan wrote: > > > > > > ok. Should I send MS word drafts to the dev list for review? > >
Re: I would like to offer myself to help with documentation
It would be nice if it was just simple. Stylesheets are not. Why dont we just use html - Original Message - From: "Alan C. Yackel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 16, 2001 7:31 PM Subject: Re: I would like to offer myself to help with documentation > "Craig R. McClanahan" wrote: > > > On Sat, 16 Jun 2001, Alan C. Yackel wrote: > > > > > > > > Another nice item would be more info on the XMLs. I've had to go > > > through the DTD files before to figure out what some attributes do. > > > A detailed description of all tags and attributes for the > > > struts-config.xml would be great. Along with the same for setting up > > > the ActionServlet in the web.xml. > > > > > > > Are these not documented in struts-config_1_0.dtd itself? There are > > pretty copious comments there about what is allowed. > > > > > Alan Yackel > > > Creatrixs INC. > > > > > > > Craig > > They are. That's where I looked to figure out what attributes to use. My point is > that in the User's Guide these tags are discussed, but only about half of the > attributes are defined for what they do. It would be nice if they were all defined > and explained why you'd use them in one easy to read document. The DTD is self > documenting, but I was thinking more along the lines of the User's Guide. > > Alan >
Re: I would like to offer myself to help with documentation
ok. So I will send you my first piece in that format. Thanks Ted.(disconnecting) - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 16, 2001 1:24 PM Subject: Re: I would like to offer myself to help with documentation > I often start with plain text since its easiest to retrofit with the XML > tags later. > > Everything we use to build the Struts documentation is in the source > download (\doc). > > Jonathan wrote: > > > > Ok. You tell me what you would like. I would like to send html for > > formatting purposes, but if you use stylesheets (which I hate but am willing > > to work with) I can send xml with a stylesheet >
Re: I would like to offer myself to help with documentation
Ok. You tell me what you would like. I would like to send html for formatting purposes, but if you use stylesheets (which I hate but am willing to work with) I can send xml with a stylesheet - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 16, 2001 12:46 PM Subject: Re: I would like to offer myself to help with documentation > Depending on the length you should send them inline, or post them > someplace for others to download. Or, if you want to send them to me, > I'll post them on my Struts page. > > I'd be a little nervous about distributing MS Word documents myself, > given the critters they can hide. > > The final drafts that we have to post to the Struts Web site need to be > in the XML format you would find in the source distribution. (Which is > admittedly a serious pain.) > > Jonathan wrote: > > > > ok. Should I send MS word drafts to the dev list for review? >
Re: I would like to offer myself to help with documentation
Also, truthfully, you could provide this System.out version with the Struts Documentation war. That way you could read, use and watch the framework simultaneously - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 16, 2001 12:38 PM Subject: Re: I would like to offer myself to help with documentation > Jonathan wrote: > > I also think that the easier it is for first timers to understand > > Struts and how it works, the more likely you will have committed users and > > thus more feedback and thus better development. > > I have been meaning to try refactoring the installation page so that it > starts with the binary distribution, and encourages trying the Struts > sample WARs first. Starting out with the prerequisites for buildling > Struts seems daunting. > > Jonathan wrote: > > Also, I think most of the explanations in available tutorials on the net are > > not clear. > > Then go for it. Scratch what itches * you * the most. >
Re: I would like to offer myself to help with documentation
ok. Should I send MS word drafts to the dev list for review? - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 16, 2001 12:38 PM Subject: Re: I would like to offer myself to help with documentation > Jonathan wrote: > > I also think that the easier it is for first timers to understand > > Struts and how it works, the more likely you will have committed users and > > thus more feedback and thus better development. > > I have been meaning to try refactoring the installation page so that it > starts with the binary distribution, and encourages trying the Struts > sample WARs first. Starting out with the prerequisites for buildling > Struts seems daunting. > > Jonathan wrote: > > Also, I think most of the explanations in available tutorials on the net are > > not clear. > > Then go for it. Scratch what itches * you * the most. >
Re: I would like to offer myself to help with documentation
Also, I think most of the explanations in available tutorials on the net are not clear. - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 16, 2001 11:40 AM Subject: Re: I would like to offer myself to help with documentation > Personally, I don't think that your questions would "clutter up" the > list. If you don't understand it, then it's (very) likely that many > others do not either. Moreover, the developer's list is intended for > discussions about developing and packaging struts, and it * is * the > appropriate place to post questions about drafting documentation. > > Are you talking about refactoring the current Users Guide, adding > additional chapters, like maybe a tutorial, or starting with a clean > slate? > > Any known documentation issues should be logged in bugzilla, which would > include enhancement requests. > > < http://nagoya.apache.org/bugzilla/ > > > I've been working on some additional material, like Strut by Strut and > the kickstart FAQ (see husted.com/about/struts). The first part of the > FAQ is really done, and I put in under the Jakarta FAQ-o-Matic (but I > see that it's down again (sigh) -- anyone what to propose an alternative > here? It's an embarrasment.) > > I'm also about ready to release a major update to Strut by Strut, but > I'm not sure whether to propose that for the package or leave it as a > Resource. > > There was also an update to the Resource page, which includes a number > of recent 3rd party tutorials and articles, but was inadvertently left > out of yesterday's 1.0. See > > < http://husted.com/about/struts/resources.html > > > for a copy of what I just added to 1.1. > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ > > Jonathan wrote: > > > > Hello all. > > It seems that there is a back log of documentation to do and I would like to > > offer to help with it as I am very good at explaining things. It also helps > > me understand the framework in a deeper way. However, because I am still > > relatively green with Struts (3 months) I will need to correspond with some > > of you outside of the list to get questions answered (I dont want to clutter > > up the list with these questions). I can complete sections according to > > when you want them, or I can do it in the order I want. > > > > If this is ok with you all and you are interested, please send me an email > > at mailto:[EMAIL PROTECTED] > > > > Let us all salute the Sixers on their valiant effort last night >
Re: I would like to offer myself to help with documentation
Really what ever is appropriate is fine. As long as you know in advance that I will be posting these questions through the process. I think the best place to start is where you feel documentation is needed most right now. I also think that the easier it is for first timers to understand Struts and how it works, the more likely you will have committed users and thus more feedback and thus better development. I also think we you all need to package a war file in which System.outs can be generated in a clear way to demonstrate the steps Struts goes through from request to response. That helps users understand visually as well as with the documentation. I know you have debug level output but they dont go method to method for EACH AND EVERY METHOD. Obviously this is not the war file to be developing with, but would be excellent to study Struts. Aside from that I think that Documentation can be done on a piece by piece basis. What do you think? - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 16, 2001 11:40 AM Subject: Re: I would like to offer myself to help with documentation > Personally, I don't think that your questions would "clutter up" the > list. If you don't understand it, then it's (very) likely that many > others do not either. Moreover, the developer's list is intended for > discussions about developing and packaging struts, and it * is * the > appropriate place to post questions about drafting documentation. > > Are you talking about refactoring the current Users Guide, adding > additional chapters, like maybe a tutorial, or starting with a clean > slate? > > Any known documentation issues should be logged in bugzilla, which would > include enhancement requests. > > < http://nagoya.apache.org/bugzilla/ > > > I've been working on some additional material, like Strut by Strut and > the kickstart FAQ (see husted.com/about/struts). The first part of the > FAQ is really done, and I put in under the Jakarta FAQ-o-Matic (but I > see that it's down again (sigh) -- anyone what to propose an alternative > here? It's an embarrasment.) > > I'm also about ready to release a major update to Strut by Strut, but > I'm not sure whether to propose that for the package or leave it as a > Resource. > > There was also an update to the Resource page, which includes a number > of recent 3rd party tutorials and articles, but was inadvertently left > out of yesterday's 1.0. See > > < http://husted.com/about/struts/resources.html > > > for a copy of what I just added to 1.1. > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ > > Jonathan wrote: > > > > Hello all. > > It seems that there is a back log of documentation to do and I would like to > > offer to help with it as I am very good at explaining things. It also helps > > me understand the framework in a deeper way. However, because I am still > > relatively green with Struts (3 months) I will need to correspond with some > > of you outside of the list to get questions answered (I dont want to clutter > > up the list with these questions). I can complete sections according to > > when you want them, or I can do it in the order I want. > > > > If this is ok with you all and you are interested, please send me an email > > at mailto:[EMAIL PROTECTED] > > > > Let us all salute the Sixers on their valiant effort last night >
I would like to offer myself to help with documentation
Hello all. It seems that there is a back log of documentation to do and I would like to offer to help with it as I am very good at explaining things. It also helps me understand the framework in a deeper way. However, because I am still relatively green with Struts (3 months) I will need to correspond with some of you outside of the list to get questions answered (I dont want to clutter up the list with these questions). I can complete sections according to when you want them, or I can do it in the order I want. If this is ok with you all and you are interested, please send me an email at mailto:[EMAIL PROTECTED] Let us all salute the Sixers on their valiant effort last night
Re: Object Models and patterns in Struts
This is interesting, but Ted, how do I read this diagram??! - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 15, 2001 11:05 AM Subject: Re: Object Models and patterns in Struts > I'd say that this is a very clear expression of where most people are > trying to go right now. > > For my own work, I'd diagram the scenario as: > > Controller Model > App Layer Business Layer > HTTP ++ +--+ > >| Action |<>| Object Model | > Request ++ +--+ >| ^ > (Request Obj)| |+--+ >| +---<| App/Sess Objects | Controller >V v| - Action Mappings| App Layer > HTTP ++| - Conn Pool | > <| JSP || - et cetera | > Response ++ +--+ >Web Layer^ > View | > [ Configuration ] > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ >
Re: Client/Server Side Validation for Struts 1.1
Also, here is a quick over view of Barracuda: 1) You make some xhtml fragments and save them as html files. That is, you make your template pieces, but you put them in html files home sign in events You would then save this as "whatever.html". Do this for all your template pieces. Notice id="menu". This identifies the tag element as "menu". Barracuda will take everything from that tag element only, to its closing tag element, and will see it as a piece of a dom tree and ignore the other tags etc(ie it will ignore the tag etc.). home sign in events It is only concerned with the pieces you gave id="" to. You then run "ant" (a "make" tool in java for those who dont know) which compiles these fragments into xml objects. Now you have a bunch of fragment objects (template pieces), and you need to put them together on some kind of "canvas" to make a complete document. In the classes provided by Barracuda, you obtain a "root" element, which is like a new white canvass an artist wuold use, and you append (like pin the tail on the donkey) each fragment on the canvass in the order you want. When the class is called, it renders the canvass object which renders each fragment on the canvass. - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 15, 2001 9:34 AM Subject: Re: Client/Server Side Validation for Struts 1.1 > I've gotten down to a 15,000 foot view of Barracuda, and it looks like > they are doing some nice work. All things remaining equal, I believe it > would be better if our approaches were compatible with Barracuda. For > example, if someone did want to do more with event processing, using as > much of Barracuda's as we can would be excellent, if nothing else is > compromised. > > I would say that having distinct ActionForm's and databeans are a > necessary evil, in order to keep Struts loosely coupled with the > business layer. Though, techniques to generate both from a common > defination would be a real leap forward. > > I'd also say that on a validation error, we should always return exactly > what the user entered without any transformations. The user's data > should be considered immutable, except by the user (at least until is > fully validated and submitted to the business layer), or by some > client-side helper that did the transformation then and there (which > would also have to be done server-side since we can't rely on the > clients!). > > David Winterfeldt wrote: > > > > I just wanted to put this out there to see what people > > think since I took the time to look at how Barracuda > > worked. I like the idea of not having two classes > > (ActionForm and a data bean), but I guess there will > > be a few different tools to autogenerate these as time > > goes by. Do you autogenerate classes based on the xml > > file? You have all the information in the xml file to > > make this possible, right? I think most of the issues > > you mention could be worked around, but you're Mapper > > idea is much more flexible. Is any source for what > > you've done available to look at or is it proprietary > > (I do have the xml file you sent to the list)? > > > > David >
Re: Client/Server Side Validation for Struts 1.1
May I make a suggestion. Consider a 3 page wizard (3 forms). you could
have a wrapper bean for all three forms like we do in EJB with enterprise
beans and dependent objects, but this would be for the front end. that way
you could even reuse ActionForm(s).
Ex.
1st page = name/address
2nd page = purchase items
3rd page = credit card information
Each ActionForm bean would be an attribute to a bean called
PurchaseValueObjectBean
PurchaseValueObjectBean{
NameAddressForm
PurchaseItemsForm
CreditCardInfo
validate()
}
I could then call validate() on the PurchaseValueObjectBean which would call
validate on all three beans.
Of course this is assuming that the PurchaseValueObjectBean must know about
the beans it holds, and it should I believe.
Any ideas?
- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 9:34 AM
Subject: Re: Client/Server Side Validation for Struts 1.1
> I've gotten down to a 15,000 foot view of Barracuda, and it looks like
> they are doing some nice work. All things remaining equal, I believe it
> would be better if our approaches were compatible with Barracuda. For
> example, if someone did want to do more with event processing, using as
> much of Barracuda's as we can would be excellent, if nothing else is
> compromised.
>
> I would say that having distinct ActionForm's and databeans are a
> necessary evil, in order to keep Struts loosely coupled with the
> business layer. Though, techniques to generate both from a common
> defination would be a real leap forward.
>
> I'd also say that on a validation error, we should always return exactly
> what the user entered without any transformations. The user's data
> should be considered immutable, except by the user (at least until is
> fully validated and submitted to the business layer), or by some
> client-side helper that did the transformation then and there (which
> would also have to be done server-side since we can't rely on the
> clients!).
>
> David Winterfeldt wrote:
> >
> > I just wanted to put this out there to see what people
> > think since I took the time to look at how Barracuda
> > worked. I like the idea of not having two classes
> > (ActionForm and a data bean), but I guess there will
> > be a few different tools to autogenerate these as time
> > goes by. Do you autogenerate classes based on the xml
> > file? You have all the information in the xml file to
> > make this possible, right? I think most of the issues
> > you mention could be worked around, but you're Mapper
> > idea is much more flexible. Is any source for what
> > you've done available to look at or is it proprietary
> > (I do have the xml file you sent to the list)?
> >
> > David
>
Re: WhoWeAre
Mike, I'm from Lower merion and I went to Penn. My cousin is an engineer at Drexel. - Original Message - From: "SCHACHTER,MICHAEL (HP-NewJersey,ex2)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 14, 2001 11:27 AM Subject: RE: WhoWeAre > Ted, > > If you could add this for me I'd appreciate it: > > --- > Mike Schachter > I'm currently a student of computer > science at Drexel University in Philadelphia, PA. > I've been working at HP Middleware, formerly > Bluestone Software for 3 years programming in > Java and recently J2EE technologies. I'm a full > time worker from September until April and a student > and part time worker from April until August. > In my spare time I've been known to run monkey-knife > fights in a shady south philly warehouse. Err... > I mean... nothing. > > > > -Original Message- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 14, 2001 8:33 AM > To: [EMAIL PROTECTED] > Subject: WhoWeAre > > > I'm going to slip a WhoWeAre page to the documentation later today, > listing the contributors and Committers. > > This would go over the WhoWeAre text that is in the root folder of the > distribution. Craig and I have longish bios there. If any other > Committers would like to send me theirs, I'll include them in the > update. > > Source Code Contributors > > Arun M. Thomas > Chris Audley > Craig R. McClanahan > David Geary > Don Clasen > Florent Carpentier > Jeff Hutchison > Jimmy Larsson > Luis Arias > Marius Barduta > Mike Schachter > Niall Pemberton > Ralph Schaer > Rob Leland > Sean Kelly > Ted Husted > > > User Guide Contributors > --- > Chris Assenza > Craig R. McClanahan > David Geary > dIon Gillard > Eric Wu > John Rousseau > Larry McCay > Martin Cooper > Matthias Kerkhoff > Mike Schachter > Robert Hayden > Stanley Santiago > Ted Husted > Wong Kok Kai > > > Active Committers > - > Craig R. McClanahan ([EMAIL PROTECTED]) > David Geary ([EMAIL PROTECTED]) > Michael Schachter ([EMAIL PROTECTED]) > Ted Husted ([EMAIL PROTECTED]) > Rob Leland ([EMAIL PROTECTED]) > Vincent Massol ([EMAIL PROTECTED]) > Cedric Dumoulin ([EMAIL PROTECTED]) > Martin Cooper ([EMAIL PROTECTED]) > > > Emeritus Committers > --- > + Luis Arias > + Pierre Delilse > > > More About Us ... > -- > > < Craig and Ted hyperbole /> > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ >
Re: Workflow Context
My group is thinking of 4 new scopes.
1) Workflow scope - last as long as the set of steps in a task you are
completeing
2) our own HttpSession object
3) publication scope
4) publication group scope
We are a publishing company with many reports and magazines
- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 13, 2001 8:40 AM
Subject: Workflow Context
> Something that has come up now and again is the idea of a "workflow"
> context - more than a single request but less than a session.
>
> Towards that end, I've been experimenting with placing a Hashtable in
> the session where I can store objects between requests, and remove them
> when the mutli-request task is complete. I'm calling this a "Registry".
>
> My current test case is leaving an input form to go off and look up some
> foreign keys, and then have the keys filled in when you get back.
>
> To do this, I put an extra submit button next to the foreign keys. When
> the action sees one of these come in, it puts the ActionForm in the
> registry, and forwards to a search form for the key.
>
> String pickDonor = request.getParameter("pickDonor");
> if (pickDonor!=null) {
> servlet.log("item.Access: Saving itemForm in Registry",2);
> registry.put(formName,thisForm);
> return mapping.findForward("pickDonor");
> }
>
> The data access Actions in the application register a form's key
> property when appropriate:
>
> // Remove or update donor key
> if (task.equals("delete"))
> registry.remove(formKey);
> else
> registry.setString(formKey,thisForm.getKey());
>
> This is stateless and happens whenever the key is accessed.
>
> Later, when they request an input form, the Action checks the registry:
>
> // -- Check registry; repopulate bean if form not finished
> if (registry.containsKey(formName)) {
> servlet.log("item.Input: Restoring itemForm from Registry",2);
> Form itemForm = (Form) registry.remove(formName);
> try {
> BeanUtils.populate(thisForm,itemForm.getMap());
> }
> // :TODO: Generate "unexpected error" message
> catch (IllegalAccessException iae) {;}
> catch (InvocationTargetException ite) {;}
> thisForm.resetKeys(mapping,request);
> }
>
> You will note that the final trick is a "resetKeys()" method on the
> ActionForm, which sets any foreign keys it is watching from the
> registry, or to a default value is there is no registry key.
>
> The registry is being setup when they login. If I keep this structure, I
> could also keep the loginBean there so that my application just has the
> one session object to manage.
>
> I'll be testing and refining this approach more today, and just wondered
> if anyone else is working in this area.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
Re: Client/Server Side Validation for Struts 1.1
I totally agree. Its seems like a one or two man show. If I didnt have
immediate needs and a restriction to jsp because of fear of new things, I
would be playing around with it more. I just dont like apps too heavily
reliant on xml because my collegues and I are having a real hard time with
it. Xml is very picky, and I hate xslt for presenation with very few
exceptions. Their validation is pretty far along, maybe as old as struts.
I read about Enhydra atleast a year or a year and a half ago. Barracuda's
founder is on the Struts list, and I am on the Barracudas list. It doesnt
have as much activity and it seems as though they are still working out some
larger bugs.
- Original Message -
From: "David Winterfeldt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2001 12:31 AM
Subject: Re: Client/Server Side Validation for Struts 1.1
> I just saw the type conversion thread going on in the
> user list, but I've thought about this for a bit and
> you mentioned possibly modeling or taking code from an
> existing framework.
>
> How closely have you looked at Barracuda Ted? Some of
> what they do is interesting. I think we could make an
> ActionForm derivitive that loosely followed their
> steps in processing an object.
>
> Barracuda
> -
> FormMap
>FormElement
> key - the key/property name
> type - the FormType (ie. String, Boolean,
> Integer, etc)
> defaultVal - the default value (ie. the value to
> be used if the key is not present in the form source)
> validator - FormValidators responsible for
> validating this particular element
> allowMultiples - is it possible for this key to
> have multiple values in the form source
>
>
> add these other fields to the field element in the
> valdation.xml
>
> public class BarracudaActionForm extends ActionForm {
>Map formMap = new HashMap();
>
>public Map getFormMap() { return formMap; }
>
>public void setFormMap(Map formMap)
>this.formMap = formMap;
>}
>
>public void reset(ActionMapping mapping,
> HttpServletRequest request) {
> formMap.clear();
>}
>
> }
>
> populate map
>
> perform transformations from map to real objects using
> subclasses of java.text.Format as Rey Francois has
> suggested, if the transformation was successful remove
> the item from the Map. (Struts html tags would need to
> be able to try the Map first and then the actual
> ActionForm property. This could tie in with a dynamic
> ActionForm class)
>
> populate default values
>
> perform other validations
>
> Or we could make a transformation class for the
> general transformation package you suggested and you
> would pass in any two JavaBeans and it could map
> values between the two. Something like this could be
> used from a short cut method in the ActionForm.
>
> public Object getDataBean() {
>// Class name could come from an xml
> transform/mapping file
>Object bean =
> Class.forName(className).newInstance();
>Transformation.transform(this, bean);
>return bean;
> }
>
> It seems from discussions that most people would
> prefer the latter based on current usage on the lists,
> but you wouldn't need two classes with the first
> approach and it is from a working framework. What is
> your opinion?
>
> David
>
>
> --- Ted Husted <[EMAIL PROTECTED]> wrote:
> > I still have the feeling that we lack a decent
> > foundation package to do
> > the grunt work of typecasting and String formatting,
> > so that things like
> > a Validation servlet and something like a
> > > picture="##/##/##" > tag could share a common
> > codebase.
> >
> > We might want to start with something like this:
> >
> > <
> >
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01522.html
> > >
> >
> > Perhaps as an extension to java.text.Format, as Rey
> > Francois has been
> > suggesting:
> >
> > <
> >
> http://www.mail-archive.com/struts-user@jakarta.apache.org/msg02711.html
> > >
> >
> > And then look at how we can use this package to
> > extend the Validation
> > servlet and enhance the bean tags.
> >
> > It's a little confusing now, since validations,
> > conversions, and
> > transformations and are closely linked, but appear
> > at different points
> > in the input / store / output continuum. Even so, I
> > think the processes
> > have enough in common to create a cohesive package,
> > even if you would
> > not use every method on any one layer of a MVC
> > application.
> >
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Custom Software ~ Technical Services.
> > -- Tel 716 737-3463.
> > -- http://www.husted.com/about/struts/
>
>
> __
> Do You Yahoo!?
> Spot the hottest trends in music, movies, and more.
> http://buzz.yahoo.com/
>
Re: Re[2]: New BeanFactory build
Thanks Oleg. Can you give me a detsiled step-by-step from the point a form is submitted until the Action perform(). - Original Message - From: "Oleg V Alexeev" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Jonathan Asbell" <[EMAIL PROTECTED]> Sent: Wednesday, June 13, 2001 3:33 PM Subject: Re[2]: New BeanFactory build > Hello Jonathan, > > It is easy stuff. 8) For me, of course, but not for another people, > because it lives in my head... Now I trying to write documentation for > bean-factory - hard work really. One little step to implement idea in > code and another - great step - to describe it in clear manner. > > Main idea is to build common mechanism to declare bean descriptions in > config file and generate it automatically at request processing. > Core class is BeanFactoryServlet - it extends ActionServlet, defines > additional digester calls and overload > ActionServlet.processPreprocess() method. New version of this method > do all work to generate beans after form processing and before action > calling. > > There are exists such abstractions as - > > 1. factory - class to generate beans > 2. template - bean description > 3. parameter - parameter decribtion for the bean-template > 4. registration - subscribtion to bean generation in action mapping > 5. parameter-value - setter for parameter in registration > > Here is a sample config with comments - > > > > > > autoCommit="false" > description="INET" > driverClass="COM.ibm.db2.jdbc.app.DB2Driver" > url="jdbc:db2:TEST" > maxCount="3" > minCount="1"> > > > > > > > > > > > > > > > > > > > type="org.apache.struts.factory.jdbc.JDBCArrayFactory" > className="org.apache.struts.factory.jdbc.JDBCFactoryMapping"/> > > > > type="org.apache.struts.factory.jdbc.JDBCSlideFactory" > className="org.apache.struts.factory.jdbc.JDBCFactoryMapping"/> > > > > type="org.apache.struts.factory.jdbc.JDBCSingleFactory" > className="org.apache.struts.factory.jdbc.JDBCFactoryMapping"/> > > > > > > > > > > name="query" > type="java.lang.String" > value="select * from bf.sample where id = ?" > force="true"/> > > > > > > > name="query" > type="java.lang.String" > value="SELECT id, name FROM bf.sample" > force="true"/> > > > > > > name="query" > type="java.lang.String" > value="SELECT id, name FROM bf.sample" > force="true"/> > > > > > > > > name="query" > type="java.lang.String" > value="SELECT id, name FROM bf.sample where id > ?" > force="true"/> > > > > > > > > > > > > > > > > > > > > > > > > > type="org.apache.struts.actions.ViewAction"> > > > > > > > > type="org.apache.struts.actions.ViewAction"> > > > > > type="org.apache.struts.actions.ViewAction"> > > > > > type="org.apache.struts.actions.ViewAction"> > > > > > type="org.apache.struts.actions.ViewAction"> > > > > > > > > Wednesday, June 13, 2001, 4:56:27 PM, you wrote: > > JA> Hello Oleg. > JA> I have been following your progress on your bean-factory, and have > JA> downloaded the classes. However, I still have not fully grasped what it is > JA> substituting in struts, and what the sequence of events is when they are > JA> called and used. Could you provide a brief summary and sequence of events? > JA> I was not able to get a complete picture of what is happening from the > JA> earlier e-mails to the list. > > JA> Sincerely > JA> Jonathan > > JA> - Original Message - > JA> From: "Oleg V Alexeev" <[EMAIL PROTECTED]> > JA> To: <[EMAIL PROTECTED]> > JA> Sent: Wednesday, June 13, 2001 8:29 AM > JA> Subject: New BeanFactory build > > > >> Hello struts-dev, > >> > >> This day (13 June) I place new build of BeanFactory (Struts extension > >> to support unattended bean generation at pre action processing) > >> > >> Last additions - hard parameter setters for bean registrations, new > >> Pager version, new PagerTag class - wrapper around Pager class (sample > >> of using in pager.jsp in sample application). > >> > >> You can review it here - > >> > >> http://www.sura.ru/~gonza/bean-factory/ > >> > >> -- > >> Best regards, > >> Oleg mailto:[EMAIL PROTECTED] > >> > >> > > > > -- > Best regards, > Olegmailto:[EMAIL PROTECTED] > >
Re: New BeanFactory build
Hello Oleg. I have been following your progress on your bean-factory, and have downloaded the classes. However, I still have not fully grasped what it is substituting in struts, and what the sequence of events is when they are called and used. Could you provide a brief summary and sequence of events? I was not able to get a complete picture of what is happening from the earlier e-mails to the list. Sincerely Jonathan - Original Message - From: "Oleg V Alexeev" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 13, 2001 8:29 AM Subject: New BeanFactory build > Hello struts-dev, > > This day (13 June) I place new build of BeanFactory (Struts extension > to support unattended bean generation at pre action processing) > > Last additions - hard parameter setters for bean registrations, new > Pager version, new PagerTag class - wrapper around Pager class (sample > of using in pager.jsp in sample application). > > You can review it here - > > http://www.sura.ru/~gonza/bean-factory/ > > -- > Best regards, > Oleg mailto:[EMAIL PROTECTED] > >
Re: Handling session timeouts
Hi Andreas. You only need to use the token in pages that have forms, because this is the only situation in which you are concerned about this problem happening. So, if you have come upon the first page in a series of forms, set the token upon hitting that first page, and do this for each consecutive participating form in the wizard. That way, if you made it to the third page, you will have generated 3 different tokens of which you used 2. The third token is in session unless the session is lost. The hidden tag IS still in the page however. So, if you go away to have a Hoagie(I'm from Philly, its a sub sandwich) and return in 40 minutes, and the session has been lost, the hidden field value will not match the value in session because it wont be there. Walla! It wont submit. You just need to make sure that the user is forwarded to an appropriate page, like either the forst page in the wizard or somewhere else. - Original Message - From: "Andreas Prohaska" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 12, 2001 4:00 AM Subject: RE: Handling session timeouts > > > Of course, tokens will help here. I could also put a special attribute > into each session and check this attribute in each action. But there are > two points I don't like here. > > * There must be at least one action where I create this attribute. And at > least in this action I do not know, if I have a new session or a re- > created one. To make the problem worse we do not require the user to log > in. So we have no special login page we could use for this purpose. > Basically the user may visit almost any page first. > > * I have to check for this attribute in *every* action and on *every* JSP > page. This could be done by creating my own Action base class, of course, > but somehow I don't like the idea (however I can't say why :-) ). > > I don't really know how to solve the problem with the JSPs. I would have > created a special tag that checks if the session is new or not. This is > bad but seems to be the only solution. Besides, I would never call JSPs > directly, but some people might want (or have) to do this. > > I didn't know that Servlet 2.3 will solve these problems, but what can > we do until then? > > andreas > > > > -Original Message- > > From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, June 12, 2001 6:07 AM > > To: Craig R. McClanahan; [EMAIL PROTECTED] > > Subject: Re: Handling session timeouts > > > > > > No Craig. If his session times out, it will loose the token > > in the session. > > Thus the page will not submit because the token in the > > session will not > > match the one in the hidden field. > > > > > >
Re: Handling session timeouts
No Craig. If his session times out, it will loose the token in the session. Thus the page will not submit because the token in the session will not match the one in the hidden field. - Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Jonathan Asbell" <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 11:07 PM Subject: Re: Handling session timeouts > > > On Mon, 11 Jun 2001, Jonathan Asbell wrote: > > > Craig, I thoght the token mechanism could have helped here. Am I wrong? > > Tokens will definitely help avoid the problem of pressing Reload, or > pressing Back Arrow and then submitting again, but they don't do anything > particularly useful in regards to detecting timeouts. > > Craig >
Re: Handling session timeouts
Craig, I thoght the token mechanism could have helped here. Am I wrong? - Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 10:30 PM Subject: Re: Handling session timeouts > On Wed, 6 Jun 2001, Andreas Prohaska wrote: > > > > > This was originally posted to the struts-user list, but Ted Husted pointed > > out that I should better discuss this on the development list. > > > > For the guys that are not listening to the user list, the background: We > > have written a wizard for a larger input process that requires some steps. > > We use one ActionForm bean for this wizard that keeps the data in the > > session context (everything done by struts). When I wanted to go to the next > > step I recognized that all my data from the previous steps was lost and > > instead I had the default values. Obviously a session timeout occured and > > the original ActionForm was removed. Then a new session was automatically > > created and a new ActionForm bean was automatically added to the session > > context. Normally this is nice, but there was no way for my Action class or > > JSP to see that in fact the session was lost and the data was wrong. > > > > Now I would recommend to place a method like processSession() at the start > > of the process() method in the ActionServlet. This could be changed by > > subclasses of the ActionServlet in order to intercept session creation and > > deprecation. OR it should call some more specialized class for this (say > > SessionManager). The advantage of this approach would be that we could also > > introduce a new tag that calls the same class in order to > > intercept session creation in JSP pages (that might be called directly). > > > > If the list decides that this could be nice, I would make the changes but > > then I need to know how I can submit them :-) > > > > What do you think? > > > > In servlet 2.2, there is *no* general event handling mechanism that can > catch a session creation no matter where it happened. In order to make > something like this work in Struts, we would have to place restrictions > like this: > > * The action cannot call request.getSession() -- it must call some > Struts-provided method that will detect the creation. > > * The user cannot *ever* call a JSP page directly, because the session > will be created (or recreated) as necessary. > > Most people work around this by a strategy like this: > > * At logon time, place an attribute into the session under a > well-known key. The Struts example app uses the User object > for this purpose. > > * At the beginning of each action (or page), check for the > existence of the well-known attribute. If it is missing, > this is a new session (possibly a replacement for a timed-out > one). In the example app, there's an custom > tag that can do this. > > * If a session times out (or is invalidated), all of the attributes > will be removed. If you want to know when either of these things > happens, simply make your attribute implement HttpSessionBindingListener > and it will be notified at timeout or invalidate time. > > The servlet 2.3 specification includes new application event listeners for > session created, session destroyed, and add/change/delete of session > attributes. Then you'll be able to build apps that react to such events > without having to involve specific attributes -- but until then we are > kind of stuck. > > > > > Andreas > > > > Craig McClanahan >
Re: [PROPOSAL] Struts Extensions
What about just creating servlets in war files which you just drop in and deploy. That is the most plug-and-play I can think of - Original Message - From: "Alan C. Yackel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 10, 2001 6:17 PM Subject: Re: [PROPOSAL] Struts Extensions > A good way to integrate each extension would be to great an Inteface > that each extension needs to implement. Then the ActionServlet can call > certail methods to initialize the extension. Have a method to set up > the digester, one for logging, a generic one, whatever we need. Then > register each extension with in the struts-config file with the class > name that implements the interface and maybe a configuration file for it > also. > > Alan Yackel > CTO > Creatrixs INC. > > > Ron Smith wrote: > > > I have a couple subsystems (data access subsystem, > > authorization, logging, etc..) that I initialize by extending > > ActionServlet. It would be nice to not have to extend > > ActionServlet and initialize each extension/subsystem manually. > > > > One approach would be to trigger initialization of the > > services off of the struts-config.xml. > > For each service you want to use, you'd just list it in > > your struts-config.xml: > > . > > > > Another issue is how to configure these extensions/subsystems. > > Right now I'm using the Digester class to configure > > my subsystems off of seperate config files. > > Each subsystem having its own configuration file > > is simple (e.g. each config file can have a separate > > format and DTD, and each subsystem can register > > its own configuration rules with the Digester), > > but you end up having to manage > > a bunch of configuration files instead of just one. > > > > By the way, thanks to whoever worked on the Digester - > > very useful and a breeze to use. > > > > --Ron > > > > David Winterfeldt wrote: > > > > > It might be nice if there was a way to register an > > > interface with the ActionServlet in the config file > > > for it to initialize a service. All the > > > ValidatorServlet I made does is parse the xml file > > > with the Digester and put an object into application > > > scope. If a class could be registered, then a servlet > > > wouldn't hang around for no reason and it wouldn't > > > need to be defined in the web.xml. And it sounds like > > > a lot of people extend the ActionServlet just to > > > initialize resources on startup. > > > > > > David > > > > > > --- Ted Husted <[EMAIL PROTECTED]> wrote: > > > > I agree that most extensions would be best written > > > > as independant > > > > servlets that plug into the application alongside > > > > the Struts > > > > ActionServlet. Though, I'm not sure they would need > > > > to register with the > > > > ActionServlet to access other parts of the > > > > framework. > > > > > > > > I haven't worked with the Digester directly, but > > > > most of the other > > > > Struts services are already exposed through the > > > > application context. > > > > Custom tags, for example, already access the Action > > > > Mappings this way. > > > > So any other servlet in the application (since > > > > that's all JSP's are) > > > > should be able to do the same. > > > > > > > > Another example is the Generic Connection Pool. The > > > > datasource is > > > > exposed through the application context and other > > > > services, like the > > > > TagLibs JDBC tags, can use the pool without knowing > > > > anything about > > > > Struts (or Struts knowing anything about them). > > > > > > > > So I would suggest that if there are other services > > > > that an extension > > > > needs to share that we expose them through the > > > > Application context. > > > > > > > > Oleg V Alexeev wrote: > > > > > > > > > To support flexible extensions mechanism for > > > > struts there are can be > > > > > made some additions to the core structure of the > > > > framework - > > > > > > > > > > 1. Add ability to register components or external > > > > servlets (at > > > > >application level) via struts-config file. > > > > > 2. Give such external components or servlets > > > > ability to use action > > > > >mappings database from ActionServlet. > > > > > 3. Extend core API of struts to support pluggable > > > > extensions - for > > > > >example use event model or direct calls via > > > > registrations in action > > > > >mappiongs database. > > > > > > > > > > The best way for my mind is to write external > > > > servlets, register it in > > > > > struts ActionServlet and use it as external > > > > services. This approach > > > > > can be useful in case of mutliple ActionServlet > > > > instances in one > > > > > application - every ActionServlet subscribe to use > > > > and uses some > > > > > amount of external services. > > > > > > __ > > > Do You Yahoo!? > > > Get personalized email addresses from Yahoo! Mail - only $35 > > > a year! http://personal.mail.yahoo
Re: Handling session timeouts
why not use the token mechanism. Doesnt it handle this already? - Original Message - From: "Martin Cooper" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 10, 2001 2:02 AM Subject: Re: Handling session timeouts > Why not just add a property to your form bean to detect this? Then you can > do the following: > > - When the bean is constructed, the 'valid' property is set to false. > - When the action sets up the bean for display, it sets 'valid' to true. > - The JSP checks the 'valid' property before using the values from the form > bean. > > This way, if the form bean is created by Struts, but not populated by your > action, the 'valid' property will be false, thus detecting the situation you > described. > > Hope this helps. > > -- > Martin Cooper > > > - Original Message - > From: "Andreas Prohaska" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, June 06, 2001 4:15 AM > Subject: Handling session timeouts > > > > > > This was originally posted to the struts-user list, but Ted Husted pointed > > out that I should better discuss this on the development list. > > > > For the guys that are not listening to the user list, the background: We > > have written a wizard for a larger input process that requires some steps. > > We use one ActionForm bean for this wizard that keeps the data in the > > session context (everything done by struts). When I wanted to go to the > next > > step I recognized that all my data from the previous steps was lost and > > instead I had the default values. Obviously a session timeout occured and > > the original ActionForm was removed. Then a new session was automatically > > created and a new ActionForm bean was automatically added to the session > > context. Normally this is nice, but there was no way for my Action class > or > > JSP to see that in fact the session was lost and the data was wrong. > > > > Now I would recommend to place a method like processSession() at the start > > of the process() method in the ActionServlet. This could be changed by > > subclasses of the ActionServlet in order to intercept session creation and > > deprecation. OR it should call some more specialized class for this (say > > SessionManager). The advantage of this approach would be that we could > also > > introduce a new tag that calls the same class in order to > > intercept session creation in JSP pages (that might be called directly). > > > > If the list decides that this could be nice, I would make the changes but > > then I need to know how I can submit them :-) > > > > What do you think? > > > > Andreas > > > > > > Andreas Prohaska Mail: [EMAIL PROTECTED] > > Apeiron GmbH Tel : +49 (089) 278257-40 > > Hohenzollernstr. 81 Fax : +49 (089) 278257-49 > > 80796 Muenchen > > > >
Re: Work flow RFC
Is there anyone on the list that actually HAS experience developing with workflow engines? - Original Message - From: "Rey Francois" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 4:40 AM Subject: RE: Work flow RFC > Another possibility is to develop extensions for the TogetherJ CASE tool. It > is entirely written in Java, therefore can run on most platform, and from my > understanding it is possible to define new diagram types and patterns. > > This may not directly relate to workflow, but we have in our team created > the concept of a request servicing diagram which is a class diagram > representing the objects involved in servicing a request. Particularly on > this diagram we display the request object and the action it is mapped to. > Although we have not done it yet, it is quite possible to develop a pattern > that generates the corresponding action mapping entry in the > struts-config.xml, and vice-versa. > > François Rey > Financial WebSuite > Capco > http://www.capco.com/ > > > -Original Message- > From: Craig Tataryn [mailto:[EMAIL PROTECTED]] > Sent: 05 June 2001 20:06 > To: Jonathan > Cc: [EMAIL PROTECTED] > Subject: Re: Work flow RFC > > > Is this a workflow editor or just a configuration editor (which would be > nice > for struts)? > > craig. > > Jonathan wrote: > > > Again, Ive got to say look at the Barracuda project. They have one of > these > > gui configurers. Check it out at > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event > > > > - Original Message - > > From: "Craig Tataryn" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, June 05, 2001 12:28 PM > > Subject: Work flow RFC > > > > > Hi, I would like your comments for the workflow item on our TODO list. > > > Currently this is how I've envisioned the workflow project: > > > > > > 1) A nice GUI type Applet or Application that has visual constructs > > > which can be connected in a Visio type manner to create an Activity > > > diagram or some other type of flow diagram. > > > > > > 2) This diagram will be persisted in an XML file which holds meta data > > > for the elements in diagram (position, type of construct (controller, > > > flat html page, cgi script, flow arrow, etc..)). > > > > > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > > > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > > > > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > > > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > > > course some sort of "pretty layout" code would have to be used to > > > un-jumble the mess of constructs that are sucked out of the > > > struts-config.xml file (i.e. take a guess at proper positioning > > > information). > > > > > > The GUI should employ some sort of extensibility mechanism like BSF > > > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > > > (http://www.beanshell.org/) to allow users to plug-in their own > > > functionality (i.e. validation code) without jeopardizing the core code > > > (what I call the Emeril Lagasse technique -- BAM!). > > > > > > I realize this is a very high level look at the TODO but I think as we > > > get more comments we will get more granular and can start dishing out > > > segments. > > > > > > Let me know what you think. > > > > > > > > > > > > The information in this email is confidential and is intended solely > for the addressee(s). > Access to this email by anyone else is unauthorised. If you are not > an intended recipient, you must not read, use or disseminate the > information contained in the email. > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Capco. > > http://www.capco.com > *** >
Re: Handling session timeouts
implement something using the HttpSessionBindingListener. We could serialize the data, or at least know that we lost the session data - Original Message - From: "Andreas Prohaska" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 7:15 AM Subject: Handling session timeouts > > This was originally posted to the struts-user list, but Ted Husted pointed > out that I should better discuss this on the development list. > > For the guys that are not listening to the user list, the background: We > have written a wizard for a larger input process that requires some steps. > We use one ActionForm bean for this wizard that keeps the data in the > session context (everything done by struts). When I wanted to go to the next > step I recognized that all my data from the previous steps was lost and > instead I had the default values. Obviously a session timeout occured and > the original ActionForm was removed. Then a new session was automatically > created and a new ActionForm bean was automatically added to the session > context. Normally this is nice, but there was no way for my Action class or > JSP to see that in fact the session was lost and the data was wrong. > > Now I would recommend to place a method like processSession() at the start > of the process() method in the ActionServlet. This could be changed by > subclasses of the ActionServlet in order to intercept session creation and > deprecation. OR it should call some more specialized class for this (say > SessionManager). The advantage of this approach would be that we could also > introduce a new tag that calls the same class in order to > intercept session creation in JSP pages (that might be called directly). > > If the list decides that this could be nice, I would make the changes but > then I need to know how I can submit them :-) > > What do you think? > > Andreas > > > Andreas Prohaska Mail: [EMAIL PROTECTED] > Apeiron GmbH Tel : +49 (089) 278257-40 > Hohenzollernstr. 81 Fax : +49 (089) 278257-49 > 80796 Muenchen > >
Re: Work flow RFC
Well Josh, if you have an idea please share it. I am all ears. How would you do workflow with xml? - Original Message - From: "Joshua Yip" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 10:53 PM Subject: Re: Work flow RFC > Are you trying to develop an workflow application using purely servlets and > jsp? > > XML is the future! > > Joshua Yip > Software Developer > IB-DOCS.COM > Intelligent Business Document dot Com > Office email: [EMAIL PROTECTED] > Personal Email:[EMAIL PROTECTED] > YahooID: joshuayip > ICQ:8657630 > > - Original Message - > From: "Ted Husted" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, June 06, 2001 12:48 AM > Subject: Re: Work flow RFC > > > > I'm still fuzzy on the mechanism we would use to represent and enforce > > the workflow. There has been mention of things like command tokens, but > > are any code samples available. > > > > Can anyone explain how Barracuda implements their workflow, and whether > > it could be mapped to the Struts Actions/ActionMappings model? > > > > I believe Barracuda and Struts are complementary in most ways, and it > > would be in our best interest to adopt and adapt rather than > > roll-our-own, if feasible. > > > > Jonathan wrote: > > > > > > Again, Ive got to say look at the Barracuda project. They have one of > these > > > gui configurers. Check it out at > > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event >
Re: Work flow RFC
Good catch. Well, that just means that it is an issue across the board. Lets get a list together of possible approaches and put it up somewhere for us to comment on and review. - Original Message - From: "Frye, Dave" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 2:22 PM Subject: RE: Work flow RFC > >From Barracuda's Scope Summary (see, > http://barracuda.enhydra.org/Barracuda/docs/scope_summary.html#2.4), > Barracuda's scope explicitly excludes application flow control. > > didge > > -Original Message- > From: Jonathan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 05, 2001 9:34 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Work flow RFC > > > Again, Ive got to say look at the Barracuda project. They have one of these > gui configurers. Check it out at > http://barracuda.enhydra.org/Barracuda/GetBConfig.event > > > - Original Message - > From: "Craig Tataryn" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 05, 2001 12:28 PM > Subject: Work flow RFC > > > > Hi, I would like your comments for the workflow item on our TODO list. > > Currently this is how I've envisioned the workflow project: > > > > 1) A nice GUI type Applet or Application that has visual constructs > > which can be connected in a Visio type manner to create an Activity > > diagram or some other type of flow diagram. > > > > 2) This diagram will be persisted in an XML file which holds meta data > > for the elements in diagram (position, type of construct (controller, > > flat html page, cgi script, flow arrow, etc..)). > > > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > > course some sort of "pretty layout" code would have to be used to > > un-jumble the mess of constructs that are sucked out of the > > struts-config.xml file (i.e. take a guess at proper positioning > > information). > > > > The GUI should employ some sort of extensibility mechanism like BSF > > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > > (http://www.beanshell.org/) to allow users to plug-in their own > > functionality (i.e. validation code) without jeopardizing the core code > > (what I call the Emeril Lagasse technique -- BAM!). > > > > I realize this is a very high level look at the TODO but I think as we > > get more comments we will get more granular and can start dishing out > > segments. > > > > Let me know what you think. > > > > > > >
Re: Work flow RFC
The lead on the Barracuda project is a subscriber to the Struts list! Christian Cryder ([EMAIL PROTECTED]) He was the one who said he likes to "lurk" and spoke about security on Monday May 7, "RE: Potential Security Flaw in Struts MVC" - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 12:48 PM Subject: Re: Work flow RFC > I'm still fuzzy on the mechanism we would use to represent and enforce > the workflow. There has been mention of things like command tokens, but > are any code samples available. > > Can anyone explain how Barracuda implements their workflow, and whether > it could be mapped to the Struts Actions/ActionMappings model? > > I believe Barracuda and Struts are complementary in most ways, and it > would be in our best interest to adopt and adapt rather than > roll-our-own, if feasible. > > Jonathan wrote: > > > > Again, Ive got to say look at the Barracuda project. They have one of these > > gui configurers. Check it out at > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event >
Re: Client/Server Side Validation for Struts 1.1
I still think it may be better to have one validation package and a bunch of filter/transformers for each lnaguage and local you want to support. That way the user can enter in data in the way he/she is accostomed, and we developers who are aware of such differences can convert the users format into our own which we use to process and validate. When you want to add a language and or local, just make a filter/converter for it, and use the exact same validation package without having to add to it for each local/language. Would love to hear any comment on this. cheers Jonathan - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 10:55 AM Subject: Re: Client/Server Side Validation for Struts 1.1 > > Memo from Nic Hobbs of PricewaterhouseCoopers > > Start of message text > > Firstly let me apologise for my lack of communication recently - we have > had some deadlines on our project that have kept me busy. I have been > lurking and listening to the discussions though, but find I often am too > late to reply to things - when I get around to it someone has already > answered the question! Especially with most of you being in a different > time zone ;) > > Anyway, on to the point. I agree that we need to distinguish between the > view and the model here. It has long been a concern of mine, coming from a > languages and linguistics background originally that, especially in the > java world, locales are too simplified for many of the reasons that have > been mooted here. > > However, I don't think we need to complicate things too much. William is > right by saying that, in the example of currencies, the calcualation of the > value in different currencies is the responsilibity of the business logic, > whether by a feed or a static table or however. The responsibility of the > view is just to render it with the correct currency format. > > This however, doesn't answer the questions of our now well mooted Spanish > speaking, mexican ex-pat, californian trying to buy in Brazil (phew...). I > would like to point something out on this score though. The chances are > that if our mexican friend is accessing a brazilian website the values they > will be seeing will be in the currency of that country rather than in their > own. So several things: a) we cannot just use their local to render the > values as this will list them in US dollars and b) for most sites the > closest they get to showing currency conversions is a link to an external > site that does this sort of thing, so we don't have to worry about > conversion c) we can only really validate an address against a PAF (an > address/postcode file in the UK) or its equivalent. > > This leaves us with an interesting scenario. We have found that the locale > needed to render the values is in fact that of the server rather than the > client (which is not the current struts approach) and that in order for the > customer to complete their order they will need to enter in an address > which is in their locale and not the server's (ie potentially different > postcodes (sorry I'm european!) and 'phone numbers). > > So how do we handle this? The display of values that we have control over > is pretty straight forward as we can control the server locales ourselves > and render them on the screen accordingly, although not using the automatic > recognition of locale that struts supports. This is also true of multiple > currencies such as the example of euros and DM in Germany. This is in fact > something we are dealing with on our project for a financial client at the > moment. > > The others are more of a problem. However, again there are several > strategies that we can adopt as far as I see it. The first is that in the > scenario above there may well be a limit to where the company is prepared > to export to and therefore they only need to support the locales they want > to. The second is that we could support minor validation on the client side > (ie a phone number is only numbers and brackets or something similar) and > do the full validation on the server side based on subclasses for each > locale we want to support. In this scenario we have one form for all > locales (used loosely) but check the format on the server for a specific > locale. However, we still have problems even here. Take for instance the > Spanish name. US and UK names tend to be along the lines of Fred Smith. > Spanish names include both the mother's and father's surnames i.e. Fred > Jones Smith (well the spanish equivalent anyway ;) How can we cope with > this on one form? Aren't these business decisions to be made rather than > one's for the
