portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [J2] Menu implementation
Date Wed, 16 Jun 2004 15:42:00 GMT


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:
>>>
>>>
>>>>I've been trying to get a clear picture of what the options and 
>>>>positions are about menu creation for J2.
>>>>
>>>>I'm quite lost after reviewing several sources:
>>>> - 1) current J1 impl
>>>> - 2) design-docs/src/decorations/J2 layout and decorator handling.pdf,
>>>> - 3) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=14232
>>>>   ([J2} Proposal for Layout, pages & Decorator handling in J2)
>>>> - 4) http://nagoya.apache.org/jira/browse/JS2-69
>>>>   (Finalizing Portal Navigation using the Profiler)
>>>>
>>>>A few design issues needs to be addressed I think to be able to decide 
>>>>on the impl. of menus.
>>>>
>>>>- Nested pages
>>>>Should these be allowed?
>>>>Part of that question is what a Page is.
>>>>The pdf (see 2) says its to be considered a Fragment.
>>>>If this is meant as a "fragment" which can be included, alright. But, 
>>>>I don't see how it also can
>>>>be a "Fragment" (note the case) or why it should be made one.
>>>>
>>>>Fragments already can contain other Fragments though. This is more or 
>>>>less in analogy to nested
>>>>portlets in J1 I belief.
>>>>
>>>>Maybe one reason why one would want to nest pages is to be able to 
>>>>define different decoration on a nested page.
>>>>It has been suggested by Scott (see 4) to allow for the most flexible 
>>>>way possible this should be possible
>>>>(even up/down overrides if needed).
>>>>
>>>
>>>I see pages as existing in a bug bucket of pages.
>>>Its up to the profiler to locate the page.
>>>The way this is implemented in J2, the profiler looks at the URL path to 
>>>find the page.
>>>For example
>>>
>>>/jetspeed/portal/pam
>>>/jetspeed/portal/struts-demo
>>>
>>>Locates a page named "pam" and "struts-demo" respectively
>>>A believe that the Jetspeed Profiler should support locating pages in a 
>>>CMS-like URI namespace:
>>>
>>>/jetspeed/portal/root/folder1/folder2/mypage
>>
>>I think this is already possible right now, although not really based on a "Folder"
object.
>>
>>
>>>Would locate a page name "mypage" in the folder "/folder1/folder2"
>>>
>>>This does not imply that pages can be nested, and Im against nesting 
>>>page as it corrupts the semantics of a page version a fragment.
>>>The page implementation should support 'nesting' or 'referencing' of 
>>>fragments.
>>>A fragment should also be referenced in the portal URL, for example as a 
>>>render parameter:
>>>
>>>/jetspeed/portal/folder3/page4/_r_fragment/3939
>>>
>>>
>>>
>>>>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.
Inside psml? That would kill capability independence for sure...
I would be -1 on that.
> 
> 
>>>>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.
> 
> 
> 
>>>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.
> 
> 
>>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.
> 
> 
>>>>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.
> 
> 
>>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.
We sure would have a hard time supporting that kind of feature through a DB
Page manager tough, or the code has to be stored "raw". But JCMS should
be able to handle that just fine.

> 
> 
>>>>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).
> 
> Next we introduce the idea of a navigation renderer that would consume
> and render either .menu files OR folder/page structures.  
Per site or per root folder?

> 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.
What I don't see how and where these folder navigation renderers are to be
defined. We need some kind of configuration for them...
Would you suggest special psml type definitions or something different?
If I interpreted this correctly I guess this can only be defined in/on the
root folder as all folders and pages below it will have to conform to the
same definition otherwise navigating within could lead to strange effects.
And possibly one standard site definition which could be overridden per
root folder?

I think I do like this proposal so far. I can even see we might not need
.menu file or embedded menu definitions after all.
Only having to define all these extra Pages (in contrast to the J1
implementation) which all reference the same decorators seems not so nice.
Furthermore, we would lose the ability to define acl inheritance etc. Or
should we also be able to define these on each folder? A folder really
is going to be much more than just a file system structure then...
And, these menus somehow are to be embedded into a rendered page.
Where are we to define these. In the page decorator?

> 
> 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.
> 
> 
>>>>I'd like some comments and if already possible a vote which way we 
>>>>should go about menu rendering.
>>>>I know I'll something soon ;-)
>>>
>>>
>>>Yes well lets try to get some consensus on design first
>>
>>:-)
>>I don't want to push anything here. Consensus must be reached of course.
>>I just think its an important structural issue which already has been discussed a
few
>>times before. After a certain time, its better to decide instead of keep the issue
>>dangling ...
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


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