Re: Multi Step Forms
> I have a situation where i need to have a multi screen form, lets say 3 > steps. On \ > the successfull validation of the 3rd step. I want to save the data into the > DB. \ > This data would have been collected starting on step one, through step 3 and \ > ecapsulated in 1 or more objects. > My question is whats the best way to do this from a design standpoint without > using \ > actionForms, thats not in option in my case. Specifically is there a clean > way to \ > save a partially filled object from step 1 and pass it to step 2. Basically > the \ > functionality like Server.Transer in .NET. Hi Brian, This sounds like a shameless ad (which it is), but this is _exactly_ what my flow library does: http://www.superinterface.com/easywizard.htm I would appreciate if you try it. To other Struts users: please excuse me for this plug ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
Woodchuck wrote the following on 4/4/2005 3:29 PM: how do you handle browser back button issues? (the bane of all web developers who use session objects) If multiple submits will mess things up, I implement the Token stuff. Works quite nicely for me. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
To make your job a little easier with not using the Session this might work well for you (and maybe you already thought of it), but I'd try this ... Let's assume three pages that you need capture info. Build three objects that represent that page data you need to capture (A_Pojo, B_Pojo, C_Pojo) and stuff them into one master POJO - BigMomma. I'd then add BigMomma to your ActionForm and use this ActionForm for all three pages. Then on each page your hidden vars would look like bigMomma.aPojo.someProperty bigMomma.cPojo.fooBarProperty etc. When the form submits in your Action you could then stuff the whole ActionForm back into the request again. The benefit to this is all you need to maintain then is hidden form fields on the front end. You don't have to worry that much about pushing the right stuff into the request from your Actions. This is nice if you end up needing to add or remove pages etc. You only have to worry about maintaining the front end jsps. You could actually reuse one action class who's job is to just stuff the ActionForm back into the request each time. Basically your 'wizard' pages would all just use one ActionForm and one Action class. Pretty clean I think. On the final step you can just pull the bigMomma bean out of the ActionForm and send it to your persistence layer. The final step call would be to a different Action or, since I like to use Dispatch Actions (Yes, my name is Rick I use the DispatchAction:), you could just have a lastStep() method or whatever you want to call it in there that calls your backend stuff. Brian McGovern wrote the following on 4/4/2005 2:01 PM: I think i have a fundemental misunderstanding of ActionForms not having used them that much. So forget everything i said about ActionForms, i was wrong. I still dont like em partially cause im stubborn, but also because i dont like that you have to define you whole form in your struts config. Im gonna have alot of forms in my app but none of them are used in more than 1 screen. Seems like an implementation detail and not a configuration issue. Whatever. The crux of this thread really can be summed up in "At what point does using session cease being a good practice and become a lazy man's shortcut." And i think woodchuck is 100% right, there is no correct answer. Small apps or lightly used apps can use the session for just about anything whereas larger apps or heavy hit apps really should not use it much at all. To answer some of woodchuks q's though, Im using struts to delegate control flow, access resource bundles and things like that. I started out using other struts logic and bean tags but went with jstl after reading thats what apache recommends now. The app will be fairly large, and entirely behind ssl. I dont really so much care about people viewing source for these forms, this data is not CC numbers or SSNs or anything. The hidden fields i will be sending back will account for probalby 1/20th of the entire pages' source code so there is no issue with repsonse time here. My main reason for staying away from the session here is because the app im writing is a startup site that has an unknown but potentially enormous user base who will be marketed to in period campains. I have no idea how many users will be on the site filling out these forms at any given time but we will be marketing it to thousands at any given time, so i need to prepare for huge load even though i ma y never see it. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
--- Rick Reumann <[EMAIL PROTECTED]> wrote: > The thing to realize here is time is money. Does you company want to > spend a ton money creating code that is a pain to maintain? I'll bet > you > in the long run, it's cheaper to add more RAM than it would be to > maintain various solutions simply to avoid using the Session. I like > web > applications to be easy to code and maintain. And don't just think of > > the now, think of the developers that have to be on the project 6 > months > from now when requirements change. > > Some of the approaches that are often described to avoid using the > Session simply do not make sense to me when you weigh out the > maintenance costs. Invariably non-Session using solutions involve > persisting a bunch of hidden variables. This just gets really messy > from > my experience especially later on when people inherit the code and > aren't positive if they no longer need X hidden variable so they just > > leave it and then that code gets maybe copied to some other part of > the > application. Things just get ugly over time. Again, I don't use the > Session when I do not need to, but if I need to maintain state across > > multiple requests, I use it, and don't feel bad about it those are very good points. from a cost point-of-view it is definitely cheaper to buy hardware than to face potentially higher code maintenance costs in the long run. how do you handle browser back button issues? (the bane of all web developers who use session objects) > > "Hi my name is Rick and I use the Session to store objects." > > "Hi Rick!" > > lol! "hi! my name is woodchuck and load the entire database into the session!" haha ;) woodchuck __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
Brian McGovern wrote: I only use hidden html fields to save state on the weekends, with friends. What? Everyone does it!! I never inhal^H^H^H^H^Hsubmitted. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT: Session memory usage/other means] Re: Multi Step Forms
Rick Reumann wrote: "Hi my name is Rick and I use the Session to store objects." "Hi Rick!" Let's all thank Rick for sharing his story. *clap clap clap* Group hug! Well after looking for what was actually causing the out of memory problems, and determining it was just a matter of some necessary beans in Session scope causing the problem, than yes, add more memory etc. Without using even marginally over-spec'ed servers I have yet to run out of memory, and I tend to store things in session, including shopping carts, whenever it's necessary or convenient to do so. Maybe it's just because I don't store huge objects in session (in general), but even on a Torque-based app when I keep Torque beans in session I'm still not running out of room. (That's a relatively low-load app, though; it's never been stressed.) On an internal app at one of my clients, not using torque but more or less plain old beans with specific functionality on a 1G machine with (typically) 500 users connected at any given time I was never in danger of breaking anything, though. (DB hosted on another machine.) Even if I'm storing, say, 100K of crap in the session for each user (which I definitely wasn't), that's 50M of session crap. That's a lot of crap. But it's still like 5% of my memory. (Right? I have a fever today and math cells are the first to go--marked for early swap.) So it's difficult for me to get all worked up about it, especially considering time and maintainence constraints. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multi Step Forms
I only use hidden html fields to save state on the weekends, with friends. What? Everyone does it!! -Original Message- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 2:26 PM To: Struts Users Mailing List Subject: Re: Multi Step Forms Woodchuck wrote the following on 4/4/2005 1:35 PM: > for Rick: > - if and when your web app does experience OutOfMemoryExceptions due > to sheer volume (of users/sessions), then what can you do to fix this? > do you just keep maximizing the server memory, and/or keep adding > servers (clustering/load balancing)? Well after looking for what was actually causing the out of memory problems, and determining it was just a matter of some necessary beans in Session scope causing the problem, than yes, add more memory etc. The thing to realize here is time is money. Does you company want to spend a ton money creating code that is a pain to maintain? I'll bet you in the long run, it's cheaper to add more RAM than it would be to maintain various solutions simply to avoid using the Session. I like web applications to be easy to code and maintain. And don't just think of the now, think of the developers that have to be on the project 6 months from now when requirements change. Some of the approaches that are often described to avoid using the Session simply do not make sense to me when you weigh out the maintenance costs. Invariably non-Session using solutions involve persisting a bunch of hidden variables. This just gets really messy from my experience especially later on when people inherit the code and aren't positive if they no longer need X hidden variable so they just leave it and then that code gets maybe copied to some other part of the application. Things just get ugly over time. Again, I don't use the Session when I do not need to, but if I need to maintain state across multiple requests, I use it, and don't feel bad about it "Hi my name is Rick and I use the Session to store objects." "Hi Rick!" -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
Woodchuck wrote the following on 4/4/2005 1:35 PM: for Rick: - if and when your web app does experience OutOfMemoryExceptions due to sheer volume (of users/sessions), then what can you do to fix this? do you just keep maximizing the server memory, and/or keep adding servers (clustering/load balancing)? Well after looking for what was actually causing the out of memory problems, and determining it was just a matter of some necessary beans in Session scope causing the problem, than yes, add more memory etc. The thing to realize here is time is money. Does you company want to spend a ton money creating code that is a pain to maintain? I'll bet you in the long run, it's cheaper to add more RAM than it would be to maintain various solutions simply to avoid using the Session. I like web applications to be easy to code and maintain. And don't just think of the now, think of the developers that have to be on the project 6 months from now when requirements change. Some of the approaches that are often described to avoid using the Session simply do not make sense to me when you weigh out the maintenance costs. Invariably non-Session using solutions involve persisting a bunch of hidden variables. This just gets really messy from my experience especially later on when people inherit the code and aren't positive if they no longer need X hidden variable so they just leave it and then that code gets maybe copied to some other part of the application. Things just get ugly over time. Again, I don't use the Session when I do not need to, but if I need to maintain state across multiple requests, I use it, and don't feel bad about it "Hi my name is Rick and I use the Session to store objects." "Hi Rick!" -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
Brian McGovern wrote the following on 4/4/2005 12:25 PM:
And yeah im using c:out into POHTML tags. Bletch all ya want, i still
think its a better way to go than action forms. My struts-config is nice
and small too :)
I still think (as Jack pointed out) you are having some confusion
between ActionForms and maybe the Struts html tags on the page? The two
are only slightly related to each other (the Struts html tags require an
ActionForm in the background, but not the other way around). You can use
POHTML tags and still have an ActionForm hold your data for you. You do
not have to use the Struts html tags at all if you don't want to.
Although, I have to also point out in reference to your comment:
Action forms write out html for you. What if i wanted to put style
attribs in my form tags or use javascript for submission wrappers on the
button clicks, or stuff like that. Didn't think I could do that with
action forms.
Easily done. No limitation on Javascript or any css that you want to add
to any of the Struts html tags.
> I like 100% control of the code on the presentation layer.
Again, just my preference, but I think the framework should write no
html at all and should just pass data up to the view.
That's fine, but just remember this is independent of the use of
"ActionForms" so for example if you had an ActionForm with a property:
ActionForm .. .{
EmployeeBean employee;
//getEmployee setEmployee
}
on your JSP you could do...
or
and they have the same effect when populating the ActionForm. (Using the
Struts html tag saves some typing though and you can still add any
styles or javascript that you may need.)
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multi Step Forms
Brian, But you don't HAVE to define a COMPLETE form in the configuration. At least if you want to give up DynaActionForm you don't. You can define your own form in a class that extends ActionForm. Granted you have to add this to the config but with Xdoclet, or even just a gui editor (James Holme's has one on his site) it is pretty easy. Personally I like DynaActionForm since it means not touching code when a parameter is added to the form, but there are those who maintain that they should not be used in production. As far as using Session objects... I'll stay out of that one because its just an endless debate. Every architect/lead/developer has their own opinion, and you aren't going to change those opinions regardless of any argument for or against Session objects :) Al -Original Message- From: Brian McGovern [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 1:02 PM To: Struts Users Mailing List Subject: RE: Multi Step Forms I think i have a fundemental misunderstanding of ActionForms not having used them that much. So forget everything i said about ActionForms, i was wrong. I still dont like em partially cause im stubborn, but also because i dont like that you have to define you whole form in your struts config. Im gonna have alot of forms in my app but none of them are used in more than 1 screen. Seems like an implementation detail and not a configuration issue. Whatever. The crux of this thread really can be summed up in "At what point does using session cease being a good practice and become a lazy man's shortcut." And i think woodchuck is 100% right, there is no correct answer. Small apps or lightly used apps can use the session for just about anything whereas larger apps or heavy hit apps really should not use it much at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multi Step Forms
I think i have a fundemental misunderstanding of ActionForms not having used them that much. So forget everything i said about ActionForms, i was wrong. I still dont like em partially cause im stubborn, but also because i dont like that you have to define you whole form in your struts config. Im gonna have alot of forms in my app but none of them are used in more than 1 screen. Seems like an implementation detail and not a configuration issue. Whatever. The crux of this thread really can be summed up in "At what point does using session cease being a good practice and become a lazy man's shortcut." And i think woodchuck is 100% right, there is no correct answer. Small apps or lightly used apps can use the session for just about anything whereas larger apps or heavy hit apps really should not use it much at all. To answer some of woodchuks q's though, Im using struts to delegate control flow, access resource bundles and things like that. I started out using other struts logic and bean tags but went with jstl after reading thats what apache recommends now. The app will be fairly large, and entirely behind ssl. I dont really so much care about people viewing source for these forms, this data is not CC numbers or SSNs or anything. The hidden fields i will be sending back will account for probalby 1/20th of the entire pages' source code so there is no issue with repsonse time here. My main reason for staying away from the session here is because the app im writing is a startup site that has an unknown but potentially enormous user base who will be marketed to in period campains. I have no idea how many users will be on the site filling out these forms at any given time but we will be marketing it to thousands at any given time, so i need to prepare for huge load even though i may never see it. -Original Message- From: Woodchuck [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 1:35 PM To: Struts Users Mailing List Subject: Re: Multi Step Forms hihi all, i think we have trade-offs to both ways of persistence here... if i may ask: for Brian: - if you are not using ActionForm objects (nor any Struts tags for that matter, if you're only using and POHTML), then what features of Struts are you using? i'm just trying to understand the context better behind this discussion since the answer *always* depends on the context. is your web app really simple? very little business rules validation, and no need to i18n? are you not worried about having all those hidden values being seen (by viewing html source)? what about performance? adding more information that needs to be sent across the network will not necessarily affect latency, but it *will* affect response time, and this is what the users experience will be based on for any web apps. for Rick: - if and when your web app does experience OutOfMemoryExceptions due to sheer volume (of users/sessions), then what can you do to fix this? i also worry about this possible eventuality and try to use session judiciously, but even then in theory, it is still going against finite memory resources. do you just keep maximizing the server memory, and/or keep adding servers (clustering/load balancing)? and when you talk about state persistence, the issues of concurrency follows closely as well although it is a problem independent from the immediate discussion... i only bring it up because imo it is a risk factor that should be considered when thinking about state persisting strategy. woodchuck --- Rick Reumann <[EMAIL PROTECTED]> wrote: > But that's my point, if you server is going to crash because of bean > stored in Session scope that is holding simple properties, than there > > are some serious issues with your server set up. What's ironic is I > bet > you'll end up with a slower performance (at least from the user's > perspective) doing the other tricks you'll need to do in order to get > > all of this to work using only the Request. > > I totally agree in not use the Session for unnecessary operations > that > do you not need persist, but for what you are doing is the exact > reason > you have the Session. Do you think shopping carts persist all their > contents into hidden properties on each page as the user browses a > shopping site? __ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
hihi all, i think we have trade-offs to both ways of persistence here... if i may ask: for Brian: - if you are not using ActionForm objects (nor any Struts tags for that matter, if you're only using and POHTML), then what features of Struts are you using? i'm just trying to understand the context better behind this discussion since the answer *always* depends on the context. is your web app really simple? very little business rules validation, and no need to i18n? are you not worried about having all those hidden values being seen (by viewing html source)? what about performance? adding more information that needs to be sent across the network will not necessarily affect latency, but it *will* affect response time, and this is what the users experience will be based on for any web apps. for Rick: - if and when your web app does experience OutOfMemoryExceptions due to sheer volume (of users/sessions), then what can you do to fix this? i also worry about this possible eventuality and try to use session judiciously, but even then in theory, it is still going against finite memory resources. do you just keep maximizing the server memory, and/or keep adding servers (clustering/load balancing)? and when you talk about state persistence, the issues of concurrency follows closely as well although it is a problem independent from the immediate discussion... i only bring it up because imo it is a risk factor that should be considered when thinking about state persisting strategy. woodchuck --- Rick Reumann <[EMAIL PROTECTED]> wrote: > But that's my point, if you server is going to crash because of bean > stored in Session scope that is holding simple properties, than there > > are some serious issues with your server set up. What's ironic is I > bet > you'll end up with a slower performance (at least from the user's > perspective) doing the other tricks you'll need to do in order to get > > all of this to work using only the Request. > > I totally agree in not use the Session for unnecessary operations > that > do you not need persist, but for what you are doing is the exact > reason > you have the Session. Do you think shopping carts persist all their > contents into hidden properties on each page as the user browses a > shopping site? __ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
This is just the standard and too frequent mixup in talking too loosely about and tags as if they were ActionForms. He really is talking about the fact that tags resolve to html. Nothing particularly special. If he wants, he can always modify the tags to do anything he wants. Jack On Apr 4, 2005 10:12 AM, Dave Newton <[EMAIL PROTECTED]> wrote: > Brian McGovern wrote: > > >Action forms write out html for you. What if i wanted to put style attribs > >in my form tags or use javascript for submission wrappers on the button > >clicks, or stuff like that. Didn't think I could do that with action forms. > > > They do? How/when? I'm not just being a smart-aleck here, I've just > never heard of them doing that or used them in that way. I thought they > just held form data. I don't see anything in the JavaDocs relating to > this, either. > > I use JavaScript for submission wrappers (as little as possible, but I > have need to on occasion) and my tags are styled using CSS. > > What am I missing? > > Dave > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
Brian McGovern wrote: Action forms write out html for you. What if i wanted to put style attribs in my form tags or use javascript for submission wrappers on the button clicks, or stuff like that. Didn't think I could do that with action forms. They do? How/when? I'm not just being a smart-aleck here, I've just never heard of them doing that or used them in that way. I thought they just held form data. I don't see anything in the JavaDocs relating to this, either. I use JavaScript for submission wrappers (as little as possible, but I have need to on occasion) and my tags are styled using CSS. What am I missing? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
Hello, I'm Lucas, I'm new to the list... and I have a problem: An ActionForm that has an array of others ActionForms where each one has another array of ActionForms. So i nedd to present the first form in a JSP page... One of the fields of the last ActionForm, the one in the lowest level, is editable, it's a checkbox. I'm doing this: and i doesn't work either... Thanks! Lucas - 250MB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo Abrí tu cuenta aquí
RE: Multi Step Forms
Nono.. im not saying the server is gonna crash on 1 little bean in session
scope. Im just talkin about theory really. In theory, i want to avoid using
the session, if it means i have to code a little bit more, and we are just
talking about a LITTLE bit, then so be it. Im not doing a 1 for 1 match on
form fields and params either. Id be doing a
request.setAtrribute("MyOBJ", myObj) after it had been partially filled. It
really only amounts to a few lines of "extra" code on reading the hidden
fields. I'm probably over thinking this, and im sure the session is a fine
approach for this.
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, April 04, 2005 12:21 PM
To: Struts Users Mailing List
Subject: Re: Multi Step Forms
Brian McGovern wrote the following on 4/4/2005 12:01 PM:
> I see your points but I disagree. I try to keep session use to an
> ABSOLUTE minimum, because each session is stored in server memory and
> with every current user filling out form there is a change, be it slight
> or not, that the server will slow down or crash. I know it might be less
> desireable from a maintenance perspective buy my time and effort in
> development is a lesser concern weighed against the performance of a
> productions system. I totally understand that this probably won't
> happen, but planning for the worst case is never a bad idea.
But that's my point, if you server is going to crash because of bean
stored in Session scope that is holding simple properties, than there
are some serious issues with your server set up. What's ironic is I bet
you'll end up with a slower performance (at least from the user's
perspective) doing the other tricks you'll need to do in order to get
all of this to work using only the Request.
I totally agree in not use the Session for unnecessary operations that
do you not need persist, but for what you are doing is the exact reason
you have the Session. Do you think shopping carts persist all their
contents into hidden properties on each page as the user browses a
shopping site?
> I don't use action forms because I dont like em. No real reason other
> than that. I think action forms don't provide any real benefit if you
> are proficient in html and want precise to the pixel control of style on
> the presentation layer. Just my personal preference.
I'm not a big fan of Action forms either but my point is that you should
be persisting the information across requests in 'some' object and in
this case a Session-scoped Action form makes perfect sense. Think how
little coding you need with this approach vs your approach. If you don't
use an Action form, you should be persisting the user captured info at
least some POJO that you can persisst across requests.
Do you plan to grab each request parameter and shove it manually back
into the Request each time?
Do you actually plan to do...
request.setAttribute("firstName", request.getParameter("firstName") );
and then on the ensuing page have:
and do this for every property?
All of this to avoid using Session scope? I just don't get it. Do you
really think the performance impact is going to be that big using the
Session to persist a bean for the time a user is logged on to your
application? If you are that concerned about the performance of this
Session scoped bean, you can always make sure you remove the bean from
Session scope when it's no longer needed, this way it only persists for
the time the user is using the X number of pages you are concerned with.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multi Step Forms
I think this is where our school of thought parts ways. Network transmission is fininte, session usage lives as long as the user is on the site and session not expired. So if 400 people get a direct mailer and hit the site to sign up thats 400 people using portion of memory on a server. If half of them walk away to go eat lunch for a half an hour, thats 200 sessions sittin there for no reason. A fractionally slower page load is ok. A server running out of memory is not. By your rational would you also store a user's shopping cart in the session? Action forms write out html for you. What if i wanted to put style attribs in my form tags or use javascript for submission wrappers on the button clicks, or stuff like that. Didn't think I could do that with action forms. I like 100% control of the code on the presentation layer. Again, just my preference, but I think the framework should write no html at all and should just pass data up to the view. And yeah im using c:out into POHTML tags. Bletch all ya want, i still think its a better way to go than action forms. My struts-config is nice and small too :) -B Brian McGovern wrote: >I see your points but I disagree. I try to keep session use to an ABSOLUTE >minimum, because each session is stored in server memory and with every >current user filling out form there is a change, be it slight or not, that the >server will slow down or crash. I know it might be less desireable from a >maintenance perspective buy my time and effort in development is a lesser >concern weighed against the performance of a productions system. I totally >understand that this probably won't happen, but planning for the worst case is >never a bad idea. > > But isn't the server sending all those hidden form fields as well? And network transmission is certainly slower than memory access. Just sayin', is all. >I don't use action forms because I dont like em. No real reason other than >that. I think action forms don't provide any real benefit if you are >proficient in html and want precise to the pixel control of style on the >presentation layer. Just my personal preference. > > What do ActionForms have to do with the presentation layer and control over layout?! In any case, how are you pre-populating your forms, then? Scriptlets? Embedding c:out (or equiv.) into POHTML input tags? Bletcherous. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
Brian McGovern wrote the following on 4/4/2005 12:01 PM:
I see your points but I disagree. I try to keep session use to an
ABSOLUTE minimum, because each session is stored in server memory and
with every current user filling out form there is a change, be it slight
or not, that the server will slow down or crash. I know it might be less
desireable from a maintenance perspective buy my time and effort in
development is a lesser concern weighed against the performance of a
productions system. I totally understand that this probably won't
happen, but planning for the worst case is never a bad idea.
But that's my point, if you server is going to crash because of bean
stored in Session scope that is holding simple properties, than there
are some serious issues with your server set up. What's ironic is I bet
you'll end up with a slower performance (at least from the user's
perspective) doing the other tricks you'll need to do in order to get
all of this to work using only the Request.
I totally agree in not use the Session for unnecessary operations that
do you not need persist, but for what you are doing is the exact reason
you have the Session. Do you think shopping carts persist all their
contents into hidden properties on each page as the user browses a
shopping site?
I don't use action forms because I dont like em. No real reason other
than that. I think action forms don't provide any real benefit if you
are proficient in html and want precise to the pixel control of style on
the presentation layer. Just my personal preference.
I'm not a big fan of Action forms either but my point is that you should
be persisting the information across requests in 'some' object and in
this case a Session-scoped Action form makes perfect sense. Think how
little coding you need with this approach vs your approach. If you don't
use an Action form, you should be persisting the user captured info at
least some POJO that you can persisst across requests.
Do you plan to grab each request parameter and shove it manually back
into the Request each time?
Do you actually plan to do...
request.setAttribute("firstName", request.getParameter("firstName") );
and then on the ensuing page have:
and do this for every property?
All of this to avoid using Session scope? I just don't get it. Do you
really think the performance impact is going to be that big using the
Session to persist a bean for the time a user is logged on to your
application? If you are that concerned about the performance of this
Session scoped bean, you can always make sure you remove the bean from
Session scope when it's no longer needed, this way it only persists for
the time the user is using the X number of pages you are concerned with.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
Brian McGovern wrote: I see your points but I disagree. I try to keep session use to an ABSOLUTE minimum, because each session is stored in server memory and with every current user filling out form there is a change, be it slight or not, that the server will slow down or crash. I know it might be less desireable from a maintenance perspective buy my time and effort in development is a lesser concern weighed against the performance of a productions system. I totally understand that this probably won't happen, but planning for the worst case is never a bad idea. But isn't the server sending all those hidden form fields as well? And network transmission is certainly slower than memory access. Just sayin', is all. I don't use action forms because I dont like em. No real reason other than that. I think action forms don't provide any real benefit if you are proficient in html and want precise to the pixel control of style on the presentation layer. Just my personal preference. What do ActionForms have to do with the presentation layer and control over layout?! In any case, how are you pre-populating your forms, then? Scriptlets? Embedding c:out (or equiv.) into POHTML input tags? Bletcherous. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multi Step Forms
I see your points but I disagree. I try to keep session use to an ABSOLUTE minimum, because each session is stored in server memory and with every current user filling out form there is a change, be it slight or not, that the server will slow down or crash. I know it might be less desireable from a maintenance perspective buy my time and effort in development is a lesser concern weighed against the performance of a productions system. I totally understand that this probably won't happen, but planning for the worst case is never a bad idea. I don't use action forms because I dont like em. No real reason other than that. I think action forms don't provide any real benefit if you are proficient in html and want precise to the pixel control of style on the presentation layer. Just my personal preference. -B -Original Message- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 11:35 AM To: Struts Users Mailing List Subject: Re: Multi Step Forms Brian McGovern wrote the following on 4/4/2005 10:16 AM: > Sounds good. I think I want to only have 1 write to the db at the > end of Action3, and im hoping to not use the session cause this app > is gonna have alot of users. By saving it on the page, are you > talkin about using hidden form fields across the 3 pages or can i set > the oject in action 1 so that it is visible in action 2? I'm thinkin > hidden form fields are the way to go here .. you agree? I'd have to say this seems like a really ugly solution and a maintenance nightmare. I still don't see why you can't use the Session to help out. That's what it's there for. If you are going to have that many users that you can't use the Session to store a bean for each user while they are logged on, than the application has some other serious problems. If you don't want to use an ActionForm (which I'm totally confused why you can't if you are using Struts?) then just have each submission to each Action store the results in a bean that you keep in the Session. When you are all done (on the last step) persist this bean to the DB. So no, I don't agree hidden form fields are the answer. It's an icredible pain to maintain those hidden fields when requirements change, plus on each step you are going to put them all back into scope each time? Another maintenance nightmare. I see the above scenario as a perfectly acceptable use for Session scope. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
Brian McGovern wrote the following on 4/4/2005 10:16 AM: Sounds good. I think I want to only have 1 write to the db at the end of Action3, and im hoping to not use the session cause this app is gonna have alot of users. By saving it on the page, are you talkin about using hidden form fields across the 3 pages or can i set the oject in action 1 so that it is visible in action 2? I'm thinkin hidden form fields are the way to go here .. you agree? I'd have to say this seems like a really ugly solution and a maintenance nightmare. I still don't see why you can't use the Session to help out. That's what it's there for. If you are going to have that many users that you can't use the Session to store a bean for each user while they are logged on, than the application has some other serious problems. If you don't want to use an ActionForm (which I'm totally confused why you can't if you are using Struts?) then just have each submission to each Action store the results in a bean that you keep in the Session. When you are all done (on the last step) persist this bean to the DB. So no, I don't agree hidden form fields are the answer. It's an icredible pain to maintain those hidden fields when requirements change, plus on each step you are going to put them all back into scope each time? Another maintenance nightmare. I see the above scenario as a perfectly acceptable use for Session scope. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
Brian McGovern wrote: >Sounds good. I think I want to only have 1 write to the db at the end of >Action3, and im hoping to not use the session cause this app is gonna have >alot of users. By saving it on the page, are you talkin about using hidden >form fields across the 3 pages or can i set the oject in action 1 so that it >is visible in action 2? I'm thinkin hidden form fields are the way to go here >.. you agree? > > > Yup, that's exactly what I mean. On the page two you'll have for each of the fields you collect in step one. And on step three you'll have all of them for step one and two. This method is very commonly used. :-) Do it up! Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multi Step Forms
Sounds good. I think I want to only have 1 write to the db at the end of Action3, and im hoping to not use the session cause this app is gonna have alot of users. By saving it on the page, are you talkin about using hidden form fields across the 3 pages or can i set the oject in action 1 so that it is visible in action 2? I'm thinkin hidden form fields are the way to go here .. you agree? -Original Message- From: Brandon Mercer [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 9:59 AM To: Struts Users Mailing List Subject: Re: Multi Step Forms Brian McGovern wrote: >I have a situation where i need to have a multi screen form, lets say 3 steps. > On the successfull validation of the 3rd step. I want to save the data into >the DB. This data would have been collected starting on step one, through >step 3 and ecapsulated in 1 or more objects. > >My question is whats the best way to do this from a design standpoint without >using actionForms, thats not in option in my case. Specifically is there a >clean way to save a partially filled object from step 1 and pass it to step 2. > Basically the functionality like Server.Transer in .NET. > > yes there is. I've got a similar setup right now. What I've done is setup three Actions, one for each step, and I save information to a temporary DB table. This information could also be saved in the session, or on each page. Because of how I setup my DAO I actually have an object per page ( this is much cleaner in the long run). On the last page the information is reviewed by the client and I have another action that pulls the information out of wherever you put it, and stores it into the "primary" table. Brandon > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Step Forms
Brian McGovern wrote: >I have a situation where i need to have a multi screen form, lets say 3 steps. > On the successfull validation of the 3rd step. I want to save the data into >the DB. This data would have been collected starting on step one, through >step 3 and ecapsulated in 1 or more objects. > >My question is whats the best way to do this from a design standpoint without >using actionForms, thats not in option in my case. Specifically is there a >clean way to save a partially filled object from step 1 and pass it to step 2. > Basically the functionality like Server.Transer in .NET. > > yes there is. I've got a similar setup right now. What I've done is setup three Actions, one for each step, and I save information to a temporary DB table. This information could also be saved in the session, or on each page. Because of how I setup my DAO I actually have an object per page ( this is much cleaner in the long run). On the last page the information is reviewed by the client and I have another action that pulls the information out of wherever you put it, and stores it into the "primary" table. Brandon > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
