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
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
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 [EMAIL PROTECTED] wrote:
There is one very,
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
No, I haven't!
That works?
cool, that was the new thing I learned for today ;)
regards,
Martin
On 1/7/06, Laurie Harper [EMAIL PROTECTED] wrote:
Martin, have you tried changing your selector to
#formId\:namingContainerId\:myComponentId
i.e. escaping the colons?
Martin Marinschek
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
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
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
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 [EMAIL PROTECTED] wrote:
ADF Faces
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
Thanks for the replies everyone, appreciate it. I'll probably try and go
with the tomahawk components for now.
Adrian
-Original Message-
From: Sean Schofield [mailto:[EMAIL PROTECTED]
Sent: Friday, January 06, 2006 11:43 AM
To: MyFaces Discussion
Subject: Re: Something like forceId
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. TravisOn 1/6/06,
Volker Weber [EMAIL PROTECTED] wrote:
Hi,can't you use these created ids in you _javascript_?If you set a id to the form
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
: Something like forceId for regular components?
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
On 1/6/06, Simon Kitching [EMAIL PROTECTED] wrote:
I also dislike the forceId function. It's not a good solution IMHO,because it merges the concepts of HTML ids and JSF ids, thus losing theabiility to safely compose pages from JSF fragments.I have been vaguely thinking about solutions for this,
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
Hello all,
First post, hopefully not too common
a question.
Working
on a project with a lot of preexisting _javascript_ functions where the ids
of components need to be exactly what is expected. JSF seems to want to prefix
all of my component ids with the form id.
Such
as
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
18 matches
Mail list logo
