Is this now possible?

Question

The tutorial mentions:
//BEGIN////////////////////////////////////
A command_hyperlink tag can contain parameter tags that will cause an HTML <input type=hidden> element to be rendered. This input tag represents a hidden control that stores the name and value specified in the parameter tags between client/server exchanges so that the server-side classes can retrieve the value. The following two tags show command_hyperlink tags that submit ActionEvents. The first tag does not use parameters; the second tag does use parameters.
<h:command_hyperlink id="commandParamLink" commandName="login"
commandClass="LoginListener" label="link text"/>
<h:command_hyperlink id="commandParamLink" commandName="login"
commandClass="LoginListener" label="Login">
<f:parameter id="Param1" name="name"
valueRef="LoginBean.name"/>
<f:parameter id="Param2" name="value"
valueRef="LoginBean.password"/>
</h:command_hyperlink>
//END//////////////////////////////////////////////////////////
The command_hyperlink is probably now command_link. (docs not updated yet) in Beta 1
The question is: Is it possible to include parameters in this fashion with h:command_button tag?
Just curious as I don't have access to my dev machine to try this out.
Also, I haven't seen any templatization of the Renderers. The rendered code is still hardcoded. But there are many new parameters that should help.
Thanks,
Vinay

Answer 1

>
>
The tutorial mentions:
//BEGIN////////////////////////////////////
A command_hyperlink tag can contain parameter tags
that will cause an HTML <input type=hidden> element to
be rendered. This input tag represents a hidden
control that stores the name and value specified in
the parameter tags between client/server exchanges so
that the server-side classes can retrieve the value.
The following two tags show command_hyperlink tags
that submit ActionEvents. The first tag does not use
parameters; the second tag does use parameters.
<h:command_hyperlink id="commandParamLink"
commandName="login"
commandClass="LoginListener" label="link text"/>
<h:command_hyperlink id="commandParamLink"
commandName="login"
commandClass="LoginListener" label="Login">
<f:parameter id="Param1" name="name"
valueRef="LoginBean.name"/>
<f:parameter id="Param2" name="value"
valueRef="LoginBean.password"/>
</h:command_hyperlink>
//END//////////////////////////////////////////////////
The command_hyperlink is probably now command_link.
(docs not updated yet) in Beta 1
There are now two different tags that can create hyperlinks:
* <h:command_link> creates a hyperlink that acts like a submit button,
and sends the form in which it is embedded.
* <h:output_link> creates a hyperlink that links to an arbitrary URL.
This tag accepts nested <f:parameter> tags to add name/values
query parameters.
The question is: Is it possible to include parameters
in this fashion with h:command_button tag?
Neither <h:command_link> nor <h:command_button> can include nested <f:parameter> tags, because they simply submit the form they are nested inside. Therefore, you can easily convey additional values to the server by setting up hidden input fields in the form, and manipulating their values appropriately.
The new <h:output_link> lets you create a hyperlink to any arbitrary URL via the "href" parameter, and this tag does accept nested <f:parameter> tags to add query parameters.
Just curious as I don't have access to my dev machine
to try this out.
Also, I haven't seen any templatization of the
Renderers. The rendered code is still hardcoded. But
there are many new parameters that should help.
It turns out that templating is not helpful in making Renderers easier to write. I tried, for example, experiments in using JSP (with JSTL tags) as a sort of templating mechanism, but the resulting JSP code was much uglier than the corresponding Java code. Why? Because all of the standard renderers do a lot of conditional inclusion of output, and a Java "if" statement is much more concise than the JSP equivalent. I'm open to concrete suggestions on how one might design a templating system better than this, but it is difficult for me to believe that it's going to be better than the current scheme.
Renderers are classes whose purpose is to render markup for some specific markup language. The design objective should be to make it as easy as possible to write such things. In addition, Renderers are developed by component writers who are already famliar with Java -- they are generally not created by page authors. Further, templating is only half the story -- a renderer is also responsible for decoding the request parameters if you are supporting an input component, so you're going to need to write some logc anyway in those scenarios.
What we did introduce in the PFD, however, was a complete implementation of the structured output methods that were defined on ResponseWriter. For example, the encodeBegin() method for the Renderer used by the <h:output_link> method includes things like:
String href = ... the URL to be linked to ...;
writer.startElement("a", component);
writer.writeURIAttribute("href", href, "href");
Where the arguments to the startElement() method are the markup element to be created, and a reference to the component that is triggering the generation of this element, and the arguments to writeURIAttribute() are the attribute name, the attribute value (in this case known to be a URI, so it gets filtered as necessary automatically, and the property or attribute name from the original component that caused the creation of this attribute in the generated markup.
So, why do you want to bother with the last arguments on these two calls? Well, you can pass null if you are lazy, but passing the correct information makes it possible for development tools to visually render your component at design time (to the page author), and then interpret from where the user clicks the mouse which component's property sheet to show you. Well designed renderers will take pains to provide this information to development tools so that the user experience of someone creating a page with your components is made as good as possible.
Thanks,
VinayCraig McClanahan