[jsr362-experts:] Re: [jsr362-observers:] Portlet State Handling Proposal
- From: Julien Viet <
- Subject: [jsr362-experts:] Re: [jsr362-observers:] Portlet State Handling Proposal
- Date: Sun, 28 Jul 2013 19:44:16 +0200
my favorite is option #2 because it is the most clear and simple (and has
benefit to not deprecate methods).
I would use the terms PortletParameters instead of PortletState (because
"state" is a very overloaded term, when I read this word I think more of
preferences rather than parameters) and the prefix Mutable than Writable.
Concerning the addition of PortletMode and WindowState in a subinterface, I
would name the interface ViewState and make it extend PortletParameters
However I don't see yet the benefit for the portlet developer, can you tell
me about a use case using the PortletState interface ?
On Jul 26, 2013, at 11:13 AM, Martin Scott Nicklous
> I mentioned in the last meeting that I had some ideas about changes to
> portlet state (parameter) handling that would potentially make the
> interface clearer and easier to use. I would like to submit these for your
> consideration & for discussion in our next meeting.
> I made some prototypical changes to the API and put them into separate
> branches in the porteltspec3 repository on Github. There are three
> proposals, each of which are tagged. The tags are:
> * PortletState-Variant#1 - Introduces interfaces for parameter access that
> are extended by the appropriate request, response, and URL interfaces.
> * PortletState-Variant#2 - A refinement of #1.
> * PortletState-Variant#3 - Introduces a PortletState interface with a new
> model of how to handle parameters.
> If you clone the portletspec3 repository, you should have everything
> available. You can build the apidocs locally by checking out the target
> with (for example) "git checkout PortletState-Variant#3" and using "mvn
> install" followed by "mvn javadoc:javadoc" to build it. For each of the
> variants, the overview document contains a link to a diagram providing some
> explanatory information. The later diagrams include the older diagrams, so
> if you build variant #3, the overview document will point to a PDF file
> containing all charts.
> I also put the charts up on our project site in case you just want to view
> the charts without dealing with the repository. See: