Re: Synchronized and PortletConfig

[Stephan Hesmer <sh...@raleigh.ibm.com>]

Santiago Gala wrote:

> I agree in whole. This work is needed. We have been delaying this effort,
due to the new
> PortletAPI, but I think the changes go in the right direction.
>
> I tested having PortletSets cached in the session. This brought the
problem that portlets
> were not being correctly expired during the session, as expiration happens
in getPortlet()
> during creation of the PortletSet.
>
> I suggest taking out setPortletConfig() from the Portlet API and changing
to init(config),
>  so that there is no reasonable way to spoil the config again.
>
>
> We could do the following:
>
> - Maybe you could want to have commit rights, or will the changes be
commited by Ingo?
> - You post the changes' description for discussion, but I think the best
communication
> would be in the following points...
> - take 24-48 hours for people to commit other "minor" changes in the main
branch
> (I will commit the JAXP/TRAX changes, don't think they interfere)
> - open a branch for this work.
> - apply your patches in this branch
> - test a little bit
> - have a IRC meeting to discuss about any pending problems or unforessen
implications
> (maybe we understand things in different ways, and this can lead to
divergent work).
> Also, if the main developers understand the changes,and the reasons, it is
less
> likely that incompatible changes that spoil the model appear later.
> - test more :) (don't forget the jsp classes, that don't get compiled
during ./build)
> - merge the patches into the main branch
>
>
> The reasons is that I have also some changes in related classes, and while
I don't think I have problems,
> maybe I have seen things that you forgot, or the other way round. I prefer
having a branch, so that we
> can take time to think if something breaks (conflicts) without being
pressed by Sam Ruby's GUMP :)
>

I would suggest not to apply the changes in the current jetspeed, but that I
implement the changes directly with the new Portlet API. I will implement
the new API for Jetspeed here at IBM.

Therefore, I ask you all to have commit rights, so that we have two
committers here at IBM. I will mostly use it for the Portlet API (I think a
new branch is the best) and Ingo will do all other stuff from IBM, so that
the commits are consolidated.

Look in my other mail for an explanation of the sync and PortletConfig.

Stephan

Portlets and JSP fragments

[David Sean Taylor <da...@b3interactive.com>]

Ingo,

When I use JSP templating, a portlet cannot output JSP expressions to the
stream.

Im looking at default.jsp, and it has

 <jsp:include page="<%= screenJsp %>" flush="true" />

Which evals to 'ecs.jsp', which contains one tag:

<jetspeed:ecsscreen />

If the tag's output has JSP expressions, they will never be evaluated.

Maybe this is wishful thinking, but I was under the impression that portlets
could contain resuable JSP-fragments.
Is this something that the new Portlet API will support,
or will I always have to resort to writing a JSPPortlet which does something
like the ECS example below to include JSP fragments:

    public void output(PrintWriter out)
    {
        ServletContext ctx = rundata.getServletContext();
        RequestDispatcher dispatcher = ctx.getRequestDispatcher(url);
        try
        {
             dispatcher.include(rundata.getRequest(),
rundata.getResponse());


thanks,

-- david

Re: Synchronized and PortletConfig

[Santiago Gala <sg...@hisitech.com>]

David Sean Taylor wrote:

>> I would suggest not to apply the changes in the current
>> jetspeed, but that I
>> implement the changes directly with the new Portlet API. I
>> will implement
>> the new API for Jetspeed here at IBM.
>> 
>> Therefore, I ask you all to have commit rights, so that we have two
>> committers here at IBM. I will mostly use it for the Portlet
>> API (I think a
>> new branch is the best) and Ingo will do all other stuff from
>> IBM, so that
>> the commits are consolidated.
>> 
> 
> 
> +1 for Stephan
> I think this work should be done in a branch and committed frequently so we
> test it and so others can also commit to the branch
> Do you plan on implementing the entire API yourself?
> 

+1, obviously. Sorry for the delay.

RE: Synchronized and PortletConfig

[David Sean Taylor <da...@bluesunrise.com>]

>
> I would suggest not to apply the changes in the current
> jetspeed, but that I
> implement the changes directly with the new Portlet API. I
> will implement
> the new API for Jetspeed here at IBM.
>
> Therefore, I ask you all to have commit rights, so that we have two
> committers here at IBM. I will mostly use it for the Portlet
> API (I think a
> new branch is the best) and Ingo will do all other stuff from
> IBM, so that
> the commits are consolidated.
>

+1 for Stephan
I think this work should be done in a branch and committed frequently so we
test it and so others can also commit to the branch
Do you plan on implementing the entire API yourself?