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:[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
