portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barnhill William" <barnhill_will...@bah.com>
Subject Re: Page Aggregation Design
Date Wed, 26 Nov 2003 21:16:07 GMT

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
View raw message