struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Rosenberg <struts_u...@anotheria.net>
Subject Re: [POLL] What do you use action forms for?
Date Fri, 13 May 2005 08:47:22 GMT
On Thu, 2005-05-12 at 15:40 -0700, Michael Jouravlev wrote:
> On 5/12/05, Leon Rosenberg <struts_user@anotheria.net> wrote:
> > Maybe I'm repeating myself, but I give myself a last try :-)
> > I'm a beliefer of  design by responsibility. When I design an
> > application I identify responsibilities to form and define components,
> > modules and layers. Therefore I like each class to have a clear contract.
> 
> Ok, I will try for the last time too :) You design your app based on
> how well the modules designed, how fast is it, how efficient, etc.
> Where is the customer in this scheme? What about usability?
> 
> I base my design on usability. 


I've never heard about design by usability before. How exactly does it
works? Could you explain it? Maybe we all (or at least I) can learn a
bit :-) 
It would also be cool if you could give a short comparison to common
design methods, like OOD/COD with AOA, SOA and MDA.

thanx in advance 

Leon


> Then I think about nice and observable
> module interaction, and only then I care about memory consumption. As
> long as we build webapps based on current HTTP standard, we need to
> take the quirks of this standard into consideration. We need to make
> user's life easier, and to allow him to make mistakes, to click
> "wrong" buttons, to wander around and then return to same page... We
> should allow more freedom to a user. In the end, we build applications
> for the user.
> 
> If splitting one request into two is beneficial for usability, I will
> do it. And I will handle the consequences. Because usability first,
> simplicity of programming is second.
> 
> > Well it maybe get too detailed, but if you keep objects in sessions instead
> > of request you are actually working against the garbage collector.
> 
> This is a matter of implementation. I don't consider inner workings of
> garbage collector as a major factor when I design my application.
> Well, HTTP request/response cycle is a matter of implementation too.
> But in this case it directly affects usability. HTTP is not going away
> tomorrow, so I prefer to work around HTTP instead of caring about
> memory usage.
> 
> > Other, very powerful anti-session-argument is concurrency. If your session
> > object actually represent a business data object, which is
> > managed by some business logic components or stored in the db (or both) you
> > have to watch for changes done by other users/actors. This mean that you
> > actually have to notify the webservers about any changes to the objects
> 
> This is not an anti-session argument, this is argument against
> optimistic concurrency model and offline editing. This is not really
> different, when request is used. Say, you edit an existing object. You
> load object from database and show the edit form. A user takes her
> time painting the nails, and then in 10 minutes submits the data. The
> object was not sitting in the session for 10 minutes, so you saved
> here, I agree. But if someone else already have changed it, you won't
> be able to save it, just like if it were in session, no difference.
> 
> I guess we should stop arguing ;-)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message