Hi
2012/11/27 Edward Burns <edward.burns_at_oracle.com>:
>>>>>> 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?
>
Yes, that's right.
> 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.
>
+1. The controversy here is which option is better, put it on
ViewDeclarationLanguage or
move it to Application and do a call to ViewDeclarationLanguage, like is done in
createComponent(FacesContext, Resource).
> PROPOSAL: Remove FaceletFactory from the public API.
>
+1.
> 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.
>
Ok, I just mentioned it, because I'm doing some work related to
"stateless jsf mode" and its implications, and I found this concept as something
related to the view structure (different than the view state).
For example, in MyFaces there is a class called:
org.apache.myfaces.context.RequestViewContext
That deals specifically with that information. Please note that if you are
not using PSS and there is a "dynamic" part in the component tree, each time
createComponent is called, if a @ResourceDependency is found a component
is added in each postback/dynamic change. Fortunately, PSS algorithm is good
enough to replace the old JSF 1.2 state saving.
In conclusion, Application object is a "singleton" or "application
scope" class, so
if it provides a method that produce an effect or depends on the
context to work,
FacesContext should be passed. This also improves performance, because it
reduce the pressure over FacesContext ThreadLocal var.
In that sense, in MyFaces I changed this call:
app.createComponent(this._componentType);
with this one:
c = app.createComponent(faces, this._componentType, this._rendererType);
because it gives the same effect, but avoid
FacesContext.getCurrentInstance() call.
regards,
Leonardo Uribe
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/