Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 71640 invoked from network); 24 May 2007 18:34:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 May 2007 18:34:35 -0000 Received: (qmail 38587 invoked by uid 500); 24 May 2007 18:34:39 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 38542 invoked by uid 500); 24 May 2007 18:34:39 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 38527 invoked by uid 99); 24 May 2007 18:34:39 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 May 2007 11:34:39 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of mkienenb@gmail.com designates 64.233.162.229 as permitted sender) Received: from [64.233.162.229] (HELO nz-out-0506.google.com) (64.233.162.229) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 May 2007 11:34:33 -0700 Received: by nz-out-0506.google.com with SMTP id i28so168706nzi for ; Thu, 24 May 2007 11:34:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PXHylyUmlJ06UJvjct9g3gONE32LJBPtNW4El6CzdILkEhkVEfawK9l0p6KPX3LVzNqp7nFQ8Jm3fQ6Mc29WVDGOYHC6Y8JSIcJea3BLb3ZqYfNERIW1OdtqNJ9Dfep7rDud/kRyE8gkDjmIV6U5AXjjKniJ9O94q63Uj3EbkmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IoGmrpY6digc/x35bCeYtULMi07Tfb0pHEYKW2HegG91TrFiiJcadPsSlUZngLx4ISBBGWXAZgipxtQY3vLI/CyXOh329OkYB0ThX+w4pH5kSG31BgV7+sh/Z0QELjTuH5YFaRAgWfog1bIIeJYR4Jkj+D6pEMGiYDHlS9RX14Y= Received: by 10.115.23.12 with SMTP id a12mr1042589waj.1180031650125; Thu, 24 May 2007 11:34:10 -0700 (PDT) Received: by 10.114.160.3 with HTTP; Thu, 24 May 2007 11:34:10 -0700 (PDT) Message-ID: <8f985b960705241134h5f852dc7v2c78a47b2de4fc28@mail.gmail.com> Date: Thu, 24 May 2007 14:34:10 -0400 From: "Mike Kienenberger" To: "MyFaces Development" Subject: Re: subform and model changes In-Reply-To: <4655D666.8070300@ops.co.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4655503F.8030105@ops.co.at> <8f985b960705240804i641b3927if592f3c56c832bd8@mail.gmail.com> <4655D666.8070300@ops.co.at> X-Virus-Checked: Checked by ClamAV on apache.org No, the main goal of subform was to allow you to submit and validate part of a page without affecting the rest of the page. Perhaps for your own use cases, you've primarily used it to do partial page refreshing, but that's not how I've used it. I would disagree that this is the majority use case since no one else has posted an issue with the current behavior up to this point :-) One of my primary use cases is to do something like

Losing the unvalidated input of the fields outside of the subform would be unacceptable. While it's true that s:subForm is still in the sandbox, it's only because of lack of time that it's not been promoted yet. We took a straw poll a few months back and no one saw any reason why it couldn't be promoted at that point. It seems like a reasonable suggestion to allow the behavior you've suggested, but there's no reason to assume that your new behavior should be the default behavior, especially since it will change the behavior of existing applications. On 5/24/07, Mario Ivankovits wrote: > Hi Mike! > > If you want to change the submitted values to the backing bean, then > > you need to do so in code just as if you wanted to do it for a regular > > form. > > > > http://wiki.apache.org/myfaces/ClearInputComponents > Yep, I am aware of this, but I really hate to use component bindings. > This is alway a "last resort" for me. > > > That said, I'd not be opposed to adding an attribute to a subform to > > configure it to refetch from the model so long as that was not the > > default behavior. > Hmmm .... not issuing the validation and not updating the model to allow > to submit another form was the main goal of subForm, no? > If we say subForm was introduced to avoid the use of multiple h:forms on > the page, then it should refetch from the model by default. > > I'd like to add a parameter ... maybe called "refetchFromModel" ... with > a default value of "true". I am sure this is the major use case, > especially if you keep in mind that e.g. you can change the options of a > select*Listbox but not its value (yet). > It's a sandbox component, I think we can argue the change. > > Any objections? > > Ciao, > Mario > >