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? >
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: *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. > > > > > > > >
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: 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
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, concrete
> validations
> are great (especially the commonly required validation like "is s an email
> address")
> however, we will never be able to supply all
> At this stage, I'm not claiming its an adequate, or appropriate
abstaction,
> but I definitly feel its a candidate.
>
> > 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-mai
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: 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/ >
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/ >
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: Client/Server Side Validation for Struts 1.1
Ok, so why then is this an issue. What is the value of seeing Pounds AND Euros on the same page if you dont want to realte their rates. Ok, so I could enter data using pounds, or enter data using Euros depending on my personalization setting. But what is the use of DISPLAYING both if you wont give me then conversion? By the way Ted, you are up early man. I guess it finally thawed out upstate ;^> - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 7:28 AM Subject: Re: Client/Server Side Validation for Struts 1.1 > Wouldn't exchange rates count as business logic? > > I think the thrust here is the ability to take a given binary number and > display it using the currency sign and format ($###.## vs ###,##DM] for > a given nation. This package would consider the value immutable. Another > player would have to change the binary value first, and then pass it > along for formatting. > > Jonathan Asbell wrote: > > > > "Tonarino kyacua, yoku-ki-ka-ku Kyuacuda" > > > > What about allowing two or three different displays of currency, but only > > one type of currency for data entry. That way I could be in England > > entering pounds, but seeing display values in Pounds, Hong Kong $, and Euro. > > Of course this keeps making me think that at this point we are talking about > > accessing the current exchange rates, which than you would need a feed etc. > > This IS true because thereare countries in SOuth america whos currency jumps > > and dives each week, and you would not be presenting viewers with the > > correct exchange. >
question about Action Forwards in struts-config
I have boiled down action forward to a few exact situations. I would only want to do any of the following situations: 1) take me back where I was 2) take me back to where I was trying to go 3) take me to a specific page 4) take me to a default page I dont believe there is currently a neat and clean way of describing this in the struts-config. Maybe there doesnt need to be for things like "where I was trying to go" and "where I was". I am just looking for some clarity on the issues and what/why the implementation is what it is currently is
excellent links to internationalization issues
Links to developing internationalized websites Cheers yarranet.net.au - papers on multilingual web publishing.url cs.uu Programming for Internationalization FAQ.url developerWorks - Harnessing internationalization.url IBM International Text in JDK 1.2.url IBM java classes for Unicode.url Java Byte Encodings and Strings.url Javaworld - Internationalize JSP-based Websites.url Maribyrnong - multilingual ibrary Services.url Open Road - multilingual resource site.url w3c & alis study on internationalization - August 1999.url Yamada - Font Archive.url yarranet.net.au - Making a multilingual web site.url acoin i18n Internationalization Mailing List.url
Re: Client/Server Side Validation for Struts 1.1
"Tonarino kyacua, yoku-ki-ka-ku Kyuacuda"
What about allowing two or three different displays of currency, but only
one type of currency for data entry. That way I could be in England
entering pounds, but seeing display values in Pounds, Hong Kong $, and Euro.
Of course this keeps making me think that at this point we are talking about
accessing the current exchange rates, which than you would need a feed etc.
This IS true because thereare countries in SOuth america whos currency jumps
and dives each week, and you would not be presenting viewers with the
correct exchange.
- Original Message -
From: "Michael Westbay" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 04, 2001 7:33 PM
Subject: Re: Client/Server Side Validation for Struts 1.1
> Husted-san wrote:
>
> > In this context, we would want the validators to be able to recognize
> > _xx as the location (or have a super method that parsed that from the
> > locale for them). This would allow us to continue to use the one session
> > locale property to cover both situations.
>
> But what kind of compexity are you looking at? Let's take a small example
of
> languages and countries to cover:
>
> Languages: English, Spainish, Japanese
> Locales: U.S., England, Spain, Japan
>
> Now you need resources:
>
> en, en_US, en_UK, en_ES, en_JP
> es, es_US, es_UK, es_ES, es_JP
> ja, ja_US, ja_UK, ja_ES, ja_JP
>
> Add a language, multiply by 5.
> Add a country, multipy the result by 4.
>
> And most of the strings will be repeated over and over ad. nasuim.
>
> It seems to me that the target locale (meaning place) should be separate
with
> some sort of formatted strings like "(###)###-".
>
> Units of measure (dollars, yet, pesos) etc. can be localized in the
language
> file, as well as display order. For example:
>
> Language_en.properties:
> usdollar_value=US$ {0}
> yen_value={0} yen
> peso_value={0} pesos
>
> Language_ja.properties:
> usdollar_value={0}$B%I%k(B
> yen_value={0}$B1_(B
> peso_value={0}$B%Z%=(B
>
> This way, the formatting/format checking "0.00" or "#.##" can be written
> once, and used by all of the languagues.
>
> This still doesn't cover the problem with providing a choice of two
> currencies (as in the EC). Any suggestions?
>
> --
> Michael Westbay
> Work: Beacon-IT http://www.beacon-it.co.jp/
> Home: http://www.seaple.icc.ne.jp/~westbay
> Commentary: http://www.japanesebaseball.com/
>
Re: Client/Server Side Validation for Struts 1.1
Just a question. Why dont you look at resolving validations the same way we look resolving data in a database or parameter names? That is you dont store the parameter names in i18n text, just the values. You dont store the database columns as i18n column names, just the data. Maybe we could have a "Local converter" which sees what local you are using, knows that text will be entered in i18n, and converts the i18n form data into the default Local format, THEN validate. What I'm saying is that we make a copy of the form data, convert it first then validate, and a bad validation for a currency separator would say in the persons language "you are missing a currency separator", send back the original value that was copied along with the error message in the persons language - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 04, 2001 8:54 AM Subject: Re: Client/Server Side Validation for Struts 1.1 > Good points, Michael. > > Language is one thing, location is another, and right now Java i18n does > seem to infer location from language. > > In practice, this says that if they choose country XX on a > contact form, then they should get the validations for country XX, > regardless of any global XX locale setting. Of course, the same > mechanism > could apply to any number of validations, where the selection on one > field affects what is valid in another. > > My first inclination would be to provide a broad validation in the > FormSet (no letters in a telephone field (*)), and then perform a more > complete validation server-side by invoking a specific validator (if I > have one) for country XX. > > Of course, it would also be cool to support dynamic controls, where if > they chose a different location (or whatever) on the form, the runtime > validations on other fields would also change. > > -Ted. > > (*) At least telephone numbers should be letter-free now. As a child > in the US, our telephone number was expressed as EXPORT 29156, which > resolved to 3929156. Apparently we could not be trusted to remember > 7 numbers back then ;-) > > Michael Westbay wrote: > > > > Husted-san wrote: > > > > > The validation.xml supports creating FormSets for different locales. > > > > Wait a second. You just said "locales" right? Yet what are Java locales > > used for? Language. > > > > I live in Japan, however, if I'm browsing in English, what kind of phone > > number am I going to get? Dose the web designer need to write a en_JP > > locale? How about Spanish speakers in California? > > > > The name "locale" has always bothered me with Java, because it tends to be > > used to define a language rather than a place. Yes, there are en_UK and > > en_US versions, but even those are for differences in language expressions > > more than location. > > > > Now, let's say that my wife, born in Mexico, raised in the U.S., and now > > living in Japan, is surfing the Web in Spanish, and wants to send a present > > to a friend in Brazil. She's asked to enter a zip code. What "locale" will > > be presented to her? > > > > Perhaps I missed something somewhere along the line where "locale" was > > differentiated from "language" resources. It's probably just a semantics > > problem as you all have probably been thinking all along that the checks are > > to be done based on the country that the user enters in a form, not the > > "locale" to which (s)he is surfing. But that'll be something else that one > > must keep in mind when solidifying a spec. > > > > Sorry, but even though "locale" is probably the correct word here, it's kind > > of confusing in the context of i18n in Java. > > > > -- > > Michael Westbay > > Work: Beacon-IT http://www.beacon-it.co.jp/ > > Home: http://www.seaple.icc.ne.jp/~westbay > > Commentary: http://www.japanesebaseball.com/ >
Credit card validation FYI
You all probably know about this but I thought I would send it anyway. http://www.beachnet.com/~hstiles/cardtype.html MOD-10 is an algorithm that is used by almost any credit card company togenerate / validate credit cards.How it works?First you have to know what kind of credit card you have.You can find itoutby looking at the first(leftmost) number of it.This is what itmeans:3= American Express4 = Visa5 = Mastercard etc.The algorithm goes as follows : go from right to left and multiply everysecond digit by 2.If the result of themultiplication is greater than 9 , subtract 9 from it.(ex. if 16 then 16 -9 = 7).Thenn add the result to the sum.All other numbers of the card don't need to be multiplied , just add themto the sum..When on the end (sum mod 10) = 0 ,the card is valid.In otherwords it means that the sum must be a multiple of 10 (10,20,30).Example:5 4 2 4 1 8 0 0 2 6 7 6 9 0 0 5---1+4+4+4+2+8+0+0+4+6+5+6+9+0+0+5 = 58This card of course isn't valid because the sum (58) isn't a multiple of10.How to generate cards?Well if you want to generate cards , you first have to decide what type ofcards.If you would decide for a Mastercard, then the first number would bea constant of 5.Therefore we will have to go from left to right to generatecards.The sum will have a value of 1 on the beginning (see example).Thengenerate random numbers up to the 15th digit.Like described above, multiplyevery second number and add all results together to a sum.Then calculatethe last number (checksum): if sum is a multiple of ten, then the 16thnumber (checksum digit) will be 0.Otherwise substract the sum from the nexthighest multiple of 10.In the example above we would say : 60 - 53 = 7.Therefore the last digit is7 and not 5.You could do that in pascal by saying : last_number:=10 - (summod 10) ;Now someone might say that he could generate as many cards as he wants andcould misuse them.But that's not the truth.Many online verificationservices will also check your user info and expiration date with your bank,which of course can't be generated by this program.I've however heardmyself that there are many small companies(XXX - sites,Online downloads)which still use only MOD-10 scripts for validation.
Re: Proposed feature: Bean property transformations
I think the Barracuda project has done things in this area
http://barracuda.enhydra.org/
I am currently beginning to implement struts and have also been reading
about the alternatives. Each is developing in its own direction. I like
the Barracuda design. It is more OO and does not rely on jsp.
- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, June 01, 2001 9:46 AM
Subject: Re: Proposed feature: Bean property transformations
> What I'm missing is a comprehensive, general package for converting data
> types and formatting properties for presentation. Most of this
> functionality is available somewhere in java and javax space, but it's
> spread around.
>
> What would be most useful, I think, is a single, generic package that
> provided
>
> (1) validation of Strings using regular expressions (a la David
> Winterfeldt's servlet), with direct support for native and JDBC
> datatypes,
>
> (2) binary to String and String to binary conversions for all native and
> standard types, and support for adding others,
>
> (3) given a formatting specification ("00#.##") and data of any
> supported type, return a formatted presentation String,
>
> (4) support for locale-senstive transformations with (3),
>
> (5) support for extending the formatting specification for unusual
> circumstances, and
>
> (6) provide simple date-calculation methods and a countdown presentation
> format (seconds, minutes, hours, or days from now until then).
>
> We could then use this helper object during the validation cycle to
> convert incoming Strings to the other types needed by business-logic
> objects, AND pass through the functionality from a > tag, that could pull a property from a given bean, transform it, and
return a formatted String for direct use by the view.
>
> If there is not something like this already out there, I've very
> interested in getting started on this package, since I really, really
> need it for my own projects. Could be a nice addition to the Commons ...
>
> I'm cross-posting this to Struts user in case someone can suggest a
> package that already provides this functionality.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
>
> Ron Smith wrote:
> >
> > I've been thinking of implementing this feature lately and I haven't
> > seen it proposed on this list yet. Any comments?
> >
> > Summary:
> > Provide a means to flexibly plug in transformations that could
> > be applied to JavaBean properties for presentation in a JSP page.
> > What transformation to apply to which JavaBean property
> > is specified in the Struts JSP tags (e.g. bean:write).
> > Transformations are Java classes that are responsible for taking
> > a JavaBean property or any other Object, applying whatever
> > transformation, and returning the transformed Object for
> > presentation in a JSP page.
> > Some example transformations are to format a date in a specific
> > format, format decimal numbers, or even to sort a collection in
> > a particular order before iterating over the collection's objects.
> >
> > Motivation:
> > Separating business entity code from presentation-specific code
> > is a good thing. Consider a business entity class called Order. If
> > we want to display the orderPlacedDate attribute in 4 different
> > date formats on a JSP page, we could add 4 different methods to
> > the Order class to support these 4 different formats. But we quickly
> > end up with a very cluttered Order class and the Order class is too
> > coupled to the presentation details.
> > One approach I've used is to create presentation wrapper classes
> > which hold references to the business entity objects and are
> > responsible for all of the presentation specific formatting. The
> > JSP pages access the presentation wrapper classes and not the business
> > entity classes. For sites that access many different business entity
> > classes, this can become very tedious.
> > A better approach would be to be able to plug-in specific types of
> > presentation transformations to be applied to specific JavaBean
> > properties that are to be displayed in a JSP page without having to
> > create unecessary wrapper classes.
> >
> > Details:
> > Transformations are coded in transformation classes, all of which
> > implement
> > a Transformation interface. This interface has one public method:
> > Object transform(Object inObj)
> > This method is responsible for applying whatever transformation is
> > needed
> > to the passed in object and returning a transformed version of the
> > object for presentation in a JSP page.
> > The transformation objects would be created at initialization based on
> > the
> > configuration file, and could be initialized with some parameters from
> > the
> > configuration file (e.g. the date format string to be used for a date
> > transformation). E
Struts status items list /\/\/\
Can any one of you put together a list? We need to know: 1) what can currently be thrown out (assuming I have the most recent evenings build) 2) what are, and where can we obtain all of the recently contributed pieces which are under consideration, being worked on or tested (the Token mechanism submission, the iterate patch, the message patch, validation, bean factory, auto beans, etc. etc. etc.) 3) what is next item that has been decided but has not been included in any nightly build. 4) what specific areas are we currently looking at to solve Just a brief list for the rest of us to have an idea of current state and the direction in the near future. It will effect what we are personally building. Cheers. Jonathan
Re: Bean philosophy
Great explanation Ted. I am interested in your implementation of the ValueObjects. It appears as though you dont use the ActionForm as a value object, but rather pass the ActionForm beans values on to the value object after validating symantics in the Action. Is this true? I ask because I have read 3-4 different ways to implement the value object, and I am interested in what works best with struts. You remember the comment by Bryan Field-Elliot? He wrote me with his implementation which he felt he still had to work out some issues with hiding some data from other classes. I then read an interesting idea at theserverside.com http://www.theserverside.com/patterns/thread.jsp?thread_id=2722 and another version http://www.theserverside.com/patterns/depbmp.jsp. - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 30, 2001 10:38 PM Subject: Re: Bean philosophy > Jonas Bjornerstedt wrote: > > I see little reason (yet) why the ActionForm should be modeled as such. > > I think the keyword here is "yet". Much of the underlying Struts designs > are based on trends and patterns that have yet to reach their logical > conclusion. > > For example, future Java design tools are sure to fully support > JavaBeans. Support for other structures, like hashtables, is likely to > be less thorough. Another example is custom tags, which are a good thing > now, but will be a truly tremendous thing when the visual HTML editors > catch up with the Java 2 spec. > > Struts is also designed to work well with J2EE design patterns, which > rely on JavaBeans. I construct both my form and model (or value) beans > at the same time (using simple search and replace templates), and then > extend the value beans to work with native types. Personally, I find it > more convenient to be working with beans on both sides, rather than with > a hashtable here and a JavaBean there. > > It is also very important to note that the ActionForm beans are just a > means to an end. They exist as an adaptor between the HTML forms and the > rest of your application. After the data has been captured, it should be > handed to another object to handle the business-logic portion of your > program. As such, they are usually only persistent for the life of a > request, and as you say, should do little beside validating the input > and converting the data for use by another object. > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ >
Re: Bean philosophy
Craig, that was the most excellent explanation. What currently IS available for use regarding the automatic properties, and how may I use them? I download the nightly builds ;^> - Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, May 30, 2001 4:14 PM Subject: RE: Bean philosophy > > > On Wed, 30 May 2001, Jonas Bjornerstedt wrote: > > > Although you get basic type conversion with the getter/setter methods, it is > > not a convincing argument. The price you pay for getting something that is > > rather simple, is that 1) you have to always extend ActionForm 2) often use > > reflection / PropertyUtils to get the information out. > > > > Wouldn't it be more logical if the ActionForm did the type conversion when > > validating rather than the Struts controller? This would be possible if the > > interface had separate > > > > String get(String name) and > > Object getAttribute(String name) > > > > methods. > > > > > Hello Jonas, > > I think you've really got two threads of questions here, so let me try to > address them separately. > > (1) Why use getXxx and setXxx for properties? > > This is a general design pattern called JavaBeans, and you will find it > very commonly implemented. There's a specification that documents these > conventions, available at: > > http://java.sun.com/products/javabeans/docs/spec.html > > but the basic principles revolve around: > > * Information hiding (for example, how do *you* know that a > particular getter method returns a simple property value, > and doesn't do some on-the-fly calculations every time?) > > * Introspection (so that development tools can recognize the > design patterns and provide a nice GUI user interface for > creating and connecting beans). > > Dynamic properties are a very very very heavily requested feature, and > will undoubtedly be addressed early in the Struts 1.1 development > cycle. Supporting them elegantly is more than just a couple of tweaks > here and there, so we want to make sure that we've got all the bases > covered with our design. > > In the mean time, though, you'll see the JavaBeans naming patterns used > almost universally in Java programming, so it's well worth your time to > learn them and start using them. > > (2) Why ActionForm versus just ordinary beans? > > This is a deliberate and fundamental design decision that I made when > first designing Struts. The short answer is that, IMHO, form beans are > part of the View layer in an MVC architecture, not the Model layer. This > is based on the following principles: > > * When the user enters invalid data, the application needs to be > able to redisplay what the user last entered (even if it was wrong), > along with the error messages, so that the user doesn't have to > retype everything again. Would *you* ever use a web application > that didn't have this property? > > * In order to do this in a web application, there needs to be some > representation of the current input state from the user's last form > submit (again, even if it's wrong). So it doesn't make sense to try > to use the "real" JavaBeans that actually represent your data. Consider > an integer field, where the user typed in "1A3" instead of "123". If > you're using a "real" data object, you get an input conversion error -- > and NO WAY to reproduce what the last input again. You need a separate > object anyway. > > * In addition, Struts supports the optional concept of calling a > validate() method for you. Thus, there needed to be some Java API > for form beans anyway -- either an interface or a class -- so that > the controller servlet can recognize when to do it. Originally > ActionForm was an interface, but that made every Struts application > fragile in the face of later enhancements -- adding a new public > method to the ActionForm interface would break every single existing > form bean in every single Struts based application, and that would not > be very popular :-). Therefore, we use a base class instead. > > * You can, of course, use the underlying BeanUtils.populate() method > yourself to populate any arbitrary object. It's just that Struts won't > give you the other automatic support it does for ActionForm beans. > > > Jonas > > > > Craig McClanahan > > > > > -Original Message- > > > From: David Winterfeldt [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, May 30, 2001 5:32 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Bean philosophy > > > > > > > > > I wanted to crank out a prototype of something and > > > didn't want to make all of the setter/getter methods > > > so I modified PropertyUtils to handle java.util.Map. > > > I posted some source, but other people have cleaner OO > > > implementation ideas that they have posted. Something > > > along this idea is scheduled in the Struts 1.1 To Do > > > list. > > > > > > The thread is: > > > "Proper
Request from contributer user.....
Hello all. I am still only a few months playing with struts but I would like to ask if you wouldn't mind putting more detailed debugging in the framework. I personally am studying the framework by reading about it, but most importantly by watching how it performs step by step. I do this by adding the same type of statements as yours, but if you set a debug level of 5 it gives you a step by step view of what is occuring. Could you consider this. It is because it is hard enough to understand a framework when you really cant see exactly what is happening. But it is a nice framewor ;^> respectfully Jonathan
