On Fri, January 6, 2006 2:01 pm, Michael Jouravlev said: > The above was not meant to be an attack on you (do you have > suggest-type thing?) ;-)) Google has also bandwidth and number of > connections to spare ;-)
Oh, I know, I was just pointing it out because many people don't realize they do that, and it's kinda cool. Your right of course, they can spare some bandwidth for keypresses :) > ...and the larger the Javascript file gets. If validation still has to > be done on server, how do you compare (1) one-time (hopefully) load of > a large Javascript validation file for client-based validation, with > (2) going back to the server and updating a relatively small page > region without full page reload? [ I have my Ajax now too, :-) ] The > latter is simpler for me. Is it better? It is not much worse than > former I would say, but a lot simpler, and I do not have to duplicate > Java validation in Javascript. That's a fair point. Assuming it is a one-time load though, just the simple fact that there are less requests being made with client-side validation I think is a clear benefit. Well, PRESUMABLY less requests anyway... the more you can catch without hitting the server, the less requests. It *is* simpler when only the server is involved though, no question there. Just the fact that you don't have to have duplicate code (whether you write it yourself or have some taglib or something generate it) is a clear advantage. >> If you combine an ActionForm with an Action, what happens if you want to >> give that combined object session scope? Would you then store the >> entire >> thing in session? I would assume so. That seems like a (potentially) >> big >> waste of resources. > > Why? The code and class definition are loaded only once. Where the > resources are wasted? Well, if I have a couple of pages that I want to store in session, and it is a combined object, my session is bigger than if the objects I'm storing are just data. That's what I was referring to. There is still physical memory being used to store the instance of the Action class in session. I'm a stickler about the size of session because I work in a distributed environment where session size is something you need to be very cognizant of. > I am pretty happy with ActionForm in session ;) I know :) And I'm a big believer in "whatever works for you", so I'm happy either way. >> If an ActionForm is thought of >> ONLY as a buffer as you say, a DTO between presentation and control >> basically, Struts seems a lot cleaner all of a sudden. > > Um, a lot cleaner (1) if it contains only request parameters > per-request as it is bieing recommended to be used now, or (2) if it > contains I/O data between requests during conversation with a user, > including wrong input values and error messages? Good question... I'd say #1, but I treat it as an I/O buffer in the sense that yes, it takes in request parameters per-request, but it also is the container where output data goes to be rendered by the presentation layer, and that would include error messages. It would NOT include state between related requests though (i.e., a wizard flow). #2 is where that "something else" I mentioned comes in. And again, I'm talking generalities here... there are obviously places where session-scoped ActionForms make sense right now. And of course I have to reiterate that I don't have at the moment a better answer, we're just discussing what the problems with the current framework might be, expressed in terms of what we'd like to see, as per the original topic of the thread :) > The main drawback of session-scoped ActionForm is that I can have only > one of each kind. Does not work well with several windows opened. > Couple of years ago I was doing a little different, i had a list of > session-scoped presentation objects that contained I/O values and > errors. So I could have one action form and several session-scoped I/O > objects related to it. But then I decided to abandon this, too complex > to manage and users don't usually open secondary windows themselves. That's along the lines of what I am describing above. Maybe what there needs to be is a single I/O buffer object and some peripheral objects attached to the same view for "other things", which sonuds about like what your saying you played with :) > Michael. Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
