[jsr-314-open] Inconsistency between Spec and XSD for include-view-params
by Dan Allen
Neil Griffin is asking about the include-view-params attibute/element in
faces-config.xml. I reply to his inquiry inline.
---------- Forwarded message ----------
> From: Neil Griffin <neil.griffin(a)liferay.com>
> Date: Sat, Aug 1, 2009 at 7:46 PM
> Subject: Inconsistency between Spec and XSD for include-view-params
> To: jsr-314-comments(a)jcp.org
>
> Hi there again Guys,
>
> Section 7.4.3 of the Spec has an example navigation-handler, which shows
> how to use the include-view-params feature:
>
> <redirect>
> <view-param>
> <name>userId</name><value>someValue</value>
> </view-param>
> <include-view-params>true</include-view-params>
> </redirect>
>
> However, using <include-view-params> as an XML element is invalid according
> to web-facesconfig_2_0.xsd
>
Clearly they need to be made the same, one way or another.
>
>
> But then, in section 7.4.2, the Spec talks about the "include-view-params"
> attribute on the <redirect /> element, like this:
>
> <redirect include-view-params="true" />
>
> The attribute syntax is what the XSD wants, and what Ryan's blog [1])
> claims as well.
>
To be hones, I can't remember what the final decision was.
>
> Having said that, if the attribute way is the right syntax, then I think
> there are two problems with it:
>
> 1. Although I prefer attribute-syntax for XML, the faces-config.xml file
> doesn't use XML attributes anywhere.Instead, it uses the verbose
> <element>#PCDATA</element> syntax. So having an attribute on <redirect /> is
> really inconsistent with the rest of the file.
>
False. The root element has "id", "version" and "metadata-complete"
attributes. The "id" attribute is allowed on many other elements as well.
2. it's really inconsistent and weird to have
dashes-in-the-name-of-an-xml-attribute. For example, we use camelCase for
actionListener:
<h:commandButton actionListener="#{myBean.actionListener}" />
Again, false. The dashes in the name of an XML attribute is standard for
Java EE config files. See persistence.xml. The others only have
metadata-complete as an example.
3. The functionality/purpose of this include-view-parameters feature is
really confusing. Does it mean:
A. Include/exclude the f:viewParam stuff found in f:metaData of the
from-view-id?
B. Include/exclude the <view-param> children of the <redirect>
element?
C. Both A & B?
A.
The idea is that when constructing the URL to navigate to, should that URL
be "enhanced" with the view parameters or should it be left as is. The
<view-param> children of the <redirect> element are explicit and should
never be left off. Otherwise, you wouldn't put them there. The view
parameters are considered "magic" in this sense (i.e., not explicit).
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
14 years, 9 months
Re: [jsr-314-open] Providing the ability to instantiate EzCompcomponents in Java code
by Kito Mann
FYI, the component class is determined by the component type already
-- no need to expicitly specify it. In other words, if you specify a
component type for <component:implementation>, the Java class with the
matching type will be used.
Sent from my iPhone
http://www.jsfcentral.com
http://www.Virtua.com
On Aug 2, 2009, at 5:49 PM, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com
> wrote:
> On Sun, 2009-08-02 at 12:04 +0200, Norbert Truchsess wrote:
>> What do you mean by 'multiple class implementations'?
>>
>
> More than one Java Class file per XHTML markup component -- but as
> Kito suggested, I don't see much use in that, so your description of
> specifying the Java class in the <component:interface> sounds good.
14 years, 9 months
