OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [wsrp-wsia] JSR168 & WSRP aligment


Dear WSRP TC and JSR168 EG,

*This message is being sent to the WSRP TC and JSR168 EG aliases*

Following there is the list of areas we found we have to work to
ensure a proper alignment between JSR168 and WSRP specifications.

This email is correction/addition/clarification to the previous
email we've sent to Thomas a while ago, the one that has been
forwarded to both groups.

Please let us know of any corrections, additions and questions
you may have.

Regards.

Alejandro / Stefan
JSR168 specification co-leads


[IINA acronym: Impact If there is Not Alignment ]

1-------------------------------------------------------------------
Action definition differs between JSR168 and WSRP.

WSRP defines actions as the event where all state changes happen.

JSR168 defines actions as the event where state changes that affect
other portlet changes happen. When JSR168 EG decided to get rid of
non-blocking action from the API one of the key arguments was that
it could still be possible to model non-blocking actions by using
getMarkup. This non-blocking behavior can and should only be used
if the portlet is not modifying a state that may affect other
portlets, otherwise the overall behavior may not be deterministic.

This means a different programming model for WSRP and JSR portlets.
Specifically, JSR168 allows changing properties in getMarkup. WSRP
does not allow changing properties during the getMarkup.

IINA: Medium/High. JSR168 based producers would have to use producer
managed properties. Providing that WSRP remove this restriction in
the case of producer managed properties. Or, as part of the WSRP
programming guidelines it would have to have extra requirements for
JSR168 portlet developers.

2--------------------------------------------------------------------
JSR168 allows setting properties not defined in the portlet (entity
type) definition

It is not clear if WSRP allows setting properties not defined in the
entity type metadata.

IINA: Low/Medium. JSR168 based producers would have to use producer
managed properties.

3--------------------------------------------------------------------
JSR168 property types are of String or String[]. Types are
interchangeable (a String value can be replaced with a String[] value)

WSRP allows type <any> for properties

IINA: None. Entities offered by JSR168 based producers would only
use String and String[] values. A JSR168 based producer would not
use other types.

4--------------------------------------------------------------------
JSR168 properties definition can define a property as non-modifiable
(by the end user)

WSRP does not define a non-modifiable attribute for properties.

IINA: Low/Medium. For producer managed properties none, this
functionality is handled completely by the producer. For consumer
manage properties, an extension would have to used.

5--------------------------------------------------------------------
JSR168 does not define properties metadata such as value-type,
is-value-required, min-value, max-value, valid-values. JSR168 only
defines name/value/modifiable (String/String|String[]/boolean).

IINA: None. JSR168 producer implementations could define extensions
to expose WSRP properties metadata

6--------------------------------------------------------------------
JSR168 defines the concept of windowID to uniquely identify an
occurrence of a portlet in a portal page. The windowID is used by
the JSR168 producer to manage the session scope for portlets. The
windowID must not change during the duration of a session.

INNA:

If the WSRP 'refHandle' can be used for this purpose this is a
non-issue (The copy-on-write or alternate-solution may have some
consequences on this).

Otherwise: Medium/High. Consumers wanting to interact with JSR168
based producers would have to implement the extension the JSR168
producer defines for that. This would be problematic as different
JSR168 based producers could define this extension in a different
way.

7--------------------------------------------------------------------
JSR168 wants to use the same CSS styles but with a more generic
prefix such as 'portlet-' or 'fragment-'

WSRP is defining 'wsia-' as prefix for the CSS sytles.

IINA: Medium/High. Common look and feel would not be achieved unless
the consumer uses both styles.

8--------------------------------------------------------------------
JSR168 portal/portlet-container extensions are expressed as String
name-value pairs (where a given name may have several occurrences,
a la HTTP headers)

WSRP allows type <any> for extensions

IINA: Medium/High. JSR168 producers and portlets will have to rely
on vendor provided types to access this extensions. Relying on
vendor provided types will most likely create runtime exceptions
because missing class or cast problems. It would impact JSR168
producers and portlets portability.

Question: Is the intention of WSRP to use <any> for future features
(post v1.0) and to state that extensions must be expressed as string
elements in v1.0?

9--------------------------------------------------------------------
JSR168 needs the list of allowed portlet-modes and window-states on
processInteraction and getMarkup calls to allow the producer to
restrict to allowed values portlet-mode and window-states changes
and portletURL creation.

WSRP does not provide this information

IINA: Medium/High. Consumers wanting to interact with JSR168 based
producers would have to implement the extension the JSR168 producer
defines for that. This would be problematic as different JSR168
based producers could define this extension in a different way.

10-------------------------------------------------------------------
JSR168 defines a simple expiration cache on a per session basis.

WSRP is considering a more complex validating cache mechanism.

IINA: None. JSR168 producers could expose the WSRP caching as an
extension.

NOTE: JSR168 EG is waiting for WSRP resolution on caching to see if a
more complex mechanism could be supported in v1.0.

11-------------------------------------------------------------------
JSR168 can not model WSRP entity creation using copy-on-write without
exposing the copy-on-write behavior to the portlet developers.

IINA: High. It would seriously affect interoperability between JSR168
and WSRP.

NOTE: current discussion in WSRP on an alternate solution.

12-------------------------------------------------------------------
Window States and Portlet Modes constants differ between JSR168 and
WSRP.

WSRP: VIEW_NORMAL, VIEW_MINIMIZED, VIEW_MAXIMIZED, VIEW_MODE,
       EDIT_MODE, HELP_MODE.

JSR168: NORMAL, MINIMIZED, MAXIMIZED, VIEW, EDIT, HELP

IINA: Low. JSR168 producers would have to map the WSRP window state
names to the JSR168 window state names on each performInteraction/
getMarkup.

13-------------------------------------------------------------------
JSR168 does not provide localization support for portlet type
metadata (portlet name, init parameters, properties).

IINA: None. JSR168 producer implementations could define extensions
to expose WSRP properties metadata.

14-------------------------------------------------------------------
JSR168 defines User Information as String name-value pairs with not
structure.

WSRP defines a structured element for User Information.

IINA: Low. JSR168 producer will have to flatten the WSRP User
Information structure into String name-value pairs.

---------------------------------------------------------------------



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC