Hi
First of all thanks Ed for mention this change on this list.
I think we have a problem with FaceletFactory, because it does not
consider MyFaces Core alternative solution.
Internally, MyFaces has this class as a parent for FaceletFactory:
http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/view/facelets/FaceletFactory.java
In few words, it has the following methods:
public abstract Facelet getFacelet(String uri) throws IOException;
public abstract Facelet getFacelet(String uri) throws IOException;
public abstract Facelet getViewMetadataFacelet(String uri) throws IOException;
public abstract Facelet getViewMetadataFacelet(URL url) throws
IOException, FaceletException, FacesException, ELException;
public abstract Facelet getCompositeComponentMetadataFacelet(String
uri) throws IOException;
public abstract Facelet getCompositeComponentMetadataFacelet(URL url)
throws IOException, FaceletException, FacesException, ELException;
MyFaces algorithm for composite components creates a different
metadata facelet and use it later to build them.
This is how it looks vdl.getComponentMetadata() in MyFaces:
public BeanInfo getComponentMetadata(FacesContext context,
Resource componentResource)
{
BeanInfo beanInfo = null;
try
{
Facelet compositeComponentFacelet;
FaceletFactory.setInstance(_faceletFactory);
try
{
compositeComponentFacelet =
_faceletFactory.getCompositeComponentMetadataFacelet(componentResource.getURL());
}
finally
{
FaceletFactory.setInstance(null);
}
.... more code applying the facelets to get finally the
BeanInfo object. ....
Previously in MyFaces 2.1 FaceletCache implementation, I added this note:
* TODO: Note MyFaces core has another type of Facelet for read
composite component
* metadata. The reason behind do this in MyFaces is to retrieve some
information
* related to insertChildren/insertFacet that can be used as metadata
and use that
* information later to do the hack for composite components using
templates, instead
* rely on component relocation. This is not handled by FaceletCache
included here
* but in practice this should not be a problem, because the intention
of this class
* is handle Facelet instances created using custom ResourceResolver stuff, and
* usually those pages are for views, not for composite components.
Even if that is
* true, composite component metadata Facelet is smaller (only add
cc:xxx stuff) that
* the other ones used for views or the one used to apply the
composite component
* itself.
Is there any chance to rename/include the required method to handle
composite component metadata? In my understanding it is logical to
have an alternate facelet to build the metadata, right? It could be
good to modify FaceletCache too, but I do not consider it necessary
(but if it is possible great!).
regards,
Leonardo Uribe
2011/9/15 Ed Burns <edward.burns_at_oracle.com>:
>>>>>> On Thu, 15 Sep 2011 08:32:15 -0700, Ed Burns <edward.burns_at_oracle.com> said:
>
> EB> Please see the issue tracker for a changebundle that fixes this issue.
> EB> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611
>
> EB> I still have to write the spec language, but the API was simply moved
> EB> over from the jsf-ri module.
>
> Here is the updated javadoc, still without spec language for this
> feature.
>
> https://maven.java.net/service/local/repositories/snapshots/archive/javax/faces/javax.faces-api/2.2-SNAPSHOT/javax.faces-api-2.2-20110915.154225-6-javadoc.jar/!/index.html
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
> | 7 business days until JSF 2.2 Early Draft Review
> | 11 business days until JavaOne 2011
>