I agree with your point about scripting being "unobtrusive", ie that
ideally it should transparently "attach" to existing objects to enhance
their behaviour without having to modify the original elements, like
subclassing extends a class without modifying it.
However completely breaking the encapsulation of JSF components to do
that is ugly. Really ugly. If you are enough of a "purist" to care about
implementing javascript in an "unobtrusive" manner then surely you care
enough about encapsulation to not break that unless absolutely
necessary. If the page is not composed of multiple fragments, then the
IDs are stable and can be used as-is without forceId; if the page is
being composed from multiple fragments then using forceId couples these
fragments together (risks id collisions).
A tag like the one I suggest which generates a js variable containing
the clientId of a specified component seems to generally meet your
requirement of "unobtrusive", in that it can be placed in the page
independently of the component it references. And it can be applied to
any component, not just Tomahawk ones.
Styles are a different problem; I agree I cannot see any elegant
solution. One choice is to specify styleClass="id_foo" on the element
and then target the style using the class rather than the id. Not very
nice, but is it any more obtrusive than specifying "forceId" on the JSF
component? And at least styleClass is part of the JSF standard.
Regards,
Simon
Stefan Frank wrote:
There are some usecases, where it is really, really useful to have a
definite id on the component and where forceid is needed: eg. if you
want to use tinyMCE as texteditor on a textfield. Using a defined id is
the only solution to style different textfields with different
tinyMCE-Skins.
The onclick-handler and passing this is not a good or even sufficient
solution to this problem: Remember, that this is still markup, not code,
and an unobtrusive way of adding behavior to the elements in a dom-tree
is certainly preferrable to scattering your code over the whole page
(even if it is generated and "only" javascript) - (eg. see
http://alistapart.com/articles/behavioralseparation for a discussion of
unobtrusive javascript)
and unless someone can show up a better way, forceId is currently the
only way to tie hand-written javascript to jsf-components
therefore +0.8 by me, as it is dirty, but useful sometimes.
cheers
stf
2007/4/13, Volker Weber <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>:
i revert to +0.5 because im not realy involved in tomahawk.
But if someone try to introduce forceId to tobago he gets my -1.
I still can't see any reason to use this (except user/password fields
on form based login).
Regards,
Volker
2007/4/13, Volker Weber <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >:
> 2007/4/12, Simon Kitching <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
> > And forceId sucks anyway. I'd like to see it deprecated and
removed from
> > Tomahawk completely.
>
> +1
>
> :-)
>
> Regards,
> Volker
>
> >
> > This is not needed when javascript is invoked from the
"onclick" of a
> > component, which is most of the time. Just pass the "this"
component to
> > the javascript function and resolve the desired component id
relative to
> > the client-id of the component on which the onclick occurred.
> >
> > For the other cases, a tag that outputs the client-id of a target
> > component as a javascript variable is a nicer solution. At
worst, there
> > is a collision of javascript variable names but at least that
doesn't
> > stuff up the JSF component ids.
> >
> > Regards,
> >
> > Simon
> >
> > Mike Kienenberger wrote:
> > > Probably because facelets detects valid attributes by looking
for a
> > > concrete getter.
> > >
> > > ForceId is implemented as a generic getter, so facelets will
never be
> > > able to find a "getForceId()" method on a component. You
can ignore
> > > the warning as facelets will just set/get using the generic
method
> > > when the concrete method fails. Maybe some point down the
road it
> > > might be worthwhile to see facelet taglib files identify these
> > > "hidden" attributes, but functionally, it'll work just fine
as is.
> > > Having to add these to the taglib files starts to make it too
much
> > > like jsp busywork :-)
> > >
> > > On 4/12/07, [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
> > >> Don't know if this has been discussed here before...
> > >>
> > >> I am getting warnings that the 'forceId' attribute is not on
various
> > >> types, e.g.,
org.apache.myfaces.component.html.ext.HtmlInputText. I
> > >> recently ported to facelets and I don't remember seeing this
warning
> > >> when I was just using myfaces alone.
> > >>
> > >> I saw a work-around, but I am wondering whether I have to do
some
> > >> additional configuration.
> > >>
> >
> >
>
