struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <ahardy.str...@cyberspaceroad.com>
Subject Re: Fundamental flaw in Model-Driven?
Date Sat, 26 Apr 2008 10:34:34 GMT
Jeromy Evans on 26/04/08 04:51, wrote:
> I haven't had an opportunity to absorb your suggestion properly yet but 
> thought I'd mention I agree with your line of thinking that the 
> validation mechanism in particular needs to be improved. However, this 
> is a general problem that also applies to rich clients; that is 
> responsibility for rolling back changes to a model, and various patterns 
> have developed over the years.  A temporary copy is a simple 
> implementation, however within a JPA-environment automatically creating 
> a clone is often infeasible or undesirable. For example, if it's 
> attached to a session, this process may cause hydration of the entire 
> object graph. Unless the framework is provided hints, it won't know what 
> to safely/efficiently clone.
> 
> Having the framework maintain dirty flags or proxy for the model also 
> seems ineffective as the JPA provider performs the exact same task, only 
> better.
> 
> The option to write straight to the model (or DTO) and performing 
> validation of the model (or DTO) is a distinguishing feature of Struts 
> 2, but also the source of such complications. Anyway, I don't have a 
> solution, but I do intend to start resolving the numerous validation 
> issues in JIRA in the near future and this one is the list.

Pondering over this issue during breakfast, I thought I'd check out how some 
other frameworks do it and I found some weak descriptions criticising struts for 
'architectural issues' which I've been hearing for years but now I've forgotten 
what they actually are. I think in most cases they referred to Struts 1, but 
does anyone know of a good architectural critique that goes over such issues?



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


Mime
View raw message