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: [J2] RE: Page Aggregation Design
Date Fri, 28 Nov 2003 22:05:17 GMT
Another possible project to look at is JXpath/ The home pas is 
http://jakarta.apache.org/commons/jxpath/ . I've used it in the past 
with good results.


David Sean Taylor wrote:

>
> 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
>
>


---------------------------------------------------------------------
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