Re: [jsr-314-open-mirror] [jsr-314-open] composite:attribute "targets" property does not match with ViewDeclarationLanguage.retargetMethodExpressions
by Ed Burns
>>>>> On Mon, 18 Oct 2010 20:36:06 -0500, Leonardo Uribe <lu4242(a)gmail.com> said:
[...]
LU> There are two possible alternatives here:
LU> 1. Implement the algorithm proposed for retargetMethodExpressions
LU> and ignore composite:attribute "targets" property says.
LU> 2. Implement the expected behavior of composite:attribute "targets"
LU> property and make some changes to retargetMethodExpressions
LU> algorithm.
LU> The intention is take option 2 and include it for JSF 2.0, because
LU> in theory should be handled as an implementation detail of the
LU> algorithm (anyway it could be good to update the documentation with
LU> the same advice used for retargetAttachedObjects).
Certainly you have identified a valid issue. The root problem is that
the top level component needs to have a Java programming way to expose
its composite-ness.
LU> For "action", "actionListener", "validator" and
LU> "valueChangeListener" it is clear that the action to take is
LU> something like this:
LU> - If target is a composite component and that one "retarget" to
LU> other components and additionally does not implements
LU> [ActionSource2/EditableValueHolder], call:
LU> targetComponent.getAttributes().put(attributeName,
LU> attributeNameValueExpression);
LU> and call retargetMethodExpressions recursively. Take care of
LU> apply the method twice and if the property pointed by
LU> "attributeName" was already set, revert its effects.
The solution you propose will work, but it feels a bit too
implementation-ish. Right now we declare that every compositeComponent
must be a NamingContainer. Perhaps it's time to define a new abstract
sub-class of NamingContainer that is a union of all the behavioral
interfaces?
public abstract class javax.faces.component.CompositeComponent
implements NamingContainer, ActionSource2, EditableValueHolder {
public abstract void acceptRetargetedMethodExpressions(BeanInfo
ccMetadata);
}
LU> The tricky part is how to handle generic method expression
LU> properties. The javadoc says:
We could specify whatever we needed in that
acceptRetargetedMethodExpressions() method.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 16 work days until German Oracle User's Group Conference
14 years, 2 months
[jsr-314-open-mirror] [jsr-314-open] [853-cc:clientBehaviorDocumentation] RESOLVED (was: Re: [2.1 Spec Review] composite:clientBehavior still missing)
by Ed Burns
Summary:
Thank you David for rescuing this from the cracks of obscurity. I have
fixed it in the latest HEAD (Revision 8679 (Jenny)) and have uploaded a
snapshot of the VDLDocs to [5].
The JCP MR Provenance of this issue is very muddy. It should have been
in 2.0, we had it in 2.0 Rev a, should have put it into 2.1, but it was
overlooked and rescued thanks to David. I really want to just get this
done, so I want to generalize the existing issue on the changelog, 850,
to cover this.
Details:
>>>>> On Thu, 21 Oct 2010 09:16:58 -0600, David Geary <clarity.training(a)gmail.com> said:
DG> I don't see this in the 2.1 spec. I'd be happy to write something.
Thanks, David. This issue had fallen through the cracks.
According to Mojarra issue 771 [1], 'This is already documented in the
ChangeLog (See "JSF 2.NEXT ChangeLog Wiki" link at right) as issue
C026.'
I looked at the wiki, only to find that several edits had been made by
people I've never heard of. This was spam vandalism and it wiped out
the wiki entry, making it effectively invalid. I have removed the
content of the wiki page, pointing instead to the non-editable page at
JCP.org. Looking in the history, I see that it was indeed in the wiki
[2] and referred to issue 853 [3]. To make things even more confusing,
there is still yet another issue, 791 [1].
The definitive issue now 853, which I have marked as fixed.
[1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=771
[2] http://wiki.jcp.org/wiki/page_history.php?page_id=47&diff2=279
[3] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=853
[4] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=791
[5] https://javaserverfaces-spec-public.dev.java.net/files/documents/1936/153...
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 13 work days until German Oracle User's Group Conference
14 years, 2 months
[jsr-314-open-mirror] [jsr-314-open] [jsf 2.1 Spec Review] javax.faces.ViewState in jsf.ajax.html
by Werner Punz
Hello After reviewing a section which was problematic in the past, I want to
comment on the viewstate handling again:
jsf.ajax.html
<update id="javax.faces.viewstate">
locate and update the submitting form's javax.faces.ViewState value with the
CDATA contents from the response. Locate and update the
javax.faces.ViewState value for all forms specified in the render target
list.
Does this really suffice, what if the element is not a form, what if the
form is inside a render target or outside a render target. Currently in
myfaces we deal with those cases because the viewstate needs to be updated
wether the target element is a form or not.
What happens if you only execute but dont render? Or if you execute in one
form and render in another?
Werner
14 years, 2 months
Re: [jsr-314-open-mirror] [jsr-314-open] [Mojarra-1812-FacesServlet.service] PROPOSAL
by Ed Burns
Summary:
Strictly speaking this is a Mojarra issue, not a spec issue. There are
spec implications, but these were addressed during 2.0 Rev a.
Details:
>>>>> On Wed, 20 Oct 2010 21:10:17 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> you never responded to this, but I see on the patch for 1512 that you
MM> implemented Blake's suggestion. Is this right?
Here is what we did to address this. The spec portion of this issue is
very simple.
In 2.0 Rev a we modified the last sentence in FacesServlet.service to
say:
The implementation must make it so FacesContext.release() is called
within a finally block as late as possible in the processing for the
JSF related portion of this request.
The implementation portion is more complicated. As a convenience to app
developers, Ryan made an implementation decision in Mojarra 2.0 to
agressively dirty session scoped managed beans by providing an
HttpServletRequestListener.requestDestroyed() impl that did the
dirtying. Blake pointed out that this was in poor taste and also bad
for performance. In Mojarra 2.1 I elected to make this behavior only
happen when you specify the impl specific context param
com.sun.faces.enableAgressiveSessionDirtying.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 14 work days until German Oracle User's Group Conference
14 years, 2 months
Re: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
by Ed Burns
Executive Summary:
* Andy comments on the new Chapter 11, basically stating that we don't
need it.
* Ed replies stating that that Dan had requested full XML syntax, but
that Ed is willing to remove chapter 11 for now and simply rely on
what we have in the appendix regarding the facelets-processing elemens
in the faces-config-extension element.
>>>>> On Mon, 18 Oct 2010 17:25:25 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> Ed, All -
AS> I have finally started reviewing the pdf, including the new chapter 11:
AS> "The JSF XML View Syntax". Unfortunately, while reviewing this chapter
AS> I felt very lost.
AS> The chapter opens with:
>> As of version 2.1 of this specification, JavaServer Faces
>> implementations must support (although JSF-based applications need not
>> utilize) using plain XML as a View Declaration Language (VDL).
AS> I didn't realize that we were introducing a new VDL. I thought that our
AS> efforts have been focused on allowing the existing Facelets VDL to be
AS> more XML-friendly by providing control over XML processing behavior.
This is what Dan Allen has wanted all along. It was very clearly stated
in his requests and emails to this list.
>> The main difference between using XML as a VDL and using Facelets is
>> that the XML syntax does not support HTML template text. In other
>> words, every element in a facelets XML page must be a JSF UI
>> component. There is no facility for automatically generating transient
>> UIComponent instances from template text. If you want this facility,
>> use Facelets as your VDL.
AS> The differences that we have been discussing between legacy
AS> xhtml-centric Facelets and the new xml-centric approach are related to
AS> processing of XML-centric constructs such as CDATA blocks, XML
AS> declarations, processing instructions, etc... I didn't realize that we
AS> would also be changing how HTML template text/tags were handled. If
AS> this means that you cannot use HTML elements in the new XML views, my
AS> guess is that nobody will be interested in adopting this approach.
I thought so too, but that seems to be what Dan wanted so that's what I
put in the spec.
>> First note the outer-most <faces-view> element. In Facelets, the
>> outer-most element is normally the <html> element. In Facelets, the
>> <html> element is where the taglibs used in the page are declared. In
>> the Faces XML VDL, the <faces-view> element is the outer-most element
>> and here is where the taglibs used are declared.
AS> One small but important feature that folks seemed to like about Facelets
AS> is that it made the <f:view> optional. If we now require a new
AS> top-level element, my guess is that many people will find this to be a
AS> step backwards.
I'm certainly open to dropping this requirement. In fact, I have
modified Mojarra so that you can have the following as valid
jsf.view.xml syntax.
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html">
<h:head><h:title>Raw XML View</h:title></h:head>
<h:body>
<h2>XML declaration: consumed</h2>
<h2>Processing instruction: consumed</h2>
<?xml-stylesheet href="funky.xsl" type="text/xml" alternate="yes"?>
<h2>CDATA section: consumed</h2>
<![CDATA[ <p>This is CDATA</p> ]]>
<h2>Inline text escaping: escaped</h2>
<code>
<br/>
&lt;context-param&gt;
<br/>
&nbsp;&nbsp;&lt;param-name&gt;javax.faces.PARTIAL_STATE_SAVING
&lt;/param-name&gt;
<br/>
&nbsp;&nbsp;&lt;param-value&gt;true&lt;/param-value&gt
;
<br/>
&lt;/context-param&gt;
</code>
<h2>Comments: consumed</h2>
<!-- comments consumed -->
<h:form prependId="false" id="form">
<h:panelGrid id="grid" column="2">
<h:outputText id="text" value="hello"></h:outputText>
<h:commandButton id="button" value="reload"></h:commandButton>
</h:panelGrid>
#{processAsJspxBean.prop}
<p>html template text</p>
</h:form>
</h:body>
</html>
AS> I find section 11.2, "Java Programming Language Specification for Faces
AS> XML Views" to be overly detailed and difficult to read, eg:
[...]
AS> I would prefer that we focus on the approach that is currently outlined
AS> in Apendix A, section 1.2.1.1 ("The facelets-processing element") and
AS> avoid introducing a new VDL as described in chapter 11.
AS> BTW, if we are introducing a new VDL, one thing that is missing is any
AS> mention of how to map views to this VDL - ie. there is no equivalent of
AS> the javax.faces.FACELETS_VIEW_MAPPINGS. Though based on the concerns
AS> that Leonardo raised on our other active thread, rather than introduce
AS> additional context parameters for this sort of thing, we should look
AS> into a generic faces-config-based VDL registration mechanism.
Unless anyone disagrees, I'll remove chapter 11, perhaps we can revisit
this at such time as JBoss is able to contribute again to these
discussions.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 16 work days until German Oracle User's Group Conference
14 years, 2 months
Re: [jsr-314-open-mirror] [jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
by Ed Burns
>>>>> On Mon, 11 Oct 2010 16:01:25 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> I had to take another look at the doc/code for the various context
AS> parameters in this area. My understanding is:
AS> - The "javax.faces.FACELETS_SUFFIX" context parameter specifies a single
AS> file extension that is mapped to the Facelets engine. This defaults to
AS> the ViewHandler.DEFAULT_FACELETS_SUFFIX value (ie. ".xhtml").
AS> - The "javax.faces.FACELETS_VIEW_MAPPINGS" context parameter allows
AS> multiple extensions/prefixes to be mapped to the Facelets engine. This
AS> context parameter has no default value.
AS> To be honest, it isn't clear to me why two context parameters were
AS> necessary, since it seems that FACES_VIEW_MAPPINGS is more general than
AS> FACELETS_SUFFIX, though I suppose we just inherited this from Facelets 1.x.
This is correct.
AS> With the default values as specified above, .view.xml extensions will
AS> not not routed to the Facelets engine. Instead, the application must
AS> explicitly specify this mapping via the FACELETS_VIEW_MAPPINGS context
AS> parameter. If we want to embrace this new file extension more fully, we
AS> either need to:
AS> - Enhance the DEFAULT_FACELETS_SUFFIX context parameter to allow it to
AS> support multiple values + change the default value to ".xhtml
AS> .view.xml". Or...
AS> - Specify a default value for the FACELETS_VIEW_MAPPINGS context parameter.
AS> Either of these seem acceptable to me.
I am reluctant to bind .view.xml to be "Facelets". Yes, right now
Mojarra is using the Facelets VDL impl to process .view.xml but I'd
rather leave the DEFAULT_FACELETS_SUFFIX and FACELET_VIEW_MAPPINGS
unchanged for 2.1. Note that I did change the value of
ViewHandler.DEFAULT_SUFFIX to be ".xhtml .view.xml .jsp".
I have just uploaded the latest expert community draft to
https://javaserverfaces-spec-public.dev.java.net/files/documents/1936/153...
The content relating to this issue is in Appendix A section 1.2.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
14 years, 2 months
[jsr-314-open-mirror] [jsr-314-open] [2.1 Spec Review] FaceletCache issues
by Andy Schwartz
Some additional issues that turned up while reviewing the API doc:
1. FaceletCache and FaceletCacheFactory are missing documentation.
The original (Mojarra implementation-specific) version of this
functionality does include documentation, but that doesn't seem to have
carried over into the public API.
2. The doc in FaceletCache.MemberFactory is incorrect
The class doc says: "Factory interface for creating FaceletHandler
instances." However, we're actually creating Facelet instances, not
FaceletHandler instances.
3. Wider access than necessary for some methods in FaceletCache
The original (Mojarra-specific) version of this functionality exposes
the following methods:
public final void init(InstanceFactory<V> faceletFactory,
InstanceFactory<V> metafaceletFactory)
protected final InstanceFactory<V> getFaceletInstanceFactory()
protected final InstanceFactory<V> getMetadataFaceletInstanceFactory()
The equivalent methods in the new public API are:
public void setMemberFactories(MemberFactory<V> faceletFactory,
MemberFactory<V> viewMetadataFaceletFactory)
public MemberFactory<V> getMemberFactory()
public MemberFactory<V> getMetadataMemberFactory()
The idea behind the init+getters approach was that the base FaceletCache
class handles initialization and storage of the factories on behalf of
subclasses. Since these factories are only used by subclasses, the
getters only need to be protected. Probably safe to leave these final
as there is no need for subclasses to provide alternate implementations
of these methods.
#3 isn't a big deal, but would be nice to correct (particularly the
public/protected issue). #1 and #2 seem more important to address.
Andy
14 years, 2 months
Re: [jsr-314-open-mirror] [jsr-314-open] JBoss provides JSR-314-OPEN archives
by Dan Allen
I meant to post about this *a long* time ago, but suffice to say it got
buried in my backlog.
It doesn't include all the archives because JBoss IT couldn't figure out
which drawer they put them in. But it picked up around the time we agreed to
find a way to make them available. This was the contingency plan :)
- Dan Allen
Sent from my Android-powered phone:
An open platform for carriers, consumers
and developers.
On Oct 21, 2010 11:33 AM, "Ed Burns" <edward.burns(a)oracle.com> wrote:
Dan Allen reported on his twitter feed that these JSR-314-OPEN archives
exist. Thanks to Dan and RedHat for making this data
available: <http://lists.jboss.org/pipermail/jsr-314-open-mirror/>.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 14 work days until German Oracle User's Group Conference
14 years, 2 months
