portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J2] RE: Page Aggregation Design
Date Fri, 28 Nov 2003 21:52:43 GMT

On Thursday, November 27, 2003, at 05:07  PM, Tim Reilly wrote:

> Hi David,
> I have to admit I saw the postings on this subject, read the design  
> doc, and
> replied without looking at the code nor schema. I will look to get  
> better
> idea around the fragments and other elements. I'm seeing the Desktop is
> different concept than what I thought. Would you agree the site  
> structure,
> and the layout(s) that consume that sitemap/structure are different
> concerns; highly related though?
yes i think im following you
The site map is a model, an abstract hierarchy, a view; whereas layouts  
(templates) programmatically access and control that model

>> So its really just a layout (template) with a theme (stylesheet,
>> images) associated with it.
> Ok.
> I see the rules approach to doing this as a big+.
> So one could chain or build rules to locate the desktop for...
> $subdomain $application $markup, $theme, $browser, $browser-version,
> $locale, $locale-variant, $organization, $business-unit, $department,  
> $role
> Or really anything the rules engine lends to, and any objects one  
> configures
> the rules to look at.

OK, thanks, its good to get some feedback on the rules stuff, its still  
new and rough around the edges

>> What if a desktop was located via profiling rules just like a page?
> Yes, I think that would do a lot for the design and allow for the type  
> of
> virtualization we're challenged with.

Im working on representing the desktop model in the database -- it will  
basically mirror the page model: rule-based location of desktop, and  
support for hierarchies and navigations (menus). I checked in what I  
have thus far

>> <desktop id="209">
>> <page-group id="apache">
>>     <page id='jetspeed'/>
>>     <page id='pluto'/>
>>     ...
>>     <decorator id='menu8'/>
> 	<page-group>
> 		<page id='page-3'/>
> 	</page-group>
>> </page-group>
> ... just to make clearer I'd add another page-group to the page-group.
> I'm not sure if specifying the decorator in the same physical document  
> is
> best, but the loaded DOM might have it, unless it's just jsp or vm  
> that use
> the DOM data to create those elements.
understood, its a hierarchy, not just a flat 1-level relationship

>> Im wondering if we should force any structure on pages.
>> I have modeled pages so that they are all contained in a big page
>> bucket.
> The big page bucket sounds good. I wrote a CMS system a couple of  
> years ago
> that is still in use, but in retrospect I wish I'd decoupled the  
> content
> more like you mention - along these lines:
> - content in a big bucket
> - an administrative tree/heirarchy to manage what's in the bucket (the
> administrator's view to the contents of the bucket for organizing -  
> content
> only allowed in one node of the tree.)
> - another tree/heirarchy that is the site map (same content can appear  
> in
> multiple nodes of this tree)
> I'm not suggesting for J2 or maybe? Just commenting on the low  
> coupling is
> probably better.
>> Could you give us some examples of what a URL would look like, or the
>> X-Path notation to locate a desktop, page, sub-page...
> I've been trying to find what I saw with no luck.
> Anyhow, I'm not sure if I read it, or was reading something on xpath  
> and
> thought about how to address portlets.
> The approach would be something like:
> http://[somedomain]/j2/.loc/desktop209/apache/jetspeed/js-rss-portlet/ 
> .ws/ma
> x
> parse the url into
> /desktop209/apache/jetspeed/js-rss-portlet/
> then using the xml/dom fragment from above I would translate this  
> string
> into several xpath queries to find out
> (I'm no expert for XPath, but I'll try)
> /desktop[id()=desktop209]::descendant::pagegroup
>     would me give all top level page-groups
> /desktop[id()=desktop209]::descendant::pagegroup[id()=apache]::page
>     to get all of the pages needed in this request
> / 
> desktop[id()=desktop209]::descendant::pagegroup[id()=apache]::page[id() 
> =jet
> speed]::decentant::portlet
>    to get all the portlets for this request
> anyhow it's taking part of the url and translating into a way to  
> address the
> DOM elements needed for the request.
> Based on the ad-hoc schema above you could assume the first  
> /something/ is
> the desktop,
> the last /something/ is the page, and anything in between are  
> page-groups.
> You could also 'ugly' the url to actually have some or all of the xpath
> query string
> Oops, mid-sentance I realized what I recalled had to do with Cocoon not
> gridsphere.
> I can't find the document, but I'll post it if I find it.
> I could go on... but I'll keep it short ;P
I like the idea of embedding XPath in the url, looking for precedents  
but not finding much

Have you looked at Jaxen?
Its a Java XPath Engine and 'universal object model walker'

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message