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: [Jetspeed-2] RE: Page Aggregation Design
Date Thu, 27 Nov 2003 01:20:06 GMT
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


Mime
View raw message