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: [J2] Menu implementation
Date Wed, 16 Jun 2004 20:38:22 GMT

On Jun 16, 2004, at 6:31 AM, Scott T Weaver wrote:

> On Tue, 2004-06-15 at 18:28, Ate Douma wrote:
>> David Sean Taylor wrote:
>>
>>>
>>> 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 solution
>> +1
> Also -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.
That would just be a different fragment type, such as "markup"
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

>>
>>>
>>>> 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
>> I think if we are going to support non-page based fragments (for 
>> references)
>> 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.
>
Well it does make some sense and certainly simplifies things
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


>>
>>>
>>> I believe the page within a page concept can be easily supported via 
>>> the
>>> profiler's portal URI space, a CMS-like tree
>> Using folder semantics you mean? Then I'm +1.
> I 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?
>>> Im also wondering if the Page Manager should support the JCMS API
>> One thing at a time please ;-)
>> 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 ;)

>>
>>>
>>>> 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 case
>> I meant in this case a TabbedPane displaying fragments defined 
>> *within* a page.
> I 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

>
>> You won't have a folder then.
>>
>>> What about external links, links to other pages...
>>> Or perhaps the folder is how someone defines a menu
> What about having a special link file that you drop into a folder?  
> Just
> 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.
>
For a external link, I think a menu definition is simpler and easier to 
understand
This does sound intriguing though, each menu option could have its own 
decorations and style

>>>
>>>>
>>>> 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.
>
>
>>>> 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
>> +1. I'm all for folder support on this. But not to be restricted by 
>> it.
>
> 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).
>
This sounds reasonable for folders.
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
david@bluesunrise.com
[office]   +01 707 773-4646
[mobile] +01 707 529 9194



---------------------------------------------------------------------
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