From andy.schwartz at oracle.com Sun Aug 16 04:45:24 2020 Content-Type: multipart/mixed; boundary="===============2513273720227104328==" MIME-Version: 1.0 From: Andy Schwartz To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] binding vs. ui:repeat Date: Mon, 07 Sep 2009 21:06:58 -0400 Message-ID: <4AA5AE32.4080405@oracle.com> In-Reply-To: 1252247305.4843.13.camel@quadshark --===============2513273720227104328== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thanks Lincoln. I haven't had time to debug this, but I have a theory = about what might be happening. In your sample: > rendered=3D"#{!cc.attrs.disabled}"> > * action=3D"#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}" = > /> * > We expect "cc" to resolve to the containing composite component (ie. to = the component). I wouldn't be surprised if what is = actually happening is that "cc" is being resolved to the = composite component instead. One reason why I suspect this might be = happening is that I know that Ryan has investigated/resolved similar = problems not too long ago. Another reason why I am suspicious about = this is because we have faced similar issues in our own (ADF Faces) = declarative component solution. This stuff can get tricky. :-) Hey Ryan - Does this problem look familiar? Any thoughts on this? Andy Lincoln Baxter, III wrote: > Hey Andy, here you go: > > In the mean time I'm going to sign up for the dev lists. > > ---------------------------------------------------------------------- > Using: > action=3D"*#{taskController.saveTaskAjax(cc.attrs.story, = > cc.attrs.task)}*" /> > > *#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}* =3D > null values passed to method > *#{taskController.saveTaskAjax(currentStoryBean.story, task)}* =3D > correct values resolved, assuming currentStoryBean.story and task > are both in the EL/page scope somewhere. > > > ---------------------------------------------------------------------- > *CC Impl:* > > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h=3D"http://java.sun.com/jsf/html" > xmlns:f=3D"http://java.sun.com/jsf/core" > xmlns:a=3D"http://java.sun.com/jsf/composite/ajax" > xmlns:cc=3D"http://java.sun.com/jsf/composite"> > > > > default=3D"false" /> > > > > > > #{cc.attrs.styleClass} taskBlock_#{cc.attrs.task.status}" = > style=3D"#{cc.attrs.style}"> > >
> rendered=3D"#{cc.attrs.disabled}"/> > rendered=3D"#{!cc.attrs.disabled}"> > * action=3D"#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}" = > /> * > >
> > > > > ---------------------------------------------------------------------- > *consuming page code:* <-- this is where task is defined in the = > UI:Repeat, so it is in scope > > PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:c=3D"http://java.sun.com/jsp/jstl/core" > xmlns:f=3D"http://java.sun.com/jsf/core" > xmlns:h=3D"http://java.sun.com/jsf/html" > xmlns:socialpm=3D"http://java.sun.com/jsf/composite/socialpm" > xmlns:pretty=3D"http://ocpsoft.com/prettyfaces" > xmlns:ui=3D"http://java.sun.com/jsf/facelets" xml:lang=3D"en" lang=3D"en"> > > > > >
This story has no tasks. That could be a problem = > later...
> > > > members=3D"#{currentProjectBean.project.activeMembers}" > disabled=3D"#{!authorizationBean.isMember or !currentStoryBean.story.open= }" > deletable=3D"true" styleClass=3D"m5t" refreshOnSave=3D"false" /> > > > > > > > > > On Sat, 2009-09-05 at 15:23 -0400, Andy Schwartz wrote: >> Hey Lincoln - >> >> Lincoln Baxter, III wrote: >> > First, please let me know if there is a better place to ask JSF Dev = >> > related questions. >> > >> >> I suppose the Mojarra dev list might be the right place for = >> implementation questions: >> >> https://javaserverfaces.dev.java.net/mailinglists.html >> >> Though personally I am fine with you asking here. :-) >> >> Could you send along your composite component implementation (and = >> perhaps a snippet from the consuming page)? Just want to make sure I = >> understand the use case. >> >> Andy >> >> >> = > -- > *Lincoln Baxter, III* > Co-Founder of OcpSoft > Author of PrettyFaces URL Rewriting = > for JSF > > --===============2513273720227104328==-- From Ryan.Lubke at Sun.COM Sun Aug 16 04:45:24 2020 Content-Type: multipart/mixed; boundary="===============8138302047748199205==" MIME-Version: 1.0 From: Ryan Lubke To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] binding vs. ui:repeat Date: Tue, 08 Sep 2009 09:59:11 -0700 Message-ID: <4AA68D5F.60809@sun.com> In-Reply-To: 4AA5AE32.4080405@oracle.com --===============8138302047748199205== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 9/7/09 6:06 PM, Andy Schwartz wrote: > Thanks Lincoln. I haven't had time to debug this, but I have a theory = > about what might be happening. In your sample: > >> > rendered=3D"#{!cc.attrs.disabled}"> >> *> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, = >> cc.attrs.task)}" /> * >> > > We expect "cc" to resolve to the containing composite component (ie. = > to the component). I wouldn't be surprised if = > what is actually happening is that "cc" is being resolved to the = > composite component instead. Yep, that's what is happening. > One reason why I suspect this might be happening is that I know that = > Ryan has investigated/resolved similar problems not too long ago. The problem we resolved was the passing of #{cc.attrs} attributes = between nested composite components. For this case, the spec recommends using cc.parent.attrs.story and = cc.parent.attrs.task, where parent resolves to the nearest composite component parent of the current composite = component. > Another reason why I am suspicious about this is because we have faced = > similar issues in our own (ADF Faces) declarative component solution. = > This stuff can get tricky. :-) > > Hey Ryan - > > Does this problem look familiar? Any thoughts on this? > > Andy > > Lincoln Baxter, III wrote: >> Hey Andy, here you go: >> >> In the mean time I'm going to sign up for the dev lists. >> >> ---------------------------------------------------------------------- >> Using: >> > action=3D"*#{taskController.saveTaskAjax(cc.attrs.story, = >> cc.attrs.task)}*" /> >> >> *#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}* =3D >> null values passed to method >> *#{taskController.saveTaskAjax(currentStoryBean.story, task)}* =3D >> correct values resolved, assuming currentStoryBean.story and task >> are both in the EL/page scope somewhere. >> >> >> ---------------------------------------------------------------------- >> *CC Impl:* >> >> >> > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> >> > xmlns:h=3D"http://java.sun.com/jsf/html" >> xmlns:f=3D"http://java.sun.com/jsf/core" >> xmlns:a=3D"http://java.sun.com/jsf/composite/ajax" >> xmlns:cc=3D"http://java.sun.com/jsf/composite"> >> >> >> >> > default=3D"false" /> >> >> >> >> >> >> > #{cc.attrs.styleClass} taskBlock_#{cc.attrs.task.status}" = >> style=3D"#{cc.attrs.style}"> >> >>
>> > rendered=3D"#{cc.attrs.disabled}"/> >> > rendered=3D"#{!cc.attrs.disabled}"> >> *> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, = >> cc.attrs.task)}" /> * >> >>
>> >> >> >> >> ---------------------------------------------------------------------- >> *consuming page code:* <-- this is where task is defined in the = >> UI:Repeat, so it is in scope >> >> > PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" >> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> >> > xmlns:c=3D"http://java.sun.com/jsp/jstl/core" >> xmlns:f=3D"http://java.sun.com/jsf/core" >> xmlns:h=3D"http://java.sun.com/jsf/html" >> xmlns:socialpm=3D"http://java.sun.com/jsf/composite/socialpm" >> xmlns:pretty=3D"http://ocpsoft.com/prettyfaces" >> xmlns:ui=3D"http://java.sun.com/jsf/facelets" xml:lang=3D"en" lang=3D"en= "> >> >> >> >> >>
This story has no tasks. That could be a problem = >> later...
>> >> >> >> > members=3D"#{currentProjectBean.project.activeMembers}" >> disabled=3D"#{!authorizationBean.isMember or = >> !currentStoryBean.story.open}" >> deletable=3D"true" styleClass=3D"m5t" refreshOnSave=3D"false" /> >> >> >> >> >> >> >> >> >> On Sat, 2009-09-05 at 15:23 -0400, Andy Schwartz wrote: >>> Hey Lincoln - >>> >>> Lincoln Baxter, III wrote: >>> > First, please let me know if there is a better place to ask JSF = >>> Dev > related questions. >>> > >>> >>> I suppose the Mojarra dev list might be the right place for = >>> implementation questions: >>> >>> https://javaserverfaces.dev.java.net/mailinglists.html >>> >>> Though personally I am fine with you asking here. :-) >>> >>> Could you send along your composite component implementation (and = >>> perhaps a snippet from the consuming page)? Just want to make sure = >>> I understand the use case. >>> >>> Andy >>> >>> >> -- = >> *Lincoln Baxter, III* >> Co-Founder of OcpSoft >> Author of PrettyFaces URL Rewriting = >> for JSF >> >> > --===============8138302047748199205==-- From lincolnbaxter at gmail.com Sun Aug 16 04:45:24 2020 Content-Type: multipart/mixed; boundary="===============7368817074854316740==" MIME-Version: 1.0 From: lincolnbaxter at gmail.com To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] binding vs. ui:repeat Date: Tue, 08 Sep 2009 17:18:29 +0000 Message-ID: <956029407-1252430287-cardhu_decombobulator_blackberry.rim.net-663268378-@bda160.bisx.prod.on.blackberry> In-Reply-To: 4AA68D5F.60809@sun.com --===============7368817074854316740== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Ok. Ill try that. I just wanted to make sure that I didn't miss something, = before I check in this code to mojarra. = More when I get home, thanks! Lincoln Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Ryan Lubke Date: Tue, 08 Sep 2009 09:59:11 = To: Subject: Re: [jsr-314-open] binding vs. ui:repeat On 9/7/09 6:06 PM, Andy Schwartz wrote: > Thanks Lincoln. I haven't had time to debug this, but I have a theory = > about what might be happening. In your sample: > >> > rendered=3D"#{!cc.attrs.disabled}"> >> *> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, = >> cc.attrs.task)}" /> * >> > > We expect "cc" to resolve to the containing composite component (ie. = > to the component). I wouldn't be surprised if = > what is actually happening is that "cc" is being resolved to the = > composite component instead. Yep, that's what is happening. > One reason why I suspect this might be happening is that I know that = > Ryan has investigated/resolved similar problems not too long ago. The problem we resolved was the passing of #{cc.attrs} attributes = between nested composite components. For this case, the spec recommends using cc.parent.attrs.story and = cc.parent.attrs.task, where parent resolves to the nearest composite component parent of the current composite = component. > Another reason why I am suspicious about this is because we have faced = > similar issues in our own (ADF Faces) declarative component solution. = > This stuff can get tricky. :-) > > Hey Ryan - > > Does this problem look familiar? Any thoughts on this? > > Andy > > Lincoln Baxter, III wrote: >> Hey Andy, here you go: >> >> In the mean time I'm going to sign up for the dev lists. >> >> ---------------------------------------------------------------------- >> Using: >> > action=3D"*#{taskController.saveTaskAjax(cc.attrs.story, = >> cc.attrs.task)}*" /> >> >> *#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}* =3D >> null values passed to method >> *#{taskController.saveTaskAjax(currentStoryBean.story, task)}* =3D >> correct values resolved, assuming currentStoryBean.story and task >> are both in the EL/page scope somewhere. >> >> >> ---------------------------------------------------------------------- >> *CC Impl:* >> >> >> > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> >> > xmlns:h=3D"http://java.sun.com/jsf/html" >> xmlns:f=3D"http://java.sun.com/jsf/core" >> xmlns:a=3D"http://java.sun.com/jsf/composite/ajax" >> xmlns:cc=3D"http://java.sun.com/jsf/composite"> >> >> >> >> > default=3D"false" /> >> >> >> >> >> >> > #{cc.attrs.styleClass} taskBlock_#{cc.attrs.task.status}" = >> style=3D"#{cc.attrs.style}"> >> >>
>> > rendered=3D"#{cc.attrs.disabled}"/> >> > rendered=3D"#{!cc.attrs.disabled}"> >> *> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, = >> cc.attrs.task)}" /> * >> >>
>> >> >> >> >> ---------------------------------------------------------------------- >> *consuming page code:* <-- this is where task is defined in the = >> UI:Repeat, so it is in scope >> >> > PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" >> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> >> > xmlns:c=3D"http://java.sun.com/jsp/jstl/core" >> xmlns:f=3D"http://java.sun.com/jsf/core" >> xmlns:h=3D"http://java.sun.com/jsf/html" >> xmlns:socialpm=3D"http://java.sun.com/jsf/composite/socialpm" >> xmlns:pretty=3D"http://ocpsoft.com/prettyfaces" >> xmlns:ui=3D"http://java.sun.com/jsf/facelets" xml:lang=3D"en" lang=3D"en= "> >> >> >> >> >>
This story has no tasks. That could be a problem = >> later...
>> >> >> >> > members=3D"#{currentProjectBean.project.activeMembers}" >> disabled=3D"#{!authorizationBean.isMember or = >> !currentStoryBean.story.open}" >> deletable=3D"true" styleClass=3D"m5t" refreshOnSave=3D"false" /> >> >> >> >> >> >> >> >> >> On Sat, 2009-09-05 at 15:23 -0400, Andy Schwartz wrote: >>> Hey Lincoln - >>> >>> Lincoln Baxter, III wrote: >>> > First, please let me know if there is a better place to ask JSF = >>> Dev > related questions. >>> > >>> >>> I suppose the Mojarra dev list might be the right place for = >>> implementation questions: >>> >>> https://javaserverfaces.dev.java.net/mailinglists.html >>> >>> Though personally I am fine with you asking here. :-) >>> >>> Could you send along your composite component implementation (and = >>> perhaps a snippet from the consuming page)? Just want to make sure = >>> I understand the use case. >>> >>> Andy >>> >>> >> -- = >> *Lincoln Baxter, III* >> Co-Founder of OcpSoft >> Author of PrettyFaces URL Rewriting = >> for JSF >> >> > --===============7368817074854316740==-- From lincolnbaxter at gmail.com Sun Aug 16 04:45:24 2020 Content-Type: multipart/mixed; boundary="===============7720293901112559723==" MIME-Version: 1.0 From: Lincoln Baxter, III To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] binding vs. ui:repeat Date: Wed, 09 Sep 2009 00:08:29 -0400 Message-ID: <1252469309.22703.26.camel@quadshark> In-Reply-To: 4AA68D5F.60809@sun.com --===============7720293901112559723== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > Yep, that's what is happening. YOU, sirs, are good. Andy and Ryan both nailed it. Thank you. This needs to be put in a good place where people will find it, if it is not already. I searched for it in the PDLdoc but only found a reference to parent in the index, and not to this effect. I'm not sure most people would think to go through the parent, since EL is usually a direct reference to the object immediately at hand. Perhaps in the "Nesting of composite components" section? https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/facelets/index.= html On Tue, 2009-09-08 at 09:59 -0700, Ryan Lubke wrote: -- Lincoln Baxter, III Co-Founder of OcpSoft Author of PrettyFaces URL Rewriting for JSF --===============7720293901112559723== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv L0VOIj4KPEhUTUw+CjxIRUFEPgogIDxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09O VEVOVD0idGV4dC9odG1sOyBDSEFSU0VUPVVURi04Ij4KICA8TUVUQSBOQU1FPSJHRU5FUkFUT1Ii IENPTlRFTlQ9Ikd0a0hUTUwvMy4yNi4wIj4KPC9IRUFEPgo8Qk9EWT4KPEJMT0NLUVVPVEUgVFlQ RT1DSVRFPgogICAgPFRUPjxGT05UIENPTE9SPSIjMWExYTFhIj5ZZXAsIHRoYXQncyB3aGF0IGlz IGhhcHBlbmluZy48L0ZPTlQ+PC9UVD48QlI+CjwvQkxPQ0tRVU9URT4KWU9VLCBzaXJzLCBhcmUg Z29vZC48QlI+CjxCUj4KQW5keSBhbmQgUnlhbiBib3RoIG5haWxlZCBpdC48QlI+CjxCUj4KVGhh bmsgeW91LiBUaGlzIG5lZWRzIHRvIGJlIHB1dCBpbiBhIGdvb2QgcGxhY2Ugd2hlcmUgcGVvcGxl IHdpbGwgZmluZCBpdCwgaWYgaXQgaXMgbm90IGFscmVhZHkuIEkgc2VhcmNoZWQgZm9yIGl0IGlu IHRoZSBQRExkb2MgYnV0IG9ubHkgZm91bmQgYSByZWZlcmVuY2UgdG8gcGFyZW50IGluIHRoZSBp bmRleCwgYW5kIG5vdCB0byB0aGlzIGVmZmVjdC4gSSdtIG5vdCBzdXJlIG1vc3QgcGVvcGxlIHdv dWxkIHRoaW5rIHRvIGdvIHRocm91Z2ggdGhlIHBhcmVudCwgc2luY2UgRUwgaXMgdXN1YWxseSBh IGRpcmVjdCByZWZlcmVuY2UgdG8gdGhlIG9iamVjdCBpbW1lZGlhdGVseSBhdCBoYW5kLjxCUj4K PEJSPgpQZXJoYXBzIGluIHRoZSAmcXVvdDtOZXN0aW5nIG9mIGNvbXBvc2l0ZSBjb21wb25lbnRz JnF1b3Q7IHNlY3Rpb24/PEJSPgo8QlI+CjxBIEhSRUY9Imh0dHBzOi8vamF2YXNlcnZlcmZhY2Vz LmRldi5qYXZhLm5ldC9ub25hdi9kb2NzLzIuMC9wZGxkb2NzL2ZhY2VsZXRzL2luZGV4Lmh0bWwi Pmh0dHBzOi8vamF2YXNlcnZlcmZhY2VzLmRldi5qYXZhLm5ldC9ub25hdi9kb2NzLzIuMC9wZGxk b2NzL2ZhY2VsZXRzL2luZGV4Lmh0bWw8L0E+PEJSPgo8QlI+Ck9uIFR1ZSwgMjAwOS0wOS0wOCBh dCAwOTo1OSAtMDcwMCwgUnlhbiBMdWJrZSB3cm90ZTo8QlI+CjxUQUJMRSBDRUxMU1BBQ0lORz0i MCIgQ0VMTFBBRERJTkc9IjAiIFdJRFRIPSIxMDAlIj4KPFRSPgo8VEQ+Ci0tPEJSPgo8Qj5MaW5j b2xuIEJheHRlciwgSUlJPC9CPjxCUj4KQ28tRm91bmRlciBvZiA8QSBIUkVGPSJodHRwOi8vb2Nw c29mdC5jb20iPk9jcFNvZnQ8L0E+PEJSPgpBdXRob3Igb2YgPEEgSFJFRj0iaHR0cDovL29jcHNv ZnQuY29tL3ByZXR0eWZhY2VzIj5QcmV0dHlGYWNlczwvQT4gVVJMIFJld3JpdGluZyBmb3IgSlNG PEJSPgo8QlI+CjxCUj4KPC9URD4KPC9UUj4KPC9UQUJMRT4KPC9CT0RZPgo8L0hUTUw+Cg== --===============7720293901112559723==-- From lincolnbaxter at gmail.com Sun Aug 16 04:45:24 2020 Content-Type: multipart/mixed; boundary="===============6979339960593787462==" MIME-Version: 1.0 From: Lincoln Baxter, III To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] binding vs. ui:repeat Date: Wed, 09 Sep 2009 00:33:13 -0400 Message-ID: <1252470793.22703.41.camel@quadshark> In-Reply-To: 4AA68D5F.60809@sun.com --===============6979339960593787462== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable One more issue I'd like to bring up: it appears that when using the value of the object provided has not yet been updated in the model, hence, the value is the old value, not the new value. When using on the button submitting the values, the new value is populated into the model instead... which is the behavior I would expect. Pardon the probably obvious question... Is there an contract with valueChangeListeners that states they fire before model updates? I see in the spec that it fires: "when a new local value has been created, and has passed all validations," but nothing about if the model has been updated or not. --Lincoln On Tue, 2009-09-08 at 09:59 -0700, Ryan Lubke wrote: > On 9/7/09 6:06 PM, Andy Schwartz wrote: > > Thanks Lincoln. I haven't had time to debug this, but I have a theory = > > about what might be happening. In your sample: > > > >> >> rendered=3D"#{!cc.attrs.disabled}"> > >> * >> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, = > >> cc.attrs.task)}" /> * > >> > > > > We expect "cc" to resolve to the containing composite component (ie. = > > to the component). I wouldn't be surprised if = > > what is actually happening is that "cc" is being resolved to the = > > composite component instead. > Yep, that's what is happening. > > One reason why I suspect this might be happening is that I know that = > > Ryan has investigated/resolved similar problems not too long ago. > The problem we resolved was the passing of #{cc.attrs} attributes = > between nested composite components. > For this case, the spec recommends using cc.parent.attrs.story and = > cc.parent.attrs.task, where parent resolves > to the nearest composite component parent of the current composite = > component. > > Another reason why I am suspicious about this is because we have faced = > > similar issues in our own (ADF Faces) declarative component solution. = > > This stuff can get tricky. :-) > > > > Hey Ryan - > > > > Does this problem look familiar? Any thoughts on this? > > > > Andy > > > > Lincoln Baxter, III wrote: > >> Hey Andy, here you go: > >> > >> In the mean time I'm going to sign up for the dev lists. > >> > >> ---------------------------------------------------------------------- > >> Using: > >> >> action=3D"*#{taskController.saveTaskAjax(cc.attrs.story, = > >> cc.attrs.task)}*" /> > >> > >> *#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}* = =3D > >> null values passed to method > >> *#{taskController.saveTaskAjax(currentStoryBean.story, task)}* =3D > >> correct values resolved, assuming currentStoryBean.story and task > >> are both in the EL/page scope somewhere. > >> > >> > >> ---------------------------------------------------------------------- > >> *CC Impl:* > >> > >> > >> >> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > >> >> xmlns:h=3D"http://java.sun.com/jsf/html" > >> xmlns:f=3D"http://java.sun.com/jsf/core" > >> xmlns:a=3D"http://java.sun.com/jsf/composite/ajax" > >> xmlns:cc=3D"http://java.sun.com/jsf/composite"> > >> > >> > >> > >> >> default=3D"false" /> > >> > >> > >> > >> > >> > >> >> #{cc.attrs.styleClass} taskBlock_#{cc.attrs.task.status}" = > >> style=3D"#{cc.attrs.style}"> > >> > >>
> >> >> rendered=3D"#{cc.attrs.disabled}"/> > >> >> rendered=3D"#{!cc.attrs.disabled}"> > >> * >> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, = > >> cc.attrs.task)}" /> * > >> > >>
> >> > >> > >> > >> > >> ---------------------------------------------------------------------- > >> *consuming page code:* <-- this is where task is defined in the = > >> UI:Repeat, so it is in scope > >> > >> >> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" > >> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > >> >> xmlns:c=3D"http://java.sun.com/jsp/jstl/core" > >> xmlns:f=3D"http://java.sun.com/jsf/core" > >> xmlns:h=3D"http://java.sun.com/jsf/html" > >> xmlns:socialpm=3D"http://java.sun.com/jsf/composite/socialpm" > >> xmlns:pretty=3D"http://ocpsoft.com/prettyfaces" > >> xmlns:ui=3D"http://java.sun.com/jsf/facelets" xml:lang=3D"en" lang=3D"= en"> > >> > >> > >> > >> > >>
This story has no tasks. That could be a problem = > >> later...
> >> > >> > >> > >> >> members=3D"#{currentProjectBean.project.activeMembers}" > >> disabled=3D"#{!authorizationBean.isMember or = > >> !currentStoryBean.story.open}" > >> deletable=3D"true" styleClass=3D"m5t" refreshOnSave=3D"false" /> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Sat, 2009-09-05 at 15:23 -0400, Andy Schwartz wrote: > >>> Hey Lincoln - > >>> > >>> Lincoln Baxter, III wrote: > >>> > First, please let me know if there is a better place to ask JSF = > >>> Dev > related questions. > >>> > > >>> > >>> I suppose the Mojarra dev list might be the right place for = > >>> implementation questions: > >>> > >>> https://javaserverfaces.dev.java.net/mailinglists.html > >>> > >>> Though personally I am fine with you asking here. :-) > >>> > >>> Could you send along your composite component implementation (and = > >>> perhaps a snippet from the consuming page)? Just want to make sure = > >>> I understand the use case. > >>> > >>> Andy > >>> > >>> > >> -- = > >> *Lincoln Baxter, III* > >> Co-Founder of OcpSoft > >> Author of PrettyFaces URL Rewriting = > >> for JSF > >> > >> > > > = -- Lincoln Baxter, III Co-Founder of OcpSoft Author of PrettyFaces URL Rewriting for JSF --===============6979339960593787462== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv L0VOIj4KPEhUTUw+CjxIRUFEPgogIDxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09O VEVOVD0idGV4dC9odG1sOyBDSEFSU0VUPVVURi04Ij4KICA8TUVUQSBOQU1FPSJHRU5FUkFUT1Ii IENPTlRFTlQ9Ikd0a0hUTUwvMy4yNi4wIj4KPC9IRUFEPgo8Qk9EWT4KT25lIG1vcmUgaXNzdWUg SSdkIGxpa2UgdG8gYnJpbmcgdXA6IGl0IGFwcGVhcnMgdGhhdCB3aGVuIHVzaW5nICZsdDtmOnZh bHVlQ2hhbmdlTGlzdGVuZXIgYWN0aW9uPSZxdW90Oy4uLiZxdW90OyAvJmd0OyB0aGUgdmFsdWUg b2YgdGhlIG9iamVjdCBwcm92aWRlZCBoYXMgbm90IHlldCBiZWVuIHVwZGF0ZWQgaW4gdGhlIG1v ZGVsLCBoZW5jZSwgdGhlIHZhbHVlIGlzIHRoZSBvbGQgdmFsdWUsIG5vdCB0aGUgbmV3IHZhbHVl LjxCUj4KPEJSPgpXaGVuIHVzaW5nICZsdDtmOmFjdGlvbkxpc3RlbmVyJmd0OyBvbiB0aGUgYnV0 dG9uIHN1Ym1pdHRpbmcgdGhlIHZhbHVlcywgdGhlIG5ldyB2YWx1ZSBpcyBwb3B1bGF0ZWQgaW50 byB0aGUgbW9kZWwgaW5zdGVhZC4uLiB3aGljaCBpcyB0aGUgYmVoYXZpb3IgSSB3b3VsZCBleHBl Y3QuPEJSPgo8QlI+ClBhcmRvbiB0aGUgcHJvYmFibHkgb2J2aW91cyBxdWVzdGlvbi4uLjxCUj4K PEJSPgpJcyB0aGVyZSBhbiBjb250cmFjdCB3aXRoIHZhbHVlQ2hhbmdlTGlzdGVuZXJzIHRoYXQg c3RhdGVzIHRoZXkgZmlyZSBiZWZvcmUgbW9kZWwgdXBkYXRlcz8gSSBzZWUgaW4gdGhlIHNwZWMg dGhhdCBpdCBmaXJlczogJnF1b3Q7d2hlbiBhIG5ldyBsb2NhbCB2YWx1ZSBoYXMgYmVlbiBjcmVh dGVkLCBhbmQgaGFzIHBhc3NlZCBhbGwgdmFsaWRhdGlvbnMsJnF1b3Q7IGJ1dCBub3RoaW5nIGFi b3V0IGlmIHRoZSBtb2RlbCBoYXMgYmVlbiB1cGRhdGVkIG9yIG5vdC48QlI+CjxCUj4KLS1MaW5j b2xuPEJSPgo8QlI+Ck9uIFR1ZSwgMjAwOS0wOS0wOCBhdCAwOTo1OSAtMDcwMCwgUnlhbiBMdWJr ZSB3cm90ZToKPEJMT0NLUVVPVEUgVFlQRT1DSVRFPgo8UFJFPgpPbiA5LzcvMDkgNjowNiBQTSwg QW5keSBTY2h3YXJ0eiB3cm90ZToKJmd0OyBUaGFua3MgTGluY29sbi4gIEkgaGF2ZW4ndCBoYWQg dGltZSB0byBkZWJ1ZyB0aGlzLCBidXQgSSBoYXZlIGEgdGhlb3J5IAomZ3Q7IGFib3V0IHdoYXQg bWlnaHQgYmUgaGFwcGVuaW5nLiAgSW4geW91ciBzYW1wbGU6CiZndDsKJmd0OyZndDsgJmx0O2E6 ZWRpdFRleHQgdmFsdWU9JnF1b3Q7I3tjYy5hdHRycy50YXNrLnRleHR9JnF1b3Q7IAomZ3Q7Jmd0 OyByZW5kZXJlZD0mcXVvdDsjeyFjYy5hdHRycy5kaXNhYmxlZH0mcXVvdDsmZ3Q7CiZndDsmZ3Q7 ICombHQ7ZjphY3Rpb25MaXN0ZW5lciBmb3I9JnF1b3Q7c3VibWl0JnF1b3Q7IAomZ3Q7Jmd0OyBh Y3Rpb249JnF1b3Q7I3t0YXNrQ29udHJvbGxlci5zYXZlVGFza0FqYXgoY2MuYXR0cnMuc3Rvcnks IAomZ3Q7Jmd0OyBjYy5hdHRycy50YXNrKX0mcXVvdDsgLyZndDsgKgomZ3Q7Jmd0OyAmbHQ7L2E6 ZWRpdFRleHQmZ3Q7CiZndDsKJmd0OyBXZSBleHBlY3QgJnF1b3Q7Y2MmcXVvdDsgdG8gcmVzb2x2 ZSB0byB0aGUgY29udGFpbmluZyBjb21wb3NpdGUgY29tcG9uZW50IChpZS4gCiZndDsgdG8gdGhl ICZsdDtzb2NpYWxwbTp0YXNrQmxvY2smZ3Q7IGNvbXBvbmVudCkuICBJIHdvdWxkbid0IGJlIHN1 cnByaXNlZCBpZiAKJmd0OyB3aGF0IGlzIGFjdHVhbGx5IGhhcHBlbmluZyBpcyB0aGF0ICZxdW90 O2NjJnF1b3Q7IGlzICBiZWluZyByZXNvbHZlZCB0byB0aGUgCiZndDsgJmx0O2E6ZWRpdFRleHQm Z3Q7IGNvbXBvc2l0ZSBjb21wb25lbnQgaW5zdGVhZC4KWWVwLCB0aGF0J3Mgd2hhdCBpcyBoYXBw ZW5pbmcuCiZndDsgT25lIHJlYXNvbiB3aHkgSSBzdXNwZWN0IHRoaXMgbWlnaHQgYmUgaGFwcGVu aW5nIGlzIHRoYXQgSSBrbm93IHRoYXQgCiZndDsgUnlhbiBoYXMgaW52ZXN0aWdhdGVkL3Jlc29s dmVkIHNpbWlsYXIgcHJvYmxlbXMgbm90IHRvbyBsb25nIGFnby4KVGhlIHByb2JsZW0gd2UgcmVz b2x2ZWQgd2FzIHRoZSBwYXNzaW5nIG9mICN7Y2MuYXR0cnN9IGF0dHJpYnV0ZXMgCmJldHdlZW4g bmVzdGVkIGNvbXBvc2l0ZSBjb21wb25lbnRzLgpGb3IgdGhpcyBjYXNlLCB0aGUgc3BlYyByZWNv bW1lbmRzIHVzaW5nIGNjLnBhcmVudC5hdHRycy5zdG9yeSBhbmQgCmNjLnBhcmVudC5hdHRycy50 YXNrLCB3aGVyZSBwYXJlbnQgcmVzb2x2ZXMKdG8gdGhlIG5lYXJlc3QgY29tcG9zaXRlIGNvbXBv bmVudCBwYXJlbnQgb2YgdGhlIGN1cnJlbnQgY29tcG9zaXRlIApjb21wb25lbnQuCiZndDsgQW5v dGhlciByZWFzb24gd2h5IEkgYW0gc3VzcGljaW91cyBhYm91dCB0aGlzIGlzIGJlY2F1c2Ugd2Ug aGF2ZSBmYWNlZCAKJmd0OyBzaW1pbGFyIGlzc3VlcyBpbiBvdXIgb3duIChBREYgRmFjZXMpIGRl Y2xhcmF0aXZlIGNvbXBvbmVudCBzb2x1dGlvbi4gIAomZ3Q7IFRoaXMgc3R1ZmYgY2FuIGdldCB0 cmlja3kuIDotKQomZ3Q7CiZndDsgSGV5IFJ5YW4gLQomZ3Q7CiZndDsgRG9lcyB0aGlzIHByb2Js ZW0gbG9vayBmYW1pbGlhcj8gIEFueSB0aG91Z2h0cyBvbiB0aGlzPwomZ3Q7CiZndDsgQW5keQom Z3Q7CiZndDsgTGluY29sbiBCYXh0ZXIsIElJSSB3cm90ZToKJmd0OyZndDsgSGV5IEFuZHksIGhl cmUgeW91IGdvOgomZ3Q7Jmd0OwomZ3Q7Jmd0OyBJbiB0aGUgbWVhbiB0aW1lIEknbSBnb2luZyB0 byBzaWduIHVwIGZvciB0aGUgZGV2IGxpc3RzLgomZ3Q7Jmd0OwomZ3Q7Jmd0OyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCiZndDsmZ3Q7IFVzaW5nOgomZ3Q7Jmd0OyAmbHQ7ZjphY3Rpb25MaXN0ZW5lciBmb3I9JnF1 b3Q7c3VibWl0JnF1b3Q7IAomZ3Q7Jmd0OyBhY3Rpb249JnF1b3Q7KiN7dGFza0NvbnRyb2xsZXIu c2F2ZVRhc2tBamF4KGNjLmF0dHJzLnN0b3J5LCAKJmd0OyZndDsgY2MuYXR0cnMudGFzayl9KiZx dW90OyAvJmd0OwomZ3Q7Jmd0OwomZ3Q7Jmd0OyAgICAgKiN7dGFza0NvbnRyb2xsZXIuc2F2ZVRh c2tBamF4KGNjLmF0dHJzLnN0b3J5LCBjYy5hdHRycy50YXNrKX0qID0KJmd0OyZndDsgICAgIG51 bGwgdmFsdWVzIHBhc3NlZCB0byBtZXRob2QKJmd0OyZndDsgICAgICoje3Rhc2tDb250cm9sbGVy LnNhdmVUYXNrQWpheChjdXJyZW50U3RvcnlCZWFuLnN0b3J5LCB0YXNrKX0qID0KJmd0OyZndDsg ICAgIGNvcnJlY3QgdmFsdWVzIHJlc29sdmVkLCBhc3N1bWluZyBjdXJyZW50U3RvcnlCZWFuLnN0 b3J5IGFuZCB0YXNrCiZndDsmZ3Q7ICAgICBhcmUgYm90aCBpbiB0aGUgRUwvcGFnZSBzY29wZSBz b21ld2hlcmUuCiZndDsmZ3Q7CiZndDsmZ3Q7CiZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KJmd0OyZn dDsgKkNDIEltcGw6KgomZ3Q7Jmd0OwomZ3Q7Jmd0OwomZ3Q7Jmd0OyAmbHQ7IURPQ1RZUEUgaHRt bCBQVUJMSUMgJnF1b3Q7LS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25hbC8vRU4mcXVv dDsKJmd0OyZndDsgICAgICAgICAmcXVvdDs8QSBIUkVGPSJodHRwOi8vd3d3LnczLm9yZy9UUi94 aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9uYWwuZHRkIj5odHRwOi8vd3d3LnczLm9yZy9UUi94 aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9uYWwuZHRkPC9BPiZxdW90OyZndDsKJmd0OyZndDsg Jmx0O2h0bWwgeG1sbnM9JnF1b3Q7PEEgSFJFRj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRt bCI+aHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbDwvQT4mcXVvdDsKJmd0OyZndDsgeG1sbnM6 aD0mcXVvdDs8QSBIUkVGPSJodHRwOi8vamF2YS5zdW4uY29tL2pzZi9odG1sIj5odHRwOi8vamF2 YS5zdW4uY29tL2pzZi9odG1sPC9BPiZxdW90OwomZ3Q7Jmd0OyB4bWxuczpmPSZxdW90OzxBIEhS RUY9Imh0dHA6Ly9qYXZhLnN1bi5jb20vanNmL2NvcmUiPmh0dHA6Ly9qYXZhLnN1bi5jb20vanNm L2NvcmU8L0E+JnF1b3Q7CiZndDsmZ3Q7IHhtbG5zOmE9JnF1b3Q7PEEgSFJFRj0iaHR0cDovL2ph dmEuc3VuLmNvbS9qc2YvY29tcG9zaXRlL2FqYXgiPmh0dHA6Ly9qYXZhLnN1bi5jb20vanNmL2Nv bXBvc2l0ZS9hamF4PC9BPiZxdW90OwomZ3Q7Jmd0OyB4bWxuczpjYz0mcXVvdDs8QSBIUkVGPSJo dHRwOi8vamF2YS5zdW4uY29tL2pzZi9jb21wb3NpdGUiPmh0dHA6Ly9qYXZhLnN1bi5jb20vanNm L2NvbXBvc2l0ZTwvQT4mcXVvdDsmZ3Q7CiZndDsmZ3Q7ICZsdDtjYzppbnRlcmZhY2UmZ3Q7CiZn dDsmZ3Q7ICZsdDtjYzphdHRyaWJ1dGUgbmFtZT0mcXVvdDtzdG9yeSZxdW90OyByZXF1aXJlZD0m cXVvdDt0cnVlJnF1b3Q7IHR5cGU9JnF1b3Q7T2JqZWN0JnF1b3Q7IC8mZ3Q7CiZndDsmZ3Q7ICZs dDtjYzphdHRyaWJ1dGUgbmFtZT0mcXVvdDt0YXNrJnF1b3Q7IHJlcXVpcmVkPSZxdW90O3RydWUm cXVvdDsgdHlwZT0mcXVvdDtPYmplY3QmcXVvdDsgLyZndDsKJmd0OyZndDsgJmx0O2NjOmF0dHJp YnV0ZSBuYW1lPSZxdW90O2Rpc2FibGVkJnF1b3Q7IHJlcXVpcmVkPSZxdW90O2ZhbHNlJnF1b3Q7 IHR5cGU9JnF1b3Q7Qm9vbGVhbiZxdW90OyAKJmd0OyZndDsgZGVmYXVsdD0mcXVvdDtmYWxzZSZx dW90OyAvJmd0OwomZ3Q7Jmd0OyAmbHQ7Y2M6aW5zZXJ0Q2hpbGRyZW4gLyZndDsKJmd0OyZndDsg Jmx0Oy9jYzppbnRlcmZhY2UmZ3Q7CiZndDsmZ3Q7CiZndDsmZ3Q7ICZsdDtjYzppbXBsZW1lbnRh dGlvbiZndDsKJmd0OyZndDsgJmx0O2g6b3V0cHV0U3R5bGVzaGVldCBuYW1lPSZxdW90O3NvY2lh bHBtL3NvY2lhbHBtLmNzcyZxdW90OyAvJmd0OwomZ3Q7Jmd0OyAmbHQ7aDpwYW5lbEdyb3VwIGlk PSZxdW90O3Rhc2tCbG9jayZxdW90OyBsYXlvdXQ9JnF1b3Q7YmxvY2smcXVvdDsgY2xhc3M9JnF1 b3Q7Ym94LWJvcmRlcmVkIHA1IAomZ3Q7Jmd0OyAje2NjLmF0dHJzLnN0eWxlQ2xhc3N9IHRhc2tC bG9ja18je2NjLmF0dHJzLnRhc2suc3RhdHVzfSZxdW90OyAKJmd0OyZndDsgc3R5bGU9JnF1b3Q7 I3tjYy5hdHRycy5zdHlsZX0mcXVvdDsmZ3Q7CiZndDsmZ3Q7CiZndDsmZ3Q7ICZsdDtkaXYgY2xh c3M9JnF1b3Q7bTVsJnF1b3Q7IHN0eWxlPSZxdW90O21hcmdpbi1yaWdodDogMjVweDsmcXVvdDsg Jmd0OwomZ3Q7Jmd0OyAmbHQ7aDpvdXRwdXRUZXh0IHZhbHVlPSZxdW90OyN7Y2MuYXR0cnMudGFz ay50ZXh0fSZxdW90OyAKJmd0OyZndDsgcmVuZGVyZWQ9JnF1b3Q7I3tjYy5hdHRycy5kaXNhYmxl ZH0mcXVvdDsvJmd0OwomZ3Q7Jmd0OyAmbHQ7YTplZGl0VGV4dCB2YWx1ZT0mcXVvdDsje2NjLmF0 dHJzLnRhc2sudGV4dH0mcXVvdDsgCiZndDsmZ3Q7IHJlbmRlcmVkPSZxdW90OyN7IWNjLmF0dHJz LmRpc2FibGVkfSZxdW90OyZndDsKJmd0OyZndDsgKiZsdDtmOmFjdGlvbkxpc3RlbmVyIGZvcj0m cXVvdDtzdWJtaXQmcXVvdDsgCiZndDsmZ3Q7IGFjdGlvbj0mcXVvdDsje3Rhc2tDb250cm9sbGVy LnNhdmVUYXNrQWpheChjYy5hdHRycy5zdG9yeSwgCiZndDsmZ3Q7IGNjLmF0dHJzLnRhc2spfSZx dW90OyAvJmd0OyAqCiZndDsmZ3Q7ICZsdDsvYTplZGl0VGV4dCZndDsKJmd0OyZndDsgJmx0Oy9k aXYmZ3Q7CiZndDsmZ3Q7ICZsdDsvY2M6aW1wbGVtZW50YXRpb24mZ3Q7CiZndDsmZ3Q7ICZsdDsv aHRtbCZndDsKJmd0OyZndDsKJmd0OyZndDsKJmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQomZ3Q7Jmd0 OyAqY29uc3VtaW5nIHBhZ2UgY29kZToqICZsdDstLSB0aGlzIGlzIHdoZXJlIHRhc2sgaXMgZGVm aW5lZCBpbiB0aGUgCiZndDsmZ3Q7IFVJOlJlcGVhdCwgc28gaXQgaXMgaW4gc2NvcGUKJmd0OyZn dDsKJmd0OyZndDsgJmx0OyFET0NUWVBFIGh0bWwKJmd0OyZndDsgICAgICAgUFVCTElDICZxdW90 Oy0vL1czQy8vRFREIFhIVE1MIDEuMCBUcmFuc2l0aW9uYWwvL0VOJnF1b3Q7CiZndDsmZ3Q7ICAg ICAgICZxdW90OzxBIEhSRUY9Imh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwx LXRyYW5zaXRpb25hbC5kdGQiPmh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwx LXRyYW5zaXRpb25hbC5kdGQ8L0E+JnF1b3Q7Jmd0OwomZ3Q7Jmd0OyAmbHQ7aHRtbCB4bWxucz0m cXVvdDs8QSBIUkVGPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIj5odHRwOi8vd3d3Lncz Lm9yZy8xOTk5L3hodG1sPC9BPiZxdW90OwomZ3Q7Jmd0OyB4bWxuczpjPSZxdW90OzxBIEhSRUY9 Imh0dHA6Ly9qYXZhLnN1bi5jb20vanNwL2pzdGwvY29yZSI+aHR0cDovL2phdmEuc3VuLmNvbS9q c3AvanN0bC9jb3JlPC9BPiZxdW90OwomZ3Q7Jmd0OyB4bWxuczpmPSZxdW90OzxBIEhSRUY9Imh0 dHA6Ly9qYXZhLnN1bi5jb20vanNmL2NvcmUiPmh0dHA6Ly9qYXZhLnN1bi5jb20vanNmL2NvcmU8 L0E+JnF1b3Q7CiZndDsmZ3Q7IHhtbG5zOmg9JnF1b3Q7PEEgSFJFRj0iaHR0cDovL2phdmEuc3Vu LmNvbS9qc2YvaHRtbCI+aHR0cDovL2phdmEuc3VuLmNvbS9qc2YvaHRtbDwvQT4mcXVvdDsKJmd0 OyZndDsgeG1sbnM6c29jaWFscG09JnF1b3Q7PEEgSFJFRj0iaHR0cDovL2phdmEuc3VuLmNvbS9q c2YvY29tcG9zaXRlL3NvY2lhbHBtIj5odHRwOi8vamF2YS5zdW4uY29tL2pzZi9jb21wb3NpdGUv c29jaWFscG08L0E+JnF1b3Q7CiZndDsmZ3Q7IHhtbG5zOnByZXR0eT0mcXVvdDs8QSBIUkVGPSJo dHRwOi8vb2Nwc29mdC5jb20vcHJldHR5ZmFjZXMiPmh0dHA6Ly9vY3Bzb2Z0LmNvbS9wcmV0dHlm YWNlczwvQT4mcXVvdDsKJmd0OyZndDsgeG1sbnM6dWk9JnF1b3Q7PEEgSFJFRj0iaHR0cDovL2ph dmEuc3VuLmNvbS9qc2YvZmFjZWxldHMiPmh0dHA6Ly9qYXZhLnN1bi5jb20vanNmL2ZhY2VsZXRz PC9BPiZxdW90OyB4bWw6bGFuZz0mcXVvdDtlbiZxdW90OyBsYW5nPSZxdW90O2VuJnF1b3Q7Jmd0 OwomZ3Q7Jmd0OwomZ3Q7Jmd0OyAmbHQ7dWk6Y29tcG9zaXRpb24mZ3Q7CiZndDsmZ3Q7ICZsdDto OmZvcm0gaWQ9JnF1b3Q7dGFza3NGb3JtJnF1b3Q7Jmd0OwomZ3Q7Jmd0OyAmbHQ7YzppZiB0ZXN0 PSZxdW90OyN7ZW1wdHkgY3VycmVudFN0b3J5QmVhbi5zdG9yeS50YXNrc30mcXVvdDsmZ3Q7CiZn dDsmZ3Q7ICZsdDtkaXYgY2xhc3M9JnF1b3Q7bTUmcXVvdDsmZ3Q7VGhpcyBzdG9yeSBoYXMgbm8g dGFza3MuIFRoYXQgY291bGQgYmUgYSBwcm9ibGVtIAomZ3Q7Jmd0OyBsYXRlci4uLiZsdDsvZGl2 Jmd0OwomZ3Q7Jmd0OyAmbHQ7L2M6aWYmZ3Q7CiZndDsmZ3Q7CiZndDsmZ3Q7ICZsdDt1aTpyZXBl YXQgdmFsdWU9JnF1b3Q7I3tjdXJyZW50U3RvcnlCZWFuLnN0b3J5LnRhc2tzfSZxdW90OyB2YXI9 JnF1b3Q7dGFzayZxdW90OyZndDsKJmd0OyZndDsgJmx0O3NvY2lhbHBtOnRhc2tCbG9jayB0YXNr PSZxdW90OyN7dGFza30mcXVvdDsgc3Rvcnk9JnF1b3Q7I3tjdXJyZW50U3RvcnlCZWFuLnN0b3J5 fSZxdW90OwomZ3Q7Jmd0OyBtZW1iZXJzPSZxdW90OyN7Y3VycmVudFByb2plY3RCZWFuLnByb2pl Y3QuYWN0aXZlTWVtYmVyc30mcXVvdDsKJmd0OyZndDsgZGlzYWJsZWQ9JnF1b3Q7I3shYXV0aG9y aXphdGlvbkJlYW4uaXNNZW1iZXIgb3IgCiZndDsmZ3Q7ICFjdXJyZW50U3RvcnlCZWFuLnN0b3J5 Lm9wZW59JnF1b3Q7CiZndDsmZ3Q7IGRlbGV0YWJsZT0mcXVvdDt0cnVlJnF1b3Q7IHN0eWxlQ2xh c3M9JnF1b3Q7bTV0JnF1b3Q7IHJlZnJlc2hPblNhdmU9JnF1b3Q7ZmFsc2UmcXVvdDsgLyZndDsK Jmd0OyZndDsgJmx0Oy91aTpyZXBlYXQmZ3Q7CiZndDsmZ3Q7ICZsdDsvaDpmb3JtJmd0OwomZ3Q7 Jmd0OyAmbHQ7L3VpOmNvbXBvc2l0aW9uJmd0OwomZ3Q7Jmd0OyAmbHQ7L2h0bWwmZ3Q7CiZndDsm Z3Q7CiZndDsmZ3Q7CiZndDsmZ3Q7CiZndDsmZ3Q7CiZndDsmZ3Q7IE9uIFNhdCwgMjAwOS0wOS0w NSBhdCAxNToyMyAtMDQwMCwgQW5keSBTY2h3YXJ0eiB3cm90ZToKJmd0OyZndDsmZ3Q7IEhleSBM aW5jb2xuIC0KJmd0OyZndDsmZ3Q7CiZndDsmZ3Q7Jmd0OyBMaW5jb2xuIEJheHRlciwgSUlJIHdy b3RlOgomZ3Q7Jmd0OyZndDsgJmd0OyBGaXJzdCwgcGxlYXNlIGxldCBtZSBrbm93IGlmIHRoZXJl IGlzIGEgYmV0dGVyIHBsYWNlIHRvIGFzayBKU0YgCiZndDsmZ3Q7Jmd0OyBEZXYgJmd0OyByZWxh dGVkIHF1ZXN0aW9ucy4KJmd0OyZndDsmZ3Q7ICZndDsKJmd0OyZndDsmZ3Q7CiZndDsmZ3Q7Jmd0 OyBJIHN1cHBvc2UgdGhlIE1vamFycmEgZGV2IGxpc3QgbWlnaHQgYmUgdGhlIHJpZ2h0IHBsYWNl IGZvciAKJmd0OyZndDsmZ3Q7IGltcGxlbWVudGF0aW9uIHF1ZXN0aW9uczoKJmd0OyZndDsmZ3Q7 CiZndDsmZ3Q7Jmd0OyA8QSBIUkVGPSJodHRwczovL2phdmFzZXJ2ZXJmYWNlcy5kZXYuamF2YS5u ZXQvbWFpbGluZ2xpc3RzLmh0bWwiPmh0dHBzOi8vamF2YXNlcnZlcmZhY2VzLmRldi5qYXZhLm5l dC9tYWlsaW5nbGlzdHMuaHRtbDwvQT4KJmd0OyZndDsmZ3Q7CiZndDsmZ3Q7Jmd0OyBUaG91Z2gg cGVyc29uYWxseSBJIGFtIGZpbmUgd2l0aCB5b3UgYXNraW5nIGhlcmUuIDotKQomZ3Q7Jmd0OyZn dDsKJmd0OyZndDsmZ3Q7IENvdWxkIHlvdSBzZW5kIGFsb25nIHlvdXIgY29tcG9zaXRlIGNvbXBv bmVudCBpbXBsZW1lbnRhdGlvbiAoYW5kIAomZ3Q7Jmd0OyZndDsgcGVyaGFwcyBhIHNuaXBwZXQg ZnJvbSB0aGUgY29uc3VtaW5nIHBhZ2UpPyAgSnVzdCB3YW50IHRvIG1ha2Ugc3VyZSAKJmd0OyZn dDsmZ3Q7IEkgdW5kZXJzdGFuZCB0aGUgdXNlIGNhc2UuCiZndDsmZ3Q7Jmd0OwomZ3Q7Jmd0OyZn dDsgQW5keQomZ3Q7Jmd0OyZndDsKJmd0OyZndDsmZ3Q7CiZndDsmZ3Q7IC0tIAomZ3Q7Jmd0OyAq TGluY29sbiBCYXh0ZXIsIElJSSoKJmd0OyZndDsgQ28tRm91bmRlciBvZiBPY3BTb2Z0ICZsdDs8 QSBIUkVGPSJodHRwOi8vb2Nwc29mdC5jb20iPmh0dHA6Ly9vY3Bzb2Z0LmNvbTwvQT4mZ3Q7CiZn dDsmZ3Q7IEF1dGhvciBvZiBQcmV0dHlGYWNlcyAmbHQ7PEEgSFJFRj0iaHR0cDovL29jcHNvZnQu Y29tL3ByZXR0eWZhY2VzIj5odHRwOi8vb2Nwc29mdC5jb20vcHJldHR5ZmFjZXM8L0E+Jmd0OyBV UkwgUmV3cml0aW5nIAomZ3Q7Jmd0OyBmb3IgSlNGCiZndDsmZ3Q7CiZndDsmZ3Q7CiZndDsKCjwv UFJFPgo8L0JMT0NLUVVPVEU+CjxUQUJMRSBDRUxMU1BBQ0lORz0iMCIgQ0VMTFBBRERJTkc9IjAi IFdJRFRIPSIxMDAlIj4KPFRSPgo8VEQ+Ci0tPEJSPgo8Qj5MaW5jb2xuIEJheHRlciwgSUlJPC9C PjxCUj4KQ28tRm91bmRlciBvZiA8QSBIUkVGPSJodHRwOi8vb2Nwc29mdC5jb20iPk9jcFNvZnQ8 L0E+PEJSPgpBdXRob3Igb2YgPEEgSFJFRj0iaHR0cDovL29jcHNvZnQuY29tL3ByZXR0eWZhY2Vz Ij5QcmV0dHlGYWNlczwvQT4gVVJMIFJld3JpdGluZyBmb3IgSlNGPEJSPgo8QlI+CjxCUj4KPC9U RD4KPC9UUj4KPC9UQUJMRT4KPC9CT0RZPgo8L0hUTUw+Cg== --===============6979339960593787462==-- From kito.mann at virtua.com Sun Aug 16 04:45:24 2020 Content-Type: multipart/mixed; boundary="===============5222205429505553179==" MIME-Version: 1.0 From: Kito Mann To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] binding vs. ui:repeat Date: Wed, 09 Sep 2009 12:35:25 -0400 Message-ID: In-Reply-To: 1252470793.22703.41.camel@quadshark --===============5222205429505553179== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Sep 9, 2009 at 12:33 AM, Lincoln Baxter, III < lincolnbaxter(a)gmail.com> wrote: > One more issue I'd like to bring up: it appears that when using > the value of the object provided= has > not yet been updated in the model, hence, the value is the old value, not > the new value. > > When using on the button submitting the values, the new > value is populated into the model instead... which is the behavior I would > expect. > > Pardon the probably obvious question... > > Is there an contract with valueChangeListeners that states they fire befo= re > model updates? I see in the spec that it fires: "when a new local value h= as > been created, and has passed all validations," but nothing about if the > model has been updated or not. > They're fired after the Process Validations phase (or Apply Request Values if immediate=3Dtrue), which always occurs before the Update Model phase. The idea is that the input must be in a valid state before the model is updated. > > --Lincoln > > On Tue, 2009-09-08 at 09:59 -0700, Ryan Lubke wrote: > > On 9/7/09 6:06 PM, Andy Schwartz wrote: > > Thanks Lincoln. I haven't had time to debug this, but I have a theory > > about what might be happening. In your sample: > > > >> >> rendered=3D"#{!cc.attrs.disabled}"> > >> * >> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, > >> cc.attrs.task)}" /> * > >> > > > > We expect "cc" to resolve to the containing composite component (ie. > > to the component). I wouldn't be surprised if > > what is actually happening is that "cc" is being resolved to the > > composite component instead. > Yep, that's what is happening. > > One reason why I suspect this might be happening is that I know that > > Ryan has investigated/resolved similar problems not too long ago. > The problem we resolved was the passing of #{cc.attrs} attributes > between nested composite components. > For this case, the spec recommends using cc.parent.attrs.story and > cc.parent.attrs.task, where parent resolves > to the nearest composite component parent of the current composite > component. > > Another reason why I am suspicious about this is because we have faced > > similar issues in our own (ADF Faces) declarative component solution. > > This stuff can get tricky. :-) > > > > Hey Ryan - > > > > Does this problem look familiar? Any thoughts on this? > > > > Andy > > > > Lincoln Baxter, III wrote: > >> Hey Andy, here you go: > >> > >> In the mean time I'm going to sign up for the dev lists. > >> > >> ---------------------------------------------------------------------- > >> Using: > >> >> action=3D"*#{taskController.saveTaskAjax(cc.attrs.story, > >> cc.attrs.task)}*" /> > >> > >> *#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}* = =3D > >> null values passed to method > >> *#{taskController.saveTaskAjax(currentStoryBean.story, task)}* =3D > >> correct values resolved, assuming currentStoryBean.story and task > >> are both in the EL/page scope somewhere. > >> > >> > >> ---------------------------------------------------------------------- > >> *CC Impl:* > >> > >> > >> >> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > >> >> xmlns:h=3D"http://java.sun.com/jsf/html" > >> xmlns:f=3D"http://java.sun.com/jsf/core" > >> xmlns:a=3D"http://java.sun.com/jsf/composite/ajax" > >> xmlns:cc=3D"http://java.sun.com/jsf/composite"> > >> > >> > >> > >> >> default=3D"false" /> > >> > >> > >> > >> > >> > >> >> #{cc.attrs.styleClass} taskBlock_#{cc.attrs.task.status}" > >> style=3D"#{cc.attrs.style}"> > >> > >>
> >> >> rendered=3D"#{cc.attrs.disabled}"/> > >> >> rendered=3D"#{!cc.attrs.disabled}"> > >> * >> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, > >> cc.attrs.task)}" /> * > >> > >>
> >> > >> > >> > >> > >> ---------------------------------------------------------------------- > >> *consuming page code:* <-- this is where task is defined in the > >> UI:Repeat, so it is in scope > >> > >> >> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" > >> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > >> >> xmlns:c=3D"http://java.sun.com/jsp/jstl/core" > >> xmlns:f=3D"http://java.sun.com/jsf/core" > >> xmlns:h=3D"http://java.sun.com/jsf/html" > >> xmlns:socialpm=3D"http://java.sun.com/jsf/composite/socialpm" > >> xmlns:pretty=3D"http://ocpsoft.com/prettyfaces" > >> xmlns:ui=3D"http://java.sun.com/jsf/facelets" xml:lang=3D"en" lang=3D"= en"> > >> > >> > >> > >> > >>
This story has no tasks. That could be a problem > >> later...
> >> > >> > >> > >> >> members=3D"#{currentProjectBean.project.activeMembers}" > >> disabled=3D"#{!authorizationBean.isMember or > >> !currentStoryBean.story.open}" > >> deletable=3D"true" styleClass=3D"m5t" refreshOnSave=3D"false" /> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Sat, 2009-09-05 at 15:23 -0400, Andy Schwartz wrote: > >>> Hey Lincoln - > >>> > >>> Lincoln Baxter, III wrote: > >>> > First, please let me know if there is a better place to ask JSF > >>> Dev > related questions. > >>> > > >>> > >>> I suppose the Mojarra dev list might be the right place for > >>> implementation questions: > >>> > >>> https://javaserverfaces.dev.java.net/mailinglists.html > >>> > >>> Though personally I am fine with you asking here. :-) > >>> > >>> Could you send along your composite component implementation (and > >>> perhaps a snippet from the consuming page)? Just want to make sure > >>> I understand the use case. > >>> > >>> Andy > >>> > >>> > >> -- > >> *Lincoln Baxter, III* > >> Co-Founder of OcpSoft > >> Author of PrettyFaces URL Rewriting > >> for JSF > >> > >> > > > > > -- > *Lincoln Baxter, III* > Co-Founder of OcpSoft > Author of PrettyFaces URL Rewriting for > JSF > > > --===============5222205429505553179== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBTZXAgOSwgMjAwOSBhdCAx MjozMyBBTSwgTGluY29sbiBCYXh0ZXIsIElJSSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9 Im1haWx0bzpsaW5jb2xuYmF4dGVyQGdtYWlsLmNvbSI+bGluY29sbmJheHRlckBnbWFpbC5jb208 L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46 IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgoKCgogIAogIAoKPGRpdj4K T25lIG1vcmUgaXNzdWUgSSYjMzk7ZCBsaWtlIHRvIGJyaW5nIHVwOiBpdCBhcHBlYXJzIHRoYXQg d2hlbiB1c2luZyAmbHQ7Zjp2YWx1ZUNoYW5nZUxpc3RlbmVyIGFjdGlvbj0mcXVvdDsuLi4mcXVv dDsgLyZndDsgdGhlIHZhbHVlIG9mIHRoZSBvYmplY3QgcHJvdmlkZWQgaGFzIG5vdCB5ZXQgYmVl biB1cGRhdGVkIGluIHRoZSBtb2RlbCwgaGVuY2UsIHRoZSB2YWx1ZSBpcyB0aGUgb2xkIHZhbHVl LCBub3QgdGhlIG5ldyB2YWx1ZS48YnI+Cgo8YnI+CldoZW4gdXNpbmcgJmx0O2Y6YWN0aW9uTGlz dGVuZXImZ3Q7IG9uIHRoZSBidXR0b24gc3VibWl0dGluZyB0aGUgdmFsdWVzLCB0aGUgbmV3IHZh bHVlIGlzIHBvcHVsYXRlZCBpbnRvIHRoZSBtb2RlbCBpbnN0ZWFkLi4uIHdoaWNoIGlzIHRoZSBi ZWhhdmlvciBJIHdvdWxkIGV4cGVjdC48YnI+Cjxicj4KUGFyZG9uIHRoZSBwcm9iYWJseSBvYnZp b3VzIHF1ZXN0aW9uLi4uPGJyPgo8YnI+CklzIHRoZXJlIGFuIGNvbnRyYWN0IHdpdGggdmFsdWVD aGFuZ2VMaXN0ZW5lcnMgdGhhdCBzdGF0ZXMgdGhleSBmaXJlIGJlZm9yZSBtb2RlbCB1cGRhdGVz PyBJIHNlZSBpbiB0aGUgc3BlYyB0aGF0IGl0IGZpcmVzOiAmcXVvdDt3aGVuIGEgbmV3IGxvY2Fs IHZhbHVlIGhhcyBiZWVuIGNyZWF0ZWQsIGFuZCBoYXMgcGFzc2VkIGFsbCB2YWxpZGF0aW9ucywm cXVvdDsgYnV0IG5vdGhpbmcgYWJvdXQgaWYgdGhlIG1vZGVsIGhhcyBiZWVuIHVwZGF0ZWQgb3Ig bm90Ljxicj4KPC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPlRoZXkmIzM5O3JlIGZpcmVkIGFm dGVyIHRoZSBQcm9jZXNzIFZhbGlkYXRpb25zIHBoYXNlIChvciBBcHBseSBSZXF1ZXN0IFZhbHVl cyBpZiBpbW1lZGlhdGU9dHJ1ZSksIHdoaWNoIGFsd2F5cyBvY2N1cnMgYmVmb3JlIHRoZSBVcGRh dGUgTW9kZWwgcGhhc2UuIFRoZSBpZGVhIGlzIHRoYXQgdGhlIGlucHV0IG11c3QgYmUgaW4gYSB2 YWxpZCBzdGF0ZSBiZWZvcmUgdGhlIG1vZGVsIGlzIHVwZGF0ZWQuPGJyPgo8L2Rpdj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij48ZGl2Pjxmb250IGNvbG9yPSIjODg4ODg4Ij4KPGJyPgotLUxpbmNvbG48L2ZvbnQ+ PGRpdiBjbGFzcz0iaW0iPjxicj4KPGJyPgpPbiBUdWUsIDIwMDktMDktMDggYXQgMDk6NTkgLTA3 MDAsIFJ5YW4gTHVia2Ugd3JvdGU6CjwvZGl2PjxkaXY+PGRpdj48L2Rpdj48ZGl2IGNsYXNzPSJo NSI+PGJsb2NrcXVvdGUgdHlwZT0iQ0lURSI+CjxwcmU+T24gOS83LzA5IDY6MDYgUE0sIEFuZHkg U2Nod2FydHogd3JvdGU6CiZndDsgVGhhbmtzIExpbmNvbG4uICBJIGhhdmVuJiMzOTt0IGhhZCB0 aW1lIHRvIGRlYnVnIHRoaXMsIGJ1dCBJIGhhdmUgYSB0aGVvcnkgCiZndDsgYWJvdXQgd2hhdCBt aWdodCBiZSBoYXBwZW5pbmcuICBJbiB5b3VyIHNhbXBsZToKJmd0OwomZ3Q7Jmd0OyAmbHQ7YTpl ZGl0VGV4dCB2YWx1ZT0mcXVvdDsje2NjLmF0dHJzLnRhc2sudGV4dH0mcXVvdDsgCiZndDsmZ3Q7 IHJlbmRlcmVkPSZxdW90OyN7IWNjLmF0dHJzLmRpc2FibGVkfSZxdW90OyZndDsKJmd0OyZndDsg KiZsdDtmOmFjdGlvbkxpc3RlbmVyIGZvcj0mcXVvdDtzdWJtaXQmcXVvdDsgCiZndDsmZ3Q7IGFj dGlvbj0mcXVvdDsje3Rhc2tDb250cm9sbGVyLnNhdmVUYXNrQWpheChjYy5hdHRycy5zdG9yeSwg CiZndDsmZ3Q7IGNjLmF0dHJzLnRhc2spfSZxdW90OyAvJmd0OyAqCiZndDsmZ3Q7ICZsdDsvYTpl ZGl0VGV4dCZndDsKJmd0OwomZ3Q7IFdlIGV4cGVjdCAmcXVvdDtjYyZxdW90OyB0byByZXNvbHZl IHRvIHRoZSBjb250YWluaW5nIGNvbXBvc2l0ZSBjb21wb25lbnQgKGllLiAKJmd0OyB0byB0aGUg Jmx0O3NvY2lhbHBtOnRhc2tCbG9jayZndDsgY29tcG9uZW50KS4gIEkgd291bGRuJiMzOTt0IGJl IHN1cnByaXNlZCBpZiAKJmd0OyB3aGF0IGlzIGFjdHVhbGx5IGhhcHBlbmluZyBpcyB0aGF0ICZx dW90O2NjJnF1b3Q7IGlzICBiZWluZyByZXNvbHZlZCB0byB0aGUgCiZndDsgJmx0O2E6ZWRpdFRl eHQmZ3Q7IGNvbXBvc2l0ZSBjb21wb25lbnQgaW5zdGVhZC4KWWVwLCB0aGF0JiMzOTtzIHdoYXQg aXMgaGFwcGVuaW5nLgomZ3Q7IE9uZSByZWFzb24gd2h5IEkgc3VzcGVjdCB0aGlzIG1pZ2h0IGJl IGhhcHBlbmluZyBpcyB0aGF0IEkga25vdyB0aGF0IAomZ3Q7IFJ5YW4gaGFzIGludmVzdGlnYXRl ZC9yZXNvbHZlZCBzaW1pbGFyIHByb2JsZW1zIG5vdCB0b28gbG9uZyBhZ28uClRoZSBwcm9ibGVt IHdlIHJlc29sdmVkIHdhcyB0aGUgcGFzc2luZyBvZiAje2NjLmF0dHJzfSBhdHRyaWJ1dGVzIApi ZXR3ZWVuIG5lc3RlZCBjb21wb3NpdGUgY29tcG9uZW50cy4KRm9yIHRoaXMgY2FzZSwgdGhlIHNw ZWMgcmVjb21tZW5kcyB1c2luZyBjYy5wYXJlbnQuYXR0cnMuc3RvcnkgYW5kIApjYy5wYXJlbnQu YXR0cnMudGFzaywgd2hlcmUgcGFyZW50IHJlc29sdmVzCnRvIHRoZSBuZWFyZXN0IGNvbXBvc2l0 ZSBjb21wb25lbnQgcGFyZW50IG9mIHRoZSBjdXJyZW50IGNvbXBvc2l0ZSAKY29tcG9uZW50Lgom Z3Q7IEFub3RoZXIgcmVhc29uIHdoeSBJIGFtIHN1c3BpY2lvdXMgYWJvdXQgdGhpcyBpcyBiZWNh dXNlIHdlIGhhdmUgZmFjZWQgCiZndDsgc2ltaWxhciBpc3N1ZXMgaW4gb3VyIG93biAoQURGIEZh Y2VzKSBkZWNsYXJhdGl2ZSBjb21wb25lbnQgc29sdXRpb24uICAKJmd0OyBUaGlzIHN0dWZmIGNh biBnZXQgdHJpY2t5LiA6LSkKJmd0OwomZ3Q7IEhleSBSeWFuIC0KJmd0OwomZ3Q7IERvZXMgdGhp cyBwcm9ibGVtIGxvb2sgZmFtaWxpYXI/ICBBbnkgdGhvdWdodHMgb24gdGhpcz8KJmd0OwomZ3Q7 IEFuZHkKJmd0OwomZ3Q7IExpbmNvbG4gQmF4dGVyLCBJSUkgd3JvdGU6CiZndDsmZ3Q7IEhleSBB bmR5LCBoZXJlIHlvdSBnbzoKJmd0OyZndDsKJmd0OyZndDsgSW4gdGhlIG1lYW4gdGltZSBJJiMz OTttIGdvaW5nIHRvIHNpZ24gdXAgZm9yIHRoZSBkZXYgbGlzdHMuCiZndDsmZ3Q7CiZndDsmZ3Q7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KJmd0OyZndDsgVXNpbmc6CiZndDsmZ3Q7ICZsdDtmOmFjdGlvbkxpc3Rl bmVyIGZvcj0mcXVvdDtzdWJtaXQmcXVvdDsgCiZndDsmZ3Q7IGFjdGlvbj0mcXVvdDsqI3t0YXNr Q29udHJvbGxlci5zYXZlVGFza0FqYXgoY2MuYXR0cnMuc3RvcnksIAomZ3Q7Jmd0OyBjYy5hdHRy cy50YXNrKX0qJnF1b3Q7IC8mZ3Q7CiZndDsmZ3Q7CiZndDsmZ3Q7ICAgICAqI3t0YXNrQ29udHJv bGxlci5zYXZlVGFza0FqYXgoY2MuYXR0cnMuc3RvcnksIGNjLmF0dHJzLnRhc2spfSogPQomZ3Q7 Jmd0OyAgICAgbnVsbCB2YWx1ZXMgcGFzc2VkIHRvIG1ldGhvZAomZ3Q7Jmd0OyAgICAgKiN7dGFz a0NvbnRyb2xsZXIuc2F2ZVRhc2tBamF4KGN1cnJlbnRTdG9yeUJlYW4uc3RvcnksIHRhc2spfSog PQomZ3Q7Jmd0OyAgICAgY29ycmVjdCB2YWx1ZXMgcmVzb2x2ZWQsIGFzc3VtaW5nIGN1cnJlbnRT dG9yeUJlYW4uc3RvcnkgYW5kIHRhc2sKJmd0OyZndDsgICAgIGFyZSBib3RoIGluIHRoZSBFTC9w YWdlIHNjb3BlIHNvbWV3aGVyZS4KJmd0OyZndDsKJmd0OyZndDsKJmd0OyZndDsgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQomZ3Q7Jmd0OyAqQ0MgSW1wbDoqCiZndDsmZ3Q7CiZndDsmZ3Q7CiZndDsmZ3Q7ICZsdDsh RE9DVFlQRSBodG1sIFBVQkxJQyAmcXVvdDstLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlv bmFsLy9FTiZxdW90OwomZ3Q7Jmd0OyAgICAgICAgICZxdW90OzxhIGhyZWY9Imh0dHA6Ly93d3cu dzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25hbC5kdGQiIHRhcmdldD0iX2Js YW5rIj5odHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9uYWwu ZHRkPC9hPiZxdW90OyZndDsKJmd0OyZndDsgJmx0O2h0bWwgeG1sbnM9JnF1b3Q7PGEgaHJlZj0i aHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cu dzMub3JnLzE5OTkveGh0bWw8L2E+JnF1b3Q7CiZndDsmZ3Q7IHhtbG5zOmg9JnF1b3Q7PGEgaHJl Zj0iaHR0cDovL2phdmEuc3VuLmNvbS9qc2YvaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9q YXZhLnN1bi5jb20vanNmL2h0bWw8L2E+JnF1b3Q7CiZndDsmZ3Q7IHhtbG5zOmY9JnF1b3Q7PGEg aHJlZj0iaHR0cDovL2phdmEuc3VuLmNvbS9qc2YvY29yZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly9qYXZhLnN1bi5jb20vanNmL2NvcmU8L2E+JnF1b3Q7CiZndDsmZ3Q7IHhtbG5zOmE9JnF1b3Q7 PGEgaHJlZj0iaHR0cDovL2phdmEuc3VuLmNvbS9qc2YvY29tcG9zaXRlL2FqYXgiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vamF2YS5zdW4uY29tL2pzZi9jb21wb3NpdGUvYWpheDwvYT4mcXVvdDsK Jmd0OyZndDsgeG1sbnM6Y2M9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2phdmEuc3VuLmNvbS9qc2Yv Y29tcG9zaXRlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2phdmEuc3VuLmNvbS9qc2YvY29tcG9z aXRlPC9hPiZxdW90OyZndDsKJmd0OyZndDsgJmx0O2NjOmludGVyZmFjZSZndDsKJmd0OyZndDsg Jmx0O2NjOmF0dHJpYnV0ZSBuYW1lPSZxdW90O3N0b3J5JnF1b3Q7IHJlcXVpcmVkPSZxdW90O3Ry dWUmcXVvdDsgdHlwZT0mcXVvdDtPYmplY3QmcXVvdDsgLyZndDsKJmd0OyZndDsgJmx0O2NjOmF0 dHJpYnV0ZSBuYW1lPSZxdW90O3Rhc2smcXVvdDsgcmVxdWlyZWQ9JnF1b3Q7dHJ1ZSZxdW90OyB0 eXBlPSZxdW90O09iamVjdCZxdW90OyAvJmd0OwomZ3Q7Jmd0OyAmbHQ7Y2M6YXR0cmlidXRlIG5h bWU9JnF1b3Q7ZGlzYWJsZWQmcXVvdDsgcmVxdWlyZWQ9JnF1b3Q7ZmFsc2UmcXVvdDsgdHlwZT0m cXVvdDtCb29sZWFuJnF1b3Q7IAomZ3Q7Jmd0OyBkZWZhdWx0PSZxdW90O2ZhbHNlJnF1b3Q7IC8m Z3Q7CiZndDsmZ3Q7ICZsdDtjYzppbnNlcnRDaGlsZHJlbiAvJmd0OwomZ3Q7Jmd0OyAmbHQ7L2Nj OmludGVyZmFjZSZndDsKJmd0OyZndDsKJmd0OyZndDsgJmx0O2NjOmltcGxlbWVudGF0aW9uJmd0 OwomZ3Q7Jmd0OyAmbHQ7aDpvdXRwdXRTdHlsZXNoZWV0IG5hbWU9JnF1b3Q7c29jaWFscG0vc29j aWFscG0uY3NzJnF1b3Q7IC8mZ3Q7CiZndDsmZ3Q7ICZsdDtoOnBhbmVsR3JvdXAgaWQ9JnF1b3Q7 dGFza0Jsb2NrJnF1b3Q7IGxheW91dD0mcXVvdDtibG9jayZxdW90OyBjbGFzcz0mcXVvdDtib3gt Ym9yZGVyZWQgcDUgCiZndDsmZ3Q7ICN7Y2MuYXR0cnMuc3R5bGVDbGFzc30gdGFza0Jsb2NrXyN7 Y2MuYXR0cnMudGFzay5zdGF0dXN9JnF1b3Q7IAomZ3Q7Jmd0OyBzdHlsZT0mcXVvdDsje2NjLmF0 dHJzLnN0eWxlfSZxdW90OyZndDsKJmd0OyZndDsKJmd0OyZndDsgJmx0O2RpdiBjbGFzcz0mcXVv dDttNWwmcXVvdDsgc3R5bGU9JnF1b3Q7bWFyZ2luLXJpZ2h0OiAyNXB4OyZxdW90OyAmZ3Q7CiZn dDsmZ3Q7ICZsdDtoOm91dHB1dFRleHQgdmFsdWU9JnF1b3Q7I3tjYy5hdHRycy50YXNrLnRleHR9 JnF1b3Q7IAomZ3Q7Jmd0OyByZW5kZXJlZD0mcXVvdDsje2NjLmF0dHJzLmRpc2FibGVkfSZxdW90 Oy8mZ3Q7CiZndDsmZ3Q7ICZsdDthOmVkaXRUZXh0IHZhbHVlPSZxdW90OyN7Y2MuYXR0cnMudGFz ay50ZXh0fSZxdW90OyAKJmd0OyZndDsgcmVuZGVyZWQ9JnF1b3Q7I3shY2MuYXR0cnMuZGlzYWJs ZWR9JnF1b3Q7Jmd0OwomZ3Q7Jmd0OyAqJmx0O2Y6YWN0aW9uTGlzdGVuZXIgZm9yPSZxdW90O3N1 Ym1pdCZxdW90OyAKJmd0OyZndDsgYWN0aW9uPSZxdW90OyN7dGFza0NvbnRyb2xsZXIuc2F2ZVRh c2tBamF4KGNjLmF0dHJzLnN0b3J5LCAKJmd0OyZndDsgY2MuYXR0cnMudGFzayl9JnF1b3Q7IC8m Z3Q7ICoKJmd0OyZndDsgJmx0Oy9hOmVkaXRUZXh0Jmd0OwomZ3Q7Jmd0OyAmbHQ7L2RpdiZndDsK Jmd0OyZndDsgJmx0Oy9jYzppbXBsZW1lbnRhdGlvbiZndDsKJmd0OyZndDsgJmx0Oy9odG1sJmd0 OwomZ3Q7Jmd0OwomZ3Q7Jmd0OwomZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiZndDsmZ3Q7ICpjb25z dW1pbmcgcGFnZSBjb2RlOiogJmx0Oy0tIHRoaXMgaXMgd2hlcmUgdGFzayBpcyBkZWZpbmVkIGlu IHRoZSAKJmd0OyZndDsgVUk6UmVwZWF0LCBzbyBpdCBpcyBpbiBzY29wZQomZ3Q7Jmd0OwomZ3Q7 Jmd0OyAmbHQ7IURPQ1RZUEUgaHRtbAomZ3Q7Jmd0OyAgICAgICBQVUJMSUMgJnF1b3Q7LS8vVzND Ly9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25hbC8vRU4mcXVvdDsKJmd0OyZndDsgICAgICAgJnF1 b3Q7PGEgaHJlZj0iaHR0cDovL3d3dy53My5vcmcvVFIveGh0bWwxL0RURC94aHRtbDEtdHJhbnNp dGlvbmFsLmR0ZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9E VEQveGh0bWwxLXRyYW5zaXRpb25hbC5kdGQ8L2E+JnF1b3Q7Jmd0OwomZ3Q7Jmd0OyAmbHQ7aHRt bCB4bWxucz0mcXVvdDs8YSBocmVmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbDwvYT4mcXVvdDsKJmd0OyZn dDsgeG1sbnM6Yz0mcXVvdDs8YSBocmVmPSJodHRwOi8vamF2YS5zdW4uY29tL2pzcC9qc3RsL2Nv cmUiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vamF2YS5zdW4uY29tL2pzcC9qc3RsL2NvcmU8L2E+ JnF1b3Q7CiZndDsmZ3Q7IHhtbG5zOmY9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2phdmEuc3VuLmNv bS9qc2YvY29yZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9qYXZhLnN1bi5jb20vanNmL2NvcmU8 L2E+JnF1b3Q7CiZndDsmZ3Q7IHhtbG5zOmg9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2phdmEuc3Vu LmNvbS9qc2YvaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9qYXZhLnN1bi5jb20vanNmL2h0 bWw8L2E+JnF1b3Q7CiZndDsmZ3Q7IHhtbG5zOnNvY2lhbHBtPSZxdW90OzxhIGhyZWY9Imh0dHA6 Ly9qYXZhLnN1bi5jb20vanNmL2NvbXBvc2l0ZS9zb2NpYWxwbSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly9qYXZhLnN1bi5jb20vanNmL2NvbXBvc2l0ZS9zb2NpYWxwbTwvYT4mcXVvdDsKJmd0OyZn dDsgeG1sbnM6cHJldHR5PSZxdW90OzxhIGhyZWY9Imh0dHA6Ly9vY3Bzb2Z0LmNvbS9wcmV0dHlm YWNlcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9vY3Bzb2Z0LmNvbS9wcmV0dHlmYWNlczwvYT4m cXVvdDsKJmd0OyZndDsgeG1sbnM6dWk9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2phdmEuc3VuLmNv bS9qc2YvZmFjZWxldHMiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vamF2YS5zdW4uY29tL2pzZi9m YWNlbGV0czwvYT4mcXVvdDsgeG1sOmxhbmc9JnF1b3Q7ZW4mcXVvdDsgbGFuZz0mcXVvdDtlbiZx dW90OyZndDsKJmd0OyZndDsKJmd0OyZndDsgJmx0O3VpOmNvbXBvc2l0aW9uJmd0OwomZ3Q7Jmd0 OyAmbHQ7aDpmb3JtIGlkPSZxdW90O3Rhc2tzRm9ybSZxdW90OyZndDsKJmd0OyZndDsgJmx0O2M6 aWYgdGVzdD0mcXVvdDsje2VtcHR5IGN1cnJlbnRTdG9yeUJlYW4uc3RvcnkudGFza3N9JnF1b3Q7 Jmd0OwomZ3Q7Jmd0OyAmbHQ7ZGl2IGNsYXNzPSZxdW90O201JnF1b3Q7Jmd0O1RoaXMgc3Rvcnkg aGFzIG5vIHRhc2tzLiBUaGF0IGNvdWxkIGJlIGEgcHJvYmxlbSAKJmd0OyZndDsgbGF0ZXIuLi4m bHQ7L2RpdiZndDsKJmd0OyZndDsgJmx0Oy9jOmlmJmd0OwomZ3Q7Jmd0OwomZ3Q7Jmd0OyAmbHQ7 dWk6cmVwZWF0IHZhbHVlPSZxdW90OyN7Y3VycmVudFN0b3J5QmVhbi5zdG9yeS50YXNrc30mcXVv dDsgdmFyPSZxdW90O3Rhc2smcXVvdDsmZ3Q7CiZndDsmZ3Q7ICZsdDtzb2NpYWxwbTp0YXNrQmxv Y2sgdGFzaz0mcXVvdDsje3Rhc2t9JnF1b3Q7IHN0b3J5PSZxdW90OyN7Y3VycmVudFN0b3J5QmVh bi5zdG9yeX0mcXVvdDsKJmd0OyZndDsgbWVtYmVycz0mcXVvdDsje2N1cnJlbnRQcm9qZWN0QmVh bi5wcm9qZWN0LmFjdGl2ZU1lbWJlcnN9JnF1b3Q7CiZndDsmZ3Q7IGRpc2FibGVkPSZxdW90OyN7 IWF1dGhvcml6YXRpb25CZWFuLmlzTWVtYmVyIG9yIAomZ3Q7Jmd0OyAhY3VycmVudFN0b3J5QmVh bi5zdG9yeS5vcGVufSZxdW90OwomZ3Q7Jmd0OyBkZWxldGFibGU9JnF1b3Q7dHJ1ZSZxdW90OyBz dHlsZUNsYXNzPSZxdW90O201dCZxdW90OyByZWZyZXNoT25TYXZlPSZxdW90O2ZhbHNlJnF1b3Q7 IC8mZ3Q7CiZndDsmZ3Q7ICZsdDsvdWk6cmVwZWF0Jmd0OwomZ3Q7Jmd0OyAmbHQ7L2g6Zm9ybSZn dDsKJmd0OyZndDsgJmx0Oy91aTpjb21wb3NpdGlvbiZndDsKJmd0OyZndDsgJmx0Oy9odG1sJmd0 OwomZ3Q7Jmd0OwomZ3Q7Jmd0OwomZ3Q7Jmd0OwomZ3Q7Jmd0OwomZ3Q7Jmd0OyBPbiBTYXQsIDIw MDktMDktMDUgYXQgMTU6MjMgLTA0MDAsIEFuZHkgU2Nod2FydHogd3JvdGU6CiZndDsmZ3Q7Jmd0 OyBIZXkgTGluY29sbiAtCiZndDsmZ3Q7Jmd0OwomZ3Q7Jmd0OyZndDsgTGluY29sbiBCYXh0ZXIs IElJSSB3cm90ZToKJmd0OyZndDsmZ3Q7ICZndDsgRmlyc3QsIHBsZWFzZSBsZXQgbWUga25vdyBp ZiB0aGVyZSBpcyBhIGJldHRlciBwbGFjZSB0byBhc2sgSlNGIAomZ3Q7Jmd0OyZndDsgRGV2ICZn dDsgcmVsYXRlZCBxdWVzdGlvbnMuCiZndDsmZ3Q7Jmd0OyAmZ3Q7CiZndDsmZ3Q7Jmd0OwomZ3Q7 Jmd0OyZndDsgSSBzdXBwb3NlIHRoZSBNb2phcnJhIGRldiBsaXN0IG1pZ2h0IGJlIHRoZSByaWdo dCBwbGFjZSBmb3IgCiZndDsmZ3Q7Jmd0OyBpbXBsZW1lbnRhdGlvbiBxdWVzdGlvbnM6CiZndDsm Z3Q7Jmd0OwomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9qYXZhc2VydmVyZmFjZXMuZGV2 LmphdmEubmV0L21haWxpbmdsaXN0cy5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9qYXZh c2VydmVyZmFjZXMuZGV2LmphdmEubmV0L21haWxpbmdsaXN0cy5odG1sPC9hPgomZ3Q7Jmd0OyZn dDsKJmd0OyZndDsmZ3Q7IFRob3VnaCBwZXJzb25hbGx5IEkgYW0gZmluZSB3aXRoIHlvdSBhc2tp bmcgaGVyZS4gOi0pCiZndDsmZ3Q7Jmd0OwomZ3Q7Jmd0OyZndDsgQ291bGQgeW91IHNlbmQgYWxv bmcgeW91ciBjb21wb3NpdGUgY29tcG9uZW50IGltcGxlbWVudGF0aW9uIChhbmQgCiZndDsmZ3Q7 Jmd0OyBwZXJoYXBzIGEgc25pcHBldCBmcm9tIHRoZSBjb25zdW1pbmcgcGFnZSk/ICBKdXN0IHdh bnQgdG8gbWFrZSBzdXJlIAomZ3Q7Jmd0OyZndDsgSSB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZS4K Jmd0OyZndDsmZ3Q7CiZndDsmZ3Q7Jmd0OyBBbmR5CiZndDsmZ3Q7Jmd0OwomZ3Q7Jmd0OyZndDsK Jmd0OyZndDsgLS0gCiZndDsmZ3Q7ICpMaW5jb2xuIEJheHRlciwgSUlJKgomZ3Q7Jmd0OyBDby1G b3VuZGVyIG9mIE9jcFNvZnQgJmx0OzxhIGhyZWY9Imh0dHA6Ly9vY3Bzb2Z0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly9vY3Bzb2Z0LmNvbTwvYT4mZ3Q7CiZndDsmZ3Q7IEF1dGhvciBvZiBQ cmV0dHlGYWNlcyAmbHQ7PGEgaHJlZj0iaHR0cDovL29jcHNvZnQuY29tL3ByZXR0eWZhY2VzIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL29jcHNvZnQuY29tL3ByZXR0eWZhY2VzPC9hPiZndDsgVVJM IFJld3JpdGluZyAKJmd0OyZndDsgZm9yIEpTRgomZ3Q7Jmd0OwomZ3Q7Jmd0OwomZ3Q7Cgo8L3By ZT4KPC9ibG9ja3F1b3RlPgo8L2Rpdj48L2Rpdj48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIwIiB3aWR0aD0iMTAwJSI+Cjx0Ym9keT48dHI+Cjx0ZD4KLS08ZGl2IGNsYXNzPSJp bSI+PGJyPgo8Yj5MaW5jb2xuIEJheHRlciwgSUlJPC9iPjxicj4KQ28tRm91bmRlciBvZiA8YSBo cmVmPSJodHRwOi8vb2Nwc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5PY3BTb2Z0PC9hPjxicj48 L2Rpdj48ZGl2IGNsYXNzPSJpbSI+CkF1dGhvciBvZiA8YSBocmVmPSJodHRwOi8vb2Nwc29mdC5j b20vcHJldHR5ZmFjZXMiIHRhcmdldD0iX2JsYW5rIj5QcmV0dHlGYWNlczwvYT4gVVJMIFJld3Jp dGluZyBmb3IgSlNGPGJyPgo8YnI+Cjxicj4KPC9kaXY+PC90ZD4KPC90cj4KPC90Ym9keT48L3Rh YmxlPgo8L2Rpdj4KCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+Cg== --===============5222205429505553179==-- From dan.j.allen at gmail.com Sun Aug 16 04:45:24 2020 Content-Type: multipart/mixed; boundary="===============1137823369939433702==" MIME-Version: 1.0 From: Dan Allen To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] binding vs. ui:repeat Date: Wed, 09 Sep 2009 13:04:25 -0400 Message-ID: <19758da0909091004j5935c87t7aed281e2677f15d@mail.gmail.com> In-Reply-To: c5b496b0909090935m7ca9d04bl8372a909f22a0f79@mail.gmail.com --===============1137823369939433702== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Sep 9, 2009 at 12:35 PM, Kito Mann wrote: > > > On Wed, Sep 9, 2009 at 12:33 AM, Lincoln Baxter, III < > lincolnbaxter(a)gmail.com> wrote: > >> One more issue I'd like to bring up: it appears that when using >> the value of the object provide= d has >> not yet been updated in the model, hence, the value is the old value, not >> the new value. >> >> When using on the button submitting the values, the n= ew >> value is populated into the model instead... which is the behavior I wou= ld >> expect. >> >> Pardon the probably obvious question... >> >> Is there an contract with valueChangeListeners that states they fire >> before model updates? I see in the spec that it fires: "when a new local >> value has been created, and has passed all validations," but nothing abo= ut >> if the model has been updated or not. >> > > They're fired after the Process Validations phase (or Apply Request Values > if immediate=3Dtrue), which always occurs before the Update Model phase. = The > idea is that the input must be in a valid state before the model is updat= ed. > And that the value change listener is notified of the intent to change the model value, hence giving it a chance to block the update (or at least that becomes a possible course of action). -Dan -- = Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan --===============1137823369939433702== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgU2VwIDksIDIwMDkgYXQgMTI6MzUgUE0s IEtpdG8gTWFubiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpraXRvLm1hbm5A dmlydHVhLmNvbSI+a2l0by5tYW5uQHZpcnR1YS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJy PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHgg c29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRk aW5nLWxlZnQ6IDFleDsiPgo8YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGNs YXNzPSJpbSI+T24gV2VkLCBTZXAgOSwgMjAwOSBhdCAxMjozMyBBTSwgTGluY29sbiBCYXh0ZXIs IElJSSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpsaW5jb2xuYmF4dGVyQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxpbmNvbG5iYXh0ZXJAZ21haWwuY29tPC9hPiZndDs8 L3NwYW4+IHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i Ym9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBw dCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+CgoKCiAgCiAgCgo8ZGl2PgpPbmUgbW9y ZSBpc3N1ZSBJJiMzOTtkIGxpa2UgdG8gYnJpbmcgdXA6IGl0IGFwcGVhcnMgdGhhdCB3aGVuIHVz aW5nICZsdDtmOnZhbHVlQ2hhbmdlTGlzdGVuZXIgYWN0aW9uPSZxdW90Oy4uLiZxdW90OyAvJmd0 OyB0aGUgdmFsdWUgb2YgdGhlIG9iamVjdCBwcm92aWRlZCBoYXMgbm90IHlldCBiZWVuIHVwZGF0 ZWQgaW4gdGhlIG1vZGVsLCBoZW5jZSwgdGhlIHZhbHVlIGlzIHRoZSBvbGQgdmFsdWUsIG5vdCB0 aGUgbmV3IHZhbHVlLjxicj4KCgo8YnI+CldoZW4gdXNpbmcgJmx0O2Y6YWN0aW9uTGlzdGVuZXIm Z3Q7IG9uIHRoZSBidXR0b24gc3VibWl0dGluZyB0aGUgdmFsdWVzLCB0aGUgbmV3IHZhbHVlIGlz IHBvcHVsYXRlZCBpbnRvIHRoZSBtb2RlbCBpbnN0ZWFkLi4uIHdoaWNoIGlzIHRoZSBiZWhhdmlv ciBJIHdvdWxkIGV4cGVjdC48YnI+Cjxicj4KUGFyZG9uIHRoZSBwcm9iYWJseSBvYnZpb3VzIHF1 ZXN0aW9uLi4uPGJyPgo8YnI+CklzIHRoZXJlIGFuIGNvbnRyYWN0IHdpdGggdmFsdWVDaGFuZ2VM aXN0ZW5lcnMgdGhhdCBzdGF0ZXMgdGhleSBmaXJlIGJlZm9yZSBtb2RlbCB1cGRhdGVzPyBJIHNl ZSBpbiB0aGUgc3BlYyB0aGF0IGl0IGZpcmVzOiAmcXVvdDt3aGVuIGEgbmV3IGxvY2FsIHZhbHVl IGhhcyBiZWVuIGNyZWF0ZWQsIGFuZCBoYXMgcGFzc2VkIGFsbCB2YWxpZGF0aW9ucywmcXVvdDsg YnV0IG5vdGhpbmcgYWJvdXQgaWYgdGhlIG1vZGVsIGhhcyBiZWVuIHVwZGF0ZWQgb3Igbm90Ljxi cj4KCjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48ZGl2Pjxicj5UaGV5JiMzOTtyZSBmaXJlZCBh ZnRlciB0aGUgUHJvY2VzcyBWYWxpZGF0aW9ucyBwaGFzZSAob3IgQXBwbHkgUmVxdWVzdCBWYWx1 ZXMgaWYgaW1tZWRpYXRlPXRydWUpLCB3aGljaCBhbHdheXMgb2NjdXJzIGJlZm9yZSB0aGUgVXBk YXRlIE1vZGVsIHBoYXNlLiBUaGUgaWRlYSBpcyB0aGF0IHRoZSBpbnB1dCBtdXN0IGJlIGluIGEg dmFsaWQgc3RhdGUgYmVmb3JlIHRoZSBtb2RlbCBpcyB1cGRhdGVkLjxicj4KPC9kaXY+PC9kaXY+ PC9ibG9ja3F1b3RlPjxkaXY+PGJyPkFuZCB0aGF0IHRoZSB2YWx1ZSBjaGFuZ2UgbGlzdGVuZXIg aXMgbm90aWZpZWQgb2YgdGhlIGludGVudCB0byBjaGFuZ2UgdGhlIG1vZGVsIHZhbHVlLCBoZW5j ZSBnaXZpbmcgaXQgYSBjaGFuY2UgdG8gYmxvY2sgdGhlIHVwZGF0ZSAob3IgYXQgbGVhc3QgdGhh dCBiZWNvbWVzIGEgcG9zc2libGUgY291cnNlIG9mIGFjdGlvbikuPGJyPgo8YnI+LURhbjwvZGl2 PjwvZGl2Pjxicj4tLSA8YnI+RGFuIEFsbGVuPGJyPlNlbmlvciBTb2Z0d2FyZSBFbmdpbmVlciwg UmVkIEhhdCB8IEF1dGhvciBvZiBTZWFtIGluIEFjdGlvbjxicj5SZWdpc3RlcmVkIExpbnV4IFVz ZXIgIzIzMTU5Nzxicj48YnI+PGEgaHJlZj0iaHR0cDovL21vamF2ZWxpbnV4LmNvbSI+aHR0cDov L21vamF2ZWxpbnV4LmNvbTwvYT48YnI+PGEgaHJlZj0iaHR0cDovL21vamF2ZWxpbnV4LmNvbS9z ZWFtaW5hY3Rpb24iPmh0dHA6Ly9tb2phdmVsaW51eC5jb20vc2VhbWluYWN0aW9uPC9hPjxicj4K PGEgaHJlZj0iaHR0cDovL2luLnJlbGF0aW9uLnRvL0Jsb2dnZXJzL0RhbiI+aHR0cDovL2luLnJl bGF0aW9uLnRvL0Jsb2dnZXJzL0RhbjwvYT48YnI+Cg== --===============1137823369939433702==-- From lincolnbaxter at gmail.com Sun Aug 16 04:45:24 2020 Content-Type: multipart/mixed; boundary="===============4196359828523359999==" MIME-Version: 1.0 From: lincolnbaxter at gmail.com To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] binding vs. ui:repeat Date: Wed, 09 Sep 2009 17:09:19 +0000 Message-ID: <1479683294-1252516134-cardhu_decombobulator_blackberry.rim.net-1412137097-@bda160.bisx.prod.on.blackberry> In-Reply-To: 19758da0909091004j5935c87t7aed281e2677f15d@mail.gmail.com --===============4196359828523359999== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Makes sense, perhaps some additional verbiage to that point would be apropo= s. Ill add a tracker for a pdl doc enhancement. Thanks. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Dan Allen Date: Wed, 9 Sep 2009 13:04:25 = To: Cc: Subject: Re: [jsr-314-open] binding vs. ui:repeat On Wed, Sep 9, 2009 at 12:35 PM, Kito Mann wrote: > > > On Wed, Sep 9, 2009 at 12:33 AM, Lincoln Baxter, III < > lincolnbaxter(a)gmail.com> wrote: > >> One more issue I'd like to bring up: it appears that when using >> the value of the object provide= d has >> not yet been updated in the model, hence, the value is the old value, not >> the new value. >> >> When using on the button submitting the values, the n= ew >> value is populated into the model instead... which is the behavior I wou= ld >> expect. >> >> Pardon the probably obvious question... >> >> Is there an contract with valueChangeListeners that states they fire >> before model updates? I see in the spec that it fires: "when a new local >> value has been created, and has passed all validations," but nothing abo= ut >> if the model has been updated or not. >> > > They're fired after the Process Validations phase (or Apply Request Values > if immediate=3Dtrue), which always occurs before the Update Model phase. = The > idea is that the input must be in a valid state before the model is updat= ed. > And that the value change listener is notified of the intent to change the model value, hence giving it a chance to block the update (or at least that becomes a possible course of action). -Dan -- = Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan --===============4196359828523359999== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4gPEhUTUw+PEhFQUQ+IDxNRVRBIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4gPC9IRUFEPk1ha2VzIHNlbnNlLCBwZXJoYXBz IHNvbWUgYWRkaXRpb25hbCB2ZXJiaWFnZSB0byB0aGF0IHBvaW50IHdvdWxkIGJlIGFwcm9wb3Mu IElsbCBhZGQgYSB0cmFja2VyIGZvciBhIHBkbCBkb2MgZW5oYW5jZW1lbnQuPGJyLz48YnIvPjxi ci8+VGhhbmtzLjxici8+PGJyLz48cD5TZW50IGZyb20gbXkgVmVyaXpvbiBXaXJlbGVzcyBCbGFj a0JlcnJ5PC9wPjxwPjxociBzaXplPTIgd2lkdGg9MTAwJSBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9 LTE+PGI+RnJvbTwvYj46ICBEYW4gQWxsZW4gPGRhbi5qLmFsbGVuQGdtYWlsLmNvbT48YnI+PGI+ RGF0ZTwvYj46IFdlZCwgOSBTZXAgMjAwOSAxMzowNDoyNSAtMDQwMDxicj48Yj5UbzwvYj46ICZs dDtqc3ItMzE0LW9wZW5AamNwLm9yZyZndDs8YnI+PGI+U3ViamVjdDwvYj46IFJlOiBbanNyLTMx NC1vcGVuXSAmbHQ7aDpkYXRhVGFibGUmZ3Q7IGJpbmRpbmcgdnMuIHVpOnJlcGVhdDxicj48L2Zv bnQ+PC9wPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIFNlcCA5LCAyMDA5IGF0IDEy OjM1IFBNLCBLaXRvIE1hbm4gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86a2l0 by5tYW5uQHZpcnR1YS5jb20iPmtpdG8ubWFubkB2aXJ0dWEuY29tPC9hPiZndDs8L3NwYW4+IHdy b3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVm dDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhl eDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48 ZGl2IGNsYXNzPSJpbSI+T24gV2VkLCBTZXAgOSwgMjAwOSBhdCAxMjozMyBBTSwgTGluY29sbiBC YXh0ZXIsIElJSSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpsaW5jb2xuYmF4 dGVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxpbmNvbG5iYXh0ZXJAZ21haWwuY29tPC9h PiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAw cHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4gICAgICAgICAgPGRpdj4gT25l IG1vcmUgaXNzdWUgSSYjMzk7ZCBsaWtlIHRvIGJyaW5nIHVwOiBpdCBhcHBlYXJzIHRoYXQgd2hl biB1c2luZyAmbHQ7Zjp2YWx1ZUNoYW5nZUxpc3RlbmVyIGFjdGlvbj0mcXVvdDsuLi4mcXVvdDsg LyZndDsgdGhlIHZhbHVlIG9mIHRoZSBvYmplY3QgcHJvdmlkZWQgaGFzIG5vdCB5ZXQgYmVlbiB1 cGRhdGVkIGluIHRoZSBtb2RlbCwgaGVuY2UsIHRoZSB2YWx1ZSBpcyB0aGUgb2xkIHZhbHVlLCBu b3QgdGhlIG5ldyB2YWx1ZS48YnI+ICA8YnI+IFdoZW4gdXNpbmcgJmx0O2Y6YWN0aW9uTGlzdGVu ZXImZ3Q7IG9uIHRoZSBidXR0b24gc3VibWl0dGluZyB0aGUgdmFsdWVzLCB0aGUgbmV3IHZhbHVl IGlzIHBvcHVsYXRlZCBpbnRvIHRoZSBtb2RlbCBpbnN0ZWFkLi4uIHdoaWNoIGlzIHRoZSBiZWhh dmlvciBJIHdvdWxkIGV4cGVjdC48YnI+PGJyPiBQYXJkb24gdGhlIHByb2JhYmx5IG9idmlvdXMg cXVlc3Rpb24uLi48YnI+PGJyPiBJcyB0aGVyZSBhbiBjb250cmFjdCB3aXRoIHZhbHVlQ2hhbmdl TGlzdGVuZXJzIHRoYXQgc3RhdGVzIHRoZXkgZmlyZSBiZWZvcmUgbW9kZWwgdXBkYXRlcz8gSSBz ZWUgaW4gdGhlIHNwZWMgdGhhdCBpdCBmaXJlczogJnF1b3Q7d2hlbiBhIG5ldyBsb2NhbCB2YWx1 ZSBoYXMgYmVlbiBjcmVhdGVkLCBhbmQgaGFzIHBhc3NlZCBhbGwgdmFsaWRhdGlvbnMsJnF1b3Q7 IGJ1dCBub3RoaW5nIGFib3V0IGlmIHRoZSBtb2RlbCBoYXMgYmVlbiB1cGRhdGVkIG9yIG5vdC48 YnI+IDwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48ZGl2Pjxicj5UaGV5JiMzOTtyZSBmaXJlZCBh ZnRlciB0aGUgUHJvY2VzcyBWYWxpZGF0aW9ucyBwaGFzZSAob3IgQXBwbHkgUmVxdWVzdCBWYWx1 ZXMgaWYgaW1tZWRpYXRlPXRydWUpLCB3aGljaCBhbHdheXMgb2NjdXJzIGJlZm9yZSB0aGUgVXBk YXRlIE1vZGVsIHBoYXNlLiBUaGUgaWRlYSBpcyB0aGF0IHRoZSBpbnB1dCBtdXN0IGJlIGluIGEg dmFsaWQgc3RhdGUgYmVmb3JlIHRoZSBtb2RlbCBpcyB1cGRhdGVkLjxicj48L2Rpdj48L2Rpdj48 L2Jsb2NrcXVvdGU+PGRpdj48YnI+QW5kIHRoYXQgdGhlIHZhbHVlIGNoYW5nZSBsaXN0ZW5lciBp cyBub3RpZmllZCBvZiB0aGUgaW50ZW50IHRvIGNoYW5nZSB0aGUgbW9kZWwgdmFsdWUsIGhlbmNl IGdpdmluZyBpdCBhIGNoYW5jZSB0byBibG9jayB0aGUgdXBkYXRlIChvciBhdCBsZWFzdCB0aGF0 IGJlY29tZXMgYSBwb3NzaWJsZSBjb3Vyc2Ugb2YgYWN0aW9uKS48YnI+PGJyPi1EYW48L2Rpdj48 L2Rpdj48YnI+LS0gPGJyPkRhbiBBbGxlbjxicj5TZW5pb3IgU29mdHdhcmUgRW5naW5lZXIsIFJl ZCBIYXQgfCBBdXRob3Igb2YgU2VhbSBpbiBBY3Rpb248YnI+UmVnaXN0ZXJlZCBMaW51eCBVc2Vy ICMyMzE1OTc8YnI+PGJyPjxhIGhyZWY9Imh0dHA6Ly9tb2phdmVsaW51eC5jb20iPmh0dHA6Ly9t b2phdmVsaW51eC5jb208L2E+PGJyPjxhIGhyZWY9Imh0dHA6Ly9tb2phdmVsaW51eC5jb20vc2Vh bWluYWN0aW9uIj5odHRwOi8vbW9qYXZlbGludXguY29tL3NlYW1pbmFjdGlvbjwvYT48YnI+PGEg aHJlZj0iaHR0cDovL2luLnJlbGF0aW9uLnRvL0Jsb2dnZXJzL0RhbiI+aHR0cDovL2luLnJlbGF0 aW9uLnRvL0Jsb2dnZXJzL0RhbjwvYT48YnI+ICA8L2h0bWw+ --===============4196359828523359999==-- From andy.schwartz at oracle.com Sun Aug 16 04:45:25 2020 Content-Type: multipart/mixed; boundary="===============5144798823885912085==" MIME-Version: 1.0 From: Andy Schwartz To: jsr-314-open-mirror at lists.jboss.org Subject: [jsr-314-open] #{cc} semantics Date: Tue, 15 Sep 2009 18:34:49 -0400 Message-ID: <4AB01689.7080408@oracle.com> In-Reply-To: 4AA68D5F.60809@sun.com --===============5144798823885912085== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Ryan, All - Breaking this topic off into a separate thread, though I am impressed = with the length of the " binding vs. ui:repeat" thread. :-) Ryan Lubke wrote: > On 9/7/09 6:06 PM, Andy Schwartz wrote: >> Thanks Lincoln. I haven't had time to debug this, but I have a = >> theory about what might be happening. In your sample: >> >>> >> rendered=3D"#{!cc.attrs.disabled}"> >>> *>> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, = >>> cc.attrs.task)}" /> * >>> >> >> We expect "cc" to resolve to the containing composite component (ie. = >> to the component). I wouldn't be surprised if = >> what is actually happening is that "cc" is being resolved to the = >> composite component instead. > Yep, that's what is happening. >> One reason why I suspect this might be happening is that I know that = >> Ryan has investigated/resolved similar problems not too long ago. > The problem we resolved was the passing of #{cc.attrs} attributes = > between nested composite components. > For this case, the spec recommends using cc.parent.attrs.story and = > cc.parent.attrs.task, where parent resolves > to the nearest composite component parent of the current composite = > component. I am concerned about this behavior. It isn't clear to me whether the = spec is explicit about this behavior, or whether this is something that = happens to fall out of the implementation. Either way, the current = behavior seems counterintuitive to me, and, well... wrong. My feeling is that when a composite component author uses a #{cc} = expression in a composite component implementation, eg: The correct behavior (the behavior expected by the composite component = author) is to resolve the #{cc} expression relative to where the = expression is defined - not relative to where it happens to end up in = the component tree. So, for example, I believe that these three uses of = the #{cc.attrs.value} expression should all evaluate to the same value: The fact that the #{cc.attrs.value} expression evaluates the same in = cases #1 and #2 but not in case #3 is non-obvious and is going to be = confusing for our users. The fact that Lincoln and I were confused = about this is a good indication that others will be as well. I am not happy with the work around of using #cc.parent.attrs, since = this means that: 1. The user must recognize that the component in question is a composite = component and code the expression differently. While at the moment it = is fairly easy to determine whether a particular component is a = composite or not (by looking at the namespace declaration), I think that = we should strive to blur these lines rather than reinforce them. For = example, I would like to see the ability to define a single tag library = that consists of both composite and non-composite components, making the = choice of component implementation more transparent to the user. 2. Once the user has coded the expression in a composite = component-specific way, this introduces a dependency on the fact that = the component in question is a composite component - a dependency that = shouldn't be necessary for this particular case. Such dependencies = inhibit flexibility. If in the future the provider of the composite = component decides to switch to a Java-based component, this will break = any code (or EL expression) that assumes that the component is a = composite. We should keep such dependencies to a minimum. 3. This also introduces a subtle dependency on the composite component's = implementation. What if the composite component implementation passes = the expression along to yet another nested composite component? Does = the user now need to specify an expression that pops out multiple levels = of parents? While it is certainly trickier to deal with from an implementation = perspective, I believe that it is very important that we re-consider the = current behavior and consider spec'ing that #{cc} expressions always = resolve relative to the context in which they are defined. I feel that = the current behavior violates the principle of least surprise (both = Lincoln and I were surprised) and also breaks encapsulation (ie. = introduces implementation-specific dependencies). Leaving aside questions of how we might implement my preferred behavior = for the moment... Does anyone have comments on which behavior makes = sense from a spec/end user perspective? Andy --===============5144798823885912085==-- From Ken.Paulsen at Sun.COM Sun Aug 16 04:45:25 2020 Content-Type: multipart/mixed; boundary="===============6812115274736432266==" MIME-Version: 1.0 From: Ken Paulsen To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] #{cc} semantics Date: Tue, 15 Sep 2009 16:53:13 -0700 Message-ID: <4AB028E9.2000408@sun.com> In-Reply-To: 4AB01689.7080408@oracle.com --===============6812115274736432266== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Well Andy..... I agree 100% with you. Thanks, Ken Andy Schwartz wrote: > Ryan, All - > > Breaking this topic off into a separate thread, though I am impressed = > with the length of the " binding vs. ui:repeat" thread. :-) > > Ryan Lubke wrote: >> On 9/7/09 6:06 PM, Andy Schwartz wrote: >>> Thanks Lincoln. I haven't had time to debug this, but I have a = >>> theory about what might be happening. In your sample: >>> >>>> >>> rendered=3D"#{!cc.attrs.disabled}"> >>>> *>>> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, = >>>> cc.attrs.task)}" /> * >>>> >>> >>> We expect "cc" to resolve to the containing composite component (ie. = >>> to the component). I wouldn't be surprised if = >>> what is actually happening is that "cc" is being resolved to the = >>> composite component instead. >> Yep, that's what is happening. >>> One reason why I suspect this might be happening is that I know that = >>> Ryan has investigated/resolved similar problems not too long ago. >> The problem we resolved was the passing of #{cc.attrs} attributes = >> between nested composite components. >> For this case, the spec recommends using cc.parent.attrs.story and = >> cc.parent.attrs.task, where parent resolves >> to the nearest composite component parent of the current composite = >> component. > > I am concerned about this behavior. It isn't clear to me whether the = > spec is explicit about this behavior, or whether this is something = > that happens to fall out of the implementation. Either way, the = > current behavior seems counterintuitive to me, and, well... wrong. > > My feeling is that when a composite component author uses a #{cc} = > expression in a composite component implementation, eg: > > > > > > The correct behavior (the behavior expected by the composite component = > author) is to resolve the #{cc} expression relative to where the = > expression is defined - not relative to where it happens to end up in = > the component tree. So, for example, I believe that these three uses = > of the #{cc.attrs.value} expression should all evaluate to the same = > value: > > > > > > > > > > > > > > > > > > > > > > > The fact that the #{cc.attrs.value} expression evaluates the same in = > cases #1 and #2 but not in case #3 is non-obvious and is going to be = > confusing for our users. The fact that Lincoln and I were confused = > about this is a good indication that others will be as well. > > I am not happy with the work around of using #cc.parent.attrs, since = > this means that: > > 1. The user must recognize that the component in question is a = > composite component and code the expression differently. While at the = > moment it is fairly easy to determine whether a particular component = > is a composite or not (by looking at the namespace declaration), I = > think that we should strive to blur these lines rather than reinforce = > them. For example, I would like to see the ability to define a single = > tag library that consists of both composite and non-composite = > components, making the choice of component implementation more = > transparent to the user. > > 2. Once the user has coded the expression in a composite = > component-specific way, this introduces a dependency on the fact that = > the component in question is a composite component - a dependency that = > shouldn't be necessary for this particular case. Such dependencies = > inhibit flexibility. If in the future the provider of the composite = > component decides to switch to a Java-based component, this will break = > any code (or EL expression) that assumes that the component is a = > composite. We should keep such dependencies to a minimum. > > 3. This also introduces a subtle dependency on the composite = > component's implementation. What if the composite component = > implementation passes the expression along to yet another nested = > composite component? Does the user now need to specify an expression = > that pops out multiple levels of parents? > > While it is certainly trickier to deal with from an implementation = > perspective, I believe that it is very important that we re-consider = > the current behavior and consider spec'ing that #{cc} expressions = > always resolve relative to the context in which they are defined. I = > feel that the current behavior violates the principle of least = > surprise (both Lincoln and I were surprised) and also breaks = > encapsulation (ie. introduces implementation-specific dependencies). > > Leaving aside questions of how we might implement my preferred = > behavior for the moment... Does anyone have comments on which = > behavior makes sense from a spec/end user perspective? > > Andy > --===============6812115274736432266==-- From asmirnov at exadel.com Sun Aug 16 04:45:25 2020 Content-Type: multipart/mixed; boundary="===============1895150020010687791==" MIME-Version: 1.0 From: Alaxander Smirnov To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] #{cc} semantics Date: Tue, 15 Sep 2009 17:44:45 -0700 Message-ID: <4AB034FD.4040300@exadel.com> In-Reply-To: 4AB01689.7080408@oracle.com --===============1895150020010687791== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/15/2009 03:34 PM, Andy Schwartz wrote: > Ryan, All - > > Breaking this topic off into a separate thread, though I am impressed = > with the length of the " binding vs. ui:repeat" thread. :-) > > Ryan Lubke wrote: >> On 9/7/09 6:06 PM, Andy Schwartz wrote: >>> Thanks Lincoln. I haven't had time to debug this, but I have a = >>> theory about what might be happening. In your sample: >>> >>>> >>> rendered=3D"#{!cc.attrs.disabled}"> >>>> *>>> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, = >>>> cc.attrs.task)}" /> * >>>> >>> >>> We expect "cc" to resolve to the containing composite component (ie. = >>> to the component). I wouldn't be surprised if = >>> what is actually happening is that "cc" is being resolved to the = >>> composite component instead. >> Yep, that's what is happening. >>> One reason why I suspect this might be happening is that I know that = >>> Ryan has investigated/resolved similar problems not too long ago. >> The problem we resolved was the passing of #{cc.attrs} attributes = >> between nested composite components. >> For this case, the spec recommends using cc.parent.attrs.story and = >> cc.parent.attrs.task, where parent resolves >> to the nearest composite component parent of the current composite = >> component. > > I am concerned about this behavior. It isn't clear to me whether the = > spec is explicit about this behavior, or whether this is something = > that happens to fall out of the implementation. Either way, the = > current behavior seems counterintuitive to me, and, well... wrong. > > My feeling is that when a composite component author uses a #{cc} = > expression in a composite component implementation, eg: > > > > > > The correct behavior (the behavior expected by the composite component = > author) is to resolve the #{cc} expression relative to where the = > expression is defined - not relative to where it happens to end up in = > the component tree. So, for example, I believe that these three uses = > of the #{cc.attrs.value} expression should all evaluate to the same = > value: > > > > > > > > > > > > > > > > > > > > > > > The fact that the #{cc.attrs.value} expression evaluates the same in = > cases #1 and #2 but not in case #3 is non-obvious and is going to be = > confusing for our users. The fact that Lincoln and I were confused = > about this is a good indication that others will be as well. Complete agree with that point. Especially in the case of using = third-party libraries, where vendor could decide to change component = implementation from java to composite or vice versa that can break other = composite components depended of the original library. > > I am not happy with the work around of using #cc.parent.attrs, since = > this means that: > > 1. The user must recognize that the component in question is a = > composite component and code the expression differently. While at the = > moment it is fairly easy to determine whether a particular component = > is a composite or not (by looking at the namespace declaration), I = > think that we should strive to blur these lines rather than reinforce = > them. For example, I would like to see the ability to define a single = > tag library that consists of both composite and non-composite = > components, making the choice of component implementation more = > transparent to the user. Yes, that is obvious wishlist for component library vendors. = Unfortunately, it is not possible now to mix Java and composite = components in the same library ( at least, this is not trivial to do in = the implementation-independent way. > > 2. Once the user has coded the expression in a composite = > component-specific way, this introduces a dependency on the fact that = > the component in question is a composite component - a dependency that = > shouldn't be necessary for this particular case. Such dependencies = > inhibit flexibility. If in the future the provider of the composite = > component decides to switch to a Java-based component, this will break = > any code (or EL expression) that assumes that the component is a = > composite. We should keep such dependencies to a minimum. > > 3. This also introduces a subtle dependency on the composite = > component's implementation. What if the composite component = > implementation passes the expression along to yet another nested = > composite component? Does the user now need to specify an expression = > that pops out multiple levels of parents? > > While it is certainly trickier to deal with from an implementation = > perspective, I believe that it is very important that we re-consider = > the current behavior and consider spec'ing that #{cc} expressions = > always resolve relative to the context in which they are defined. I = > feel that the current behavior violates the principle of least = > surprise (both Lincoln and I were surprised) and also breaks = > encapsulation (ie. introduces implementation-specific dependencies). > > Leaving aside questions of how we might implement my preferred = > behavior for the moment... Does anyone have comments on which = > behavior makes sense from a spec/end user perspective? > > Andy > --===============1895150020010687791==-- From dan.j.allen at gmail.com Sun Aug 16 04:45:25 2020 Content-Type: multipart/mixed; boundary="===============5616779694651690727==" MIME-Version: 1.0 From: Dan Allen To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] #{cc} semantics Date: Wed, 16 Sep 2009 15:23:33 -0400 Message-ID: <19758da0909161223s7fd75fbdw51720feca8ffabc0@mail.gmail.com> In-Reply-To: 4AB01689.7080408@oracle.com --===============5616779694651690727== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable +1. Also... > 1. The user must recognize that the component in question is a composite > component and code the expression differently. While at the moment it is > fairly easy to determine whether a particular component is a composite or > not (by looking at the namespace declaration), I think that we should str= ive > to blur these lines rather than reinforce them. Exactly. We don't want the page author to start discriminating between the implementations of a component. That's dangerous. Leaving aside questions of how we might implement my preferred behavior for > the moment... Does anyone have comments on which behavior makes sense fr= om > a spec/end user perspective? > > The general goal should be to make composite components as indistinguishable from formal Java-developed components as possible. -Dan -- = Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen --===============5616779694651690727== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" KzEuPGJyPjxicj5BbHNvLi4uPGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCBy Z2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVm dDogMWV4OyI+PGJyPgoxLiBUaGUgdXNlciBtdXN0IHJlY29nbml6ZSB0aGF0IHRoZSBjb21wb25l bnQgaW4gcXVlc3Rpb24gaXMgYSBjb21wb3NpdGUgY29tcG9uZW50IGFuZCBjb2RlIHRoZSBleHBy ZXNzaW9uIGRpZmZlcmVudGx5LiDCoFdoaWxlIGF0IHRoZSBtb21lbnQgaXQgaXMgZmFpcmx5IGVh c3kgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYSBwYXJ0aWN1bGFyIGNvbXBvbmVudCBpcyBhIGNvbXBv c2l0ZSBvciBub3QgKGJ5IGxvb2tpbmcgYXQgdGhlIG5hbWVzcGFjZSBkZWNsYXJhdGlvbiksIEkg dGhpbmsgdGhhdCB3ZSBzaG91bGQgc3RyaXZlIHRvIGJsdXIgdGhlc2UgbGluZXMgcmF0aGVyIHRo YW4gcmVpbmZvcmNlIHRoZW0uPC9ibG9ja3F1b3RlPgo8ZGl2Pjxicj5FeGFjdGx5LiBXZSBkb24m IzM5O3Qgd2FudCB0aGUgcGFnZSBhdXRob3IgdG8gc3RhcnQgZGlzY3JpbWluYXRpbmcgYmV0d2Vl biB0aGUgaW1wbGVtZW50YXRpb25zIG9mIGEgY29tcG9uZW50LiBUaGF0JiMzOTtzIGRhbmdlcm91 cy4gPGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJi b3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0 IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KCkxlYXZpbmcgYXNpZGUgcXVlc3Rpb25z IG9mIGhvdyB3ZSBtaWdodCBpbXBsZW1lbnQgbXkgcHJlZmVycmVkIGJlaGF2aW9yIGZvciB0aGUg bW9tZW50Li4uIMKgRG9lcyBhbnlvbmUgaGF2ZSBjb21tZW50cyBvbiB3aGljaCBiZWhhdmlvciBt YWtlcyBzZW5zZSBmcm9tIGEgc3BlYy9lbmQgdXNlciBwZXJzcGVjdGl2ZT88YnI+PGZvbnQgY29s b3I9IiM4ODg4ODgiPgo8YnI+PC9mb250PjwvYmxvY2txdW90ZT48ZGl2Pjxicj5UaGUgZ2VuZXJh bCBnb2FsIHNob3VsZCBiZSB0byBtYWtlIGNvbXBvc2l0ZSBjb21wb25lbnRzIGFzIGluZGlzdGlu Z3Vpc2hhYmxlIGZyb20gZm9ybWFsIEphdmEtZGV2ZWxvcGVkIGNvbXBvbmVudHMgYXMgcG9zc2li bGUuPGJyPjxicj4tRGFuPC9kaXY+PC9kaXY+PGJyPi0tIDxicj5EYW4gQWxsZW48YnI+U2VuaW9y IFNvZnR3YXJlIEVuZ2luZWVyLCBSZWQgSGF0IHwgQXV0aG9yIG9mIFNlYW0gaW4gQWN0aW9uPGJy PgpSZWdpc3RlcmVkIExpbnV4IFVzZXIgIzIzMTU5Nzxicj48YnI+PGEgaHJlZj0iaHR0cDovL21v amF2ZWxpbnV4LmNvbSI+aHR0cDovL21vamF2ZWxpbnV4LmNvbTwvYT48YnI+PGEgaHJlZj0iaHR0 cDovL21vamF2ZWxpbnV4LmNvbS9zZWFtaW5hY3Rpb24iPmh0dHA6Ly9tb2phdmVsaW51eC5jb20v c2VhbWluYWN0aW9uPC9hPjxicj48YSBocmVmPSJodHRwOi8vd3d3Lmdvb2dsZS5jb20vcHJvZmls ZXMvZGFuLmouYWxsZW4iPmh0dHA6Ly93d3cuZ29vZ2xlLmNvbS9wcm9maWxlcy9kYW4uai5hbGxl bjwvYT48YnI+Cgo= --===============5616779694651690727==-- From lincolnbaxter at gmail.com Sun Aug 16 04:45:26 2020 Content-Type: multipart/mixed; boundary="===============8818113368915945251==" MIME-Version: 1.0 From: Lincoln Baxter, III To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] #{cc} semantics Date: Thu, 17 Sep 2009 00:49:27 -0400 Message-ID: <1253162967.4786.130.camel@quadshark> In-Reply-To: 4AB01689.7080408@oracle.com --===============8818113368915945251== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, 2009-09-15 at 18:34 -0400, Andy Schwartz wrote: > I feel that = > the current behavior violates the principle of least surprise (both = > Lincoln and I were surprised) and also breaks encapsulation (ie. = > introduces implementation-specific dependencies). Andy, I agree. = +1 In every other EL situation, values are rooted in the context within which they were defined. I didn't give it too much thought at first, but this would definitely be counter-intuitive. This is probably stating the obvious, but I don't want to forget about use case #4: passing as an attribute should also behave the same way (see inline.) > > = > > > = > > > > > > > = > > > > > > > = > = > It boggles my mind thinking about how to go about implementing this, but it needs to happen in order to, as Andy said, "adhere to the principle of least surprise". = --Lincoln -- Lincoln Baxter, III Co-Founder of OcpSoft Author of PrettyFaces URL Rewriting for JSF --===============8818113368915945251== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv L0VOIj4KPEhUTUw+CjxIRUFEPgogIDxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09O VEVOVD0idGV4dC9odG1sOyBDSEFSU0VUPVVURi04Ij4KICA8TUVUQSBOQU1FPSJHRU5FUkFUT1Ii IENPTlRFTlQ9Ikd0a0hUTUwvMy4yNi4wIj4KPC9IRUFEPgo8Qk9EWT4KPEJSPgpPbiBUdWUsIDIw MDktMDktMTUgYXQgMTg6MzQgLTA0MDAsIEFuZHkgU2Nod2FydHogd3JvdGU6PEJSPgo8QkxPQ0tR VU9URSBUWVBFPUNJVEU+CiAgICA8VFQ+PEZPTlQgQ09MT1I9IiMxYTFhMWEiPkkgZmVlbCB0aGF0 IDwvRk9OVD48L1RUPjxCUj4KICAgIDxUVD48Rk9OVCBDT0xPUj0iIzFhMWExYSI+dGhlIGN1cnJl bnQgYmVoYXZpb3IgdmlvbGF0ZXMgdGhlIHByaW5jaXBsZSBvZiBsZWFzdCBzdXJwcmlzZSAoYm90 aCA8L0ZPTlQ+PC9UVD48QlI+CiAgICA8VFQ+PEZPTlQgQ09MT1I9IiMxYTFhMWEiPkxpbmNvbG4g YW5kIEkgd2VyZSBzdXJwcmlzZWQpIGFuZCBhbHNvIGJyZWFrcyBlbmNhcHN1bGF0aW9uIChpZS4g PC9GT05UPjwvVFQ+PEJSPgogICAgPFRUPjxGT05UIENPTE9SPSIjMWExYTFhIj5pbnRyb2R1Y2Vz IGltcGxlbWVudGF0aW9uLXNwZWNpZmljIGRlcGVuZGVuY2llcykuPC9GT05UPjwvVFQ+PEJSPgo8 L0JMT0NLUVVPVEU+CjxCUj4KQW5keSwgSSBhZ3JlZS4gPEJSPgo8QlI+CisxPEJSPgo8QlI+Cklu IGV2ZXJ5IG90aGVyIEVMIHNpdHVhdGlvbiwgdmFsdWVzIGFyZSByb290ZWQgaW4gdGhlIGNvbnRl eHQgd2l0aGluIHdoaWNoIHRoZXkgd2VyZSBkZWZpbmVkLiBJIGRpZG4ndCBnaXZlIGl0IHRvbyBt dWNoIHRob3VnaHQgYXQgZmlyc3QsIGJ1dCB0aGlzIHdvdWxkIGRlZmluaXRlbHkgYmUgY291bnRl ci1pbnR1aXRpdmUuPEJSPgo8QlI+ClRoaXMgaXMgcHJvYmFibHkgc3RhdGluZyB0aGUgb2J2aW91 cywgYnV0IEkgZG9uJ3Qgd2FudCB0byBmb3JnZXQgYWJvdXQgdXNlIGNhc2UgIzQ6IHBhc3Npbmcg YXMgYW4gYXR0cmlidXRlIHNob3VsZCBhbHNvIGJlaGF2ZSB0aGUgc2FtZSB3YXkgKHNlZSBpbmxp bmUuKTxCUj4KPEJSPgo8QkxPQ0tRVU9URSBUWVBFPUNJVEU+CjxQUkU+CiAgJmx0O2NvbXBvc2l0 ZTppbXBsZW1lbnRhdGlvbiZndDsKCiAgICAmbHQ7IS0tIDEuIEV4cHJlc3Npb24gZGlyZWN0bHkg aW4gdGhlIGltcGxlbWVudGF0aW9uIC0tJmd0OwogICAgJmx0O2g6b3V0cHV0VGV4dCB2YWx1ZT0m cXVvdDsje2NjLmF0dHJzLnZhbHVlfSZxdW90OyZndDsKCiAgICAmbHQ7IS0tIDIuIEV4cHJlc3Np b24gaW4gbm9uLWNvbXBvc2l0ZSBjb21wb25lbnQgZmFjZXQgLS0mZ3Q7CiAgICAmbHQ7YmFyOnNv bWVKYXZhQ29tcG9zaXRlJmd0OwogICAgICAmbHQ7ZjpmYWNldCBuYW1lPSZxdW90O3NvbWVGYWNl dCZxdW90OyZndDsKICAgICAgICAmbHQ7aDpvdXRwdXRUZXh0IHZhbHVlPSZxdW90OyN7Y2MuYXR0 cnMudmFsdWV9JnF1b3Q7Jmd0OwogICAgICAmbHQ7L2Y6ZmFjZXQmZ3Q7CiAgICAmbHQ7L2Jhcjpz b21lSmF2YUNvbXBvbmVudCZndDsKCiAgICAmbHQ7IS0tIDMuIEV4cHJlc3Npb24gaW4gY29tcG9z aXRlIGNvbXBvbmVudCBmYWNldCAtLSZndDsKICAgICZsdDtmb286c29tZUNvbXBvc2l0ZUNvbXBv bmVudCZndDsKICAgICAgJmx0O2Y6ZmFjZXQgbmFtZT0mcXVvdDtzb21lRmFjZXQmcXVvdDsmZ3Q7 CiAgICAgICAgJmx0O2g6b3V0cHV0VGV4dCB2YWx1ZT0mcXVvdDsje2NjLmF0dHJzLnZhbHVlfSZx dW90OyZndDsKICAgICAgJmx0Oy9mOmZhY2V0Jmd0OwombmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy9m b286c29tZUNvbXBvc2l0ZUNvbXBvbmVudCZndDsKCjwvUFJFPgo8L0JMT0NLUVVPVEU+CjxQUkU+ Cgo8L1BSRT4KPFRUPjxGT05UIENPTE9SPSIjMWExYTFhIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0 OyEtLSA8L0ZPTlQ+PC9UVD48VFQ+NDwvVFQ+PFRUPjxGT05UIENPTE9SPSIjMWExYTFhIj4uIEV4 cHJlc3Npb24gaW4gY29tcG9zaXRlPC9GT05UPjwvVFQ+PFRUPiA8L1RUPjxUVD48Rk9OVCBDT0xP Uj0iIzFhMWExYSI+Y29tcG9uZW50IGE8L0ZPTlQ+PC9UVD48VFQ+dHRyaWJ1dGU8L1RUPjxUVD48 Rk9OVCBDT0xPUj0iIzFhMWExYSI+IC0tJmd0OzwvRk9OVD48L1RUPjxCUj4KPFRUPjxGT05UIENP TE9SPSIjMWExYTFhIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2Jhcjpzb21lPC9GT05UPjwvVFQ+ PFRUPkNvbXBvc2l0ZUNvbXBvbmVudCA8L1RUPjxUVD48Rk9OVCBDT0xPUj0iIzFhMWExYSI+dmFs dWU9JnF1b3Q7I3tjYy5hdHRycy52YWx1ZX0mcXVvdDs8L0ZPTlQ+PC9UVD48VFQ+IC8mZ3Q7PC9U VD48QlI+CjxCUj4KPEJMT0NLUVVPVEUgVFlQRT1DSVRFPgo8UFJFPgoKICAmbHQ7L2NvbXBvc2l0 ZTppbXBsZW1lbnRhdGlvbiZndDsKPC9QUkU+CjwvQkxPQ0tRVU9URT4KPEJSPgpJdCBib2dnbGVz IG15IG1pbmQgdGhpbmtpbmcgYWJvdXQgaG93IHRvIGdvIGFib3V0IGltcGxlbWVudGluZyB0aGlz LCBidXQgaXQgbmVlZHMgdG8gaGFwcGVuIGluIG9yZGVyIHRvLCBhcyBBbmR5IHNhaWQsICZxdW90 O2FkaGVyZSB0byB0aGUgcHJpbmNpcGxlIG9mIGxlYXN0IHN1cnByaXNlJnF1b3Q7LiA8QlI+CjxC Uj4KLS1MaW5jb2xuPEJSPgo8QlI+CjxUQUJMRSBDRUxMU1BBQ0lORz0iMCIgQ0VMTFBBRERJTkc9 IjAiIFdJRFRIPSIxMDAlIj4KPFRSPgo8VEQ+Ci0tPEJSPgo8Qj5MaW5jb2xuIEJheHRlciwgSUlJ PC9CPjxCUj4KQ28tRm91bmRlciBvZiA8QSBIUkVGPSJodHRwOi8vb2Nwc29mdC5jb20iPk9jcFNv ZnQ8L0E+PEJSPgpBdXRob3Igb2YgPEEgSFJFRj0iaHR0cDovL29jcHNvZnQuY29tL3ByZXR0eWZh Y2VzIj5QcmV0dHlGYWNlczwvQT4gVVJMIFJld3JpdGluZyBmb3IgSlNGPEJSPgo8QlI+CjxCUj4K PC9URD4KPC9UUj4KPC9UQUJMRT4KPC9CT0RZPgo8L0hUTUw+Cg== --===============8818113368915945251==-- From kito.mann at virtua.com Sun Aug 16 04:45:26 2020 Content-Type: multipart/mixed; boundary="===============3410301476979734408==" MIME-Version: 1.0 From: Kito Mann To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] #{cc} semantics Date: Thu, 17 Sep 2009 12:12:24 -0400 Message-ID: In-Reply-To: 4AB01689.7080408@oracle.com --===============3410301476979734408== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable +1 --- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://twitter.com/jsfcentral JSF 2 Seminar Oct 6th: http://www.regonline.com/jsf2seminar JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 On Tue, Sep 15, 2009 at 6:34 PM, Andy Schwartz = wrote: > Ryan, All - > > Breaking this topic off into a separate thread, though I am impressed with > the length of the " binding vs. ui:repeat" thread. :-) > > Ryan Lubke wrote: > >> On 9/7/09 6:06 PM, Andy Schwartz wrote: >> >>> Thanks Lincoln. I haven't had time to debug this, but I have a theory >>> about what might be happening. In your sample: >>> >>> >>> rendered=3D"#{!cc.attrs.disabled}"> >>>> *>>> action=3D"#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)= }" /> * >>>> >>>> >>> >>> We expect "cc" to resolve to the containing composite component (ie. to >>> the component). I wouldn't be surprised if what is >>> actually happening is that "cc" is being resolved to the >>> composite component instead. >>> >> Yep, that's what is happening. >> >>> One reason why I suspect this might be happening is that I know that Ry= an >>> has investigated/resolved similar problems not too long ago. >>> >> The problem we resolved was the passing of #{cc.attrs} attributes between >> nested composite components. >> For this case, the spec recommends using cc.parent.attrs.story and >> cc.parent.attrs.task, where parent resolves >> to the nearest composite component parent of the current composite >> component. >> > > I am concerned about this behavior. It isn't clear to me whether the spec > is explicit about this behavior, or whether this is something that happens > to fall out of the implementation. Either way, the current behavior seems > counterintuitive to me, and, well... wrong. > > My feeling is that when a composite component author uses a #{cc} > expression in a composite component implementation, eg: > > > > > > The correct behavior (the behavior expected by the composite component > author) is to resolve the #{cc} expression relative to where the expressi= on > is defined - not relative to where it happens to end up in the component > tree. So, for example, I believe that these three uses of the > #{cc.attrs.value} expression should all evaluate to the same value: > > > > > > > > > > > > > > > > > > > > > > > The fact that the #{cc.attrs.value} expression evaluates the same in cases > #1 and #2 but not in case #3 is non-obvious and is going to be confusing = for > our users. The fact that Lincoln and I were confused about this is a good > indication that others will be as well. > > I am not happy with the work around of using #cc.parent.attrs, since this > means that: > > 1. The user must recognize that the component in question is a composite > component and code the expression differently. While at the moment it is > fairly easy to determine whether a particular component is a composite or > not (by looking at the namespace declaration), I think that we should str= ive > to blur these lines rather than reinforce them. For example, I would like > to see the ability to define a single tag library that consists of both > composite and non-composite components, making the choice of component > implementation more transparent to the user. > > 2. Once the user has coded the expression in a composite component-specif= ic > way, this introduces a dependency on the fact that the component in quest= ion > is a composite component - a dependency that shouldn't be necessary for t= his > particular case. Such dependencies inhibit flexibility. If in the future > the provider of the composite component decides to switch to a Java-based > component, this will break any code (or EL expression) that assumes that = the > component is a composite. We should keep such dependencies to a minimum. > > 3. This also introduces a subtle dependency on the composite component's > implementation. What if the composite component implementation passes the > expression along to yet another nested composite component? Does the user > now need to specify an expression that pops out multiple levels of parent= s? > > While it is certainly trickier to deal with from an implementation > perspective, I believe that it is very important that we re-consider the > current behavior and consider spec'ing that #{cc} expressions always reso= lve > relative to the context in which they are defined. I feel that the curre= nt > behavior violates the principle of least surprise (both Lincoln and I were > surprised) and also breaks encapsulation (ie. introduces > implementation-specific dependencies). > > Leaving aside questions of how we might implement my preferred behavior f= or > the moment... Does anyone have comments on which behavior makes sense fr= om > a spec/end user perspective? > > Andy > > --===============3410301476979734408== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" KzE8YnIgY2xlYXI9ImFsbCI+LS0tPGJyPktpdG8gRC4gTWFubiAtLSBBdXRob3IsIEphdmFTZXJ2 ZXIgRmFjZXMgaW4gQWN0aW9uPGJyPjxhIGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNvbS9raXRvOTki Pmh0dHA6Ly90d2l0dGVyLmNvbS9raXRvOTk8L2E+IKA8YSBocmVmPSJodHRwOi8vdHdpdHRlci5j b20vanNmY2VudHJhbCI+aHR0cDovL3R3aXR0ZXIuY29tL2pzZmNlbnRyYWw8L2E+PGJyPgpKU0Yg MiBTZW1pbmFyIE9jdCA2dGg6IDxhIGhyZWY9Imh0dHA6Ly93d3cucmVnb25saW5lLmNvbS9qc2Yy c2VtaW5hciI+aHR0cDovL3d3dy5yZWdvbmxpbmUuY29tL2pzZjJzZW1pbmFyPC9hPjxicj5KU0Yg U3VtbWl0IENvbmZlcmVuY2UgRGVjIDFzdC00dGggaW4gT3JsYW5kbzogPGEgaHJlZj0iaHR0cDov L3d3dy5qc2ZzdW1taXQuY29tIj5odHRwOi8vd3d3LmpzZnN1bW1pdC5jb208L2E+PGJyPgo8YSBo cmVmPSJodHRwOi8vd3d3LkpTRkNlbnRyYWwuY29tIj5odHRwOi8vd3d3LkpTRkNlbnRyYWwuY29t PC9hPiAtIEphdmFTZXJ2ZXIgRmFjZXMgRkFRLCBuZXdzLCBhbmQgaW5mbzxicj4rMSAyMDMtNDA0 LTQ4NDggeDM8YnI+Cjxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgU2Vw IDE1LCAyMDA5IGF0IDY6MzQgUE0sIEFuZHkgU2Nod2FydHogPHNwYW4gZGlyPSJsdHIiPiZsdDs8 YSBocmVmPSJtYWlsdG86YW5keS5zY2h3YXJ0ekBvcmFjbGUuY29tIj5hbmR5LnNjaHdhcnR6QG9y YWNsZS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQp OyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgpSeWFuLCBB bGwgLTxicj4KPGJyPgpCcmVha2luZyB0aGlzIHRvcGljIG9mZiBpbnRvIGEgc2VwYXJhdGUgdGhy ZWFkLCB0aG91Z2ggSSBhbSBpbXByZXNzZWQgd2l0aCB0aGUgbGVuZ3RoIG9mIHRoZSAmcXVvdDsm bHQ7aDpkYXRhVGFibGUmZ3Q7IGJpbmRpbmcgdnMuIHVpOnJlcGVhdCZxdW90OyB0aHJlYWQuIDot KTxicj4KPGJyPgpSeWFuIEx1YmtlIHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7 IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+Ck9uIDkvNy8w OSA2OjA2IFBNLCBBbmR5IFNjaHdhcnR6IHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIw NCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+ClRoYW5r cyBMaW5jb2xuLiCgSSBoYXZlbiYjMzk7dCBoYWQgdGltZSB0byBkZWJ1ZyB0aGlzLCBidXQgSSBo YXZlIGEgdGhlb3J5IGFib3V0IHdoYXQgbWlnaHQgYmUgaGFwcGVuaW5nLiCgSW4geW91ciBzYW1w bGU6PGJyPgo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRl ci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0 IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgombHQ7YTplZGl0VGV4dCB2YWx1ZT0mcXVvdDsj e2NjLmF0dHJzLnRhc2sudGV4dH0mcXVvdDsgcmVuZGVyZWQ9JnF1b3Q7I3shY2MuYXR0cnMuZGlz YWJsZWR9JnF1b3Q7Jmd0Ozxicj4KKiZsdDtmOmFjdGlvbkxpc3RlbmVyIGZvcj0mcXVvdDtzdWJt aXQmcXVvdDsgYWN0aW9uPSZxdW90OyN7dGFza0NvbnRyb2xsZXIuc2F2ZVRhc2tBamF4KGNjLmF0 dHJzLnN0b3J5LCBjYy5hdHRycy50YXNrKX0mcXVvdDsgLyZndDsgKjxicj4KJmx0Oy9hOmVkaXRU ZXh0Jmd0Ozxicj4KPC9ibG9ja3F1b3RlPgo8YnI+CldlIGV4cGVjdCAmcXVvdDtjYyZxdW90OyB0 byByZXNvbHZlIHRvIHRoZSBjb250YWluaW5nIGNvbXBvc2l0ZSBjb21wb25lbnQgKGllLiB0byB0 aGUgJmx0O3NvY2lhbHBtOnRhc2tCbG9jayZndDsgY29tcG9uZW50KS4goEkgd291bGRuJiMzOTt0 IGJlIHN1cnByaXNlZCBpZiB3aGF0IGlzIGFjdHVhbGx5IGhhcHBlbmluZyBpcyB0aGF0ICZxdW90 O2NjJnF1b3Q7IGlzIKBiZWluZyByZXNvbHZlZCB0byB0aGUgJmx0O2E6ZWRpdFRleHQmZ3Q7IGNv bXBvc2l0ZSBjb21wb25lbnQgaW5zdGVhZC48YnI+Cgo8L2Jsb2NrcXVvdGU+ClllcCwgdGhhdCYj Mzk7cyB3aGF0IGlzIGhhcHBlbmluZy48YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJn aW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgpPbmUgcmVhc29uIHdo eSBJIHN1c3BlY3QgdGhpcyBtaWdodCBiZSBoYXBwZW5pbmcgaXMgdGhhdCBJIGtub3cgdGhhdCBS eWFuIGhhcyBpbnZlc3RpZ2F0ZWQvcmVzb2x2ZWQgc2ltaWxhciBwcm9ibGVtcyBub3QgdG9vIGxv bmcgYWdvLjxicj4KPC9ibG9ja3F1b3RlPgpUaGUgcHJvYmxlbSB3ZSByZXNvbHZlZCB3YXMgdGhl IHBhc3Npbmcgb2YgI3tjYy5hdHRyc30gYXR0cmlidXRlcyBiZXR3ZWVuIG5lc3RlZCBjb21wb3Np dGUgY29tcG9uZW50cy48YnI+CkZvciB0aGlzIGNhc2UsIHRoZSBzcGVjIHJlY29tbWVuZHMgdXNp bmcgY2MucGFyZW50LmF0dHJzLnN0b3J5IGFuZCBjYy5wYXJlbnQuYXR0cnMudGFzaywgd2hlcmUg cGFyZW50IHJlc29sdmVzPGJyPgp0byB0aGUgbmVhcmVzdCBjb21wb3NpdGUgY29tcG9uZW50IHBh cmVudCBvZiB0aGUgY3VycmVudCBjb21wb3NpdGUgY29tcG9uZW50Ljxicj4KPC9ibG9ja3F1b3Rl Pgo8YnI+CkkgYW0gY29uY2VybmVkIGFib3V0IHRoaXMgYmVoYXZpb3IuIKBJdCBpc24mIzM5O3Qg Y2xlYXIgdG8gbWUgd2hldGhlciB0aGUgc3BlYyBpcyBleHBsaWNpdCBhYm91dCB0aGlzIGJlaGF2 aW9yLCBvciB3aGV0aGVyIHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgaGFwcGVucyB0byBmYWxsIG91 dCBvZiB0aGUgaW1wbGVtZW50YXRpb24uIKBFaXRoZXIgd2F5LCB0aGUgY3VycmVudCBiZWhhdmlv ciBzZWVtcyBjb3VudGVyaW50dWl0aXZlIHRvIG1lLCBhbmQsIHdlbGwuLi4gd3JvbmcuPGJyPgoK PGJyPgpNeSBmZWVsaW5nIGlzIHRoYXQgd2hlbiBhIGNvbXBvc2l0ZSBjb21wb25lbnQgYXV0aG9y IHVzZXMgYSAje2NjfSBleHByZXNzaW9uIGluIGEgY29tcG9zaXRlIGNvbXBvbmVudCBpbXBsZW1l bnRhdGlvbiwgZWc6PGJyPgo8YnI+CqAmbHQ7Y29tcG9zaXRlOmltcGxlbWVudGF0aW9uJmd0Ozxi cj4KIKAgJmx0O2g6b3V0cHV0VGV4dCB2YWx1ZT0mcXVvdDsje2NjLmF0dHJzLnZhbHVlfSZxdW90 OyZndDs8YnI+CqAmbHQ7L2NvbXBvc2l0ZTppbXBsZW1lbnRhdGlvbiZndDs8YnI+Cjxicj4KVGhl IGNvcnJlY3QgYmVoYXZpb3IgKHRoZSBiZWhhdmlvciBleHBlY3RlZCBieSB0aGUgY29tcG9zaXRl IGNvbXBvbmVudCBhdXRob3IpIGlzIHRvIHJlc29sdmUgdGhlICN7Y2N9IGV4cHJlc3Npb24gcmVs YXRpdmUgdG8gd2hlcmUgdGhlIGV4cHJlc3Npb24gaXMgZGVmaW5lZCAtIG5vdCByZWxhdGl2ZSB0 byB3aGVyZSBpdCBoYXBwZW5zIHRvIGVuZCB1cCBpbiB0aGUgY29tcG9uZW50IHRyZWUuIKBTbywg Zm9yIGV4YW1wbGUsIEkgYmVsaWV2ZSB0aGF0IHRoZXNlIHRocmVlIHVzZXMgb2YgdGhlICN7Y2Mu YXR0cnMudmFsdWV9IGV4cHJlc3Npb24gc2hvdWxkIGFsbCBldmFsdWF0ZSB0byB0aGUgc2FtZSB2 YWx1ZTo8YnI+Cgo8YnI+CqAmbHQ7Y29tcG9zaXRlOmltcGxlbWVudGF0aW9uJmd0Ozxicj4KPGJy PgogoCAmbHQ7IS0tIDEuIEV4cHJlc3Npb24gZGlyZWN0bHkgaW4gdGhlIGltcGxlbWVudGF0aW9u IC0tJmd0Ozxicj4KIKAgJmx0O2g6b3V0cHV0VGV4dCB2YWx1ZT0mcXVvdDsje2NjLmF0dHJzLnZh bHVlfSZxdW90OyZndDs8YnI+Cjxicj4KIKAgJmx0OyEtLSAyLiBFeHByZXNzaW9uIGluIG5vbi1j b21wb3NpdGUgY29tcG9uZW50IGZhY2V0IC0tJmd0Ozxicj4KIKAgJmx0O2Jhcjpzb21lSmF2YUNv bXBvc2l0ZSZndDs8YnI+CiCgIKAgJmx0O2Y6ZmFjZXQgbmFtZT0mcXVvdDtzb21lRmFjZXQmcXVv dDsmZ3Q7PGJyPgogoCCgIKAgJmx0O2g6b3V0cHV0VGV4dCB2YWx1ZT0mcXVvdDsje2NjLmF0dHJz LnZhbHVlfSZxdW90OyZndDs8YnI+CiCgIKAgJmx0Oy9mOmZhY2V0Jmd0Ozxicj4KIKAgJmx0Oy9i YXI6c29tZUphdmFDb21wb25lbnQmZ3Q7PGJyPgo8YnI+CiCgICZsdDshLS0gMy4gRXhwcmVzc2lv biBpbiBjb21wb3NpdGUgY29tcG9uZW50IGZhY2V0IC0tJmd0Ozxicj4KIKAgJmx0O2Zvbzpzb21l Q29tcG9zaXRlQ29tcG9uZW50Jmd0Ozxicj4KIKAgoCAmbHQ7ZjpmYWNldCBuYW1lPSZxdW90O3Nv bWVGYWNldCZxdW90OyZndDs8YnI+CiCgIKAgoCAmbHQ7aDpvdXRwdXRUZXh0IHZhbHVlPSZxdW90 OyN7Y2MuYXR0cnMudmFsdWV9JnF1b3Q7Jmd0Ozxicj4KIKAgoCAmbHQ7L2Y6ZmFjZXQmZ3Q7PGJy PgogoCAmbHQ7L2Zvbzpzb21lQ29tcG9zaXRlQ29tcG9uZW50Jmd0Ozxicj4KPGJyPgqgJmx0Oy9j b21wb3NpdGU6aW1wbGVtZW50YXRpb24mZ3Q7PGJyPgo8YnI+ClRoZSBmYWN0IHRoYXQgdGhlICN7 Y2MuYXR0cnMudmFsdWV9IGV4cHJlc3Npb24gZXZhbHVhdGVzIHRoZSBzYW1lIGluIGNhc2VzICMx IGFuZCAjMiBidXQgbm90IGluIGNhc2UgIzMgaXMgbm9uLW9idmlvdXMgYW5kIGlzIGdvaW5nIHRv IGJlIGNvbmZ1c2luZyBmb3Igb3VyIHVzZXJzLiCgVGhlIGZhY3QgdGhhdCBMaW5jb2xuIGFuZCBJ IHdlcmUgY29uZnVzZWQgYWJvdXQgdGhpcyBpcyBhIGdvb2QgaW5kaWNhdGlvbiB0aGF0IG90aGVy cyB3aWxsIGJlIGFzIHdlbGwuPGJyPgoKPGJyPgpJIGFtIG5vdCBoYXBweSB3aXRoIHRoZSB3b3Jr IGFyb3VuZCBvZiB1c2luZyAjY2MucGFyZW50LmF0dHJzLCBzaW5jZSB0aGlzIG1lYW5zIHRoYXQ6 PGJyPgo8YnI+CjEuIFRoZSB1c2VyIG11c3QgcmVjb2duaXplIHRoYXQgdGhlIGNvbXBvbmVudCBp biBxdWVzdGlvbiBpcyBhIGNvbXBvc2l0ZSBjb21wb25lbnQgYW5kIGNvZGUgdGhlIGV4cHJlc3Np b24gZGlmZmVyZW50bHkuIKBXaGlsZSBhdCB0aGUgbW9tZW50IGl0IGlzIGZhaXJseSBlYXN5IHRv IGRldGVybWluZSB3aGV0aGVyIGEgcGFydGljdWxhciBjb21wb25lbnQgaXMgYSBjb21wb3NpdGUg b3Igbm90IChieSBsb29raW5nIGF0IHRoZSBuYW1lc3BhY2UgZGVjbGFyYXRpb24pLCBJIHRoaW5r IHRoYXQgd2Ugc2hvdWxkIHN0cml2ZSB0byBibHVyIHRoZXNlIGxpbmVzIHJhdGhlciB0aGFuIHJl aW5mb3JjZSB0aGVtLiCgRm9yIGV4YW1wbGUsIEkgd291bGQgbGlrZSB0byBzZWUgdGhlIGFiaWxp dHkgdG8gZGVmaW5lIGEgc2luZ2xlIHRhZyBsaWJyYXJ5IHRoYXQgY29uc2lzdHMgb2YgYm90aCBj b21wb3NpdGUgYW5kIG5vbi1jb21wb3NpdGUgY29tcG9uZW50cywgbWFraW5nIHRoZSBjaG9pY2Ug b2YgY29tcG9uZW50IGltcGxlbWVudGF0aW9uIG1vcmUgdHJhbnNwYXJlbnQgdG8gdGhlIHVzZXIu PGJyPgoKPGJyPgoyLiBPbmNlIHRoZSB1c2VyIGhhcyBjb2RlZCB0aGUgZXhwcmVzc2lvbiBpbiBh IGNvbXBvc2l0ZSBjb21wb25lbnQtc3BlY2lmaWMgd2F5LCB0aGlzIGludHJvZHVjZXMgYSBkZXBl bmRlbmN5IG9uIHRoZSBmYWN0IHRoYXQgdGhlIGNvbXBvbmVudCBpbiBxdWVzdGlvbiBpcyBhIGNv bXBvc2l0ZSBjb21wb25lbnQgLSBhIGRlcGVuZGVuY3kgdGhhdCBzaG91bGRuJiMzOTt0IGJlIG5l Y2Vzc2FyeSBmb3IgdGhpcyBwYXJ0aWN1bGFyIGNhc2UuIKBTdWNoIGRlcGVuZGVuY2llcyBpbmhp Yml0IGZsZXhpYmlsaXR5LiCgSWYgaW4gdGhlIGZ1dHVyZSB0aGUgcHJvdmlkZXIgb2YgdGhlIGNv bXBvc2l0ZSBjb21wb25lbnQgZGVjaWRlcyB0byBzd2l0Y2ggdG8gYSBKYXZhLWJhc2VkIGNvbXBv bmVudCwgdGhpcyB3aWxsIGJyZWFrIGFueSBjb2RlIChvciBFTCBleHByZXNzaW9uKSB0aGF0IGFz c3VtZXMgdGhhdCB0aGUgY29tcG9uZW50IGlzIGEgY29tcG9zaXRlLiCgV2Ugc2hvdWxkIGtlZXAg c3VjaCBkZXBlbmRlbmNpZXMgdG8gYSBtaW5pbXVtLjxicj4KCjxicj4KMy4gVGhpcyBhbHNvIGlu dHJvZHVjZXMgYSBzdWJ0bGUgZGVwZW5kZW5jeSBvbiB0aGUgY29tcG9zaXRlIGNvbXBvbmVudCYj Mzk7cyBpbXBsZW1lbnRhdGlvbi4goFdoYXQgaWYgdGhlIGNvbXBvc2l0ZSBjb21wb25lbnQgaW1w bGVtZW50YXRpb24gcGFzc2VzIHRoZSBleHByZXNzaW9uIGFsb25nIHRvIHlldCBhbm90aGVyIG5l c3RlZCBjb21wb3NpdGUgY29tcG9uZW50PyCgRG9lcyB0aGUgdXNlciBub3cgbmVlZCB0byBzcGVj aWZ5IGFuIGV4cHJlc3Npb24gdGhhdCBwb3BzIG91dCBtdWx0aXBsZSBsZXZlbHMgb2YgcGFyZW50 cz88YnI+Cgo8YnI+CldoaWxlIGl0IGlzIGNlcnRhaW5seSB0cmlja2llciB0byBkZWFsIHdpdGgg ZnJvbSBhbiBpbXBsZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZSwgSSBiZWxpZXZlIHRoYXQgaXQgaXMg dmVyeSBpbXBvcnRhbnQgdGhhdCB3ZSByZS1jb25zaWRlciB0aGUgY3VycmVudCBiZWhhdmlvciBh bmQgY29uc2lkZXIgc3BlYyYjMzk7aW5nIHRoYXQgI3tjY30gZXhwcmVzc2lvbnMgYWx3YXlzIHJl c29sdmUgcmVsYXRpdmUgdG8gdGhlIGNvbnRleHQgaW4gd2hpY2ggdGhleSBhcmUgZGVmaW5lZC4g oEkgZmVlbCB0aGF0IHRoZSBjdXJyZW50IGJlaGF2aW9yIHZpb2xhdGVzIHRoZSBwcmluY2lwbGUg b2YgbGVhc3Qgc3VycHJpc2UgKGJvdGggTGluY29sbiBhbmQgSSB3ZXJlIHN1cnByaXNlZCkgYW5k IGFsc28gYnJlYWtzIGVuY2Fwc3VsYXRpb24gKGllLiBpbnRyb2R1Y2VzIGltcGxlbWVudGF0aW9u LXNwZWNpZmljIGRlcGVuZGVuY2llcykuPGJyPgoKPGJyPgpMZWF2aW5nIGFzaWRlIHF1ZXN0aW9u cyBvZiBob3cgd2UgbWlnaHQgaW1wbGVtZW50IG15IHByZWZlcnJlZCBiZWhhdmlvciBmb3IgdGhl IG1vbWVudC4uLiCgRG9lcyBhbnlvbmUgaGF2ZSBjb21tZW50cyBvbiB3aGljaCBiZWhhdmlvciBt YWtlcyBzZW5zZSBmcm9tIGEgc3BlYy9lbmQgdXNlciBwZXJzcGVjdGl2ZT88YnI+PGZvbnQgY29s b3I9IiM4ODg4ODgiPgo8YnI+CkFuZHk8YnI+Cjxicj4KPC9mb250PjwvYmxvY2txdW90ZT48L2Rp dj48YnI+Cg== --===============3410301476979734408==--