Well, if Simon's point is that Ajax should not *require* forceId then
I agree with him (or whoever is making that point.) We're not
requiring it right now but I think that is what Travis is suggesting
(with the reasoning be that you almost always want to use it anyways.)
I'm not suggesting
Simon,
There are a few very long threads on this in the archives (when
forceId first came about.) Not only is it awkward to add
form1:subview2 etc to every reference in your javascript but if you
change your JSF form structure all of your javascript needs to change
too! (NOTE: Its not always
Additionally,
the colon is a reserved character in CSS - for pseudo-selectors. You
can run into major problems with CSS and the standard client-ids.
regards,
Martin
On 11/23/05, Sean Schofield [EMAIL PROTECTED] wrote:
Simon,
There are a few very long threads on this in the archives (when
I think Simon's question is not about why forceId exists
in the first place, but why AJAX would *require* its use.
The former was discussed long ago. The latter is a new
question which deserves careful consideration.
-- Adam
On 11/23/05, Sean Schofield [EMAIL PROTECTED] wrote:
Simon,
There
I haven't used AJAX, but isn't the javascript concerned *generated* by
JSF tags? If so, the generated javascript should be able to create
document.getElementById(form1:subview2:button1)
Or is it that AJAX is commonly combined with user-provided javascript
that manipulates the same DOM
Well, if Simon's point is that Ajax should not *require* forceId then
I agree with him (or whoever is making that point.) We're not
requiring it right now but I think that is what Travis is suggesting
(with the reasoning be that you almost always want to use it anyways.)
As for why you would
Right.
I would never, ever want to force users to use forceId for working with AJAX.
So, my opinion is on record ;)
regards,
Martin
On 11/24/05, Sean Schofield [EMAIL PROTECTED] wrote:
Well, if Simon's point is that Ajax should not *require* forceId then
I agree with him (or whoever is
Is there any particular reason why you can't just use forceId=true for
when you want it? My thinking is that its better to give the user the
flexability to decide rather then force them into a particular
choice. (Which is why I think its lame that JSF alters your id when
generating the client
Sean,
IMO, the lamenesses are that UIForm is a NamingContainer,
and f:subview is required for includes. I argued strongly
against the former during JSF 1.0, but couldn't turn the tide.
The latter's been cleared up for JSF 1.2 (and despite what
the spec said, f:subview wasn't ever *really*
Yes, I can use forceId=true when I want it, but my sentiments exactly
(about altering the id), if I set an ID, it would be nice to not have
to set forceId=true also. Especially in this new rich client /
ajaxing era that we seem to be rolling into.
Thanks for the info on what's going on Adam.
Hi Travis,
I don't know anything about the AJAX compoents so please excuse me if
this is a silly question. But why are the AJAX components requiring
forceId in the first place?
If a component's true id at the back end is form1:subview2:table3,
then why not use that id in all the AJAX stuff
There are a couple reasons I went down that road,
1: at first, when trying to get things working, it was much easier to
be able to directly access the component in javascript. I wanted to
get this working without having to deal with unknown id's, and then
come back to get it working for those
Travis Reeder wrote:
Working on this ajax stuff, I got to wondering why we don't just have
id's implemented like forceId = true? Is there any reason why we
can't just have all id's set to the id the user specifies without
prepending stuff to them?
The spec allows ids to be duplicated as long
Working on this ajax stuff, I got to wondering why we don't just have
id's implemented like forceId = true? Is there any reason why we
can't just have all id's set to the id the user specifies without
prepending stuff to them?
Travis
14 matches
Mail list logo
