The following comment has been added to this issue:
Author: Scott T Weaver
Created: Fri, 4 Jun 2004 12:26 PM
Body:
> What do you think about storing pages and folders in a CMS?
> This would allow versioning of PSML resources.
> Im currently reviewing JSR170 (Content Repository) to get a better
> idea of how JCMS could be standardized.
I like that idea, makes sense and it standardized, as long it is just as easy to
comprehend as folders that contain folders and/or pages. And only then if the same
Page can be inside multiple folders at once, like a sim link except that a Page's hard
reference does not live in any folder. To simplify, you ALWAYS access a page as a
reference.
> I see folders being order as CMS nodes, in a tree navigation like the
> example above.Folders and pages should all be accessible across a
> normalized portal wide URL where "/" is the root folder, like an
> operating system, or like a site map.Perhaps a unique index would
> also
> be a valid page identification method.
> Perhaps a unique index would also be a valid page identification
> method.
That's fine with folders being nodes. But if we use them as the basis for building
navigation, optional ordering attributes are a must. -1 on unique index as to
folders may end up with the same ordering number in which case alphabetical order
would sort it out.
> OK, this is where we *REALLY* need specification documents before
> coding.
> Roger has written and checked in a document describing the basic
> model for Jetspeed markup components. There we have agreed to
> define: decorators and layouts.
> There is currently no definition there of a theme.
> I suggest we work together on clearly defining these concepts, as
> its still unclear.
A Theme is really just the decoration that surrounds the layout. I like theme because
it sets the overall look and feel of the page and it is a very popular buzz word and
it seems that most vendor portals are using the term "theme" to describe what we call
a layout decorator. I would like to keep with present day vernacular were we can.
> What about having menu elements in PSML?I started this discussion on
> jetspeed-dev a while back, but had no response.A menu could link to
> either the current page, or outside the page.Could you please review > that and
> comment on it? need to keep things simple.
I am -1 on adding another data structure to the mix, that just complicates things.
IMOHO, menu = control from J1. I think we can kill 2 birds with one stone by relying
on the naturally hierarchical nature of using folders (nodes) which contain pages and
other folders (nodes). We just need to allow for manual ordering of those elements by
assigning ordering, which is only relevant during rendering and would have nothing to
do with actual folder/page structure itself. As I said before, let the Profiler
figure out how to aggregate all the folders that user has access to based on an ACL
that is attached to that folder/page or add additonal profiling rules that limit it
even further, but the ACL based profiling rule would be the broadest as you can't have
access anything greater than the security you have been assigned. So basically, the
ACL profiling rule should be the default.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-69?page=comments#action_35913
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-69
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JS2-69
Summary: Finallizing Portal Navigation using the Profiler
Type: New Feature
Status: Unassigned
Priority: Critical
Project: Jetspeed 2
Components:
Profiling/Portal Navigation
Versions:
2.0-dev/cvs
2.0-a1
Assignee:
Reporter: Scott T Weaver
Created: Fri, 4 Jun 2004 8:56 AM
Updated: Fri, 4 Jun 2004 12:26 PM
Description:
We still haven't settled on how we are going to generate navigations in J2. I have
some modifications to the Profiler and to the theme logic which may give us some
direction. I am bringing this up as I have been privellage to quite a few vendor
portal demos lately allowing me to see both the good and the bad of multiple
implementations.
- I would say we replace the getDesktop() with getFolders(). There is really no need
for a "root" item or Folder per se since we will be leaving this job to the current
set of profilling rules that have been assigned to the Profiler.
- Folders will contain any number of pages and/or folders.
- Folder items would be ordered the following way: first by assigned index then by
alphabetical order.
- Remove defaultPage logic from Folder, the focused Folder item would be set in this
fashion: set the focus to the last selected child in that Folder then by Folder Item
ordering algothrim defined above.
- It should be the Profiler's responsibility to preserve a user's active item on a per
Folder basis.
- A Folder would still posses the defaultTheme capabillity but with the added abillity
to enforce the defaultTheme on its childern and its childrens' children by overriding
the theme settings for those items with its own.
- Rendering the contents of the Profiler.getFolders() would be left entirely up to the
theme (currently called the layout decorator). Example: a theme could render the
first 2 levels as tabs and the rest as a hierarchical menu to the left of the layout
area.
- DO NOT introduce the idea of controls and controllers. It has been stated before
that these easily confuse people and I agree 100%. We need to keep things simple.
I think the first profiling/navgation implementation would be assigning n number of
roles to a top-level folder. Then allow the Profiler to aggregate what Folders a user
has access to by comparing the roles that user is assigned to the ones required the
Folders required roles (ACL?) I think this approach is already somewhat in place but
it just needs some final implementation details.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
