Ahh. I see how you may be confused. Consider the following
requirements of the JSR-301 portlet bridge:
1. Portlet Bridge jars should be optional in environments where the
Portal is not in place. In other words, a renderkit can be portlet
compatible without having to have the bridge jars included in
non-portlet web applications.
2. Portlet enabled applications may be coded to run both as a portlet
AND as a servlet. This means that, where possible, portlet logic is
only executed when it is run within a portlet. It also means that
anything special that is needed to run something in a portlet would not
preclude running the same code as a servlet. Obviously this pertains to
non-portal specific functionality.
3. Try to enable as many existing Faces applications to run as-is in a
portlet environment as possible.
To accommodate all of these usecases, custom UIViewRoots need to follow
a select set of requirements according to JSR-301. If we're in a portal
environment, however, and the UIViewRoot is the default system view
root, we wrap the class in a decorator which implements all this stuff
for you. This means that when running as a servlet, you get back a
non-namespaced view root. When running as a portlet, however, the
viewroot is a naming container and will handle namespacing.
Does this make sense?
Scott
Scott O'Bryan wrote:
Andrew,
Faces will not let us do this. The Portlet UIViewRoot implements a
naming container and has some other logic. What this means is that
the Portal's viewRoot needs to be the one being served to the
application at the topmost level. If it's not, we loose the naming
container. This was an issue discussed in JSR-301 EG and this was the
best we could come up with. As it stands now, applications which want
to use the standard UIViewRoot need to retrieve the ViewRoot using the
ViewHandler OR they need to implement their own naming container.
If you have any ideas about how this could be better supported by 301,
let me know and I can take it to the Expert Group.
Scott
Andrew Robinson wrote:
>From my understanding:
Application.createComponent() is the correct way to create the
UIViewRoot. The view handler should use this method internally to get
an instance to the view root component. Instead, the bridge should be
registering the component type for the special view root in the
application, so that calls to createComponent return the one needed
for the bridge.
-Andrew
On 10/18/07, Scott O'Bryan (JIRA) <[email protected]> wrote:
[
https://issues.apache.org/jira/browse/TRINIDAD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott O'Bryan updated TRINIDAD-134:
-----------------------------------
Status: Patch Available (was: Open)
StateManagerImpl is not fully compatible with JSR-301
-----------------------------------------------------
Key: TRINIDAD-134
URL:
https://issues.apache.org/jira/browse/TRINIDAD-134
Project: MyFaces Trinidad
Issue Type: Bug
Components: Portlet
Affects Versions: 1.2.1-core
Environment: JSR-168, JSR-301
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
Fix For: 1.2.2-core
Attachments: trinidad-134.patch
StateManagerImpl has a performance enhancement that is not
compatible with JSR-301. Inside of the popRoot method inside of
org.apache.myfaces.trinidadinternal.application.StateManagerImpl,
the view root is retrieved using Application.createComponent();.
The JSR-301 bridge has a special UIViewRoot that, due to
limitations in the JSF specification, can only reasonably be
retrieved through ViewHandler.createViewRoot(). We either need to
try to try to retrieve the UIViewRoot using this mechanism OR we
need to disable this performance optimization in a portal environment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
