10:27 a.m.
>>>> On Sun, 28 Mar 2010 21:21:10 -0500, Leonardo Uribe
<lu4242(a)gmail.com> said:
LU> The problem is why it is mandatory to set "javax.faces.Composite" as
LU> renderer type. The javadoc should say:
LU> "...If the renderer type is not set (return null), Call
LU>
UIComponent.setRendererType(java.lang.String)<file:///D:/jdk-1_5_0-doc/jsf20/mojarra-2.0.3-SNAPSHOT/docs/javadocs/javax/faces/component/UIComponent.html#setRendererType%28java.lang.String%29>on
LU> the
LU> UIComponent instance, passing "javax.faces.Composite" as the
argument...".
LU> In that case, a user can override the rendererType on the constructor and
LU> avoid this hack that works with the current spec:
I understand the problem you have uncovered. Take a look at the
renderkit docs for javax.faces.NamingContainer/javax.faces.Composite.
There are specific requirements in there that depend on the composite
component metadata specification.
I thought it would be toooooooo subtle to allow the Renderer to be
customized beause this contract must also be followed in the custom
renderer case.
LU> Why override the default Renderer and use a custom one? Let's
LU> suppose the component proposed needs some custom code for converter,
LU> or for decode. The right place to put that kind of code is the
LU> Renderer class, not the component, but note it is possible to put
LU> that on the component class.
Yes I understand that the Renderer is the right place for such things
but the chosen programming model for customization of composite
components is to override the top level component. Simple. If we're
going to change that I need a more compelling reason than correctness.
Ed
--
| edward.burns(a)oracle.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
12:12 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] Use a Renderer on a composite component
2010/3/29 Ed Burns <edward.burns(a)oracle.com>
>>>>> On Sun, 28 Mar 2010 21:21:10 -0500, Leonardo
Uribe <lu4242(a)gmail.com>
said:
LU> The problem is why it is mandatory to set "javax.faces.Composite" as
LU> renderer type. The javadoc should say:
LU> "...If the renderer type is not set (return null), Call
LU>
UIComponent.setRendererType(java.lang.String)<file:///D:/jdk-1_5_0-doc/jsf20/mojarra-2.0.3-SNAPSHOT/docs/javadocs/javax/faces/component/UIComponent.html#setRendererType%28java.lang.String%29>on
LU> the
LU> UIComponent instance, passing "javax.faces.Composite" as the
argument...".
LU> In that case, a user can override the rendererType on the constructor
and
LU> avoid this hack that works with the current spec:
I understand the problem you have uncovered. Take a look at the
renderkit docs for javax.faces.NamingContainer/javax.faces.Composite.
There are specific requirements in there that depend on the composite
component metadata specification.
I thought it would be toooooooo subtle to allow the Renderer to be
customized beause this contract must also be followed in the custom
renderer case.
LU> Why override the default Renderer and use a custom one? Let's
LU> suppose the component proposed needs some custom code for converter,
LU> or for decode. The right place to put that kind of code is the
LU> Renderer class, not the component, but note it is possible to put
LU> that on the component class.
Yes I understand that the Renderer is the right place for such things
but the chosen programming model for customization of composite
components is to override the top level component. Simple. If we're
going to change that I need a more compelling reason than correctness.
The current behavior of javax.faces.NamingContainer/javax.faces.Composite
renderer says that everything
inside the facet UIComponent.COMPOSITE_FACET_NAME should be rendered. But
sometimes
the markup of the component changes according to its inner state. One simple
example is
h:commandLink. If this component is disabled, it should be rendered a <span>
instead use <a>.
Other example is tomahawk displayValueOnly property, that when is set to
true, only the value
needs to be rendered.
Ok, if I have a composite component the first thought is use c:if tag, but
remember that with
partial state saving enabled this tag is evaluated when the view is build,
not when it is
rendered. Other alternative is use a component that allows to render one
child at the time, and
it is on myfaces commons (mc:renderOne, old sandbox s:limitRendered). The
third alternative is
use a custom renderer. The example I'm trying to do is this (all non
relevant code has been removed:
public void encodeEnd(FacesContext context, UIComponent component)
throws IOException
{
UIComponent compositeFacet = (UIComponent) component
.getFacet(UIComponent.COMPOSITE_FACET_NAME);
CompositeInputHtml editor = (CompositeInputHtml) component;
if( HtmlRendererUtils.isDisplayValueOnly(editor) )
{
encodeDisplayValueOnly(context, editor);
}
else if ( useFallback(editor) )
{
encodeEndFallBackMode(context, editor);
}
else
{
if( ! isVisible(editor) ){
encodeHidden(context, editor);
}
else if( ! hasAnotherPropertyThatPreventsRenderThisOneCorrectly(
context ) )
{
compositeFacet.encodeAll(context);
}
else
{
encodeEndFallBackMode(context, editor);
}
}
}
It is possible to think in other cases, like a composite component like
this:
<composite:implementation>
<f:facet name="normal">
......some html markup......
</f:facet>
<f:facet name="disabled">
......some html markup......
</f:facet>
<f:facet name="special">
......some html markup......
</f:facet>
<composite:implementation>
And use a custom renderer to control when one or other facet should be
rendered.
Note that in fact, with the hack on the component class on setRendererType,
it is possible
to override the Renderer without problem, so for my particular problem I can
live with it.
The question is if the spec should enforce the use of
javax.faces.NamingContainer/javax.faces.Composite renderer for composite
components
or not.
Leonardo
Ed
--
| edward.burns(a)oracle.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
5:10 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] Use a Renderer on a composite component
Hi Leonardo,
Ok, if I have a composite component the first thought is use c:if
tag, but
remember that with
partial state saving enabled this tag is evaluated when the view is build,
not when it is
rendered. Other alternative is use a component that allows to render one
just to get this straight, cause I seemed to read this (IMHO, wrong
assertion) several times from you already: c:if, c:forEach and
ui:include _should_ be evaluated before rendering again. This is in
Mojarra as of 2.0.3 (Ed, Ryan, correct me if I am wrong) and it should
be in MyFaces as well, right?
Anyway I support your basic motion: it would generally be good to be
able to exchange the renderer as well.
best regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
5:18 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] Use a Renderer on a composite component
On 3/29/10 5:10 PM, Martin Marinschek wrote:
Hi Leonardo,
> Ok, if I have a composite component the first thought is use c:if tag, but
> remember that with
> partial state saving enabled this tag is evaluated when the view is build,
> not when it is
> rendered. Other alternative is use a component that allows to render one
>
just to get this straight, cause I seemed to read this (IMHO, wrong
assertion) several times from you already: c:if, c:forEach and
ui:include _should_ be evaluated before rendering again. This is in
Mojarra as of 2.0.3 (Ed, Ryan, correct me if I am wrong) and it should
be in MyFaces as well, right?
Haven't had a chance to review this entire thread (or any other recent
threads - sorry!), but just wanted to jump in to say that, yes, Ryan has
implemented an initial fix for this as part of this issue:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1313
Would be good to do some additional testing with our various test cases
just to make sure that all is well.
Andy
Anyway I support your basic motion: it would generally be good to be
able to exchange the renderer as well.
best regards,
Martin
9:53 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] Use a Renderer on a composite component
2010/3/29 Andy Schwartz <andy.schwartz(a)oracle.com>
On 3/29/10 5:10 PM, Martin Marinschek wrote:
> Hi Leonardo,
>
>
>
>> Ok, if I have a composite component the first thought is use c:if tag,
>> but
>> remember that with
>> partial state saving enabled this tag is evaluated when the view is
>> build,
>> not when it is
>> rendered. Other alternative is use a component that allows to render one
>>
>>
>
> just to get this straight, cause I seemed to read this (IMHO, wrong
> assertion) several times from you already: c:if, c:forEach and
> ui:include _should_ be evaluated before rendering again. This is in
> Mojarra as of 2.0.3 (Ed, Ryan, correct me if I am wrong) and it should
> be in MyFaces as well, right?
>
>
Haven't had a chance to review this entire thread (or any other recent
threads - sorry!), but just wanted to jump in to say that, yes, Ryan has
implemented an initial fix for this as part of this issue:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1313
Would be good to do some additional testing with our various test cases
just to make sure that all is well.
Ok, that's great!. That means we need to make myfaces evaluate c:if,
c:forEach and ui:include as default, not as an option activated by a param,
like in myfaces right now. Thanks for the tip.
regards,
Leonardo Uribe
Andy
Anyway I support your basic motion: it would generally be good to be
> able to exchange the renderer as well.
>
> best regards,
>
> Martin
>
>
>
10:59 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] Use a Renderer on a composite component
Hi
The discussion here went in other direction. I created an issue of the
original proposal here:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=797
regards,
Leonardo Uribe
5188
days inactive
5234
days old
jsr-314-open-mirror@lists.jboss.org
5 comments
4 participants
participants (4)
-
Andy Schwartz -
Ed Burns -
Leonardo Uribe -
Martin Marinschek