Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 45218 invoked from network); 13 Jul 2006 05:46:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Jul 2006 05:46:25 -0000 Received: (qmail 40352 invoked by uid 500); 13 Jul 2006 05:46:22 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 40311 invoked by uid 500); 13 Jul 2006 05:46:22 -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 40299 invoked by uid 99); 13 Jul 2006 05:46:21 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jul 2006 22:46:21 -0700 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,HTML_TAG_EXIST_TBODY,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of martin.marinschek@gmail.com designates 64.233.182.191 as permitted sender) Received: from [64.233.182.191] (HELO nf-out-0910.google.com) (64.233.182.191) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jul 2006 22:46:20 -0700 Received: by nf-out-0910.google.com with SMTP id a27so46641nfc for ; Wed, 12 Jul 2006 22:45:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=tEkFffvMIlp++UlMzKfpDrYnAZHaAxcPnfzCuZpEUkNPERJ1p+Cp+5iNDO2tTJinEuCKhojMFNiPLmfzd8yDODBONdBuLW0puUY58cuFGVN58i5laNvRw2dkm+LfcU5Fkq4nICs8fCnBfGxBnZ5H67+uHl088zzcnB8/lP8291E= Received: by 10.48.42.1 with SMTP id p1mr468302nfp; Wed, 12 Jul 2006 22:45:59 -0700 (PDT) Received: by 10.49.9.19 with HTTP; Wed, 12 Jul 2006 22:45:59 -0700 (PDT) Message-ID: <5a99335f0607122245h51622dd5n64316b488449e826@mail.gmail.com> Date: Thu, 13 Jul 2006 07:45:59 +0200 From: "Martin Marinschek" To: "MyFaces Development" Subject: Re: Ids in 1.1.3 and 1.1.4 In-Reply-To: <071220062131.28654.44B56A17000C047200006FEE22007507440A9D9B0E03020E9009@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18549_24552608.1152769559382" References: <071220062131.28654.44B56A17000C047200006FEE22007507440A9D9B0E03020E9009@comcast.net> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_18549_24552608.1152769559382 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline The problem is that there is a bug in the spec here. If you called createUniqueId in earlier MyFaces versions, you would receive a unique id, but only unique for one request. On the next request, the sequence would be restarted. This would make working with dynamic component creation exceptionally hard, if not impossible. On subsequent requests, the sequence counter would'nt start anew, and you'd get DuplicateIdExceptions all over! To fix this, we went to be more inline with what JSF1.2 foresees for id creation. JSF 1.2 wants the servlet container to create unique ids - so we loose control about the ids produced, and createUniqueId is never called. Note: when we all move to 1.2, you won't know about the id-syntax anymore anyways - the servlet container provides the unique ids then. We implemented a partial solution of this - we have a separate counter for JSP-tags; and those ids are produced out of a different sequence. To make sure that the id's don't match, we prepend a "jsp" in front of the actual unique id counter. With this solution, we can store the current sequence counter of createUniqueId between requests, and dynamic component creation is not a problem anymore! I wonder why you would need the component id to have a special syntax? Do you rely in any way on this? regards, Martin On 7/12/06, Gary VanMatre wrote: > > >From: "Matthias Wessendorf" > > > > > Hey Howard, > > > > you mean stuff like ? > > > > > > > > > > > Was introduced in "Revision 359449" > > > > see > > http://svn.apache.org/viewvc?view=rev&revision=359449 > > > > I can't tell you much about that. sorry! > > > > > > I did some research on this for Shale Clay. Clay has to conditionally > decide to use the ViewRoot to create a unique id or use another method. It > looks like it has to do with partial page rendering. I suspect it wasadded for ajax component support. > > That's pretty much the same answer as Matthias. > > > > > -Matt > > Gary > > > > > On 7/12/06, Abrams, Howard A wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Is there any reason why the UIComponentTag appends "jsp" to all the > > > component ids in 1.1.3/1.1.4? Any chance this can be removed for 1.1.4so > > > that it returns the same ids as UIViewRoot.createUniqueId() and the > RI? > > > > > > > > > > > > Thanks, > > > > > > h > > > > > > -- > > Matthias Wessendorf > > > > further stuff: > > blog: http://jroller.com/page/mwessendorf > > mail: mwessendorf-at-gmail-dot-com > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces ------=_Part_18549_24552608.1152769559382 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The problem is that there is a bug in the spec here.

If you called createUniqueId in earlier MyFaces versions, you would receive a unique id, but only unique for one request. On the next request, the sequence would be restarted. This would make working with dynamic component creation exceptionally hard, if not impossible. On subsequent requests, the sequence counter would'nt start anew, and you'd get DuplicateIdExceptions all over!

To fix this, we went to be more inline with what JSF1.2 foresees for id creation. JSF 1.2 wants the servlet container to create unique ids - so we loose control about the ids produced, and createUniqueId is never called. Note: when we all move to 1.2, you won't know about the id-syntax anymore anyways - the servlet container provides the unique ids then.

We implemented a partial solution of this - we have a separate counter for JSP-tags; and those ids are produced out of a different sequence. To make sure that the id's don't match, we prepend a "jsp" in front of the actual unique id counter.

With this solution, we can store the current sequence counter of createUniqueId between requests, and dynamic component creation is not a problem anymore!

I wonder why you would need the component id to have a special syntax? Do you rely in any way on this?

regards,

Martin

On 7/12/06, Gary VanMatre <gvanmatre@comcast.net> wrote:
>From: "Matthias Wessendorf" <matzew@apache.org>

>
> Hey Howard,
>
> you mean stuff like ?
>
>


>


> Was introduced in " Revision 359449"
>
> see
> http://svn.apache.org/viewvc?view=rev&revision=359449
>
> I can't tell you much about that. sorry!
>

 

I did some research on this for Shale Clay.  Clay has to conditionally decide to use the ViewRoot to create a unique id or use another method.  It looks like it has to do with partial page rendering.   I suspect it was added for ajax component support.  

That's pretty much the same answer as Matthias.

 

> -Matt

Gary

>
> On 7/12/06, Abrams, Howard A wrote:
> >
> >
> >
> >
> > Hi,
> >
> >
> >
> > Is there any reason why the UIComponentTag appends "jsp" to all the
> > component ids in 1.1.3/1.1.4? Any chance this can be removed for 1.1.4 so
> > that it returns the same ids as UIViewRoot.createUniqueId() and the RI?
> >
> >
> >
> > Thanks,
> >
> > h
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com




--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces ------=_Part_18549_24552608.1152769559382--