portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [M2 build design] Refactoring
Date Wed, 29 Aug 2007 08:23:29 GMT
Mohan K R wrote:
> On 8/27/07, Ate Douma <ate@douma.nu> wrote:
>> David Sean Taylor wrote:

<snip/>

>>> We also need to discuss how people will map the old layouts to new
>> layouts
>> Yes.
>> In my view, we should strive to be at least backwards compatible on
>> layouts for the 2.2 release.
>> We are already going to change a lot in 2.2 which might result in quite a
>> few upgrade issues.
>> Layouts and decorations are likely the most customized elements of a
>> custom portal, so lets try to keep the pain minimal in that area.
>> Deprecating our current layout solution (if need be) would be an
>> alternative allowing end users time to upgrade until at least release >=
>> 2.3.
> 
> 
> Can't we preserve the current layout implementation and still provide a
> *new* layout solution that is independent and not the default, so existing
> layout would still function?
Well, we haven't even started properly discuss and design what the new layout and decoration
api should look like so its a bit speculative right now, but my 
preferred solution would be reimplementing our current layout implementation on top of such
a new api besides providing a new direct/more advanced solution of 
course. That way, we will have only one layout and decoration engine to maintain while maintaining
(temporarily) backwards compatibility.
The out-dated current solution could then be deprecated and possibly dropped after release
>= 2.3.

But as said, this is quite speculative right now.

Furthermore, I think we are talking about two different approaches here.

I think what Scott is proposing is a radical different way how layout and decoration is *executed*
while my original proposal concerns more about a new layout 
and decoration engine how to write/define new layout and decoration templating in a somewhat
similar way as Wicket does it but still executed from (new) layout 
portlets.
There is probably some overlap in features so they might go hand in hand, but not necessarily
so.
My first impression is that a radical new layout/decoration execution model might be difficult
to support backwards compatibility resulting in two separate 
engines which I find less ideal. But if Scotts solution can match all our current features
and turns out to be easier to work with and extend upon, it might be 
worthwhile to (temporarily) maintain two different solutions.



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


Mime
View raw message