portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Ruttimann <roger...@apache.org>
Subject Re: [J2] Menu implementation
Date Thu, 17 Jun 2004 15:25:44 GMT
David Sean Taylor wrote:

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


+1 Since it is more likely that JCMS will manage the pages.

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


If we decide to use folders/files structures for the page/menu 
implementation the JCMS integration could be done in parallel while the 
PSML-2 & rendering  is implemented.  The  definition and the inital 
implementation of the  inital pages/menu implementation should not be 
dependent on JCMS.

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

Why introducing .menu files if it could be defined in a folder? I prefer 
to keep the syntax as simple as possible.

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


I agree that the mix of rendering and implementation is a bit too 
complicated. Different levels of rendering migth confuse more than it 
helps to create menus.




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