portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [M2 build design] Refactoring
Date Tue, 04 Sep 2007 22:53:33 GMT

On Aug 27, 2007, at 9:16 AM, Ate Douma wrote:

> David Sean Taylor wrote:
>> Scott,
>> Nesting is an absolute requirement.
> +1
> Same goes for a (inline) layout-customizer solution.
>> We ripped out the content-server a while back
>> I don't really care what technology (portlets, templates, JSP,  
>> Velocity ..) is used to implement them.
> My preference is that we (at least) allow to use portlets as main  
> entry point for layout rendering.
> Being able to render and manage the layout through our core  
> technology (portlets) is in my opinion important to maintain, both  
> for support as well as presentation/communication purposes.
> Allowing additional layout (technology) solutions on the other hand  
> would be great of course (as long as it integrates well and is easy  
> to maintain).
> A new "layout and decoration api" as I proposed earlier in another  
> mail might be a good starting point to provide a better abstraction  
> for this.
>> I think the main thing we need to consider with layouts is:
>> * making layouts very easy to deploy to the system
>> * making layouts extensible. I don't want to create a new portlet  
>> just to go from 3 column 33,33,33 to 25,50,25
> Which isn't needed anyway, you can configure/override that using  
> psml fragment properties although those cannot be set through the  
> inline layout customizer.

Yes it can, but only with the desktop customizer

>> * making layouts completely editable from the customizer (like the  
>> Desktop supports, but not quite with the portal)
>> I think the main problem with portlet based layouts is that it  
>> doesn't extend well.
>> Say I want to create my own layout, I have to get the jar  
>> dependencies from the base jetspeed, and build my own layout war
>> I guess that is OK if I am writing my own layout algorithms, but I  
>> have found that I usually just need to extend the base layouts
>> Another possible issue I see is that the customization code is  
>> directly built into the layouts due to the fact that we wanted  
>> "edit in place"
>> 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.

Agree on backward compatibility as a must
That said, I really think we can improve on the current solution. I  
just want to make sure we consider from the start:

* complete customization of all features of the layout, such as  
easily replacing the logo or color themes with the customizer
* lots of code reviews before acceptance
* performance issues. Lets hits the performance issues earlier in the  
cycle this time, from past experience
* strive to make layouts more usable from designer tools. Im afraid  
that using Velocity is just not going to cut it with this requirement

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

View raw message