On Jun 16, 2004, at 6:31 AM, Scott T Weaver wrote:
On Tue, 2004-06-15 at 18:28, Ate Douma wrote:That would just be a different fragment type, such as "markup"David Sean Taylor wrote:
+1
On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
To me, this seems to lead to very complex psml though. I would certainly like to see a more simple model implemented first before going that road.
Im -1 on nested pages, and +1 on nested fragments (references), which does not need to be implemented in the first solutionAlso -1 on nested pages.
Nested fragments, but not as references, are already used by the layout portlets!I would also like to add support for non-portlet fragments, like raw html, etc.
These markup fragments will need a deployable model, like decorators
It first it would seem we lose all the benefits of a portal if we put in HTML-specific markup,
On the other hand, if your PSML pages were markup specific, like what J1 currently supports, it makes more sense
Well it does make some sense and certainly simplifies things
I think if we are going to support non-page based fragments (for references)
Probably the same result could be created without page nesting using fragment references. These could reference other pages (pulling in their decorator definitions with them) or fragments within other pages. As far as I can tell, then there would be no need to define pages within pages.
Fragments do not need to be associated with a page, at least not in a database implementation See the database model for PSML in the J2 CVS
we should also provide a file based implementation. Dunno if you should still
call it psml then though.
Believe it or not, I am beginning to think the non-RDBMS XML file-based page system is a better approach than the RDBMS one. It fits better into CMS model than an RDBMS page manager does. We could also use VFS to abstract the file system were the pages reside. VFS also supports a WebDAV based file system out the box.
RDMBS PSML can just be an implementation for those who need it. It doesn't need to be implemented first.
For scalable systems, from my experience a more robust Page Manager will be required than simply putting the pages on the file system
with no sharing across nodes
With WebDAV interfaces, we could push all of that logic (locking, versioning) back to the CMS Server and not have to deal with it
That is one of the goals of JCMS
Perhaps we should look into a VFS-backed JCMS for the WebDAV support
I will try to work on getting JCMS into incubator so that people can look at it
The current base system has a small footprint, and I'd still prefer it to go into J2 as a component
Using folder semantics you mean? Then I'm +1.
I believe the page within a page concept can be easily supported via the
profiler's portal URI space, a CMS-like treeI also think the folder metaphor is the best approach.
- Folder or menu elements
The Folder concept containing other folders and/or pages could be used
to generate menus as proposed by Scott (see 4).
Something I'm missing right now is a clear understanding how/where
folders are defined. I found the om impl but no usage
yet so its something I can't relate to enough yet to really decide if
I'm going to like it or not.
Couldn't the Page Manager support the concept of folders in its model?One thing at a time please ;-)
Im also wondering if the Page Manager should support the JCMS API
Do I understand it now correctly that folders (for a file based Page Manager)
are simply derived from filesystem folders?That is how I see it. Or possibly using a VFS file system.
Im still not convinced that VFS should be coupled to Jetspeed Prefer coupling at the JCMS level I will get some interfaces out on the web today for review
So no definition needed in the psml.
Of course, a DB Page Manager would still require explicit folder configuration.That is why I am leaning more towards a page-based system.
If we have folders and pages can't JCMS support be added then "on top" later?+1. JCMS may over complicate things in in the beginning.
I don't think so, review the interfaces first before passing judgment ;)
I meant in this case a TabbedPane displaying fragments defined *within* a page.
One important issue I would have with it though is that it wouldn't
allow me to render page fragments/portlets in a menu, not external links.
Likewise, I don't see how a TabbedPane could be rendered for the
current page using the folder
concept.
I believe the tabbed pane could automatically pick up the folder's children nodes as its menu options This is a valid use case, but not the only use caseI don't I like idea of navigating "within" a page. A page should be your final stop, all fragments being rendered at once.
The ability to navigate within a page was a popular feature in J1 (the impl caused me endless headaches)
For example, nested menus where only the selected portlet from the fragment set is displayed and all
other portlets are hidden
I think we could leverage the portlet API to achieve the same thing, through maximize mode
Although nesting maximized portlets is not really supported
For a external link, I think a menu definition is simpler and easier to understand
What about having a special link file that you drop into a folder? JustYou won't have a folder then.
What about external links, links to other pages... Or perhaps the folder is how someone defines a menu
a plain text file with url in it. You could even go as far as dropping
velocity template into a folder to support more complicated menu items
and such.
This does sound intriguing though, each menu option could have its own decorations and style
This sounds reasonable for folders.
The other proposal from David Taylor was defining new psml menu and
menu-item elements which could reference pages, (external) fragments
and external links (see 3).
I understand Scott didn't like adding additional data structures into
the mix (see 4), but I for one would prefer this
above the folder/page -> menu concept. AFAIK its way more flexible and
probably much easier to understand for a user.
+1. I'm all for folder support on this. But not to be restricted by it.And, it isn't that different from the J1 implementation. Recreating
the current J1 features for J2 will be relatively easier to do I think.
Note: I know the folder concept is not *just* about menus. I'm not opposed to folders in anyway. I just think its to restricted for menu rendering.
Can we support both, or is that too confusing to the end user? See 4 for the menu xml syntax:
<menu type='folder' url='/myfolder'/>
which would generate a menu based on a folder
This was exactly my reasoning for using menu/folder concept. I think a good compromise would be this: standard navigation would be built using the folder concept. However, we can introduce an optional "menu" fragment that would be sourced from a .menu file that contained a standardized xml format (like format proposed above).
When the user navigates to a folder, they get the default menu for that folder, all nodes within that folder.
However, how would you put a menu on a page?
This could be solved by not differentiating between folders and pages, and treat them all alike.
Whereas many systems treat pages as leaf nodes, PSML pages could be considered as non-leaf nodes like folders.
Next we introduce the idea of a navigation renderer that would consume
and render either .menu files OR folder/page structures. You could have
multiple navigation renders on a final portal page. Renders could also
be limited on the number of levels they should render. For example, you
could have tabbed renderer at the top of a page, and tell it to only
render the first 2 nested levels of folders. Then on the left hand side
of the page, we have tree-like menu render that renders from level 3 on
down.
The navigation renderer gives us a very fine grained control over how we
render our navigation and separates the model (.menu or folders) from
the view.
Custom ordering of navigation could be done by storing item order in user preferences.
Where is the renderer defined, in the fragment or menu? This seems very cool but a bit complicated
The part that Im trying to solve is how can the user clearly define menus
If we are introducing renderers and implementation details into the mix, I think it confuses the simplicity of the model
-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
