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 | | <[EMAIL PROTECTED]> | | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | *================================* > -----Original Message----- > From: Barnhill William [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
