You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2004/12/30 15:51:49 UTC
Javascript getElementById Issues
A major stumbling block for me with JSF is how the implementations all
seem to "munge" the id attributes of my JSF tags. I'm assuming this
helps with constructing the component tree and mapping the posts to
the right components, but does it have to be this way?
Both MyFaces and the RI change the id attribute. Couldn't they just
change the name attribute? Isn't that the only thing that is sent via
POST? We have tons of javascript that use the getElementById method
and this would be a problem changing it.
I know there are some workarounds with using special tags, etc. but
that seems like a lot of trouble to avoid something that is likely a
problem for many others.
sean
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
On Thu, 30 Dec 2004 12:04:39 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > There needs to be a better way than that. Every decent JavaScript library
> > out there uses getElementById() to manipulate elements and allow people to
> > build dynamic web apps. A "solution" that requires either wrapping every
> > component usage in a proxy tag or overriding all of the components isn't
> > tenable. People building dynamic web apps are not going to adopt JSF with
> > those kinds of constraints imposed on them.
>
> I agree completely. The proxyId tag is a nice workaround for now, but
> I wouldn't view it as a long-term solution. Not only do you have to
> add unecessary complexity to your javascript (which is complex enough
> already), but now you have to add extra tags everywhere in your faces
> pages just to set the id attribute. Way too cumbersome for my tastes.
>
> > I can see why there might be issues with components inside of something
> > like a data grid. But this can be overcome by, for example, taking the id
> > provided and adding an index using a well-defined scheme, so that other
> > JavaScript code can know how to identify the relevant elements.
>
> Well said.
>
Re: Javascript getElementById Issues
Posted by Werner Punz <we...@gmx.at>.
I am not a myfaces developer
but ran into the id issue today
due to the fact that I tried to implement
a custom control.
I dont thing the myfaces should introduce its own standard
unless it does not break the specs
(isn't the id naming scheme defined in the specs)
What I could see probably, and that would be the easiest
would be a sort of helper framework/non visual control
which could do the name mapping from a given normal id
and form to the internal id.
That at least would ease the burden if you have to pass
id parameters down a javascript somehwere.
Werner
Sean Schofield wrote:
>>Could we not come up with our own standard for myfaces for the time being?
>>And hopefully the JCP will follow suit or at least make for an easy
>>transition. This is such an essential thing these days especially with
>>everyone seeing what Google is doing lately.
>>
>>
>
>That would be my vote. I would be happy to try and help with the
>coding (with my limited Faces knowledge.) I can certainly help with
>the testing and patching.
>
>I did not see anything in the 1.2 spec that addresses this issue.
>Also, the 1.2 spec is still in draft and is tied to the J2EE 5.0 spec.
> We're talking a long time until 1.2 and even longer if this isn't
>addressed in that spec (which I don't believe it is.)
>
>The only issue I see is if the spec mandates the current scheme used
>by MyFaces and RI for the id. I can't see why it would, but they both
>seem to do things in an identical way ...
>
>
>
>>Travis
>>
>>
>
>sean
>
>
>
>
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> Could we not come up with our own standard for myfaces for the time being?
> And hopefully the JCP will follow suit or at least make for an easy
> transition. This is such an essential thing these days especially with
> everyone seeing what Google is doing lately.
That would be my vote. I would be happy to try and help with the
coding (with my limited Faces knowledge.) I can certainly help with
the testing and patching.
I did not see anything in the 1.2 spec that addresses this issue.
Also, the 1.2 spec is still in draft and is tied to the J2EE 5.0 spec.
We're talking a long time until 1.2 and even longer if this isn't
addressed in that spec (which I don't believe it is.)
The only issue I see is if the spec mandates the current scheme used
by MyFaces and RI for the id. I can't see why it would, but they both
seem to do things in an identical way ...
> Travis
sean
Re: Javascript getElementById Issues
Posted by Travis Reeder <tr...@ecommstats.com>.
Could we not come up with our own standard for myfaces for the time
being? And hopefully the JCP will follow suit or at least make for an
easy transition. This is such an essential thing these days especially
with everyone seeing what Google is doing lately.
Travis
Matthias Wessendorf wrote:
>As far as I understand it,
>it should be addressed at JCP, isn't it?
>Since these guys define the standard for
>JSF.
>
>Regards,
>Matthias
>
>
>
>>-----Original Message-----
>>From: Martin Cooper [mailto:martinc@apache.org]
>>Sent: Thursday, December 30, 2004 5:58 PM
>>To: MyFaces Discussion; hborders@mail.win.org
>>Cc: Sean Schofield
>>Subject: Re: Javascript getElementById Issues
>>
>>
>>There needs to be a better way than that. Every decent
>>JavaScript library
>>out there uses getElementById() to manipulate elements and
>>allow people to
>>build dynamic web apps. A "solution" that requires either
>>wrapping every
>>component usage in a proxy tag or overriding all of the
>>components isn't
>>tenable. People building dynamic web apps are not going to
>>adopt JSF with
>>those kinds of constraints imposed on them.
>>
>>I can see why there might be issues with components inside of
>>something
>>like a data grid. But this can be overcome by, for example,
>>taking the id
>>provided and adding an index using a well-defined scheme, so
>>that other
>>JavaScript code can know how to identify the relevant elements.
>>
>>--
>>Martin Cooper
>>
>>
>>On Thu, 30 Dec 2004, Heath Borders wrote:
>>
>>
>>
>>>It really becomes a problem when you start using dataTables
>>>extensively in your applications. Since JSF is iterating over the
>>>content, you can't exactly specify an id for it (it would always be
>>>the same!). My suggestion is to use j4j's proxyId tag. It
>>>
>>>
>>basically
>>
>>
>>>allows you to define a clientId.
>>>
>>>You could also override all the default components to just
>>>
>>>
>>use their
>>
>>
>>>id as their clientId, but it would probably be quite an
>>>
>>>
>>annoyance to
>>
>>
>>>do.
>>>
>>>
>>>On Thu, 30 Dec 2004 09:51:49 -0500, Sean Schofield
>>><se...@gmail.com> wrote:
>>>
>>>
>>>>A major stumbling block for me with JSF is how the implementations
>>>>all seem to "munge" the id attributes of my JSF tags. I'm
>>>>
>>>>
>>assuming
>>
>>
>>>>this helps with constructing the component tree and
>>>>
>>>>
>>mapping the posts
>>
>>
>>>>to the right components, but does it have to be this way?
>>>>
>>>>Both MyFaces and the RI change the id attribute. Couldn't
>>>>
>>>>
>>they just
>>
>>
>>>>change the name attribute? Isn't that the only thing that is sent
>>>>via POST? We have tons of javascript that use the getElementById
>>>>method and this would be a problem changing it.
>>>>
>>>>I know there are some workarounds with using special tags,
>>>>
>>>>
>>etc. but
>>
>>
>>>>that seems like a lot of trouble to avoid something that
>>>>
>>>>
>>is likely a
>>
>>
>>>>problem for many others.
>>>>
>>>>sean
>>>>
>>>>
>>>>
>>>--
>>>-Heath Borders-Wing
>>>hborders@mail.win.org
>>>
>>>
>>>
>
>
>
>
--
Travis Reeder
Ecommstats Web Analytics
www.ecommstats.com
RE: Javascript getElementById Issues
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
As far as I understand it,
it should be addressed at JCP, isn't it?
Since these guys define the standard for
JSF.
Regards,
Matthias
> -----Original Message-----
> From: Martin Cooper [mailto:martinc@apache.org]
> Sent: Thursday, December 30, 2004 5:58 PM
> To: MyFaces Discussion; hborders@mail.win.org
> Cc: Sean Schofield
> Subject: Re: Javascript getElementById Issues
>
>
> There needs to be a better way than that. Every decent
> JavaScript library
> out there uses getElementById() to manipulate elements and
> allow people to
> build dynamic web apps. A "solution" that requires either
> wrapping every
> component usage in a proxy tag or overriding all of the
> components isn't
> tenable. People building dynamic web apps are not going to
> adopt JSF with
> those kinds of constraints imposed on them.
>
> I can see why there might be issues with components inside of
> something
> like a data grid. But this can be overcome by, for example,
> taking the id
> provided and adding an index using a well-defined scheme, so
> that other
> JavaScript code can know how to identify the relevant elements.
>
> --
> Martin Cooper
>
>
> On Thu, 30 Dec 2004, Heath Borders wrote:
>
> > It really becomes a problem when you start using dataTables
> > extensively in your applications. Since JSF is iterating over the
> > content, you can't exactly specify an id for it (it would always be
> > the same!). My suggestion is to use j4j's proxyId tag. It
> basically
> > allows you to define a clientId.
> >
> > You could also override all the default components to just
> use their
> > id as their clientId, but it would probably be quite an
> annoyance to
> > do.
> >
> >
> > On Thu, 30 Dec 2004 09:51:49 -0500, Sean Schofield
> > <se...@gmail.com> wrote:
> >> A major stumbling block for me with JSF is how the implementations
> >> all seem to "munge" the id attributes of my JSF tags. I'm
> assuming
> >> this helps with constructing the component tree and
> mapping the posts
> >> to the right components, but does it have to be this way?
> >>
> >> Both MyFaces and the RI change the id attribute. Couldn't
> they just
> >> change the name attribute? Isn't that the only thing that is sent
> >> via POST? We have tons of javascript that use the getElementById
> >> method and this would be a problem changing it.
> >>
> >> I know there are some workarounds with using special tags,
> etc. but
> >> that seems like a lot of trouble to avoid something that
> is likely a
> >> problem for many others.
> >>
> >> sean
> >>
> >
> >
> > --
> > -Heath Borders-Wing
> > hborders@mail.win.org
> >
>
Re: Javascript getElementById Issues
Posted by Martin Cooper <ma...@apache.org>.
There needs to be a better way than that. Every decent JavaScript library
out there uses getElementById() to manipulate elements and allow people to
build dynamic web apps. A "solution" that requires either wrapping every
component usage in a proxy tag or overriding all of the components isn't
tenable. People building dynamic web apps are not going to adopt JSF with
those kinds of constraints imposed on them.
I can see why there might be issues with components inside of something
like a data grid. But this can be overcome by, for example, taking the id
provided and adding an index using a well-defined scheme, so that other
JavaScript code can know how to identify the relevant elements.
--
Martin Cooper
On Thu, 30 Dec 2004, Heath Borders wrote:
> It really becomes a problem when you start using dataTables
> extensively in your applications. Since JSF is iterating over the
> content, you can't exactly specify an id for it (it would always be
> the same!). My suggestion is to use j4j's proxyId tag. It basically
> allows you to define a clientId.
>
> You could also override all the default components to just use their
> id as their clientId, but it would probably be quite an annoyance to
> do.
>
>
> On Thu, 30 Dec 2004 09:51:49 -0500, Sean Schofield
> <se...@gmail.com> wrote:
>> A major stumbling block for me with JSF is how the implementations all
>> seem to "munge" the id attributes of my JSF tags. I'm assuming this
>> helps with constructing the component tree and mapping the posts to
>> the right components, but does it have to be this way?
>>
>> Both MyFaces and the RI change the id attribute. Couldn't they just
>> change the name attribute? Isn't that the only thing that is sent via
>> POST? We have tons of javascript that use the getElementById method
>> and this would be a problem changing it.
>>
>> I know there are some workarounds with using special tags, etc. but
>> that seems like a lot of trouble to avoid something that is likely a
>> problem for many others.
>>
>> sean
>>
>
>
> --
> -Heath Borders-Wing
> hborders@mail.win.org
>
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
It really becomes a problem when you start using dataTables
extensively in your applications. Since JSF is iterating over the
content, you can't exactly specify an id for it (it would always be
the same!). My suggestion is to use j4j's proxyId tag. It basically
allows you to define a clientId.
You could also override all the default components to just use their
id as their clientId, but it would probably be quite an annoyance to
do.
On Thu, 30 Dec 2004 09:51:49 -0500, Sean Schofield
<se...@gmail.com> wrote:
> A major stumbling block for me with JSF is how the implementations all
> seem to "munge" the id attributes of my JSF tags. I'm assuming this
> helps with constructing the component tree and mapping the posts to
> the right components, but does it have to be this way?
>
> Both MyFaces and the RI change the id attribute. Couldn't they just
> change the name attribute? Isn't that the only thing that is sent via
> POST? We have tons of javascript that use the getElementById method
> and this would be a problem changing it.
>
> I know there are some workarounds with using special tags, etc. but
> that seems like a lot of trouble to avoid something that is likely a
> problem for many others.
>
> sean
>
--
-Heath Borders-Wing
hborders@mail.win.org
Why component family
Posted by niksa_os <ni...@hotmail.com>.
Why component family?
What is it?
Re: Javascript getElementById Issues
Posted by Martin Marinschek <ma...@gmail.com>.
I believe almost all components are available in an extended version
(due to several enhancements in MyFaces), so that shouldn't be to big
a problem.
regards,
Martin
On Sat, 1 Jan 2005 13:01:32 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > Yes, Myfaces would still be following the spec for the behavior of
> > components if we did this. However, we could only do this on our
> > extended component set, rather than the default set of components.
> > This is because the components under the javax.faces.component.html
> > package are part of the API, so we can't alter their behavior.
>
> So this means that you cannot change the functionality of
> <h:inputText> for instance? If so, that's a bit of a bummer but not
> the end of the world.
>
> I suppose MyFaces could provide "extended" components for everything
> (including <h:inputText>) and just provide this functionality. Would
> that be the plan? Its my understanding that there is not currently an
> extended myfaces version for every component. Would it be hard to
> provide 100% coverage (even if the only enhancemtn was styleId?)
>
> The one drawback to not modifying the implentation of the standard
> components is that you are kind of locking yourself into myfaces. Not
> really a huge deal I suppose because you could always use a
> refactoring tool to replace references to <myfaces:inputText> to
> <h:inputText> if the spec were ever to address this issue.
>
> sean
>
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> Yes, Myfaces would still be following the spec for the behavior of
> components if we did this. However, we could only do this on our
> extended component set, rather than the default set of components.
> This is because the components under the javax.faces.component.html
> package are part of the API, so we can't alter their behavior.
So this means that you cannot change the functionality of
<h:inputText> for instance? If so, that's a bit of a bummer but not
the end of the world.
I suppose MyFaces could provide "extended" components for everything
(including <h:inputText>) and just provide this functionality. Would
that be the plan? Its my understanding that there is not currently an
extended myfaces version for every component. Would it be hard to
provide 100% coverage (even if the only enhancemtn was styleId?)
The one drawback to not modifying the implentation of the standard
components is that you are kind of locking yourself into myfaces. Not
really a huge deal I suppose because you could always use a
refactoring tool to replace references to <myfaces:inputText> to
<h:inputText> if the spec were ever to address this issue.
sean
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
I think its called styleId because the html "id" attribute was
originally used for CSS, not just to uniquely identify an element.
Yes, Myfaces would still be following the spec for the behavior of
components if we did this. However, we could only do this on our
extended component set, rather than the default set of components.
This is because the components under the javax.faces.component.html
package are part of the API, so we can't alter their behavior.
For our components, we should probably say that if the user enters
both an "id" and a "styleId" then we should throw an
IllegalStateException since it would be a bit confusing which clientId
should be generated (either the id's of all the parent
namingContainers strung together + the id, or just the styleId).
On Sat, 1 Jan 2005 12:18:21 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > No, it is only used for uniqueness on the client-side. Component tree
> > doesn't require unique id's. Id's must only be unique beneath a given
> > NamingContainer.
>
> So if MyFaces were to continue to generate this guaranteed unique id
> by default it would still be observing the spec right? This would
> just give the user the option to specify their own id if they didn't
> care or wanted to handle the uniqueness themselves. I am right here?
>
> Also, styleId would be more familiar to Struts users although
> personally I always found the use of the name confusing.
>
> sean
>
--
-Heath Borders-Wing
hborders@mail.win.org
On Sat, 1 Jan 2005 09:22:39 -0800 (PST), Ray Clark <rc...@yahoo.com> wrote:
> I always found styleId confusing also. But for myFaces it can't be id, it
> has to be something else, so styleId makes sense. This is a fantastic idea.
>
> Also, implementing the <p> tag and the <div> tag are great ideas as well.
>
> Thanks all,
> Ray
>
> Sean Schofield <se...@gmail.com> wrote:
>
> > No, it is only used for uniqueness on the client-side. Component tree
> > doesn't require unique id's. Id's must only be unique beneath a given
> > NamingContainer.
>
> So if MyFaces were to continue to generate this guaranteed unique id
> by default it would still be observing the spec right? This would
> just give the user the option to specify their own id if they didn't
> care or wanted to handle the uniqueness themselves. I am right here?
>
> Also, styleId would be more familiar to Struts users although
> personally I always found the use of the name confusing.
>
> sean
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Javascript getElementById Issues
Posted by Ray Clark <rc...@yahoo.com>.
I always found styleId confusing also. But for myFaces it can't be id, it has to be something else, so styleId makes sense. This is a fantastic idea.
Also, implementing the <p> tag and the <div> tag are great ideas as well.
Thanks all,
Ray
Sean Schofield <se...@gmail.com> wrote:
> No, it is only used for uniqueness on the client-side. Component tree
> doesn't require unique id's. Id's must only be unique beneath a given
> NamingContainer.
So if MyFaces were to continue to generate this guaranteed unique id
by default it would still be observing the spec right? This would
just give the user the option to specify their own id if they didn't
care or wanted to handle the uniqueness themselves. I am right here?
Also, styleId would be more familiar to Struts users although
personally I always found the use of the name confusing.
sean
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> No, it is only used for uniqueness on the client-side. Component tree
> doesn't require unique id's. Id's must only be unique beneath a given
> NamingContainer.
So if MyFaces were to continue to generate this guaranteed unique id
by default it would still be observing the spec right? This would
just give the user the option to specify their own id if they didn't
care or wanted to handle the uniqueness themselves. I am right here?
Also, styleId would be more familiar to Struts users although
personally I always found the use of the name confusing.
sean
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
I'll have to wait until monday to get an answer on where exactly the
convertClientId method is used.
As for the interface:
For HTML, we have to ensure that all clientIds are unique. This is
achieved through the spec by requiring that all id's are unique under
a namincontainer, and all clientIds correspond to
PARENT_NAMING_CONTAINER_CLIENT_ID + ":" + id. This makes all
clientIds unique. If the user is allowed to step ourside of this
automated process, we need to register all clientIds with the
UIViewRoot, and check that the directId hasn't already been specified
before returning it (if it has been specified, we would throw an
Exception). This ensures that the HTML doesn't get into an
inconsistent state (multiple HTML elements with the same id (JSF
clientId)).
On Sun, 2 Jan 2005 21:42:31 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > All renderers have a method "convertClientId" which we could override
> > in our renderers to output whatever clientId we want.
>
> I was just wondering about this method in the Renderer interface...
> When exactly is this called? I couldn't find anything substantial
> about it in the spec. It seems like it is supposed to be called from
> the getClientId() method of UIComponentBase (at least that is how
> MyFaces implementation is working.)
>
> Perhaps this would be easier than modifying the clientId manually in
> the appropriate renderer code. We would still need a directId
> attribute right? If I understand your idea, you are suggesting that
> we implement the direct id behavior through getClientId instead of
> encode() and decode() right? If so, that makes sense. (Unless we are
> abusing the intended purpose of this method for some way.)
>
> > In order to have this functionality, we might want to have an
> > interface for clientId uniqueness that an extended UIViewRoot could
> > implement.
>
> Not sure what you mean by this. Could you elaborate? (I'm also fuzzy
> on the requirements for uniqueness both in JSF and XHTML).
>
> sean
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> All renderers have a method "convertClientId" which we could override
> in our renderers to output whatever clientId we want.
I was just wondering about this method in the Renderer interface...
When exactly is this called? I couldn't find anything substantial
about it in the spec. It seems like it is supposed to be called from
the getClientId() method of UIComponentBase (at least that is how
MyFaces implementation is working.)
Perhaps this would be easier than modifying the clientId manually in
the appropriate renderer code. We would still need a directId
attribute right? If I understand your idea, you are suggesting that
we implement the direct id behavior through getClientId instead of
encode() and decode() right? If so, that makes sense. (Unless we are
abusing the intended purpose of this method for some way.)
> In order to have this functionality, we might want to have an
> interface for clientId uniqueness that an extended UIViewRoot could
> implement.
Not sure what you mean by this. Could you elaborate? (I'm also fuzzy
on the requirements for uniqueness both in JSF and XHTML).
sean
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
Yes, I was aware of the no-duplicate id dependency.
That's why I was saying that we would want to register styleId's with
the view to ensure that we don't have duplicates. Obviously, if you
defined a styleId on a component in a UIData, it would have to fail
for the same reason that defining an id would fail.
However, here's another avenue to explore:
All renderers have a method "convertClientId" which we could override
in our renderers to output whatever clientId we want.
In order to have this functionality, we might want to have an
interface for clientId uniqueness that an extended UIViewRoot could
implement.
On Sun, 2 Jan 2005 14:48:08 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Sat, 1 Jan 2005 10:56:40 -0600, Heath Borders
> <he...@gmail.com> wrote:
> > No, it is only used for uniqueness on the client-side. Component tree
> > doesn't require unique id's. Id's must only be unique beneath a given
> > NamingContainer.
>
> Actually, there *is* an important server side use of the clientId
> value -- it also becomes the name of the request parameter used to
> decode the values of submitted input fields. Indeed, this is why the
> decode and encode functionality was merged into a single API
> (Renderer) -- only the code that emits the "id" attribute knows what
> the name of the corresponding request parameter will be.
>
> You should also note that, even if you added something like "directId"
> on the MyFaces extended components, using such a component would fail
> inside a UIData (or any similar component) that renders more than one
> element from the same component -- the fact that the standard
> components use clientId is what lets UIData get involved in the id
> assignment process (since UIData is itself a naming container).
>
> Craig
>
> > On Sat, 1 Jan 2005 06:31:12 -0800 (PST), Ray Clark <rc...@yahoo.com> wrote:
> > > Is the clientId in the component used for anything
> > > other than generating uniqueness for the client side
> > > tag? Is it used on the server side in the processing
> > > of the component tree?
> > >
> > > Thanks,
> > > Ray
> > >
> > > --- Heath Borders <he...@gmail.com> wrote:
> > >
> > > > I'm in favor of doing this, though I don't think
> > > > I'll have much time
> > > > at work to dedicate to it since we're not really
> > > > aching for the
> > > > change. If I get some time, I'll try to do
> > > > something, but I can't
> > > > really commit to it.
> > > >
> > > >
> > > > On Fri, 31 Dec 2004 11:59:15 -0800, Craig McClanahan
> > > > <cr...@gmail.com> wrote:
> > > > > If you wanted to be more familiar to Struts users,
> > > > you might consider
> > > > > using "styleId" instead ... that's the attribute
> > > > all the Struts HTML
> > > > > tags use to specify the "id" attribute to be
> > > > emitted.
> > > > >
> > > > > Craig
> > > > >
> > > > > On Fri, 31 Dec 2004 14:47:55 -0500, Sean Schofield
> > > > > <se...@gmail.com> wrote:
> > > > > > > A possible solution would be to implement
> > > > direct id's (that is any id
> > > > > > > specified in the JSP translates into the same
> > > > client id) in the
> > > > > > > MyFaces extended components.
> > > > > > >
> > > > > > > We could provide a separate attribute on all
> > > > extended components
> > > > > > > called "directId". If specified, directId
> > > > would be both the id and
> > > > > > > the clientId. In order to ensure uniqueness,
> > > > we would have to have
> > > > > > > all components register their directId's with
> > > > the view root.
> > > > > > >
> > > > > > > This would allow backwards compatibility with
> > > > existing code and allow
> > > > > > > easy direct access to the clientId from the
> > > > JSP without a separate
> > > > > > > tag.
> > > > > >
> > > > > > That would be an extremely welcome enhancement.
> > > > Although I imagine it
> > > > > > would take a bit of work to get it done :-)
> > > > > >
> > > > > > > -Heath Borders-Wing
> > > > > >
> > > > > > sean
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > -Heath Borders-Wing
> > > > hborders@mail.win.org
> > > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > The all-new My Yahoo! - What will yours do?
> > > http://my.yahoo.com
> > >
> >
> > --
> > -Heath Borders-Wing
> > hborders@mail.win.org
> >
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Javascript getElementById Issues
Posted by Travis Reeder <tr...@ecommstats.com>.
+1
Heath Borders wrote:
>Its clear that there are two different ways that we could possibly
>need better id support, and that's why we should develop #2 and #3
>together.
>
>#2 supports legacy code.
>
>#3 supports new code.
>
>#1 (do nothing) can obviously still exist. If people want to totally
>ignore these features, that's fine. Let Darwin decide, as Craig said.
>
>
>On Mon, 3 Jan 2005 08:09:37 -0800 (PST), Martin Cooper
><ma...@apache.org> wrote:
>
>
>>On Mon, 3 Jan 2005, Martin Marinschek wrote:
>>
>>
>>
>>>well, what I meant is that in fact the html is almost completely
>>>generated in the JSF case, so there usually is so much change in the
>>>structure and layout of the HTML code that you almost certainly need
>>>to rewrite large portions of your javascript anyways; fine though if
>>>that is not true in your case ...
>>>
>>>
>>Consider the case in which I want to create a set of JSF components that
>>essentially wrap the widgets from an existing JavaScript framework, to
>>make them easier to use in a JSF environment. The JavaScript framework
>>almost certainly wants a great deal of control over the resulting HTML.
>>Changing the JavaScript framework so that it can be made to work with JSF
>>isn't something that's likely to happen, since (a) the people developing
>>the framework and the people wrapping widgets in JSF components are not
>>likely to be the same people, and (b) the changes would quite possibly
>>break existing uses of the framework.
>>
>>--
>>Martin Cooper
>>
>>
>>
>>
>>>you find the usage for the jsValueChangeListener component in the
>>>examples section of the myfaces example webapp, plus I wrote an e-mail
>>>about that not too long ago (should be available somewhere in the
>>>archive).
>>>
>>>regards,
>>>
>>>Martin
>>>
>>>
>>>On Mon, 3 Jan 2005 09:12:27 -0500, Sean Schofield
>>><se...@gmail.com> wrote:
>>>
>>>
>>>>>moving your web-application from one framework to another though will
>>>>>always include some handling of javascript/html, so I wouldn't weigh
>>>>>that in too much.
>>>>>
>>>>>
>>>>I'm not so sure about that. Maybe you change a few pieces of
>>>>javascript (like when switching to Struts maybe you open a window with
>>>>foo.do instead of foo.jsp) but you shouldn't have to change huge
>>>>portions of it.
>>>>
>>>>The end result of any web application is HTML. If you switch to
>>>>faces, why should you have to rewrite all of your javascript? Why
>>>>should it matter to the person who wrote the javascript that you are
>>>>now producing your HTML in a new way?
>>>>
>>>>
>>>>
>>>>
>>>>>if you have a problem with that, you will need to implement something
>>>>>coming close to a direct id (or having someone doing that for you ;)
>>>>>
>>>>>
>>>>I definitely have a problem with that (as you have probably guessed.)
>>>>And I've been following discussions elsewhere about this, and I am
>>>>definitely not alone. I say we fix it as long as there are more than
>>>>a few people affected negatively by this constraint (and as long as
>>>>the fix does not ruin things for everyone else.)
>>>>
>>>>
>>>>
>>>>>what about my other suggestion?
>>>>>
>>>>>
>>>>I'm not familiar with jsValueChange listener (although it sounds
>>>>interesting.) I didn't see it on the component page of the website,
>>>>so I will try to find out something from the source code when I get
>>>>home (no external CVS here at work.)
>>>>
>>>>
>>>>
>>>>>Martin
>>>>>
>>>>>
>>>>sean
>>>>
>>>>
>>>>
>>>>
>
>
>
>
--
Travis Reeder
Ecommstats Web Analytics
www.ecommstats.com
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
Its clear that there are two different ways that we could possibly
need better id support, and that's why we should develop #2 and #3
together.
#2 supports legacy code.
#3 supports new code.
#1 (do nothing) can obviously still exist. If people want to totally
ignore these features, that's fine. Let Darwin decide, as Craig said.
On Mon, 3 Jan 2005 08:09:37 -0800 (PST), Martin Cooper
<ma...@apache.org> wrote:
>
>
> On Mon, 3 Jan 2005, Martin Marinschek wrote:
>
> > well, what I meant is that in fact the html is almost completely
> > generated in the JSF case, so there usually is so much change in the
> > structure and layout of the HTML code that you almost certainly need
> > to rewrite large portions of your javascript anyways; fine though if
> > that is not true in your case ...
>
> Consider the case in which I want to create a set of JSF components that
> essentially wrap the widgets from an existing JavaScript framework, to
> make them easier to use in a JSF environment. The JavaScript framework
> almost certainly wants a great deal of control over the resulting HTML.
> Changing the JavaScript framework so that it can be made to work with JSF
> isn't something that's likely to happen, since (a) the people developing
> the framework and the people wrapping widgets in JSF components are not
> likely to be the same people, and (b) the changes would quite possibly
> break existing uses of the framework.
>
> --
> Martin Cooper
>
>
> > you find the usage for the jsValueChangeListener component in the
> > examples section of the myfaces example webapp, plus I wrote an e-mail
> > about that not too long ago (should be available somewhere in the
> > archive).
> >
> > regards,
> >
> > Martin
> >
> >
> > On Mon, 3 Jan 2005 09:12:27 -0500, Sean Schofield
> > <se...@gmail.com> wrote:
> >>> moving your web-application from one framework to another though will
> >>> always include some handling of javascript/html, so I wouldn't weigh
> >>> that in too much.
> >>
> >> I'm not so sure about that. Maybe you change a few pieces of
> >> javascript (like when switching to Struts maybe you open a window with
> >> foo.do instead of foo.jsp) but you shouldn't have to change huge
> >> portions of it.
> >>
> >> The end result of any web application is HTML. If you switch to
> >> faces, why should you have to rewrite all of your javascript? Why
> >> should it matter to the person who wrote the javascript that you are
> >> now producing your HTML in a new way?
> >>
> >>
> >>> if you have a problem with that, you will need to implement something
> >>> coming close to a direct id (or having someone doing that for you ;)
> >>
> >> I definitely have a problem with that (as you have probably guessed.)
> >> And I've been following discussions elsewhere about this, and I am
> >> definitely not alone. I say we fix it as long as there are more than
> >> a few people affected negatively by this constraint (and as long as
> >> the fix does not ruin things for everyone else.)
> >>
> >>> what about my other suggestion?
> >>
> >> I'm not familiar with jsValueChange listener (although it sounds
> >> interesting.) I didn't see it on the component page of the website,
> >> so I will try to find out something from the source code when I get
> >> home (no external CVS here at work.)
> >>
> >>> Martin
> >>
> >> sean
> >>
> >>
> >
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> Consider the case in which I want to create a set of JSF components that
> essentially wrap the widgets from an existing JavaScript framework, to
> make them easier to use in a JSF environment. The JavaScript framework
> almost certainly wants a great deal of control over the resulting HTML.
> Changing the JavaScript framework so that it can be made to work with JSF
> isn't something that's likely to happen, since (a) the people developing
> the framework and the people wrapping widgets in JSF components are not
> likely to be the same people, and (b) the changes would quite possibly
> break existing uses of the framework.
This is a good counter example. I don't currently rely on my
framework (Struts) to generate the javascript. With faces, however,
this would make much more sense. And so yes, for those components
that are generating javascript via the framework (say using
UIComponent.getClientId() as Craig suggested), those will allways
have to be refactored when you switch frameworks.
So that is a good example of where you would not need to use directId.
As Heath points out in this case, just go with option #1 (do
nothing.) You can just use UIComponent.getClientId() in your encode
method when generating the javascript and there are no issues.
If this is how you generate the bulk of your javascript, then I can
see why one wouldn't think this is an issue. For those of us who do
not require dynamically generated javascript all of the time, this
will be a big problem.
> Martin Cooper
sean
Re: Javascript getElementById Issues
Posted by Martin Cooper <ma...@apache.org>.
On Mon, 3 Jan 2005, Martin Marinschek wrote:
> well, what I meant is that in fact the html is almost completely
> generated in the JSF case, so there usually is so much change in the
> structure and layout of the HTML code that you almost certainly need
> to rewrite large portions of your javascript anyways; fine though if
> that is not true in your case ...
Consider the case in which I want to create a set of JSF components that
essentially wrap the widgets from an existing JavaScript framework, to
make them easier to use in a JSF environment. The JavaScript framework
almost certainly wants a great deal of control over the resulting HTML.
Changing the JavaScript framework so that it can be made to work with JSF
isn't something that's likely to happen, since (a) the people developing
the framework and the people wrapping widgets in JSF components are not
likely to be the same people, and (b) the changes would quite possibly
break existing uses of the framework.
--
Martin Cooper
> you find the usage for the jsValueChangeListener component in the
> examples section of the myfaces example webapp, plus I wrote an e-mail
> about that not too long ago (should be available somewhere in the
> archive).
>
> regards,
>
> Martin
>
>
> On Mon, 3 Jan 2005 09:12:27 -0500, Sean Schofield
> <se...@gmail.com> wrote:
>>> moving your web-application from one framework to another though will
>>> always include some handling of javascript/html, so I wouldn't weigh
>>> that in too much.
>>
>> I'm not so sure about that. Maybe you change a few pieces of
>> javascript (like when switching to Struts maybe you open a window with
>> foo.do instead of foo.jsp) but you shouldn't have to change huge
>> portions of it.
>>
>> The end result of any web application is HTML. If you switch to
>> faces, why should you have to rewrite all of your javascript? Why
>> should it matter to the person who wrote the javascript that you are
>> now producing your HTML in a new way?
>>
>>
>>> if you have a problem with that, you will need to implement something
>>> coming close to a direct id (or having someone doing that for you ;)
>>
>> I definitely have a problem with that (as you have probably guessed.)
>> And I've been following discussions elsewhere about this, and I am
>> definitely not alone. I say we fix it as long as there are more than
>> a few people affected negatively by this constraint (and as long as
>> the fix does not ruin things for everyone else.)
>>
>>> what about my other suggestion?
>>
>> I'm not familiar with jsValueChange listener (although it sounds
>> interesting.) I didn't see it on the component page of the website,
>> so I will try to find out something from the source code when I get
>> home (no external CVS here at work.)
>>
>>> Martin
>>
>> sean
>>
>>
>
Re: Javascript getElementById Issues
Posted by Martin Marinschek <ma...@gmail.com>.
well, what I meant is that in fact the html is almost completely
generated in the JSF case, so there usually is so much change in the
structure and layout of the HTML code that you almost certainly need
to rewrite large portions of your javascript anyways; fine though if
that is not true in your case ...
you find the usage for the jsValueChangeListener component in the
examples section of the myfaces example webapp, plus I wrote an e-mail
about that not too long ago (should be available somewhere in the
archive).
regards,
Martin
On Mon, 3 Jan 2005 09:12:27 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > moving your web-application from one framework to another though will
> > always include some handling of javascript/html, so I wouldn't weigh
> > that in too much.
>
> I'm not so sure about that. Maybe you change a few pieces of
> javascript (like when switching to Struts maybe you open a window with
> foo.do instead of foo.jsp) but you shouldn't have to change huge
> portions of it.
>
> The end result of any web application is HTML. If you switch to
> faces, why should you have to rewrite all of your javascript? Why
> should it matter to the person who wrote the javascript that you are
> now producing your HTML in a new way?
>
>
> > if you have a problem with that, you will need to implement something
> > coming close to a direct id (or having someone doing that for you ;)
>
> I definitely have a problem with that (as you have probably guessed.)
> And I've been following discussions elsewhere about this, and I am
> definitely not alone. I say we fix it as long as there are more than
> a few people affected negatively by this constraint (and as long as
> the fix does not ruin things for everyone else.)
>
> > what about my other suggestion?
>
> I'm not familiar with jsValueChange listener (although it sounds
> interesting.) I didn't see it on the component page of the website,
> so I will try to find out something from the source code when I get
> home (no external CVS here at work.)
>
> > Martin
>
> sean
>
>
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
Both #2 and #3 will provide solutions to this problem.
For #2, you can just give all the components you need the proper
styleIds and then you can access them from wherever you want.
For #3, you have to pass all of the components as parameters to the
<x:script /> tag, but you can still pass in as many as you'd like.
On Tue, 4 Jan 2005 05:49:23 -0800 (PST), Ray Clark <rc...@yahoo.com> wrote:
> I haven't had time to fully catch up on this thread, so I hope I am not
> stating something that has already been said.
>
> My problem/concern about any JavaScript solution is cross field JavaScript.
> I need the ability with any of these solutions to manipulate a different
> element from the one that called the JavaScript funtion. For instance, I
> have an onChange event for 1 element change the HTML/CSS of another element.
> Or what about a JavaScript that gets called on page submit to do something.
> There absolutely has to be a way to easily get the id of elements other
> than the one that invoked the function. So just having the component pass
> in a reference to the element to the function won't satisfy my needs.
>
> I'm sure all of you are aware of this. I just wanted to stress the point
> one more time.
>
> I appreciate all of the effort and thought for this. This IS an issue that
> people here would use to discourage the use of JSF.
>
> Thanks,
> Ray
>
> Sean Schofield <se...@gmail.com> wrote:
> > The whole point of using something like
> > JSF is that you are moving away from writing direct html code. In the long
> > run, every single thing on your page should be a JSF component, including
> > the script portions.
>
> I don't see myself writing all of my javascript via components anytime
> soon. IMO this would be overkill. Javascript is already difficult to
> maintain and follow, why add more complexity if you can avoid it?
>
> Yes I can envision myself starting to write more of the javascript in
> components now that faces is here. Certainly not all of it and not
> until I decide to switch my project to JSF (and even then, I will be
> converting a little bit at a time)
>
> > I think the should be used even if it
> > doesn't do anything other than output a
>
> ________________________________
> Do you Yahoo!?
> Yahoo! Mail - Find what you need with new enhanced search. Learn more.
>
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Javascript getElementById Issues
Posted by Ray Clark <rc...@yahoo.com>.
I haven't had time to fully catch up on this thread, so I hope I am not stating something that has already been said.
My problem/concern about any JavaScript solution is cross field JavaScript. I need the ability with any of these solutions to manipulate a different element from the one that called the JavaScript funtion. For instance, I have an onChange event for 1 element change the HTML/CSS of another element. Or what about a JavaScript that gets called on page submit to do something. There absolutely has to be a way to easily get the id of elements other than the one that invoked the function. So just having the component pass in a reference to the element to the function won't satisfy my needs.
I'm sure all of you are aware of this. I just wanted to stress the point one more time.
I appreciate all of the effort and thought for this. This IS an issue that people here would use to discourage the use of JSF.
Thanks,
Ray
Sean Schofield <se...@gmail.com> wrote:
> The whole point of using something like
> JSF is that you are moving away from writing direct html code. In the long
> run, every single thing on your page should be a JSF component, including
> the script portions.
I don't see myself writing all of my javascript via components anytime
soon. IMO this would be overkill. Javascript is already difficult to
maintain and follow, why add more complexity if you can avoid it?
Yes I can envision myself starting to write more of the javascript in
components now that faces is here. Certainly not all of it and not
until I decide to switch my project to JSF (and even then, I will be
converting a little bit at a time)
> I think the should be used even if it
> doesn't do anything other than output a tag. Switching to faces
> would definitely require some reworking of your javascript since the whole
> presentation paradigm has changed. That is why I prefer option #3 the most
> since it seems the most flexible and is more component oriented. It may not
> seem like the easiest thing because you have to change the way you've been
> writing your javascript, but you've also had to change the way you're
> writing your entire application.
Earlier you said "+1". What was that in reference to? Option #3 or
the combined Option #2 and Option#3 approach?
I'd like to get started on some of the Option#2 stuff but I'll need
someone to commit the patches. Also, I want to make sure that at a
minimum there are no strong objections (even if there are some who
don't feel its a big deal.) I'm willing to the work (with help from
you guys when I'm stuck) and I think it will make it much easier for
people to migrate to faces.
> And it's not exactly rewriting your javascript, it's only changing how you
> get references to the components on the page.
True, but a lot of time went into writing and debugging that
javascript. Why would I want to deal with this when there will be
other more substantive things to focus on when migrating to JSF?
> T
sean
---------------------------------
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search. Learn more.
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> The whole point of using something like
> JSF is that you are moving away from writing direct html code. In the long
> run, every single thing on your page should be a JSF component, including
> the script portions.
I don't see myself writing all of my javascript via components anytime
soon. IMO this would be overkill. Javascript is already difficult to
maintain and follow, why add more complexity if you can avoid it?
Yes I can envision myself starting to write more of the javascript in
components now that faces is here. Certainly not all of it and not
until I decide to switch my project to JSF (and even then, I will be
converting a little bit at a time)
> I think the <x:script> should be used even if it
> doesn't do anything other than output a <script> tag. Switching to faces
> would definitely require some reworking of your javascript since the whole
> presentation paradigm has changed. That is why I prefer option #3 the most
> since it seems the most flexible and is more component oriented. It may not
> seem like the easiest thing because you have to change the way you've been
> writing your javascript, but you've also had to change the way you're
> writing your entire application.
Earlier you said "+1". What was that in reference to? Option #3 or
the combined Option #2 and Option#3 approach?
I'd like to get started on some of the Option#2 stuff but I'll need
someone to commit the patches. Also, I want to make sure that at a
minimum there are no strong objections (even if there are some who
don't feel its a big deal.) I'm willing to the work (with help from
you guys when I'm stuck) and I think it will make it much easier for
people to migrate to faces.
> And it's not exactly rewriting your javascript, it's only changing how you
> get references to the components on the page.
True, but a lot of time went into writing and debugging that
javascript. Why would I want to deal with this when there will be
other more substantive things to focus on when migrating to JSF?
> T
sean
Re: Javascript getElementById Issues
Posted by Travis Reeder <tr...@ecommstats.com>.
Sean Schofield wrote:
>>moving your web-application from one framework to another though will
>>always include some handling of javascript/html, so I wouldn't weigh
>>that in too much.
>>
>>
>
>I'm not so sure about that. Maybe you change a few pieces of
>javascript (like when switching to Struts maybe you open a window with
>foo.do instead of foo.jsp) but you shouldn't have to change huge
>portions of it.
>
>The end result of any web application is HTML. If you switch to
>faces, why should you have to rewrite all of your javascript? Why
>should it matter to the person who wrote the javascript that you are
>now producing your HTML in a new way?
>
>
The whole point of using something like JSF is that you are moving away
from writing direct html code. In the long run, every single thing on
your page should be a JSF component, including the script portions. I
think the <x:script> should be used even if it doesn't do anything other
than output a <script> tag. Switching to faces would definitely require
some reworking of your javascript since the whole presentation paradigm
has changed. That is why I prefer option #3 the most since it seems the
most flexible and is more component oriented. It may not seem like the
easiest thing because you have to change the way you've been writing
your javascript, but you've also had to change the way you're writing
your entire application.
And it's not exactly rewriting your javascript, it's only changing how
you get references to the components on the page.
T
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> moving your web-application from one framework to another though will
> always include some handling of javascript/html, so I wouldn't weigh
> that in too much.
I'm not so sure about that. Maybe you change a few pieces of
javascript (like when switching to Struts maybe you open a window with
foo.do instead of foo.jsp) but you shouldn't have to change huge
portions of it.
The end result of any web application is HTML. If you switch to
faces, why should you have to rewrite all of your javascript? Why
should it matter to the person who wrote the javascript that you are
now producing your HTML in a new way?
> if you have a problem with that, you will need to implement something
> coming close to a direct id (or having someone doing that for you ;)
I definitely have a problem with that (as you have probably guessed.)
And I've been following discussions elsewhere about this, and I am
definitely not alone. I say we fix it as long as there are more than
a few people affected negatively by this constraint (and as long as
the fix does not ruin things for everyone else.)
> what about my other suggestion?
I'm not familiar with jsValueChange listener (although it sounds
interesting.) I didn't see it on the component page of the website,
so I will try to find out something from the source code when I get
home (no external CVS here at work.)
> Martin
sean
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> an easy solution for 2:
>
> In fact you can always use the id - if you set the id of the naming
> containers, you know what your client-id will look like - and you can
> easily change your javascript functions to use that (I admit a little
> longer) id.
I don't think your solution addresses some of the stickier issues I
pointed out. (http://www.mail-archive.com/myfaces-user%40incubator.apache.org/msg00746.html).
If it does, can you help me to understand how it would? Do you agree
with my reasoning on this?
> Martin
sean
Re: Javascript getElementById Issues
Posted by Martin Marinschek <ma...@gmail.com>.
As to the three proposals:
I personally would deliver both 2 and 3, the proposal number 2 does
have problems though, Craig has pointed them out...
an easy solution for 2:
In fact you can always use the id - if you set the id of the naming
containers, you know what your client-id will look like - and you can
easily change your javascript functions to use that (I admit a little
longer) id.
an easy solution for 3:
what about using the tags I recently invented for MyFaces?
jsValueChangeListener could easily be extended to be callable on any
javascript event; you can call any java-script method from the value
changed expression and can pass the id of the component you want to
change; solves at least the event handler problems; and your
javascript stays independent of any one id (better for code reuse
anyways)...
regards,
Martin
On Sun, 2 Jan 2005 23:34:06 -0600, Heath Borders
<he...@gmail.com> wrote:
> The <x:script> doesn't HAVE to drop variables into the global
> namespace. It depends upon how it is used. In the example I gave,
> there are two affected namespaces: that of the <x:script> tag and that
> of the enableOrNot() function. Of course, the <x:script> tag is
> powerful enough to allow for additions to the global namespace thusly:
>
> <h:inputText id="myInputText" value="#{bean.value}" />
> <x:script>
> <x:scriptParameter for="myInputText" id="p_myInputText" />
> var inputText = document.getElementById('p_myInputText');
> </x:script>
>
> This would therefore add "inputText" into the global namespace.
>
> I realize that the j4j tag already basically solves this problem, but
> I think that this tag is a more graceful solution that would be easy
> to implement.
>
> On Sun, 2 Jan 2005 20:34:28 -0800 (PST), Martin Cooper
> <ma...@apache.org> wrote:
> >
> >
> > On Sun, 2 Jan 2005, Sean Schofield wrote:
> >
> > >> What the <x:script> tag would have to do is search its body content
> > >> for ids specified in the <x:scriptParameter> tag and replace them with
> > >> the clientId's of the components specified in the
> > >> <x:scriptParameter>'s "for" attribute.
> > >>
> > >> Thoughts?
> > >
> > > I'm personally not too wild about this. Why do we want to subject the
> > > user to all of this extra coding? Its one thing if there is no other
> > > way, but it seems like we have another way (your suggestion of
> > > overriding convertClienttId() method.) This idea has some
> > > possibilities but it strikes me as not much of an improvement over the
> > > "proxy tag" idea that has been developed.
> > >
> > > Out of curiousity, are you leaning in favor of or against the directId
> > > attribute? I detect three distinct ideas here...
> > >
> > > #1) This is not much of a problem - do nothing
> > > #2) Allow user to specify directId/styleId attribute
> > > #3) Provide some sort of custom tag to finesse the javascript
> > >
> > > I obviously don't agree with conclusion #1. I personally favor #2
> > > over #3 because they will be equally difficult for us to code but #2
> > > will require much less of the user to use (and will look much
> > > cleaner.) You've weighed in with ideas for both #2 and #3 so I was
> > > wondering what your preference was.
> > >
> > > Where do other people stand on this? For those who don't think this
> > > is much of a problem to begin with, would either of these solutions
> > > cause prolems? Or would they be a case of unecessary effort but no
> > > harm done?
> >
> > I'm definitely in the "this is a problem" camp. I would prefer #2 over #3,
> > since it's going to make life a lot easier for the people most affected by
> > the problem.
> >
> > As far as #3 goes, note that the j4j idProxy tag generates an additional
> > element enclosing the original content. This will likely break a lot of
> > existing JavaScript code that "knows" the structure of what it's
> > manipulating. Also, the <x:script> element is dropping variables in the
> > global namespace, which is also likely to cause problems.
> >
> > --
> > Martin Cooper
> >
> > >> -Heath Borders-Wing
> > >
> > > sean
> > >
> >
>
> --
> -Heath Borders-Wing
> hborders@mail.win.org
>
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
The <x:script> doesn't HAVE to drop variables into the global
namespace. It depends upon how it is used. In the example I gave,
there are two affected namespaces: that of the <x:script> tag and that
of the enableOrNot() function. Of course, the <x:script> tag is
powerful enough to allow for additions to the global namespace thusly:
<h:inputText id="myInputText" value="#{bean.value}" />
<x:script>
<x:scriptParameter for="myInputText" id="p_myInputText" />
var inputText = document.getElementById('p_myInputText');
</x:script>
This would therefore add "inputText" into the global namespace.
I realize that the j4j tag already basically solves this problem, but
I think that this tag is a more graceful solution that would be easy
to implement.
On Sun, 2 Jan 2005 20:34:28 -0800 (PST), Martin Cooper
<ma...@apache.org> wrote:
>
>
> On Sun, 2 Jan 2005, Sean Schofield wrote:
>
> >> What the <x:script> tag would have to do is search its body content
> >> for ids specified in the <x:scriptParameter> tag and replace them with
> >> the clientId's of the components specified in the
> >> <x:scriptParameter>'s "for" attribute.
> >>
> >> Thoughts?
> >
> > I'm personally not too wild about this. Why do we want to subject the
> > user to all of this extra coding? Its one thing if there is no other
> > way, but it seems like we have another way (your suggestion of
> > overriding convertClienttId() method.) This idea has some
> > possibilities but it strikes me as not much of an improvement over the
> > "proxy tag" idea that has been developed.
> >
> > Out of curiousity, are you leaning in favor of or against the directId
> > attribute? I detect three distinct ideas here...
> >
> > #1) This is not much of a problem - do nothing
> > #2) Allow user to specify directId/styleId attribute
> > #3) Provide some sort of custom tag to finesse the javascript
> >
> > I obviously don't agree with conclusion #1. I personally favor #2
> > over #3 because they will be equally difficult for us to code but #2
> > will require much less of the user to use (and will look much
> > cleaner.) You've weighed in with ideas for both #2 and #3 so I was
> > wondering what your preference was.
> >
> > Where do other people stand on this? For those who don't think this
> > is much of a problem to begin with, would either of these solutions
> > cause prolems? Or would they be a case of unecessary effort but no
> > harm done?
>
> I'm definitely in the "this is a problem" camp. I would prefer #2 over #3,
> since it's going to make life a lot easier for the people most affected by
> the problem.
>
> As far as #3 goes, note that the j4j idProxy tag generates an additional
> element enclosing the original content. This will likely break a lot of
> existing JavaScript code that "knows" the structure of what it's
> manipulating. Also, the <x:script> element is dropping variables in the
> global namespace, which is also likely to cause problems.
>
> --
> Martin Cooper
>
> >> -Heath Borders-Wing
> >
> > sean
> >
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Javascript getElementById Issues
Posted by Martin Cooper <ma...@apache.org>.
On Sun, 2 Jan 2005, Sean Schofield wrote:
>> What the <x:script> tag would have to do is search its body content
>> for ids specified in the <x:scriptParameter> tag and replace them with
>> the clientId's of the components specified in the
>> <x:scriptParameter>'s "for" attribute.
>>
>> Thoughts?
>
> I'm personally not too wild about this. Why do we want to subject the
> user to all of this extra coding? Its one thing if there is no other
> way, but it seems like we have another way (your suggestion of
> overriding convertClienttId() method.) This idea has some
> possibilities but it strikes me as not much of an improvement over the
> "proxy tag" idea that has been developed.
>
> Out of curiousity, are you leaning in favor of or against the directId
> attribute? I detect three distinct ideas here...
>
> #1) This is not much of a problem - do nothing
> #2) Allow user to specify directId/styleId attribute
> #3) Provide some sort of custom tag to finesse the javascript
>
> I obviously don't agree with conclusion #1. I personally favor #2
> over #3 because they will be equally difficult for us to code but #2
> will require much less of the user to use (and will look much
> cleaner.) You've weighed in with ideas for both #2 and #3 so I was
> wondering what your preference was.
>
> Where do other people stand on this? For those who don't think this
> is much of a problem to begin with, would either of these solutions
> cause prolems? Or would they be a case of unecessary effort but no
> harm done?
I'm definitely in the "this is a problem" camp. I would prefer #2 over #3,
since it's going to make life a lot easier for the people most affected by
the problem.
As far as #3 goes, note that the j4j idProxy tag generates an additional
element enclosing the original content. This will likely break a lot of
existing JavaScript code that "knows" the structure of what it's
manipulating. Also, the <x:script> element is dropping variables in the
global namespace, which is also likely to cause problems.
--
Martin Cooper
>> -Heath Borders-Wing
>
> sean
>
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> As for difficulties, it seems like #3 would be vastly easier to code
> (I might even do it tomorrow at work), as opposed to #2.
Maybe I was missing something then. I will re-examine your idea
tomorrow when I am less tired.
> I don't see this as an either-or problem. Both ways can coexist peacefully.
Good point. I will try and get started on some patches for #2. I
will add them to the JIRA bug I opened on this
(http://issues.apache.org/jira/browse/MYFACES-70) and we can discuss.
In the meantime I'd be interested in feedback from others about this
approach. I will also try and think about some of the issues/concerns
that Craig has raised.
sean
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
#3 is just a possibility I came up with recently, so I thought I'd put
it out there.
I think I like #3 the best because I don't have any legacy javascript
that I am worried about including. Most of the javascript i'm
developing is very lightweight interactions between components as I
described in my example, and the <x:script> tag would take care of
this just fine.
However, we also have to be aware of our user base, and if our users
are more used to the #2 method, I don't see why we shouldn't develop
that to attract more people to MyFaces.
As for difficulties, it seems like #3 would be vastly easier to code
(I might even do it tomorrow at work), as opposed to #2.
I don't see this as an either-or problem. Both ways can coexist peacefully.
On Sun, 2 Jan 2005 21:58:57 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > What the <x:script> tag would have to do is search its body content
> > for ids specified in the <x:scriptParameter> tag and replace them with
> > the clientId's of the components specified in the
> > <x:scriptParameter>'s "for" attribute.
> >
> > Thoughts?
>
> I'm personally not too wild about this. Why do we want to subject the
> user to all of this extra coding? Its one thing if there is no other
> way, but it seems like we have another way (your suggestion of
> overriding convertClienttId() method.) This idea has some
> possibilities but it strikes me as not much of an improvement over the
> "proxy tag" idea that has been developed.
>
> Out of curiousity, are you leaning in favor of or against the directId
> attribute? I detect three distinct ideas here...
>
> #1) This is not much of a problem - do nothing
> #2) Allow user to specify directId/styleId attribute
> #3) Provide some sort of custom tag to finesse the javascript
>
> I obviously don't agree with conclusion #1. I personally favor #2
> over #3 because they will be equally difficult for us to code but #2
> will require much less of the user to use (and will look much
> cleaner.) You've weighed in with ideas for both #2 and #3 so I was
> wondering what your preference was.
>
> Where do other people stand on this? For those who don't think this
> is much of a problem to begin with, would either of these solutions
> cause prolems? Or would they be a case of unecessary effort but no
> harm done?
>
> > -Heath Borders-Wing
>
> sean
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> What the <x:script> tag would have to do is search its body content
> for ids specified in the <x:scriptParameter> tag and replace them with
> the clientId's of the components specified in the
> <x:scriptParameter>'s "for" attribute.
>
> Thoughts?
I'm personally not too wild about this. Why do we want to subject the
user to all of this extra coding? Its one thing if there is no other
way, but it seems like we have another way (your suggestion of
overriding convertClienttId() method.) This idea has some
possibilities but it strikes me as not much of an improvement over the
"proxy tag" idea that has been developed.
Out of curiousity, are you leaning in favor of or against the directId
attribute? I detect three distinct ideas here...
#1) This is not much of a problem - do nothing
#2) Allow user to specify directId/styleId attribute
#3) Provide some sort of custom tag to finesse the javascript
I obviously don't agree with conclusion #1. I personally favor #2
over #3 because they will be equally difficult for us to code but #2
will require much less of the user to use (and will look much
cleaner.) You've weighed in with ideas for both #2 and #3 so I was
wondering what your preference was.
Where do other people stand on this? For those who don't think this
is much of a problem to begin with, would either of these solutions
cause prolems? Or would they be a case of unecessary effort but no
harm done?
> -Heath Borders-Wing
sean
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
With regards to javascript, here is an extended solution:
Let's say you have the following JSP code:
<h:selectBooleanCheckbox value="#{myBean.additionalInd}"
id="additionalInd" onclick="enableOrNot()" />
<h:inputText value="#{myBean.additionalText}" disabled="#{not
myBean.additionalInd}" />
Now, obviously, if the user initially enters the page and the checkbox
is unchecked, the inputText will be disabled. If they check the box,
we would ideally like the input to be enabled with client-side logic.
We cannot easily do this because of clientId issues.
However, assuming that the selectBooleanCheckbox and inputText are in
the same NamingContainer, we could have the following tag:
<x:script>
<x:scriptParameter for="additionalnd" id="p_additionalInd" />
<x:scriptParameter for="additionalText id="p_additionalText" />
function enableOrNot()
{
var checkbox = document.getElementById('p_additionalInd');
var inputText = document.getElementById('p_additionalText');
inputText.disabled=!checkbox.checked;
}
</x:script>
What the <x:script> tag would have to do is search its body content
for ids specified in the <x:scriptParameter> tag and replace them with
the clientId's of the components specified in the
<x:scriptParameter>'s "for" attribute.
Thoughts?
On Sun, 02 Jan 2005 15:09:27 -0800, Travis Reeder
<tr...@ecommstats.com> wrote:
> I'm wondering if there's a way we could make an <x:script> tag that would
> make available certain components that we want to use in javascript for
> example:
>
> You have an inputText you want to be able to access:
> <h:inputText id="myInput"/>
>
> Then you use the x:script like so:
> <x:script>
> function foo(){
> myInput.value = "xyz";
> }
> </x:script>
>
> And x:script would output based on whether an explicit id was specified for
> a component so the end result would look like this:
>
> <script>
> // component references output first
> var myInput = document.getElementById("theActualIdAssignedToMyInput");
>
> function foo(){
> myInput.value = "xyz";
> }
> </script>
>
> Travis
>
>
> Craig McClanahan wrote:
> On Sat, 1 Jan 2005 10:56:40 -0600, Heath Borders <he...@gmail.com>
> wrote:
> No, it is only used for uniqueness on the client-side. Component tree
> doesn't require unique id's. Id's must only be unique beneath a given
> NamingContainer. Actually, there *is* an important server side use of the
> clientId value -- it also becomes the name of the request parameter used to
> decode the values of submitted input fields. Indeed, this is why the decode
> and encode functionality was merged into a single API (Renderer) -- only the
> code that emits the "id" attribute knows what the name of the corresponding
> request parameter will be. You should also note that, even if you added
> something like "directId" on the MyFaces extended components, using such a
> component would fail inside a UIData (or any similar component) that renders
> more than one element from the same component -- the fact that the standard
> components use clientId is what lets UIData get involved in the id
> assignment process (since UIData is itself a naming container). Craig
> On Sat, 1 Jan 2005 06:31:12 -0800 (PST), Ray Clark <rc...@yahoo.com>
> wrote:
> Is the clientId in the component used for anything other than generating
> uniqueness for the client side tag? Is it used on the server side in the
> processing of the component tree? Thanks, Ray --- Heath Borders
> <he...@gmail.com> wrote:
> I'm in favor of doing this, though I don't think I'll have much time at
> work to dedicate to it since we're not really aching for the change. If I
> get some time, I'll try to do something, but I can't really commit to it. On
> Fri, 31 Dec 2004 11:59:15 -0800, Craig McClanahan <cr...@gmail.com>
> wrote:
> If you wanted to be more familiar to Struts users, you might consider
> using "styleId" instead ... that's the attribute all the Struts HTML
> tags use to specify the "id" attribute to be emitted.
> Craig On Fri, 31 Dec 2004 14:47:55 -0500, Sean Schofield
> <se...@gmail.com> wrote:
>
> A possible solution would be to implement direct id's (that is any id
>
>
> specified in the JSP translates into the same client id) in the
>
>
> MyFaces extended components. We could provide a separate attribute on all
> extended components
>
>
> called "directId". If specified, directId would be both the id and
>
>
> the clientId. In order to ensure uniqueness, we would have to have
>
>
> all components register their directId's with the view root.
>
>
> This would allow backwards compatibility with existing code and allow
>
>
> easy direct access to the clientId from the JSP without a separate
>
>
> tag. That would be an extremely welcome enhancement. Although I imagine it
>
> would take a bit of work to get it done :-)
> -Heath Borders-Wing sean -- -Heath Borders-Wing hborders@mail.win.org
> __________________________________ Do you Yahoo!? The all-new My Yahoo! -
> What will yours do? http://my.yahoo.com -- -Heath Borders-Wing
> hborders@mail.win.org
> -- Travis Reeder Ecommstats Web Analytics www.ecommstats.com
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Javascript getElementById Issues
Posted by Travis Reeder <tr...@ecommstats.com>.
I'm wondering if there's a way we could make an <x:script> tag that
would make available certain components that we want to use in
javascript for example:
You have an inputText you want to be able to access:
<h:inputText id="myInput"/>
Then you use the x:script like so:
<x:script>
function foo(){
myInput.value = "xyz";
}
</x:script>
And x:script would output based on whether an explicit id was specified
for a component so the end result would look like this:
<script>
// component references output first
var myInput = document.getElementById("theActualIdAssignedToMyInput");
function foo(){
myInput.value = "xyz";
}
</script>
Travis
Craig McClanahan wrote:
>On Sat, 1 Jan 2005 10:56:40 -0600, Heath Borders
><he...@gmail.com> wrote:
>
>
>>No, it is only used for uniqueness on the client-side. Component tree
>>doesn't require unique id's. Id's must only be unique beneath a given
>>NamingContainer.
>>
>>
>
>Actually, there *is* an important server side use of the clientId
>value -- it also becomes the name of the request parameter used to
>decode the values of submitted input fields. Indeed, this is why the
>decode and encode functionality was merged into a single API
>(Renderer) -- only the code that emits the "id" attribute knows what
>the name of the corresponding request parameter will be.
>
>You should also note that, even if you added something like "directId"
>on the MyFaces extended components, using such a component would fail
>inside a UIData (or any similar component) that renders more than one
>element from the same component -- the fact that the standard
>components use clientId is what lets UIData get involved in the id
>assignment process (since UIData is itself a naming container).
>
>Craig
>
>
>
>>On Sat, 1 Jan 2005 06:31:12 -0800 (PST), Ray Clark <rc...@yahoo.com> wrote:
>>
>>
>>>Is the clientId in the component used for anything
>>>other than generating uniqueness for the client side
>>>tag? Is it used on the server side in the processing
>>>of the component tree?
>>>
>>>Thanks,
>>>Ray
>>>
>>>--- Heath Borders <he...@gmail.com> wrote:
>>>
>>>
>>>
>>>>I'm in favor of doing this, though I don't think
>>>>I'll have much time
>>>>at work to dedicate to it since we're not really
>>>>aching for the
>>>>change. If I get some time, I'll try to do
>>>>something, but I can't
>>>>really commit to it.
>>>>
>>>>
>>>>On Fri, 31 Dec 2004 11:59:15 -0800, Craig McClanahan
>>>><cr...@gmail.com> wrote:
>>>>
>>>>
>>>>>If you wanted to be more familiar to Struts users,
>>>>>
>>>>>
>>>>you might consider
>>>>
>>>>
>>>>>using "styleId" instead ... that's the attribute
>>>>>
>>>>>
>>>>all the Struts HTML
>>>>
>>>>
>>>>>tags use to specify the "id" attribute to be
>>>>>
>>>>>
>>>>emitted.
>>>>
>>>>
>>>>>Craig
>>>>>
>>>>>On Fri, 31 Dec 2004 14:47:55 -0500, Sean Schofield
>>>>><se...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>>>A possible solution would be to implement
>>>>>>>
>>>>>>>
>>>>direct id's (that is any id
>>>>
>>>>
>>>>>>>specified in the JSP translates into the same
>>>>>>>
>>>>>>>
>>>>client id) in the
>>>>
>>>>
>>>>>>>MyFaces extended components.
>>>>>>>
>>>>>>>We could provide a separate attribute on all
>>>>>>>
>>>>>>>
>>>>extended components
>>>>
>>>>
>>>>>>>called "directId". If specified, directId
>>>>>>>
>>>>>>>
>>>>would be both the id and
>>>>
>>>>
>>>>>>>the clientId. In order to ensure uniqueness,
>>>>>>>
>>>>>>>
>>>>we would have to have
>>>>
>>>>
>>>>>>>all components register their directId's with
>>>>>>>
>>>>>>>
>>>>the view root.
>>>>
>>>>
>>>>>>>This would allow backwards compatibility with
>>>>>>>
>>>>>>>
>>>>existing code and allow
>>>>
>>>>
>>>>>>>easy direct access to the clientId from the
>>>>>>>
>>>>>>>
>>>>JSP without a separate
>>>>
>>>>
>>>>>>>tag.
>>>>>>>
>>>>>>>
>>>>>>That would be an extremely welcome enhancement.
>>>>>>
>>>>>>
>>>>Although I imagine it
>>>>
>>>>
>>>>>>would take a bit of work to get it done :-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-Heath Borders-Wing
>>>>>>>
>>>>>>>
>>>>>>sean
>>>>>>
>>>>>>
>>>>>>
>>>>--
>>>>-Heath Borders-Wing
>>>>hborders@mail.win.org
>>>>
>>>>
>>>>
>>>__________________________________
>>>Do you Yahoo!?
>>>The all-new My Yahoo! - What will yours do?
>>>http://my.yahoo.com
>>>
>>>
>>>
>>--
>>-Heath Borders-Wing
>>hborders@mail.win.org
>>
>>
>>
>
>
>
--
Travis Reeder
Ecommstats Web Analytics
www.ecommstats.com
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> If you're hard coding them today, what stops you (like you, ignoring
> the repeating case) from hard coding the JSF-generated values? They
> are perfectly predictable if you use "id" elements on the form and the
> input field itself.
While its true that these elements are predictable, I think there are
some problems with this approach.
The first issue goes to ease of use. This requires that I change all
of my javascript (and there is a ton of it.) Not the end of the world
but I'd rather "take one for the team" and implement a fix in an
implmentation so others do not have to deal with this. The developers
on my team strongly urged me to hold off on faces for now just based
on this single issue. If the goal is to have faces catch on with the
development community, we should make it as easy as possible.
The second issue is that now my javascript is tied to JSF. If I ever
stop using faces (or the faces spec/implementation changes on me),
then I'm back to changing all of my javascript again. (Maybe I am
missing something here, but that seems to be the implication.)
The third issue is that even though its predictable its not allways
very easy to determine. In my case I'm using lots of tiles
(subviews). I seem to recall that the id's of these attributes is
affected by whether or not they are in subviews. So its difficult to
determine ahead of time and will be incorrect if I change the way I'm
laying things out.
Finally, there is the more complicated "nested" case. If my wizard is
generating multiple values (say picking 0-n names from an address book
wizard) then things get really complicated. The HTML being submitted
on the form doesn't even exist yet. Its generated dynamically from
the javascript (so you're submitting a contact[0], contact[1], etc.
I'm not even sure how I would manage this if id's were not an issue,
but that's for another day.
> Craig
sean
Re: Javascript getElementById Issues
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 2 Jan 2005 18:04:27 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > Actually, there *is* an important server side use of the clientId
> > value -- it also becomes the name of the request parameter used to
> > decode the values of submitted input fields. Indeed, this is why the
> > decode and encode functionality was merged into a single API
> > (Renderer) -- only the code that emits the "id" attribute knows what
> > the name of the corresponding request parameter will be.
>
> I just figured that out after doing some more intensive research on
> the JSF lifecycle. This shouldn't be a problem though because the
> same renderer that provides the customized "id" attribute can be used
> to decode it as well. Right?
That's correct ... presumably if one had a styleId attribute on the
component that dictated what the emitted "id" value would be, both the
encode and decode methods could share that understanding.
>
> > You should also note that, even if you added something like "directId"
> > on the MyFaces extended components, using such a component would fail
> > inside a UIData (or any similar component) that renders more than one
> > element from the same component -- the fact that the standard
> > components use clientId is what lets UIData get involved in the id
> > assignment process (since UIData is itself a naming container).
>
> I figured as much. Well, is there anything we could do to get around
> this? Couldn't we set the directId/styleId attribute using an index
> like in Struts? So a directId of "fooItem" would yield fooItem[1],
> fooItem[2], etc. I'm thinking this is within the realm of
> possibility. I wasn't sure whether you were pointing out a potential
> pitfall or whether you fealt this was not feasible.
Feasibility isn't really my concern ... but it becomes less and less
clear why a scheme like this would be better than what we already
have.
Well-written JavaScript methods (independent of what technology you
use to build your dynamic applications) should be accepting either
object references (in which case it can ask the element "hey element,
what's your id?") or accepting id values directly as arguments. If
you hard code the ids, page authors can break your code even in a
pure-HTML-page world, by accidentally or purposefully changing the
"id" attributes themselves.
The key is to make sure that your renderers create calls to the right
Javascirpt methods, with the right id values. Calculating what those
id values should be depends on knowing the algorithm being used -- and
I don't see how knowing that the calculated id will be whatever you
say plus a suffix is any less fragile than knowing the algorithm that
the standard JSF components use to calculate the values is.
Tell me again why we would care so much, especially in the case of
nested repeating components?
Craig
>
> > Craig
>
> sean
>
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> Actually, there *is* an important server side use of the clientId
> value -- it also becomes the name of the request parameter used to
> decode the values of submitted input fields. Indeed, this is why the
> decode and encode functionality was merged into a single API
> (Renderer) -- only the code that emits the "id" attribute knows what
> the name of the corresponding request parameter will be.
I just figured that out after doing some more intensive research on
the JSF lifecycle. This shouldn't be a problem though because the
same renderer that provides the customized "id" attribute can be used
to decode it as well. Right?
> You should also note that, even if you added something like "directId"
> on the MyFaces extended components, using such a component would fail
> inside a UIData (or any similar component) that renders more than one
> element from the same component -- the fact that the standard
> components use clientId is what lets UIData get involved in the id
> assignment process (since UIData is itself a naming container).
I figured as much. Well, is there anything we could do to get around
this? Couldn't we set the directId/styleId attribute using an index
like in Struts? So a directId of "fooItem" would yield fooItem[1],
fooItem[2], etc. I'm thinking this is within the realm of
possibility. I wasn't sure whether you were pointing out a potential
pitfall or whether you fealt this was not feasible.
> Craig
sean
Re: Javascript getElementById Issues
Posted by Craig McClanahan <cr...@gmail.com>.
On Sat, 1 Jan 2005 10:56:40 -0600, Heath Borders
<he...@gmail.com> wrote:
> No, it is only used for uniqueness on the client-side. Component tree
> doesn't require unique id's. Id's must only be unique beneath a given
> NamingContainer.
Actually, there *is* an important server side use of the clientId
value -- it also becomes the name of the request parameter used to
decode the values of submitted input fields. Indeed, this is why the
decode and encode functionality was merged into a single API
(Renderer) -- only the code that emits the "id" attribute knows what
the name of the corresponding request parameter will be.
You should also note that, even if you added something like "directId"
on the MyFaces extended components, using such a component would fail
inside a UIData (or any similar component) that renders more than one
element from the same component -- the fact that the standard
components use clientId is what lets UIData get involved in the id
assignment process (since UIData is itself a naming container).
Craig
> On Sat, 1 Jan 2005 06:31:12 -0800 (PST), Ray Clark <rc...@yahoo.com> wrote:
> > Is the clientId in the component used for anything
> > other than generating uniqueness for the client side
> > tag? Is it used on the server side in the processing
> > of the component tree?
> >
> > Thanks,
> > Ray
> >
> > --- Heath Borders <he...@gmail.com> wrote:
> >
> > > I'm in favor of doing this, though I don't think
> > > I'll have much time
> > > at work to dedicate to it since we're not really
> > > aching for the
> > > change. If I get some time, I'll try to do
> > > something, but I can't
> > > really commit to it.
> > >
> > >
> > > On Fri, 31 Dec 2004 11:59:15 -0800, Craig McClanahan
> > > <cr...@gmail.com> wrote:
> > > > If you wanted to be more familiar to Struts users,
> > > you might consider
> > > > using "styleId" instead ... that's the attribute
> > > all the Struts HTML
> > > > tags use to specify the "id" attribute to be
> > > emitted.
> > > >
> > > > Craig
> > > >
> > > > On Fri, 31 Dec 2004 14:47:55 -0500, Sean Schofield
> > > > <se...@gmail.com> wrote:
> > > > > > A possible solution would be to implement
> > > direct id's (that is any id
> > > > > > specified in the JSP translates into the same
> > > client id) in the
> > > > > > MyFaces extended components.
> > > > > >
> > > > > > We could provide a separate attribute on all
> > > extended components
> > > > > > called "directId". If specified, directId
> > > would be both the id and
> > > > > > the clientId. In order to ensure uniqueness,
> > > we would have to have
> > > > > > all components register their directId's with
> > > the view root.
> > > > > >
> > > > > > This would allow backwards compatibility with
> > > existing code and allow
> > > > > > easy direct access to the clientId from the
> > > JSP without a separate
> > > > > > tag.
> > > > >
> > > > > That would be an extremely welcome enhancement.
> > > Although I imagine it
> > > > > would take a bit of work to get it done :-)
> > > > >
> > > > > > -Heath Borders-Wing
> > > > >
> > > > > sean
> > > > >
> > > >
> > >
> > >
> > > --
> > > -Heath Borders-Wing
> > > hborders@mail.win.org
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > The all-new My Yahoo! - What will yours do?
> > http://my.yahoo.com
> >
>
> --
> -Heath Borders-Wing
> hborders@mail.win.org
>
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
No, it is only used for uniqueness on the client-side. Component tree
doesn't require unique id's. Id's must only be unique beneath a given
NamingContainer.
On Sat, 1 Jan 2005 06:31:12 -0800 (PST), Ray Clark <rc...@yahoo.com> wrote:
> Is the clientId in the component used for anything
> other than generating uniqueness for the client side
> tag? Is it used on the server side in the processing
> of the component tree?
>
> Thanks,
> Ray
>
> --- Heath Borders <he...@gmail.com> wrote:
>
> > I'm in favor of doing this, though I don't think
> > I'll have much time
> > at work to dedicate to it since we're not really
> > aching for the
> > change. If I get some time, I'll try to do
> > something, but I can't
> > really commit to it.
> >
> >
> > On Fri, 31 Dec 2004 11:59:15 -0800, Craig McClanahan
> > <cr...@gmail.com> wrote:
> > > If you wanted to be more familiar to Struts users,
> > you might consider
> > > using "styleId" instead ... that's the attribute
> > all the Struts HTML
> > > tags use to specify the "id" attribute to be
> > emitted.
> > >
> > > Craig
> > >
> > > On Fri, 31 Dec 2004 14:47:55 -0500, Sean Schofield
> > > <se...@gmail.com> wrote:
> > > > > A possible solution would be to implement
> > direct id's (that is any id
> > > > > specified in the JSP translates into the same
> > client id) in the
> > > > > MyFaces extended components.
> > > > >
> > > > > We could provide a separate attribute on all
> > extended components
> > > > > called "directId". If specified, directId
> > would be both the id and
> > > > > the clientId. In order to ensure uniqueness,
> > we would have to have
> > > > > all components register their directId's with
> > the view root.
> > > > >
> > > > > This would allow backwards compatibility with
> > existing code and allow
> > > > > easy direct access to the clientId from the
> > JSP without a separate
> > > > > tag.
> > > >
> > > > That would be an extremely welcome enhancement.
> > Although I imagine it
> > > > would take a bit of work to get it done :-)
> > > >
> > > > > -Heath Borders-Wing
> > > >
> > > > sean
> > > >
> > >
> >
> >
> > --
> > -Heath Borders-Wing
> > hborders@mail.win.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> The all-new My Yahoo! - What will yours do?
> http://my.yahoo.com
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Javascript getElementById Issues
Posted by Ray Clark <rc...@yahoo.com>.
Is the clientId in the component used for anything
other than generating uniqueness for the client side
tag? Is it used on the server side in the processing
of the component tree?
Thanks,
Ray
--- Heath Borders <he...@gmail.com> wrote:
> I'm in favor of doing this, though I don't think
> I'll have much time
> at work to dedicate to it since we're not really
> aching for the
> change. If I get some time, I'll try to do
> something, but I can't
> really commit to it.
>
>
> On Fri, 31 Dec 2004 11:59:15 -0800, Craig McClanahan
> <cr...@gmail.com> wrote:
> > If you wanted to be more familiar to Struts users,
> you might consider
> > using "styleId" instead ... that's the attribute
> all the Struts HTML
> > tags use to specify the "id" attribute to be
> emitted.
> >
> > Craig
> >
> > On Fri, 31 Dec 2004 14:47:55 -0500, Sean Schofield
> > <se...@gmail.com> wrote:
> > > > A possible solution would be to implement
> direct id's (that is any id
> > > > specified in the JSP translates into the same
> client id) in the
> > > > MyFaces extended components.
> > > >
> > > > We could provide a separate attribute on all
> extended components
> > > > called "directId". If specified, directId
> would be both the id and
> > > > the clientId. In order to ensure uniqueness,
> we would have to have
> > > > all components register their directId's with
> the view root.
> > > >
> > > > This would allow backwards compatibility with
> existing code and allow
> > > > easy direct access to the clientId from the
> JSP without a separate
> > > > tag.
> > >
> > > That would be an extremely welcome enhancement.
> Although I imagine it
> > > would take a bit of work to get it done :-)
> > >
> > > > -Heath Borders-Wing
> > >
> > > sean
> > >
> >
>
>
> --
> -Heath Borders-Wing
> hborders@mail.win.org
>
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> I'm in favor of doing this, though I don't think I'll have much time
> at work to dedicate to it since we're not really aching for the
> change. If I get some time, I'll try to do something, but I can't
> really commit to it.
OK. I've spent a few days looking over things in more detail. I
would like to help and I'm going to start submitting some patches (and
ideas for patches.) Please bear with me as I get up to speed with JSF
and MyFaces. This will also be an excellent exercise for me to get
familiar with the architecture of JSF in general.
I submitted a couple of enhancements related to this to JIRA (I
haven't seen the emails on the dev list yet though.) My first
enhancment (http://issues.apache.org/jira/browse/MYFACES-69) deals
with general housekeeping that would be nice to have done in advance
of the changes that I anticipate are necessary.
The second enhancement
(http://issues.apache.org/jira/browse/MYFACES-70) summarizes the
problem as we have discussed here.
> -Heath Borders-Wing
sean
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
I'm in favor of doing this, though I don't think I'll have much time
at work to dedicate to it since we're not really aching for the
change. If I get some time, I'll try to do something, but I can't
really commit to it.
On Fri, 31 Dec 2004 11:59:15 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> If you wanted to be more familiar to Struts users, you might consider
> using "styleId" instead ... that's the attribute all the Struts HTML
> tags use to specify the "id" attribute to be emitted.
>
> Craig
>
> On Fri, 31 Dec 2004 14:47:55 -0500, Sean Schofield
> <se...@gmail.com> wrote:
> > > A possible solution would be to implement direct id's (that is any id
> > > specified in the JSP translates into the same client id) in the
> > > MyFaces extended components.
> > >
> > > We could provide a separate attribute on all extended components
> > > called "directId". If specified, directId would be both the id and
> > > the clientId. In order to ensure uniqueness, we would have to have
> > > all components register their directId's with the view root.
> > >
> > > This would allow backwards compatibility with existing code and allow
> > > easy direct access to the clientId from the JSP without a separate
> > > tag.
> >
> > That would be an extremely welcome enhancement. Although I imagine it
> > would take a bit of work to get it done :-)
> >
> > > -Heath Borders-Wing
> >
> > sean
> >
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Javascript getElementById Issues
Posted by Craig McClanahan <cr...@gmail.com>.
If you wanted to be more familiar to Struts users, you might consider
using "styleId" instead ... that's the attribute all the Struts HTML
tags use to specify the "id" attribute to be emitted.
Craig
On Fri, 31 Dec 2004 14:47:55 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > A possible solution would be to implement direct id's (that is any id
> > specified in the JSP translates into the same client id) in the
> > MyFaces extended components.
> >
> > We could provide a separate attribute on all extended components
> > called "directId". If specified, directId would be both the id and
> > the clientId. In order to ensure uniqueness, we would have to have
> > all components register their directId's with the view root.
> >
> > This would allow backwards compatibility with existing code and allow
> > easy direct access to the clientId from the JSP without a separate
> > tag.
>
> That would be an extremely welcome enhancement. Although I imagine it
> would take a bit of work to get it done :-)
>
> > -Heath Borders-Wing
>
> sean
>
Re: Javascript getElementById Issues
Posted by Sean Schofield <se...@gmail.com>.
> A possible solution would be to implement direct id's (that is any id
> specified in the JSP translates into the same client id) in the
> MyFaces extended components.
>
> We could provide a separate attribute on all extended components
> called "directId". If specified, directId would be both the id and
> the clientId. In order to ensure uniqueness, we would have to have
> all components register their directId's with the view root.
>
> This would allow backwards compatibility with existing code and allow
> easy direct access to the clientId from the JSP without a separate
> tag.
That would be an extremely welcome enhancement. Although I imagine it
would take a bit of work to get it done :-)
> -Heath Borders-Wing
sean
Re: Javascript getElementById Issues
Posted by Heath Borders <he...@gmail.com>.
A possible solution would be to implement direct id's (that is any id
specified in the JSP translates into the same client id) in the
MyFaces extended components.
We could provide a separate attribute on all extended components
called "directId". If specified, directId would be both the id and
the clientId. In order to ensure uniqueness, we would have to have
all components register their directId's with the view root.
This would allow backwards compatibility with existing code and allow
easy direct access to the clientId from the JSP without a separate
tag.
On Thu, 30 Dec 2004 10:33:04 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Thu, 30 Dec 2004 09:51:49 -0500, Sean Schofield
> <se...@gmail.com> wrote:
> > A major stumbling block for me with JSF is how the implementations all
> > seem to "munge" the id attributes of my JSF tags. I'm assuming this
> > helps with constructing the component tree and mapping the posts to
> > the right components, but does it have to be this way?
> >
> > Both MyFaces and the RI change the id attribute. Couldn't they just
> > change the name attribute? Isn't that the only thing that is sent via
> > POST? We have tons of javascript that use the getElementById method
> > and this would be a problem changing it.
>
> The name attribute is deprecated on (nearly) all elements in XHTML, so
> that wouldn't be a good answer.
>
> The reason that "id" values are calculated is that XHTML requires all
> "id" values in the rendered page to be unique. Therefore, it is up to
> the render kit you are using to ensure that this restriction is met --
> which it does by prefixing with the id of the closest surrounding
> NamingContainer (and on up the tree) -- plus, complex components like
> UIData can get involved in the calculation process to create unique
> identifiers for looping situations. Note that, without the ability to
> generate component ids, you would not be able to do what UIData does
> in rendering multiple rows from the same child components.
>
> The key challenge for using JavaScript is knowing what the identifier
> of a component will be. There is some work going on in the JSF 1.2
> area to improve this, but the key thing to know is that the standard
> renderers all call UIComponent.getClientId() to acquire the "id" value
> to be emitted. You can do the same thing as you construct the call to
> your JavaScript functions.
>
> Craig
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Javascript getElementById Issues
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 30 Dec 2004 09:51:49 -0500, Sean Schofield
<se...@gmail.com> wrote:
> A major stumbling block for me with JSF is how the implementations all
> seem to "munge" the id attributes of my JSF tags. I'm assuming this
> helps with constructing the component tree and mapping the posts to
> the right components, but does it have to be this way?
>
> Both MyFaces and the RI change the id attribute. Couldn't they just
> change the name attribute? Isn't that the only thing that is sent via
> POST? We have tons of javascript that use the getElementById method
> and this would be a problem changing it.
The name attribute is deprecated on (nearly) all elements in XHTML, so
that wouldn't be a good answer.
The reason that "id" values are calculated is that XHTML requires all
"id" values in the rendered page to be unique. Therefore, it is up to
the render kit you are using to ensure that this restriction is met --
which it does by prefixing with the id of the closest surrounding
NamingContainer (and on up the tree) -- plus, complex components like
UIData can get involved in the calculation process to create unique
identifiers for looping situations. Note that, without the ability to
generate component ids, you would not be able to do what UIData does
in rendering multiple rows from the same child components.
The key challenge for using JavaScript is knowing what the identifier
of a component will be. There is some work going on in the JSF 1.2
area to improve this, but the key thing to know is that the standard
renderers all call UIComponent.getClientId() to acquire the "id" value
to be emitted. You can do the same thing as you construct the call to
your JavaScript functions.
Craig