David Sean Taylor wrote:
On Thursday, November 27, 2003, at 05:07 PM, Tim Reilly wrote:
Hi David,yes i think im following you
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?
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
understood, its a hierarchy, not just a flat 1-level relationship
<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.
I like the idea of embedding XPath in the url, looking for precedents but not finding muchIm 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
Have you looked at Jaxen? Its a Java XPath Engine and 'universal object model walker'
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
