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
<[EMAIL PROTECTED]> 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 <[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
> 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 <[EMAIL PROTECTED]>
> 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
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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
> <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
> __________________________________ Do you Yahoo!? The all-new My Yahoo! -
> What will yours do? http://my.yahoo.com -- -Heath Borders-Wing
> [EMAIL PROTECTED]
> -- Travis Reeder Ecommstats Web Analytics www.ecommstats.com
--
-Heath Borders-Wing
[EMAIL PROTECTED]
