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 16:25:57 GMT
Scott T Weaver wrote:

>On Thu, 2004-06-17 at 11:25, Roger Ruttimann wrote:
>  
>
>>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 ;)
>>>      
>>>
>Well, JCMS is just one more thing end users will have to get their head
>around before they can start using Jetspeed 2.  I really don't know how
>I feel about that.  I would be persuaded if some would step up and write
>some good user docs on how to the two work together.
>  
>

The two components (page/menu & JCMS) could be developed independently. 
Once the features are stable the page/menus could be integrated into 
JCMS. Reducing the dependencies for the initial implementation helps to 
speed up the J2 development.

>  
>
>>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.
>>    
>>
>+1
>  
>
>>>Where is the renderer defined, in the fragment or menu?
>>>This seems very cool but a bit complicated
>>>      
>>>
>Neither, since rendering is a look and feel/view concern you would code
>it directly into the layout template, i.e. directly into
>decorations/layout/jetspeed/jetspeed_top.vm
>
>  
>
>>>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.
>>    
>>
>
>How about adding a renderFolder(Folder, String) method to
>JetpseedPowerTool?
>
>(in you layout template)
>$jetspeed.renderFolder(myFolder, "tabbed_folders.vm") 
>
>and just let the template do the rendering.
> 
>  
>
>>
>>
>>---------------------------------------------------------------------
>>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