You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by David Sean Taylor <da...@bluesunrise.com> on 2003/11/26 20:33:39 UTC
Page Aggregation Design
Raphael and I have been brainstorming on a Page Aggregation and
Profiling redesign.
The result of these random conversations and emails are summarized in a
design document.
Its in a pretty rough state but decided it was best to get it in sooner
better than later so that everyone can get involved up front.
Its in the CVS under docs/PageAggregationDesign.txt
Please continue the discussion the Page Aggregation Design on this
thread. Look forward to your creative thoughts
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Page Aggregation Design
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
david@bluesunrise.com
+01 707 773-4646
+01 707 529 9194
+44 (0)79 8538 6471
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Page Aggregation Design
Posted by Barnhill William <ba...@bah.com>.
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
Re: [J2] RE: Page Aggregation Design
Posted by Barnhill William <ba...@bah.com>.
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
Re: [J2] RE: Page Aggregation Design
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
[J2] RE: Page Aggregation Design
Posted by Tim Reilly <ti...@consultant.com>.
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?
> 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.
> 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.
> <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.
> 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
-TR
> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com]
> Sent: Wednesday, November 26, 2003 8:20 PM
> To: Jetspeed Developers List
> Subject: Re: [Jetspeed-2] RE: Page Aggregation Design
>
>
> Hi Tim,
>
> thanks for the long response! ;-)
>
> On Wednesday, November 26, 2003, at 04:31 PM, Tim Reilly wrote:
>
> > I have some questions and comments after reading the
> > PageAggregationDesignDoc document.
> >
> > Is the Desktop / Page terminology synonymous with Websphere portal's
> > "Place"
> > / "Page" concept?
> > Basically, if you're not familiar with WPS the out of the box
> > menu/site-map
> > is a 2 level hierarchy in which you create "Places" to contain "Pages"
> > (which contain portlets.)
>
> Im a little familiar with it but no, I wasn't trying to model after it.
> What I was trying to achieve was a more generalized replacement for
> Turbine modules.
> And a much more easily configurable model.
> The desktop contains the layout of possibly a header, footer and some
> equivalents of navigations and the theme.
> A theme is a concept also in WPS, but I think Scott has planted this
> idea in my head.
> So its really just a layout (template) with a theme (stylesheet,
> images) associated with it.
>
> The way it is currently modeled, a user can only have one active
> desktop. The user can change desktops.
> But the model holds a explicit relationship between user and desktop.
> Im now considering that I made a mistake and made it too simple with
> the 1 desktop per user concept
> What if a desktop was located via profiling rules just like a page?
>
> >
> > If so, we've found this to be limiting in some instances. An n-level
> > tree or
> > hierarchy would IMO be better.
> > I think ideally a Page Container that may contain Pages or more Page
> > Containers would be nice. There is some trouble with this and
> > complexity; I
> > think the relationship must be constrained such that (I'll use the term
> > PageGroup and Page)... PageGroups that contain more PageGroups must
> > either
> > only contain one or zero Pages.
> > So the constraint would be:
> > PageGroup a1..n -------- 1..n PageGroup
> > +---- 0..1 Page
> > or
> > PageGroup b1..n -------- 1..n Pages
> >
> I think this is starting to make sense.
> In J1 we achieved this type of relationship with portlets sets and
> specialized controls and controllers.
> You are suggesting a higher level navigational "control" sitting in a
> container that holds 1..n pages.
> This allows you to decorate a collection of pages with a menu much the
> same as we decorated portlet sets (fragments) in J1
> I like this idea
> Could I suggest that the Desktop as the Page Container?
> And Page Group would then be a collection of pages in the Desktop.
> To visualize this in XML
>
> <desktop>
> <page-group>
> <page id='page-1'/>
> <page id='page-2'/>
> ...
> <decorator id='menu8'/>
> </page-group>
>
> > I'll try to explain why the n-level and why the constraint by
> > describing an
> > example view:
> > This approach allows for 2 levels of tabs across the top of the page..
> > perhaps the tier-1 PageGroups are called Desktops. The selected/active
> > Desktop's child PageGroups are displayed as the second level of Tabs.
> > The
> > view also has a right-2-level menu which is populated by the children
> > of the
> > active/selected tier2 pagegroup. The right-menu items have children
> > (at tier
> > 4 of the hierarchy) Those child elements have pages. If the user
> > clicks a
> > page group we can have this one page that is displayed along with the
> > children pagegroups (menu items.)
> > So the example would look like:
> > http://www.macromedia.com/support/forums/
> > or
> > http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore/
> > or
> > http://jakarta.apache.org/turbine/index.html has 4 levels.
> >
>
> I see so the level or the parent need to be modeled.
> Take a look at the FRAGMENT and SUB-FRAGMENT tables for examples on the
> page level
> Suppose we could do the same kind of hierarchy with PAGES
> I'm beginning to be convinced of its usefulness
>
>
> > There are a number of challenges to doing the n-tier structure, but the
> > result is worthwhile in my opinion.
> > In the relational model for this is not too difficult if you track a
> > "level"
> > attribute. I've also tracked this with a varchar path notation (not
> > sure
> > it's the best approach but it worked too.) In the file system approach
> > using
> > xml lends to the tree or hierarchy well; XPointer may also factor in -
> > I
> > think I saw something within Cocoon using XPointers... lead in to next
> > question.
> >
> 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 profiler is responsible for locating a page based on the profiling
> criteria.
> I was under the impression that this is what people wanted since my old
> design,
> which was a hierarchy of users, groups and roles, though useful, was
> often the subject
> of complaints and dissatisfaction since we hard-coded the hierarchy.
> The new design leaves it up to the profiler implementation to find a
> page.
> I do like the idea of a site map and having a concrete hierarchy of
> pages too.
> Guess Im not sure right now....in fact Im honestly confused as to
> whether Im going down the right path with configurable profiling
> criteria.
> Perhaps its too complicated....perhaps the entire site should be set
> and always addressable
>
> > Have aspects of Cocoon been reviewed to see if they fit into the the
> > solution? I've not used Cocoon, but poking around the documentation a
> > while
> > back made me think it's potentially valuable for this type of site and
> > page
> > definition.
>
> Yes I've reviewed it a little. Its pretty cool but I didn't really see
> anything new wrt profiling
>
> >
> > One of the really nice features of WPS is the capability to 'lock' down
> > pages or parts of pages. e.g. if I have the rights to a Desktop, Page
> > Group,
> > or Page I can administer it's layout and lock it down.. leaving some
> > parts
> > customizable. I know some people feel a portal is not a portal unless
> > the
> > user can customize their layouts. We actually have not and don't
> > intend to
> > allow our users to customize their pages (yet.) To us, the value of the
> > portal is in the deployment, component, and modularity of the
> > architecture
> > and now that the JSR is released - the potential to use OSS portlets,
> > as
> > well as vendor delivered portlets. So the portal not being a portal
> > without
> > user customization is mute for us.
>
> Locking down fragments is addressed in the model I hope.
> The concept of a named fragment means that a fragment can be included
> or referenced
> in your page and by setting of the security so that it can't be
> customized except for a given role, this is achieved.
>
> >
> > Portal virtualization is something we are working on. It would be
> > great if
> > Jetspeed 2 could consider it in the design. The requirement is that our
> > various extranets are migrating into our portal implementation. Based
> > on
> > some aspect of the system (not necessarily the user) we need to
> > determine
> > the theme and skin, and what "Places", "Pages" and portlets are
> > available.
> > In our case, if the url were - http://apache.ourextranet.com then we
> > would
> > set the theme, skin, and filter the available places, pages, and
> > portlets
> > that can be applied based on the apache subdomain . I guess with an
> > open
> > source solution standing up entirely separate instances of the portal
> > server
> > is not such a big deal...although if you have one for each major client
> > having 200 instances could be a nightmare. We are toying with the
> > concept of
> > an application context, and then a site context (site = the client or
> > client's business unit, application context = ourextranet b/c we have
> > multiple app's or brands) So we will likely try to filter these things
> > based
> > on those 2 attributes that we'll set in the session. We have not
> > implemented
> > the virtualization...
> > I think the rules based processing mentioned in the design doc starts
> > to
> > address such concerns in the Page Aggregation document.
> >
> What if the profiler had a rule that looked at the URL in determining
> which desktop to show?
>
> > I'll also throw out there... I was going through the gridsphere
> > documentation. If I recall correctly they managed to make pages
> > addressible
> > through some sort of XPath notation. Seemed like a nice feature.
> >
> Yes thats back to the site map concept.
> I really need to think about that - I think you're on to something
> there.
> 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...
>
> > Hopefully, sharing our challenges and direction with our portal helps
> > in the
> > J2 design discussions.
> >
> >
> > -TR
> >
> > P.S: I'm hoping the [Jetspeed-2]|[Jetspeed-1] thing in the subject will
> > catch on ;)
> > I'm not sure how to propose the convention to the list though, if it's
> > bad
> > etiquette I won't?
> >
> +1
> Maybe [J1] and [J2] will make the titles shorter
>
> -
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
> +01 707 529 9194
> +44 (0)79 8538 6471
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [Jetspeed-2] RE: Page Aggregation Design
Posted by David Sean Taylor <da...@bluesunrise.com>.
Hi Tim,
thanks for the long response! ;-)
On Wednesday, November 26, 2003, at 04:31 PM, Tim Reilly wrote:
> I have some questions and comments after reading the
> PageAggregationDesignDoc document.
>
> Is the Desktop / Page terminology synonymous with Websphere portal's
> "Place"
> / "Page" concept?
> Basically, if you're not familiar with WPS the out of the box
> menu/site-map
> is a 2 level hierarchy in which you create "Places" to contain "Pages"
> (which contain portlets.)
Im a little familiar with it but no, I wasn't trying to model after it.
What I was trying to achieve was a more generalized replacement for
Turbine modules.
And a much more easily configurable model.
The desktop contains the layout of possibly a header, footer and some
equivalents of navigations and the theme.
A theme is a concept also in WPS, but I think Scott has planted this
idea in my head.
So its really just a layout (template) with a theme (stylesheet,
images) associated with it.
The way it is currently modeled, a user can only have one active
desktop. The user can change desktops.
But the model holds a explicit relationship between user and desktop.
Im now considering that I made a mistake and made it too simple with
the 1 desktop per user concept
What if a desktop was located via profiling rules just like a page?
>
> If so, we've found this to be limiting in some instances. An n-level
> tree or
> hierarchy would IMO be better.
> I think ideally a Page Container that may contain Pages or more Page
> Containers would be nice. There is some trouble with this and
> complexity; I
> think the relationship must be constrained such that (I'll use the term
> PageGroup and Page)... PageGroups that contain more PageGroups must
> either
> only contain one or zero Pages.
> So the constraint would be:
> PageGroup a1..n -------- 1..n PageGroup
> +---- 0..1 Page
> or
> PageGroup b1..n -------- 1..n Pages
>
I think this is starting to make sense.
In J1 we achieved this type of relationship with portlets sets and
specialized controls and controllers.
You are suggesting a higher level navigational "control" sitting in a
container that holds 1..n pages.
This allows you to decorate a collection of pages with a menu much the
same as we decorated portlet sets (fragments) in J1
I like this idea
Could I suggest that the Desktop as the Page Container?
And Page Group would then be a collection of pages in the Desktop.
To visualize this in XML
<desktop>
<page-group>
<page id='page-1'/>
<page id='page-2'/>
...
<decorator id='menu8'/>
</page-group>
> I'll try to explain why the n-level and why the constraint by
> describing an
> example view:
> This approach allows for 2 levels of tabs across the top of the page..
> perhaps the tier-1 PageGroups are called Desktops. The selected/active
> Desktop's child PageGroups are displayed as the second level of Tabs.
> The
> view also has a right-2-level menu which is populated by the children
> of the
> active/selected tier2 pagegroup. The right-menu items have children
> (at tier
> 4 of the hierarchy) Those child elements have pages. If the user
> clicks a
> page group we can have this one page that is displayed along with the
> children pagegroups (menu items.)
> So the example would look like:
> http://www.macromedia.com/support/forums/
> or
> http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore/
> or
> http://jakarta.apache.org/turbine/index.html has 4 levels.
>
I see so the level or the parent need to be modeled.
Take a look at the FRAGMENT and SUB-FRAGMENT tables for examples on the
page level
Suppose we could do the same kind of hierarchy with PAGES
I'm beginning to be convinced of its usefulness
> There are a number of challenges to doing the n-tier structure, but the
> result is worthwhile in my opinion.
> In the relational model for this is not too difficult if you track a
> "level"
> attribute. I've also tracked this with a varchar path notation (not
> sure
> it's the best approach but it worked too.) In the file system approach
> using
> xml lends to the tree or hierarchy well; XPointer may also factor in -
> I
> think I saw something within Cocoon using XPointers... lead in to next
> question.
>
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 profiler is responsible for locating a page based on the profiling
criteria.
I was under the impression that this is what people wanted since my old
design,
which was a hierarchy of users, groups and roles, though useful, was
often the subject
of complaints and dissatisfaction since we hard-coded the hierarchy.
The new design leaves it up to the profiler implementation to find a
page.
I do like the idea of a site map and having a concrete hierarchy of
pages too.
Guess Im not sure right now....in fact Im honestly confused as to
whether Im going down the right path with configurable profiling
criteria.
Perhaps its too complicated....perhaps the entire site should be set
and always addressable
> Have aspects of Cocoon been reviewed to see if they fit into the the
> solution? I've not used Cocoon, but poking around the documentation a
> while
> back made me think it's potentially valuable for this type of site and
> page
> definition.
Yes I've reviewed it a little. Its pretty cool but I didn't really see
anything new wrt profiling
>
> One of the really nice features of WPS is the capability to 'lock' down
> pages or parts of pages. e.g. if I have the rights to a Desktop, Page
> Group,
> or Page I can administer it's layout and lock it down.. leaving some
> parts
> customizable. I know some people feel a portal is not a portal unless
> the
> user can customize their layouts. We actually have not and don't
> intend to
> allow our users to customize their pages (yet.) To us, the value of the
> portal is in the deployment, component, and modularity of the
> architecture
> and now that the JSR is released - the potential to use OSS portlets,
> as
> well as vendor delivered portlets. So the portal not being a portal
> without
> user customization is mute for us.
Locking down fragments is addressed in the model I hope.
The concept of a named fragment means that a fragment can be included
or referenced
in your page and by setting of the security so that it can't be
customized except for a given role, this is achieved.
>
> Portal virtualization is something we are working on. It would be
> great if
> Jetspeed 2 could consider it in the design. The requirement is that our
> various extranets are migrating into our portal implementation. Based
> on
> some aspect of the system (not necessarily the user) we need to
> determine
> the theme and skin, and what "Places", "Pages" and portlets are
> available.
> In our case, if the url were - http://apache.ourextranet.com then we
> would
> set the theme, skin, and filter the available places, pages, and
> portlets
> that can be applied based on the apache subdomain . I guess with an
> open
> source solution standing up entirely separate instances of the portal
> server
> is not such a big deal...although if you have one for each major client
> having 200 instances could be a nightmare. We are toying with the
> concept of
> an application context, and then a site context (site = the client or
> client's business unit, application context = ourextranet b/c we have
> multiple app's or brands) So we will likely try to filter these things
> based
> on those 2 attributes that we'll set in the session. We have not
> implemented
> the virtualization...
> I think the rules based processing mentioned in the design doc starts
> to
> address such concerns in the Page Aggregation document.
>
What if the profiler had a rule that looked at the URL in determining
which desktop to show?
> I'll also throw out there... I was going through the gridsphere
> documentation. If I recall correctly they managed to make pages
> addressible
> through some sort of XPath notation. Seemed like a nice feature.
>
Yes thats back to the site map concept.
I really need to think about that - I think you're on to something
there.
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...
> Hopefully, sharing our challenges and direction with our portal helps
> in the
> J2 design discussions.
>
>
> -TR
>
> P.S: I'm hoping the [Jetspeed-2]|[Jetspeed-1] thing in the subject will
> catch on ;)
> I'm not sure how to propose the convention to the list though, if it's
> bad
> etiquette I won't?
>
+1
Maybe [J1] and [J2] will make the titles shorter
-
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
+01 707 529 9194
+44 (0)79 8538 6471
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[Jetspeed-2] RE: Page Aggregation Design
Posted by Tim Reilly <ti...@consultant.com>.
I have some questions and comments after reading the
PageAggregationDesignDoc document.
Is the Desktop / Page terminology synonymous with Websphere portal's "Place"
/ "Page" concept?
Basically, if you're not familiar with WPS the out of the box menu/site-map
is a 2 level hierarchy in which you create "Places" to contain "Pages"
(which contain portlets.)
If so, we've found this to be limiting in some instances. An n-level tree or
hierarchy would IMO be better.
I think ideally a Page Container that may contain Pages or more Page
Containers would be nice. There is some trouble with this and complexity; I
think the relationship must be constrained such that (I'll use the term
PageGroup and Page)... PageGroups that contain more PageGroups must either
only contain one or zero Pages.
So the constraint would be:
PageGroup a1..n -------- 1..n PageGroup
+---- 0..1 Page
or
PageGroup b1..n -------- 1..n Pages
I'll try to explain why the n-level and why the constraint by describing an
example view:
This approach allows for 2 levels of tabs across the top of the page..
perhaps the tier-1 PageGroups are called Desktops. The selected/active
Desktop's child PageGroups are displayed as the second level of Tabs. The
view also has a right-2-level menu which is populated by the children of the
active/selected tier2 pagegroup. The right-menu items have children (at tier
4 of the hierarchy) Those child elements have pages. If the user clicks a
page group we can have this one page that is displayed along with the
children pagegroups (menu items.)
So the example would look like:
http://www.macromedia.com/support/forums/
or
http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore/
or
http://jakarta.apache.org/turbine/index.html has 4 levels.
There are a number of challenges to doing the n-tier structure, but the
result is worthwhile in my opinion.
In the relational model for this is not too difficult if you track a "level"
attribute. I've also tracked this with a varchar path notation (not sure
it's the best approach but it worked too.) In the file system approach using
xml lends to the tree or hierarchy well; XPointer may also factor in - I
think I saw something within Cocoon using XPointers... lead in to next
question.
Have aspects of Cocoon been reviewed to see if they fit into the the
solution? I've not used Cocoon, but poking around the documentation a while
back made me think it's potentially valuable for this type of site and page
definition.
One of the really nice features of WPS is the capability to 'lock' down
pages or parts of pages. e.g. if I have the rights to a Desktop, Page Group,
or Page I can administer it's layout and lock it down.. leaving some parts
customizable. I know some people feel a portal is not a portal unless the
user can customize their layouts. We actually have not and don't intend to
allow our users to customize their pages (yet.) To us, the value of the
portal is in the deployment, component, and modularity of the architecture
and now that the JSR is released - the potential to use OSS portlets, as
well as vendor delivered portlets. So the portal not being a portal without
user customization is mute for us.
Portal virtualization is something we are working on. It would be great if
Jetspeed 2 could consider it in the design. The requirement is that our
various extranets are migrating into our portal implementation. Based on
some aspect of the system (not necessarily the user) we need to determine
the theme and skin, and what "Places", "Pages" and portlets are available.
In our case, if the url were - http://apache.ourextranet.com then we would
set the theme, skin, and filter the available places, pages, and portlets
that can be applied based on the apache subdomain . I guess with an open
source solution standing up entirely separate instances of the portal server
is not such a big deal...although if you have one for each major client
having 200 instances could be a nightmare. We are toying with the concept of
an application context, and then a site context (site = the client or
client's business unit, application context = ourextranet b/c we have
multiple app's or brands) So we will likely try to filter these things based
on those 2 attributes that we'll set in the session. We have not implemented
the virtualization...
I think the rules based processing mentioned in the design doc starts to
address such concerns in the Page Aggregation document.
I'll also throw out there... I was going through the gridsphere
documentation. If I recall correctly they managed to make pages addressible
through some sort of XPath notation. Seemed like a nice feature.
Hopefully, sharing our challenges and direction with our portal helps in the
J2 design discussions.
-TR
P.S: I'm hoping the [Jetspeed-2]|[Jetspeed-1] thing in the subject will
catch on ;)
I'm not sure how to propose the convention to the list though, if it's bad
etiquette I won't?
> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com]
> Sent: Wednesday, November 26, 2003 2:34 PM
> To: Jetspeed List
> Subject: Page Aggregation Design
>
>
>
> Raphael and I have been brainstorming on a Page Aggregation and
> Profiling redesign.
> The result of these random conversations and emails are summarized in a
> design document.
> Its in a pretty rough state but decided it was best to get it in sooner
> better than later so that everyone can get involved up front.
> Its in the CVS under docs/PageAggregationDesign.txt
>
> Please continue the discussion the Page Aggregation Design on this
> thread. Look forward to your creative thoughts
>
>
> ---------------------------------------------------------------------
> 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