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:28:58 GMT
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


Mime
View raw message