Just wanted to let everyone know that I have implemented a "forceId"
attribute on the MyFaces extended components. This allows you to
specify the id to be used for the elements and ignores the wacky JSF
version of the tag. It also adds a '[row index]' suffix to elements
inside dataTable (like St
> ...I am glad someone else raised this issue, it was quite a disappointment
> to have to
> write our javascript differently than we have been doing for the last few
> years.
I knew I was not alone! I think there is enough momentum to go
forward with the fix I was proposing. Heath is already w
Title: RE: Javascript getElementById Issues
I raised this issue a while back in a previous thread, because our current application contains
a lot of _javascript_ and dhtml. There were no real solutions proposed so we had
to write some really evil code in order to attain dynamic elements in a
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
tag, but you can still pass in as many as you'
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
> 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.
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 switchin
+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
ign
> 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.
> Ch
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.
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 anywa
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 ca
> 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
f
> 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 som
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 -
The 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 tag and that
of the enableOrNot() function. Of course, the tag is
powerful enough to allow for additions to the global namespace
On Sun, 2 Jan 2005, Sean Schofield wrote:
What the tag would have to do is search its body content
for ids specified in the tag and replace them with
the clientId's of the components specified in the
's "for" attribute.
Thoughts?
I'm personally not too wild about this. Why do we want to subject
> 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 pea
#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
> What the tag would have to do is search its body content
> for ids specified in the tag and replace them with
> the clientId's of the components specified in the
> 's "for" attribute.
>
> Thoughts?
I'm personally not too wild about this. Why do we want to subject the
user to all of this extr
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
> 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 li
With regards to javascript, here is an extended solution:
Let's say you have the following JSP code:
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 cl
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
> 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 t
> 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
wou
On Sun, 2 Jan 2005 18:04:27 -0500, Sean Schofield
<[EMAIL PROTECTED]> 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
> > dec
I'm wondering if there's a way we could make an 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:
Then you use the x:script like so:
function foo(){
myInput.value = "xyz";
}
And x:scri
> 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 co
On Sat, 1 Jan 2005 10:56:40 -0600, Heath Borders
<[EMAIL PROTECTED]> 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
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
<[EMAIL PROTECTED]> wrote:
> > Yes, Myfaces would still be following the spec f
> 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
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 tha
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 tag and the tag are great ideas as well.
Thanks all,
RaySean Schofield <[EMAIL PROTECTED]> wrote:
> No, it is only use
> 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 wou
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 <[EMAIL PROTECTED]> wrote:
> Is the clientId in the component used for anything
> other
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 <[EMAIL PROTECTED]> wrote:
> I'm in favor of doing this, though I don't think
> I'll
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 <[EMAIL PROTECTED]> wro
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
<[EMAIL PROTECTED]> wrote:
> > A possible sol
> 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 t
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
th
On Thu, 30 Dec 2004 09:51:49 -0500, Sean Schofield
<[EMAIL PROTECTED]> 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 r
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 tha
> 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 wou
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
On Thu, 30 Dec 2004 12:04:39 -0500, Sean Schofield
<[EMAIL PROTECTED]> 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 wr
[EMAIL PROTECTED]
> 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
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
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.
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
50 matches
Mail list logo
