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 Thu, 17 Jun 2004 19:40:20 GMT
Maybe you could forward your lost response(s) to the list also?

Scott T Weaver wrote:

> For some reason, Roger's reply-to is his email instead of the list.
> 
> On Thu, 2004-06-17 at 15:28, Ate Douma wrote:
> 
>>I think there are some responses *lost* on the list.
>>In the response from Roger I see several included comments from Scott which haven't
been
>>received on the list (also not in the eyebrowse archives).
>>But Roger seems to have received them.
>>Scott, have you mailed roger directly or did we lose something on the list?
>>
>>Roger Ruttimann wrote:
>>
>>>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
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>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
> 
> 
> 
> 


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