Return-Path: Delivered-To: apmail-struts-dev-archive@www.apache.org Received: (qmail 42007 invoked from network); 26 Apr 2008 10:17:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Apr 2008 10:17:06 -0000 Received: (qmail 78421 invoked by uid 500); 26 Apr 2008 10:17:06 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 78370 invoked by uid 500); 26 Apr 2008 10:17:05 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 78355 invoked by uid 99); 26 Apr 2008 10:17:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 26 Apr 2008 03:17:05 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of chase@osdev.org designates 65.38.103.38 as permitted sender) Received: from [65.38.103.38] (HELO smtp.osdev.org) (65.38.103.38) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 26 Apr 2008 10:16:12 +0000 Received: from gray.osdev.org (c-76-30-37-14.hsd1.tx.comcast.net [76.30.37.14]) by smtp.osdev.org (Postfix) with ESMTP id E9DA9157D27 for ; Sat, 26 Apr 2008 05:16:32 -0500 (CDT) Message-ID: <481300FF.5000109@osdev.org> Date: Sat, 26 Apr 2008 05:16:31 -0500 From: Chase User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Struts Developers List Subject: Re: Fundamental flaw in Model-Driven? References: <20080424114307.ipiiqer2bxsswwkw@webmail.mit.edu> <4812A6B6.4090702@blueskyminds.com.au> <4812F909.1090404@cyberspaceroad.com> In-Reply-To: <4812F909.1090404@cyberspaceroad.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org > > I also stumbled across this problem. > > One solution could be to use a TypeConverter to instantiate new, > unmanaged entities during the ParamsInterceptor invocation. > > Such a TypeConverter could pass back instantiated, blank entities > (with nothing but the ID) for ParamsInterceptor to collate, and > against which ValidationInterceptor can operate. E.g. for param > 'bean=69', the type converter instantiates Bean and calls setId(69) > > Once Validation succeeds, ModelDriven and ParamsInterceptor should be > invoked again to update the managed entities. > > The unmanaged entities would just disappear out of scope and be > garbage collected. > > Such a strategy would require modification to ParamsInterceptor to > tell it to use the initial TypeConverter on the first call, but not on > the second. Whether the algorithm that controls that is accessible for > modification in the ParamsInterceptor or whether it is out-of-reach in > OGNL somewhere, I'm not sure. > If it was a blank (just id) entity then you'd lose the ability to validate "num1 > num2" where num1 was set by the params interceptor but num2 came from the database. -Chase --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org