Re: [gatein-dev] Application registry (& co) design and WSRP support.
On Oct 9, 2009, at 9:57 AM, Julien Viet wrote:
Most of the current architecture result from the quick integration
of the GateIn PC to replace the eXo PC.
The Application concept, today this concept wants to be extendable
to properly handle various use case which depends on the type of
content of a window.
1/ The PortletApplication represents a local portlet and it does
indeed have a clear portlet and application name as part of its stat
2/ The GadgetApplication represents a gadget
The main reason where you should not use PortletApplication is that
the semantic of a local portlet application is not the same as a
WSRP portlet (although it was the same in JBoss Portal). Indeed the
portlet application state is hosted by the consumer but in a non
opaque form and further more there is a notion of cascading between
portlet preferences. This does not match the WSRP semantic that is
related to hosting opaque state with no notion of inheritance on the
consumer.
The real problem is that in the code that I modified, none of the
concepts you mention PortletApplication or GadgetApplication are used.
However, there is code that predates the PC integration to support
remote portlets (cf UIPortletManagement) and code that deals with
gadgets without using GadgetApplication and still creating an
org.exoplatform.application.registry.Application object (mind you, not
org.exoplatform.web.application.Application) using
org.exoplatform.web.application.Application.EXO_PORTLET_TYPE and
org.exoplatform.web.application.Application.EXO_GAGGET_TYPE, cf
UIAddApplicationForm.
So there seems to be a lot of confusion within the internal code as to
how things should be handled. Again, none of the code I had to modify
seemed to be using the MOP, I fail to see how creating new model
objects will help in code that doesn't use it.
Maybe I'm missing something but your proposal doesn't seem to address
the issue with the admin tools.
Also, it doesn't help with the fact that ApplicationState is creating
PortletContexts to hardcoded local invoker which is the real issue to
have working WSRP invocations.
Therefore we need to work to achieve the integration of WSRP by
adding a WSRPApplication extension along with a WSRP content type in
the MOP. At the UI level we need to have a UI component that will
represent a WSRP portlet similar to the UIPortlet and UIGadget
components.
At the end we will have something like:
- application/portlet, application/gadget, application/wsrp content
types at the MOP level
- PortletApplication, GadgetApplication, WSRPApplication model objects
- UIPortlet, UIGadget, UIRemotePortlet user interface components
The rest is technical details and I think we should have a
brainstorming session about how to achieve this integration properly.
Sure. I have been asking to talk about this issue several times
already so it's really up to you! :) have nothing else to do since
this issue is blocking for my work.
Cordialement / Best,
Chris
==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow JBoss Portal: http://jbossportal.blogspot.com / http://twitter.com/jbossportal
Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm