You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by "Marti, Adrian (Adrian)" <am...@avaya.com> on 2006/01/05 22:37:20 UTC
Something like forceId for regular components?
Hello all,
First post, hopefully not too common a question.
Working on a project with a lot of preexisting javascript
functions where the id's of components need to be exactly what is
expected. JSF seems to want to prefix all of my component id's with the
form id.
Such as
<h:form id="acctform">
<h:inputText id="firstInput" ... />
... </h:form>
Will show up in the html with an id="acctform:firstInput".
This obviously breaks the javascript. I have found the forceId attribute
for Tomahawk components but haven't seen anything for the regular
components. Anyone have any advice?
Thanks,
Adrian
Re: Something like forceId for regular components?
Posted by Sean Schofield <se...@gmail.com>.
Volker,
One issue is that not all javascript is created by your components.
Especially when migrating an existing application.
There was a very long (and IMO interesting) discussion about this
forceId issue a little over a year ago. If you check the archives[1]
you can see some of the arguments that were made on both sides of the
issue.
Sean
[1] http://www.mail-archive.com/users@myfaces.apache.org/msg00680.html
On 1/6/06, Volker Weber <us...@weber-oldenburg.de> wrote:
> Hi,
>
> can't you use these created ids in you javascript?
>
> If you set a id to the form component, and to all other namingContainer
> components, you will get defined ids for all your components and can
> work with them in your scripts.
>
> IMHO forceId makes more problems than it solves.
>
> Regards
> Volker
>
> Marti, Adrian (Adrian) wrote:
> > Hello all,
> >
> >
> >
> > First post, hopefully not too common a question.
> >
> >
> >
> >
> >
> > Working on a project with a lot of preexisting javascript
> > functions where the id's of components need to be exactly what is
> > expected. JSF seems to want to prefix all of my component id's with the
> > form id.
> >
> >
> >
> > Such as
> >
> > <h:form id="acctform">
> >
> >
> >
> > <h:inputText id="firstInput" … />
> >
> > … </h:form>
> >
> >
> >
> > Will show up in the html with an id="acctform:firstInput".
> > This obviously breaks the javascript. I have found the forceId attribute
> > for Tomahawk components but haven't seen anything for the regular
> > components. Anyone have any advice?
> >
> >
> >
> >
> >
> > Thanks,
> >
> > Adrian
> >
> >
> >
> >
> >
>
> --
> Don't answer to From: address!
> Mail to this account are droped if not recieved via mailinglist.
> To contact me direct create the mail address by
> concatenating my forename to my senders domain.
>
Re: Something like forceId for regular components?
Posted by Simon Kitching <sk...@apache.org>.
On Fri, 2006-01-06 at 20:04 +0100, Volker Weber wrote:
> Hi Travis,
> I think i should read this tread.
>
> [1] http://www.mail-archive.com/users@myfaces.apache.org/msg00680.html
I think that thread is missing a lot of information.
The spec requires that a subform is a naming container, and prefixes the
ids of all child components with its own id, so that this can be done:
<h:form id="foo">
<h:inputText id="in" ../>
<f:subview id="view1">
<jsp:include page="footer.jsp"/>
</f:subview>
</h:form>
where the footer also includes some component with id="in". This is a
very important feature, and I can't see how it could be done any other
way than by the "naming container" approach. If people modifying
"included" pages had to look for every place where the page was included
and make sure they did not use any ids that were already in use by
including pages that would be a maintenance nightmare.
In addition, the portlet viewhandler prefixes the ids of all components
with a unique portlet-id, so that there is no chance of id conflicts
between independently-developed portlets. Again, I see no sane alternate
solution; the portlets are *independent* yet the final page must not
have any duplicated ids (and neither may may the JSF View tree).
The h:dataTable component is a NamingContainer for its children for very
good reasons too. Again, any component within a table that has a
user-provided id *must* have its HTML id tweaked in some way, as
multiple HTML components will be output and IDs must be unique.
Whether the h:form needed to be a naming container is debatable; I can't
for the moment see a reason for that. The ADF
form-that-is-not-a-naming-container component sounds like a good idea to
me; it's not a 100% solution but seems a straightforward solution to 95%
of cases. Anyone care to point out a good reason for having Form be a
naming container?
None of this was discussed in the thread referenced above. And
unfortunately the current "forceid" solution suffers from the first two,
and has an inelegant solution to the third.
As Craig mentioned, any JS code created by a renderer should simply pass
its id, or a reference to itself, to javascript methods it invokes.
However that doesn't apply in all cases.
Javascript invoked as a component's event handler can simply reference
"this" to get the source component which avoids the need for ids at all
in this situation.
See also:
http://wiki.apache.org/myfaces/forceId
Regards,
Simon
Re: Something like forceId for regular components?
Posted by Martin Marinschek <ma...@gmail.com>.
No, I haven't!
That works?
cool, that was the new thing I learned for today ;)
regards,
Martin
On 1/7/06, Laurie Harper <la...@holoweb.net> wrote:
> Martin, have you tried changing your selector to
>
> #formId\:namingContainerId\:myComponentId
>
> i.e. escaping the colons?
>
>
> Martin Marinschek wrote:
> > There is one very, very valid reason for forceId I keep reiterating
> > over and over (me not being a friend of forceId in the firstplace, but
> > very happy to have it after doing some real world JSF-projects):
> >
> > when you style with CSS, you quite often style with respect to the id
> > - the # selector is what is used for this.
> >
> > Now, the JSF generated ids are looking like this:
> >
> > formId:namingContainerId:myComponentId
> >
> > if you use this in your CSS, the selector will become the following:
> >
> > #formId:namingContainerId:myComponentId
> >
> > now, the colon is also the pseudo-class selector in CSS (e.g.
> > a:hover), and I have unsucessfully tried to get this type of selection
> > to run in any current browser - id styling just doesn't work anymore
> > with the JSF approach of designing id's, obviously. Please, please,
> > correct me if I am wrong (I'd be very happy to be corrected regarding
> > this)!
> >
> > regards,
> >
> > Martin
> >
> > On 1/7/06, Volker Weber <us...@weber-oldenburg.de> wrote:
> >> Volker Weber wrote:
> >>> I think i should read this tread.
> >>>
> >>> [1] http://www.mail-archive.com/users@myfaces.apache.org/msg00680.html
> >>>
> >> After reading this, i think there is only one new aspect for me.
> >>
> >> The problem with porting existing applications to jsf. If those existing
> >> application uses javascript with *hardcoded* element ids, which can't be
> >> easyly changed to the new naming sheme.
> >>
> >> This scenario is the only one where i'm (for me) willing to accept the
> >> use of forceId.
> >>
> >> But i fear that the page structure is changing so mutch, when porting to
> >> jsf, it will break those scipts anyway.
> >>
> >> Regards
> >> Volker
> >>
> >> --
> >> Don't answer to From: address!
> >> Mail to this account are droped if not recieved via mailinglist.
> >> To contact me direct create the mail address by
> >> concatenating my forename to my senders domain.
> >>
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Something like forceId for regular components?
Posted by Laurie Harper <la...@holoweb.net>.
Martin, have you tried changing your selector to
#formId\:namingContainerId\:myComponentId
i.e. escaping the colons?
Martin Marinschek wrote:
> There is one very, very valid reason for forceId I keep reiterating
> over and over (me not being a friend of forceId in the firstplace, but
> very happy to have it after doing some real world JSF-projects):
>
> when you style with CSS, you quite often style with respect to the id
> - the # selector is what is used for this.
>
> Now, the JSF generated ids are looking like this:
>
> formId:namingContainerId:myComponentId
>
> if you use this in your CSS, the selector will become the following:
>
> #formId:namingContainerId:myComponentId
>
> now, the colon is also the pseudo-class selector in CSS (e.g.
> a:hover), and I have unsucessfully tried to get this type of selection
> to run in any current browser - id styling just doesn't work anymore
> with the JSF approach of designing id's, obviously. Please, please,
> correct me if I am wrong (I'd be very happy to be corrected regarding
> this)!
>
> regards,
>
> Martin
>
> On 1/7/06, Volker Weber <us...@weber-oldenburg.de> wrote:
>> Volker Weber wrote:
>>> I think i should read this tread.
>>>
>>> [1] http://www.mail-archive.com/users@myfaces.apache.org/msg00680.html
>>>
>> After reading this, i think there is only one new aspect for me.
>>
>> The problem with porting existing applications to jsf. If those existing
>> application uses javascript with *hardcoded* element ids, which can't be
>> easyly changed to the new naming sheme.
>>
>> This scenario is the only one where i'm (for me) willing to accept the
>> use of forceId.
>>
>> But i fear that the page structure is changing so mutch, when porting to
>> jsf, it will break those scipts anyway.
>>
>> Regards
>> Volker
>>
>> --
>> Don't answer to From: address!
>> Mail to this account are droped if not recieved via mailinglist.
>> To contact me direct create the mail address by
>> concatenating my forename to my senders domain.
>>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: Something like forceId for regular components?
Posted by Martin Marinschek <ma...@gmail.com>.
P.S.:
I keep asking if the JSF expert group has put any thoughts into this
issue, and I haven't been given any answer so far - maybe this time
there is someone of the expert group reading this thread?
regards,
Martin
On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> There is one very, very valid reason for forceId I keep reiterating
> over and over (me not being a friend of forceId in the firstplace, but
> very happy to have it after doing some real world JSF-projects):
>
> when you style with CSS, you quite often style with respect to the id
> - the # selector is what is used for this.
>
> Now, the JSF generated ids are looking like this:
>
> formId:namingContainerId:myComponentId
>
> if you use this in your CSS, the selector will become the following:
>
> #formId:namingContainerId:myComponentId
>
> now, the colon is also the pseudo-class selector in CSS (e.g.
> a:hover), and I have unsucessfully tried to get this type of selection
> to run in any current browser - id styling just doesn't work anymore
> with the JSF approach of designing id's, obviously. Please, please,
> correct me if I am wrong (I'd be very happy to be corrected regarding
> this)!
>
> regards,
>
> Martin
>
> On 1/7/06, Volker Weber <us...@weber-oldenburg.de> wrote:
> >
> > Volker Weber wrote:
> > >
> > > I think i should read this tread.
> > >
> > > [1] http://www.mail-archive.com/users@myfaces.apache.org/msg00680.html
> > >
> >
> > After reading this, i think there is only one new aspect for me.
> >
> > The problem with porting existing applications to jsf. If those existing
> > application uses javascript with *hardcoded* element ids, which can't be
> > easyly changed to the new naming sheme.
> >
> > This scenario is the only one where i'm (for me) willing to accept the
> > use of forceId.
> >
> > But i fear that the page structure is changing so mutch, when porting to
> > jsf, it will break those scipts anyway.
> >
> > Regards
> > Volker
> >
> > --
> > Don't answer to From: address!
> > Mail to this account are droped if not recieved via mailinglist.
> > To contact me direct create the mail address by
> > concatenating my forename to my senders domain.
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Something like forceId for regular components?
Posted by Martin Marinschek <ma...@gmail.com>.
There is one very, very valid reason for forceId I keep reiterating
over and over (me not being a friend of forceId in the firstplace, but
very happy to have it after doing some real world JSF-projects):
when you style with CSS, you quite often style with respect to the id
- the # selector is what is used for this.
Now, the JSF generated ids are looking like this:
formId:namingContainerId:myComponentId
if you use this in your CSS, the selector will become the following:
#formId:namingContainerId:myComponentId
now, the colon is also the pseudo-class selector in CSS (e.g.
a:hover), and I have unsucessfully tried to get this type of selection
to run in any current browser - id styling just doesn't work anymore
with the JSF approach of designing id's, obviously. Please, please,
correct me if I am wrong (I'd be very happy to be corrected regarding
this)!
regards,
Martin
On 1/7/06, Volker Weber <us...@weber-oldenburg.de> wrote:
>
> Volker Weber wrote:
> >
> > I think i should read this tread.
> >
> > [1] http://www.mail-archive.com/users@myfaces.apache.org/msg00680.html
> >
>
> After reading this, i think there is only one new aspect for me.
>
> The problem with porting existing applications to jsf. If those existing
> application uses javascript with *hardcoded* element ids, which can't be
> easyly changed to the new naming sheme.
>
> This scenario is the only one where i'm (for me) willing to accept the
> use of forceId.
>
> But i fear that the page structure is changing so mutch, when porting to
> jsf, it will break those scipts anyway.
>
> Regards
> Volker
>
> --
> Don't answer to From: address!
> Mail to this account are droped if not recieved via mailinglist.
> To contact me direct create the mail address by
> concatenating my forename to my senders domain.
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Something like forceId for regular components?
Posted by Volker Weber <us...@weber-oldenburg.de>.
Volker Weber wrote:
>
> I think i should read this tread.
>
> [1] http://www.mail-archive.com/users@myfaces.apache.org/msg00680.html
>
After reading this, i think there is only one new aspect for me.
The problem with porting existing applications to jsf. If those existing
application uses javascript with *hardcoded* element ids, which can't be
easyly changed to the new naming sheme.
This scenario is the only one where i'm (for me) willing to accept the
use of forceId.
But i fear that the page structure is changing so mutch, when porting to
jsf, it will break those scipts anyway.
Regards
Volker
--
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.
Re: Something like forceId for regular components?
Posted by Volker Weber <us...@weber-oldenburg.de>.
Hi Travis,
i haven't read the thread sean mentioned [1], so just the problems which
comes direct into my mind:
Components inside of dataTable can't have a forceId ore you get illegal
html.
Page sniplets to generate repeated used subpages included via @include
into subviews also can't have forceId.
I think there was more which i currently don't remember.
What is the problem with namingcontainers?
I don't have a problem giving each namingcontainer component an defined
(speaking) id, then i have for each component a garanted id which can be
used in scripts.
I think i should read this tread.
[1] http://www.mail-archive.com/users@myfaces.apache.org/msg00680.html
Regards,
Volker
Travis Reeder wrote:
> Volker: why do you think forceId causes more problems than it solves?
> IMHO, it's the opposite, the naming containers cause way more problems
> than they solve.
>
> Travis
>
--
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.
Re: Something like forceId for regular components?
Posted by Travis Reeder <tr...@gmail.com>.
Volker: why do you think forceId causes more problems than it solves? IMHO,
it's the opposite, the naming containers cause way more problems than they
solve.
Travis
On 1/6/06, Volker Weber <us...@weber-oldenburg.de> wrote:
>
> Hi,
>
> can't you use these created ids in you javascript?
>
> If you set a id to the form component, and to all other namingContainer
> components, you will get defined ids for all your components and can
> work with them in your scripts.
>
> IMHO forceId makes more problems than it solves.
>
> Regards
> Volker
>
> Marti, Adrian (Adrian) wrote:
> > Hello all,
> >
> >
> >
> > First post, hopefully not too common a question.
> >
> >
> >
> >
> >
> > Working on a project with a lot of preexisting javascript
> > functions where the id's of components need to be exactly what is
> > expected. JSF seems to want to prefix all of my component id's with the
> > form id.
> >
> >
> >
> > Such as
> >
> > <h:form id="acctform">
> >
> >
> >
> > <h:inputText id="firstInput" … />
> >
> > … </h:form>
> >
> >
> >
> > Will show up in the html with an id="acctform:firstInput".
> > This obviously breaks the javascript. I have found the forceId attribute
> > for Tomahawk components but haven't seen anything for the regular
> > components. Anyone have any advice?
> >
> >
> >
> >
> >
> > Thanks,
> >
> > Adrian
> >
> >
> >
> >
> >
>
> --
> Don't answer to From: address!
> Mail to this account are droped if not recieved via mailinglist.
> To contact me direct create the mail address by
> concatenating my forename to my senders domain.
>
Re: Something like forceId for regular components?
Posted by Volker Weber <us...@weber-oldenburg.de>.
Hi,
can't you use these created ids in you javascript?
If you set a id to the form component, and to all other namingContainer
components, you will get defined ids for all your components and can
work with them in your scripts.
IMHO forceId makes more problems than it solves.
Regards
Volker
Marti, Adrian (Adrian) wrote:
> Hello all,
>
>
>
> First post, hopefully not too common a question.
>
>
>
>
>
> Working on a project with a lot of preexisting javascript
> functions where the id’s of components need to be exactly what is
> expected. JSF seems to want to prefix all of my component id’s with the
> form id.
>
>
>
> Such as
>
> <h:form id=”acctform”>
>
>
>
> <h:inputText id=”firstInput” … />
>
> … </h:form>
>
>
>
> Will show up in the html with an id=”acctform:firstInput”.
> This obviously breaks the javascript. I have found the forceId attribute
> for Tomahawk components but haven’t seen anything for the regular
> components. Anyone have any advice?
>
>
>
>
>
> Thanks,
>
> Adrian
>
>
>
>
>
--
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.
Re: Something like forceId for regular components?
Posted by Sean Schofield <se...@gmail.com>.
One issue that I just remembered is for elements inside UIDataTable.
There are usecases where you would want a reliable naming scheme for
those elements (like you have in Struts.) A custom form component
can't help you there.
Sean
On 1/6/06, Sean Schofield <se...@gmail.com> wrote:
> > ADF Faces provides a form component that isn't a naming container, for
> > exactly this reason. You might consider taking MyFaces' implementation
> > of h:form as a starting point and creating your own equivalent. Not sure
> > how involved that would be.
>
> That's an interesting approach. We might want to adopt something like
> that in MyFaces. I believe you would still have a problem with Tiles
> and subviews though.
>
> > L.
>
> Sean
>
Re: Something like forceId for regular components?
Posted by Sean Schofield <se...@gmail.com>.
> ADF Faces provides a form component that isn't a naming container, for
> exactly this reason. You might consider taking MyFaces' implementation
> of h:form as a starting point and creating your own equivalent. Not sure
> how involved that would be.
That's an interesting approach. We might want to adopt something like
that in MyFaces. I believe you would still have a problem with Tiles
and subviews though.
> L.
Sean
Re: Something like forceId for regular components?
Posted by Laurie Harper <la...@holoweb.net>.
Marti, Adrian (Adrian) wrote:
> Hello all,
>
>
>
> First post, hopefully not too common a question.
>
>
>
>
>
> Working on a project with a lot of preexisting javascript
> functions where the id's of components need to be exactly what is
> expected. JSF seems to want to prefix all of my component id's with the
> form id.
>
>
>
> Such as
>
> <h:form id="acctform">
>
>
>
> <h:inputText id="firstInput" ... />
>
> ... </h:form>
>
>
>
> Will show up in the html with an id="acctform:firstInput".
> This obviously breaks the javascript. I have found the forceId attribute
> for Tomahawk components but haven't seen anything for the regular
> components. Anyone have any advice?
ADF Faces provides a form component that isn't a naming container, for
exactly this reason. You might consider taking MyFaces' implementation
of h:form as a starting point and creating your own equivalent. Not sure
how involved that would be.
L.
Re: Something like forceId for regular components?
Posted by Sean Schofield <se...@gmail.com>.
Adrian,
Thanks for the post. I had the same exact problem as you did and
that's why I came up with forceId. One of the programmers on my team
made the observation that the EG must not use a lot of javascript
because this is essential for webapps with a lot of javascript.
Unfortunately the standard components cannot be changed to include
this functionality. This is because they would no longer be compliant
with the spec. There are some changes to the upcoming spec that will
attempt to deal with this.
So you are stuck with the tomahawk components if you want this type of
behavior. (Or apparently ADF is an option as well.)
Sean
On 1/5/06, Marti, Adrian (Adrian) <am...@avaya.com> wrote:
>
>
>
> Hello all,
>
>
>
> First post, hopefully not too common a question.
>
>
>
>
>
> Working on a project with a lot of preexisting javascript
> functions where the id's of components need to be exactly what is expected.
> JSF seems to want to prefix all of my component id's with the form id.
>
>
>
> Such as
>
> <h:form id="acctform">
>
>
>
> <h:inputText id="firstInput" … />
>
> … </h:form>
>
>
>
> Will show up in the html with an id="acctform:firstInput". This
> obviously breaks the javascript. I have found the forceId attribute for
> Tomahawk components but haven't seen anything for the regular components.
> Anyone have any advice?
>
>
>
>
>
> Thanks,
>
> Adrian
>
>
>
>
Re: h:dataTable with two rows per data row
Posted by Emily Gu <e2...@gmail.com>.
You can. You can use panelGroup or panelGrid inside of column.
On 1/6/06, Robert Parsons <ro...@optushome.com.au> wrote:
>
> Hi,
>
> Is it possible to create a h:dataTable that has two HTML rows per row of
> data? Its just that I want to display a long message that wont fit next
> to all the other columns, as hoping it might be possible to display it
> under the row.
>
> Thanks,
> -Robert.
>
h:dataTable with two rows per data row
Posted by Robert Parsons <ro...@optushome.com.au>.
Hi,
Is it possible to create a h:dataTable that has two HTML rows per row of
data? Its just that I want to display a long message that wont fit next
to all the other columns, as hoping it might be possible to display it
under the row.
Thanks,
-Robert.