Hi Alex,
All these are good questions, you're making my brain hurt :-) As I'm
just getting started with the code, I'm reading along in the spec just
like you are, trying to figure this stuff out.
Alexandre-Michael Neubert wrote:
and modify requiresRegistration attribute to "true".
You mean "false", right?
Yeah :-)
Can I forbid cloning of my portlets simply by not exposing the Portlet
Management interface?
Yes.
But, if I forbid cloning by no exposing this interface, my POP portlet can
never become a CCP, right? Is this going to work? Can I completely forbid
portlet cloning?
In practice, completely forbidding portlet cloning probably it wouldn't
make for a very useful portal (although there are probably some use
cases supporting such a configuration).
In section 6.3.2, page 43 ln 25 the spec discusses the use of the
'portletStateChange' flag to prevent state changes (and by extension,
cloning) for unauthorized users. So you could expose the portlet
management interface and support cloning, but only for authorized users.
One could also use information in the RegistrationContext or UserContext
to selectively prevent cloning (the parameters to the
performBlockingInteraction call).
PortletStateChange is only sent on blockingAction's (JSR-168 action
requests). You can see the diagram on page 43 of the spec (6.3.2)
OK, unfortunately, we don't use WSRP4J as consumer, just as producer, so ...
That should be OK. The spec says it is the consumer's responsibility to
tell the producer when it is safe for a state change to occur. So your
consumer, whatever it is, is responsible for setting the
'portletStateChange' field.
Ok, I have hard time to understand the utility of cloning portlets here, so
let's take an example:
* Let's suppose I have one portlet exposed by the producer and consumed by
the consumer.
* Let's also suppose, the consumer instantiates this portlet only once on
one and only one portal page (to access it you have to be authentified
though; no guest)
* Since I use a portal as client, it will take over the authentification
* Now, suppose I have two customers who identify themselves on the portal
using their login/password (each user has it's own login/password) and both
access the page where the consumer instantiated the exposed remote portlet
How would WSRP handle this case? :
* Would the portlet be cloned for the first user and then again for the
second?
I haven't examined every line of code in WSRP4J, but I believe that the
portlet won't be cloned until an End User clicks on a link that executes
a blockingInteraction call, with the Consumer setting a
'portletStateChange' field to 'cloneBeforeWrite' or 'readWrite'
* Would the users be able to both access the portlet (which is of course, in
a different state for both of them) without having to clone it?
Assuming that one or both of your End-Users has clicked on a link which
executed a blockingInteraction, as described above, then no. Each user
would have to clone the portlet.
Last question, lets suppose that the wsrp clones the portlet for the first
and then again for the second user to keep their navigation state separated
(this is what I think should happen).
Yes I agree.
Is there a mechanism in wsrp4j which allows to delete this portlet instance
once the user logs out?
No, not that I know of, but I could be wrong.
I assume (but haven't verified) the WSRP4J producer will honor the
specification and destroy portlet scopes and registration scopes upon
request. So if the Consumer requests the destruction of a
RegistrationContext or PortletContext (say on an End-User logout from
your portal) then the WSRP4J producer will destroy them (and remove any
persisted data).
If yes, how am I able to configure it ans where
(consumer or producer)? (I saw something like this in the specification)
The producer, AFAIK, must be told to destroy RegistrationContexts or
PortletContexts. It could be told by the Consumer, or by some
out-of-band mechanism like an administration tool.
Finally, if this is possible, when would this happen (how is wsrp4j able to
say that the cloned instance in not used any more)? Is there some sort of
timeout to configure like for web sessions?
No. I don't think the WSRP4J producer tracks whether or not a cloned
portlet is stale.
I apologize to ask so many questions, but I trying to get a whole picture
and this ain't easy for the moment. I think it would help a lot to have the
above scenario solved.
No apology needed. Unfortunately, I don't know that I have a solution
for you. I've wondered myself how to manage the cloned portlets when
they are no longer used.
I've decided it isn't much different than a more traditional web
application that saves user state in a database. In a traditional
webapp, users will login over time, maybe some will only login once.
Users will perform some actions in the application, resulting in some
state being recorded in the database. Then the user logs out; they may
never come back. Now you're left with a few rows in your database that
will probably never be referenced again.
Thanks for the dialog, you've definitely stimulated my thinking.
Hopefully you're getting something out of this as well :-)
Best regards,
Elliot
Thanks for your time and your answers,
Regards
Alex
I know these are a lot of questions, but I couldn't get more information
from the specification and I have hard time to understand all these
concepts.
I hope this helps. I'm certainly not an expert, but I have been digging
around in the code and the spec the last couple weeks. Others should
feel free to chime in if I'm spreading mis-information.
Thanks,
Elliot
