Hi,
I proposed not to remove InternalView class but only modify
ViewHandlerImpl in trinidad-impl - not a public part.
But you probably mean that users use the functionality of registering
InternalView in
org.apache.myfaces.trinidad.render.InternalView.properties and method
RequestContext.isInternalViewRequest? I don't see any others public
method for dealing with InternalView.
But yes, your patch solves that problem too and more simple. I made a
proposal with VDL because we have a Java based DSL as an alternative to
JSP/Facelets and we use exactly the same implementation of VDL as I
suggested with the patch.
Thanks,
Martin Kočí
Max Starets píše v Čt 22. 10. 2009 v 14:27 -0400:
> Martin,
>
> InternalView is a part of Trinidad's public API, and we cannot just get
> rid of it (there are many customers already using it).
> So the InternalView is here to stay... We may be able to adapt
> InternalView instances to the instances of VDL in the future, but
> the most expedient and simple fix for the dialog problem is overriding
> getViewDeclarationLanguage:
>
> public ViewDeclarationLanguage getViewDeclarationLanguage(FacesContext
> context,
> String viewId)
> {
> // InternalViews will not use ViewDeclarationLanguage processors,
> // since they do essentially the same job themselves.
> InternalView internal = _getInternalView(context, viewId);
> if (internal != null)
> {
> return null;
> }
> return _delegate.getViewDeclarationLanguage(context, viewId);
> }
>
> I submitted a patch with this change.
>
> Regards,
> Max Starets
>
> Martin Kočí wrote:
> > Hi,
> >
> > I've created https://issues.apache.org/jira/browse/TRINIDAD-1598
> >
> > Problem described there was introduced with JSF 2.0 - specification
> > cleary says that exactly two types of VLD are supported with
> > implementation : JSP and Facelets.
> >
> > Trinidad dialog uses a java code for component tree creation but does
> > not satisfy View Declaration Language abstraction fully. Patch suggests
> > fix this problem with following steps:
> >
> > 1) org.apache.myfaces.trinidad.render.InternalView ->
> > javax.faces.view.ViewDeclarationLanguage
> >
> > Both classes represent same concept, VDL was probably inspired by
> > InternalView. There is clear and simple mapping of methods:
> >
> > InternalView.createView(FacesContext, String) ->
> > ViewDeclarationLanguage.createView(FacesContext, String)
> >
> > InternalView.restoreView(FacesContext, String) ->
> > ViewDeclarationLanguage.restoreView(FacesContext, String)
> >
> > InternalView.renderView(FacesContext, UIViewRoot) ->
> > ViewDeclarationLanguage.renderView(FacesContext, UIViewRoot)
> >
> >
> > 2) Patch implements createView and restoreView according to
> > specificaton, renderView is already implemented
> >
> > 3) Patch comments out usage of InternalView from ViewHandlerImpl - VLD
> > is called transparently from default ViewHandler no matter if it is
> > instance of Facelets, JSP or GenericEntry VDL.
> >
> >
> > 4) Open issues:
> >
> > A) InternalView has a method isStateless(). VDL from JSF 2.0 probably
> > does not know term "stateless view" - I didn't find anything. Usage of
> > isStateless() commented out in patch - ViewHandlerImpl.writeState - the
> > only usage in trinidad-impl.
> >
> >
> > B) patch requires registration of ViewDeclatFactory in faces-config.xml,
> > patch contains modification of faces-config-base.xml, but it is dropped
> > during build, probably with maven-faces-plugin.
> >
> >
> > Please review that patch if it acceptable for trinidad 2.0 branch.
> >
> >
> > Martin
> >
> >
> >
> >
>
>
