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]
