On Wednesday, November 26, 2003, at 01:16 PM, Barnhill William wrote:
I've had a chance now to go over the sources more, and read the docs, including docs/PageAggregationDesign.txt.
It sounds good,
moving on (whizzzz)
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?The recursive tree of layout has to be stored in some kind of model.
The proposal suggests a fragment model made up of portlets which stream their content using the Portlet API interfaces.
Im not sure what the DOM gains us since I think we can have more control over the caching of portlets using a fragment model.
The fragment tree can be stored in the database, along with an XML file.
This has been argued numerous times on this list going way back.
Check the list going back 2 years when IBM was active on he Jetspeed list under subjects such as
Streaming vs DOM-based aggregation.
I think you will see that most portal vendors, and the portlet API are stream-based.
However this shouldn't stop us from implementing a DOM-based solution, for good reasons.
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.Please take a look at Cocoon's portal. It works very much like your description above.
Also review the Portlet spec, sections 12.3 RenderResponse interface, 12.32 output streams, 12.3.3 buffering
<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.Sounds good if we can get the model to plug into a DOM aggregator it may be worth while
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
You seem very well versed in the software development process.
I am sure you have worked on projects for companies and interacted with other developers.
This is really not any different, with the exception that everything is done in public, out in the open.
We just ask that you are considerate of others needs and always design for the best of the project and community and not your immediate needs. Oh and one other thing, we have this concept called "democracy" -- all the committers vote on big decisions. We don't have managers, at least not here we don't.
Regarding Performance it reminds me that we are challenged to make a better portal engine than our previous efforts
-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646 +01 707 529 9194 +44 (0)79 8538 6471
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
