portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weaver, Scott" <Swea...@rippe.com>
Subject RE: Page Aggregation Design
Date Wed, 26 Nov 2003 21:51:06 GMT
Hi Bill, 

> I'm not very versed in participating in open source projects, especially
> not at earlier stages, but would a LayoutValve requirements spec, a
> Layout portlet spec, and a set of JUnit compatibility tests be
> appropriate? Or is that too formal?

This would be great!

Regards,
*================================* 
| Scott T Weaver                 |
| <weaver@apache.org>            | 
| Apache Jetspeed Portal Project |
| Apache Pluto Portlet Container |
*================================*

> -----Original Message-----
> From: Barnhill William [mailto:barnhill_william@bah.com]
> Sent: Wednesday, November 26, 2003 4:16 PM
> To: Jetspeed Developers List
> Subject: Re: Page Aggregation Design
> 
> 
> I've had a chance now to go over the sources more, and read the docs,
> including docs/PageAggregationDesign.txt.
> It sounds good, but what do you think of the idea of using a single
> request/response-attribute (layout-description) to gather layout
> information using the LAYOUT mode, and storing that info as a dom
> instance in that attribute?
> 
> Each layout portlet would construct its own node tree and pass it back
> in the response attribute layout-description.  The value passed back
> would be inserted into the parent's node tree, which would then be
> passed back up in the same manner.
> 
> <portlet peid="yutu" type="layout">
>     <portlet peid="eere" type="content">
>           <renderHints>
>                 <hint name="xxx" value="yyy" />
>           </renderHints>
>     </portlet>
>     <portlet peid="sdsd" type="layout">
>         <portlet peid="sss" type="content">
>               <renderHints>
>                     <hint name="xxx" value="yyy" />
>               </renderHints>
>         </portlet>
>     </portlet>
> </portlet>
> 
> You will have more performance overhead, but it seems more extensible
> and you can pass more information back.
> If this was applied to remote portlets you would also have bandwidth
> issues, but these might be brought within acceptable levels using
> compression perhaps with binary representation of the XML, similar to
> JXTA.
> 
> I'll be the first to admit that the performance drawbacks of the above
> approach may outweight the extensibility benefits. Ideally two
> implmentations of  LayoutValve interface could be created and a standard
> default implementation could be chosen.  If someone wants the features
> in the other implementation then they could unplug the one and plug in
> the other.
> 
> I'm not very versed in participating in open source projects, especially
> not at earlier stages, but would a LayoutValve requirements spec, a
> Layout portlet spec, and a set of JUnit compatibility tests be
> appropriate? Or is that too formal?
> 
> Please be patient while I learn how to play in the bazaar ,
> 
> Bill Barnhill
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message