struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Tiernay" <btier...@hotmail.com>
Subject Re: Fundamental flaw in Model-Driven?
Date Sat, 26 Apr 2008 14:51:29 GMT
I'm wondering if something like OVal (a great validation framework btw) can 
help out here:

See probe mode:

http://oval.sourceforge.net/#d0e739

--------------------------------------------------
From: "Adam Hardy" <ahardy.struts@cyberspaceroad.com>
Sent: Saturday, April 26, 2008 6:34 AM
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: Fundamental flaw in Model-Driven?

> 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
>
> 

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


Mime
View raw message