[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jetspeed-dev
Subject:    Re: PortletURLProviderImpl.toString() ?
From:       Ate Douma <ate () douma ! nu>
Date:       2005-04-21 9:16:36
Message-ID: 42676F74.2030703 () douma ! nu
[Download RAW message or body]

Raphaël and others,

Sorry for the delay.
My laptop crashed a week ago and only since this weekend do I have a new 
developer environment to work with (my laptop still isn't fixed though 
:-( ).

But, I've now fixed http://issues.apache.org/jira/browse/JS2-194 and 
http://issues.apache.org/jira/browse/JS2-231.
Furthermore, I've cleaned up PortletURLProviderImpl.
So, if you have time, please test it out!

Regards, Ate

Ate Douma wrote:
> 
> 
> Raphaël Luta wrote:
> 
>> Ate Douma wrote:
>>
>>> Raphaël Luta wrote:
>>> <snip>
>>>
>>> You're absolutely correct Raphaël, this is wrong.
>>> It is a long time ago I've been looking at this and I can't remember 
>>> anymore
>>> what I was thinking at the time I wrote it but indeed, this isn't good.
>>> The whole logic behind the if (clearparameters) statement is wrong 
>>> although it
>>> more or less seems to do the job (but probably only because Pluto 
>>> always calls
>>> clearParameters() before it calls setParameters(Map)).
>>>
>>> There is more going on here though. I've seen some reports by users 
>>> complaining
>>> that previously defined renderparameters aren't removed even if not 
>>> defined on
>>> a new PortletURL. This area in the code might be part of that problem.
>>> Most likely, I was working on that functionality but simply forgot to 
>>> complete it
>>> when I rewrote the PortletURL encoding.
>>> Solving this properly might require changes to the NavigationalState 
>>> implementation as well!
>>> I wouldn't want to implement a (too) quick fix for that.
>>>
>>
>> We indeed saw some strange behavior with render parameters that don't 
>> seem to be cleared properly.
>>
>>> Starting from Wednesday, I expect to have more time on my hands to 
>>> look at this
>>> and will try to resolve it. if you can't wait that long and/or it is 
>>> blocking you
>>> go ahead and fix this part. I'll then pick it up after that.
>>>
>>
>> If you know what should be the correct behavior, I'll gladly let you
>> take care of this ! Trying to get a picture of how this stuff works is
>> a real mess given the number of facades used both on Jetspeed and Pluto
>> side.
> 
> Yes, I think I know what the correct behavior should be ;-)
> I'll give it highest priority later this week and created new issue JS-231
> (with priority Critical) for it.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> 
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]