On 6/13/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> I'm just getting in a problem because the id doesn't support EL right now.
>
> I have a table that displays a webmail inbox.
> On each row, I have a delete this email checkbox.
>
> It works fine except that it you receive a new email before you submit your
> form, the wrong email is deleted, as the checkbox's name is based on the row
> number, and the emails have all been shifted one row down.
>
> The only solution I've found to this (and other similar) problem(s) is to
> use the email's id in the checkbox's id :
> <x:selectBooleanCheckbox id="Delete_#{email.unid}_CB"
> value="#{inboxFace.removeEmailUnid[email.unid]}"/>
>
> This doesn't work right now, but I think the only solution to this problem
> IS TO ALLOW EL in id attributes.
>
> The 1.1 & 1.2PR Spec. section 3.1.4 says that "all properties other than id
> and parent, are value binding enabled".
> But we could partialy enable it. I mean use the value binding the first
> time the component's id is used, and then freeze this value.
>
> Any thoughts ?
>
If the TCK inludes tests to verify that "id" is *not* value binding
enabled (which wouldn't surprise me since it is a stated spec
requirement), then this solution would just have to be undone again in
order to pass the tests.
An alternative appropach would be to include a hidden field in one of
the columns that contains the information you need to identify the
correct model data (the message identifier for a mailbox screen, for
example). As decoding occurs and events are fired, the value of this
hidden field (along with all the others on the current row) will have
been restored to what it was, so that if the checkbox is checked you
can go find the relevant message to update or delete.
Craig
>
> On Tue, 2005-06-07 at 22:01 +0200, Martin Marinschek wrote:
> rational explanation:
>
> a value in a value-binding can change
>
> - the unique id must stay the same over the whole lifetime of a view,
> if not, where will you post the value of an input to if its id has
> changed?
>
> regards,
>
> Martin
>
> On 6/7/05, Mike Burati <[EMAIL PROTECTED]> wrote:
> >
> > > The #{}-expression isn't evaluated in the id-attribute, why not???
> >
> > The #{} expression support for Value Binding is a runtime/request-time
> > facility.
> >
> > The id attributes are used as component identifiers, by JSF, to build up
> > a component tree with unique identifiers per naming container.
> >
> > See Section 3.1 of the JSF1.1 specification for more information on
> > component identifiers and value binding. Per the spec, the id and
> > parent are the only attributes of the UI components not enabled for
> > value binding...
> >
> >
> > **********************************
> > Michael Burati
> > Senior Software Engineer
> > Bowstreet
> > 200 Ames Pond Drive
> > Tewksbury, MA 01876
> > T 978-863-1512
> > F 978-863-1555
> > www.bowstreet.com
> >
> > Get the latest information on Bowstreet's events and web seminars.
> >
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 07, 2005 3:28 PM
> > To: MyFaces Discussion
> > Subject: Re: ForcedID is not working
> >
> > *lol*, thanks I'll give it a try ;)
> >
> > By the way: why can't I do something like <tag
> > id="category-#{node.identifier}" />
> >
> > The #{}-expression isn't evaluated in the id-attribute, why not???
> >
> > Am Dienstag, 7. Juni 2005 20:03 schrieb Korhonen, Kalle:
> > > true to
> > > guide MyFaces to leave the id as is, to whatever you've set it to.
> > > Granted, the name is misleading IMHO as well.
> >
>
>
