>>>>> On Fri, 23 Nov 2012 17:58:06 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
LU> I want to remind you a mail sent some months ago
Thank you for bringing this up again. I appreciate it.
LU> [jsr-344-experts] FaceletFactory.createComponent(...) ?
LU> You can check it here:
LU>
http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-06/message/18
LU> I have been reading the latest available snapshot of the spec before
LU> public review, and this is the only point I can see could suppose a
LU> "pandora box".
LU> In few words (if we can find them for such a complex issue), the
LU> problems of use FaceletFactory outside facelets algorithm are:
Are you arguing that there are too many implementation details that
tightly couple the implentation of Facelets with the other parts of the
system, such that this FaceletFactory is effectively undecoratable?
LU> - PSS algorithm impose some restrictions about facelets algorithm.
[...]
LU> - Facelets algorithm refresh the component tree, usually under a
[...]
LU> - There is no warrant about how the ids will be generated, and if
[...]
LU> These problems are not easy to solve, but the interesting part is
LU> all of them suppose that if we can use facelets to create
LU> component subtrees and add them and then we can make
LU> facelets deal with those components as not bound to facelets tag
LU> handlers, it is possible to solve the problems.
LU> In other words, the instance of FaceletFactory used by users in
LU> programatical component manipulations, should not be the same
LU> variant as the FaceletFactory instance used by facelets algorithm.
LU> To be more clear, what we need is provide a class to use facelets
LU> into programatical component manipulations, not expose
LU> FaceletFactory as is right now. Under that context, a method like:
LU> UIComponent createComponent(FacesContext context,
LU> String taglibURI, String tagName, Map<String,Object> attributes)
LU> has a lot of sense, but not under FaceletFactory, instead under
LU> something else.
Yes, I understand.
[...]
LU> Another problem we have is FaceletFactory.createComponent cannot be
LU> moved to Application class, because it suppose create a component based on
LU> the current context, which defines the vdl used. Why the VDL does not have
LU> the right to create a component? If you read the documentation of
LU> Application.createComponent(FacesContext context, Resource componentResource),
LU> everything is related to the VDL.
PROPOSAL: Move FaceletFactory.createComponent() to be a method on
ViewDeclarationLanguage. Specify that the method returns null on the
JSP implementation.
PROPOSAL: Remove FaceletFactory from the public API.
LU> It is also weird the way how @ResourceDependency annotations are
LU> processed. To avoid duplicate component instances, it is necessary
LU> to keep track of the classes processed, but that information is not
LU> stored with the view, because it can be regenerated using PSS
LU> algorithm. I know it works, and it is ok,
You said the magic words there, so let's leave this particular aspect
untouched.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/