David Sean Taylor wrote:
> I don't know how many of you out there are just switching over to the new
> build ( I know, its about time... )
> I for one did so yesterday, and to my surprise it builds and runs!
>
> Im attempting to compile a list of potential problems for those of you about
> to do the same.
>
> Some observations about the new build. Please correct me if they are
> inaccurate:
>
> 1. default.psml has some unmatched tags. It also has some new tags
> 'portlet-controller-ref' and 'portlet-set'
>
I have problems dealing with these files, as I have two versions: one in the Web
server, that I use to experiment, and a different one in the CVS repository.
This brings a lot of headache, as I ofter forget to check differences between
the two before commiting. So, I will check problems in this area.
>
> 2. the new jcfg file now names portlet entries 'portlet-entry'
> New registries:
> <portlet-registry>
> <portlet-control-registry>
> <portlet-controller-registry>
> <media-type-registry>
> <profile-registry>
> <capability-map-registry>
>
> 3. the 'default' user's screen is empty, however the 'turbine' user works
> fine
> you can plug in your own default user screen and it seems to work
>
I seems that it is broken , after all. In my setup, both users run.
>
> 4. Portlet.getContent signature changed
> public ConcreteElement getContent( RunData rundata ) {
>
Yes. It is important that we don't store in the Portlet any information that is
in RunData or related with Request or Session. I tries to clean implementations
of Admin portlets as an example. If we do that, we are breaking a basic
assumption of the servlet threading model:
life cycle
init: parameters "constant" for the life cycle.
service (getContent in our case): All request and session related info comes in
the Request/Response pair (read RunData in portlets).
destroy: end of life.
We will not be able to cache portlets if we don't respect this assumptions. We
have been thinking of a better model for the programmer. It plainly is not
natural OO programming to have your state in transient parameters, instead than
in the object instance vars. But I could not find a way.
The closest I came was something like a portlet extending the RunData object,
but then you would have to create a new Portlet() for every new request, and
then keeping instance pools for each portlet class. It owuld not work, too
complicated. Nevertheless, for the programmer it would be more natural.
>
> 5. Portlet.getPortletConfig().getRunData() is no longer available (see
> Santiago Gala's email Nov.9)
>
Yes, that is important again, for the same reason. The configuration of a
portlet should not know anything about the request related information.
>
> 6 From the Portlet's init() method, getInitParameter() no longer works (it
> returns null):
>
> PortletConfig config = this.getPortletConfig();
> xmlFile = config.getInitParameter("xml"); // get a parameter from
> default.psml
>
You have uncovered a bug!. I'm pretty sure that this is a problem introduced by
me or in the merging process. We should clean that. I will look at it.
>
> I need help here:
> This last one really breaks a lot of my code. Is there currently a way to
> get parameters from <user>.psml?
>
> Thanks
>
> David
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
