ConsumerCapabilities question

[julien1]

ConsumerCapabilities holds a set of supported modes and window states for a given consumer. It looks like for now those are in the WSRP format.

Would it make sense to have them converted to portal types ?

The only usage I would see of that in the implementation of the org.jboss.portal.portlet.spi.PortalContext interface by the WSRP invoker. In that case the PortalContext interface implementation could perform the translation itself at runtime as well.

Usually my take is to move away from the wsrp generated classes, but it looks like ConsumerCapabilities interface is really specific to WSRP model and should be not used in the rest of the codebase except by GUI managers.

[claprun]

ConsumerCapabilities holds a set of supported modes and window states for a given consumer. It looks like for now those are in the WSRP format.

Would it make sense to have them converted to portal types ?

Right now, ConsumerCapabilities is not really used by the code but it should use portal types.

The only usage I would see of that in the implementation of the org.jboss.portal.portlet.spi.PortalContext interface by the WSRP invoker. In that case the PortalContext interface implementation could perform the translation itself at runtime as well.

Yes.

Usually my take is to move away from the wsrp generated classes, but it looks like ConsumerCapabilities interface is really specific to WSRP model and should be not used in the rest of the codebase except by GUI managers.

I agree. So your recommendation is to remove ConsumerCapabilities from the api and make it an implementation of PortalContext, with added methods to support WSRP only visible in the WSRP package?

[julien1]

Some information in consumer capabilities is useful, in particular the supported modes and window states which has definitely his place in a management tool. For the others I don't know which one are interesting to expose, if any.

ConsumerCapabilities still needs to be persisted in the database upon consumer registration, so it cannot be remove from the api. Unless we split the API between a pure persistence manager package and a more high level view, but we don't have time to spend on that for now.

I think that for now we can let it as it is, it does not harm anyone and in all case we'll need an implementation of PortalContext whether translation of wsrp types is done by the portal context implementation or before in the api layer.