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, 23 Jun 2004 14:38:31 GMT


Scott T Weaver wrote:

> Created a jetspeed 2 wiki and I just finished putting your initial
> summary out there.
> 
> http://wiki.apache.org/portals/PortalNavigation
> 
That's just great!
Can we get wiki update messages be send to the list?

> 
> On Wed, 2004-06-23 at 09:32, Ate Douma wrote:
> 
>>Scott T Weaver wrote:
>>
>>
>>>On Wed, 2004-06-23 at 06:36, Ate Douma wrote:
>>>
>>>
>>>>I'd like to add a few comments to my proposal concerning the elements section
of my example (some of which
>>>>came up yesterday during a chat I had with David Sean Taylor).
>>>>
>>>>Here's the elements section again:
>>>>
>>>>    <!-- Folder elements displayed in the menu (in the current example
in tabmenu if level < 3 or in treemenu otherwise)
>>>>         in the order as defined
>>>>    -->
>>>>    <elements>
>>>>
>>>>      <page id="page1"                         description="Page 1"/>
>>>>      <page ref="../../subfolder2/page8"/>
>>>>      <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
>>>>
>>>>      <folder id="subfolder1"/>
>>>>      <folder ref="/subfolder1/subfolder3"/>
>>>>
>>>>      <link url="http://www.apache.org"     description="Home Apache" 
       target="_self"/>
>>>>      <link url="http://portals.apache.org" description="Home Apache Portals"
target="outside"/>
>>>>
>>>>      <!-- hidden elements -->
>>>>      <page id="page2" hidden="true"/>
>>>>      <folder id="subfolder2" hidden="true"/>
>>>>
>>>>    </elements>
>>>
>>>
>>>So, we are going to have to have meta-data to describe the folder?  I
>>>thought links were going to be simple text files with urls in them, not
>>>entries in meta-data.
>>
>>I'm ok with using simple text files for Links (and element references).
>>But, there remains the need for some folder meta-data:
>>1) Folder description (for menu display)
>>2) An optional 'skip' attribute setting
>>3) Menu parameters, decorator and decoration configuration.
>>    Because of the inheritance though this won't be needed in all folders.
>>4) Menu element order and hiding elements.
>>    We can use a default ordering scheme like ordering on the descriptions.
>>    But, if that's not sufficient, some kind of meta-data will have to be
>>    specified.
>>    One option I previously suggested could be defining in within the
>>    elements (Page definition, Link and element reference files).
>>    Defining hidden elements can also be done like that.
>>
>>So, As far as I see, the only really required meta-data needed for all
>>the Folders is its description (1). The others are all optional or can be
>>solved differently (4).
>>What do you think?
> 
> Sounds good to me!
> 
> 
>>>
>>>>In my example all the elements for a menu node are specified, including those
not to be displayed
>>>>(hidden). The 'hidden' elements really are redundant in this example if all
elements are to be specified.
>>>>So you can just leave them out.
>>>
>>>-1.  I think reversing it is a better idea so that only special cases
>>>(like hidden) need to be specified.  The folder meta-data should be
>>>entirely optional.
>>
>>I agree, at least as far as it it possible. See above.
>>
>>>
>>>>But, you still need to specify all which should be displayed. Furthermore,
the order in which they are
>>>>displayed is derived from it.
>>>>
>>>>One issue from the previous discussions was that we really should provide
a intuitive and easy menu configuration.
>>>>Although I think my proposal is very powerfull, it still requires a lot of
configuration (but far less then what's needed in J1).
>>>
>>>
>>>definte +1 on ease of use and heavy documentation ;)
>>>
>>>
>>>
>>>>Maybe different strategies can be defined for deriving the elements, and their
order, so the elements section isn't
>>>>always, or not at all, needed.
>>>>One way could be allowing 'hidden' and 'order' attributes on Page and Folder
configurations.
>>>>Still, Link and element references will have to be defined. Maybe it could
be done in separate configurations (files) instead
>>>>of bundling them in one. Don't know if that would be an improvement though.
>>>
>>>Again, can't a link be a simple text file with a with a url or maybe it
>>>contains an <a href=""> </a> tag in it.
>>
>>It can. Its still meta-data though. It doesn't matter much I think if its put into
one folder-meta-data file or in 
>>several link/reference files.
>>
>>
>>>
>>>>Concerning the 'intuitive' menu definition issue: maybe what is needed is
a change of view.
>>>>In J1 you won't have a menu unless you define it (completely) on every page
which needs one.
>>>>Using this proposal, you usually have a standard menu definition (tabmenu
on the top, tree menu on the left or something similar).
>>>>Only thing needed is a proper menu node configuration instead of a complete
definition.
>>>>By default, a new Page could be automatically included in a menu unless it
is made 'hidden'. It really is more a question of in which folder 
>>>>the Page should go to get it in the correct menu.
>>>
>>>+1.
>>>
>>>
>>>
>>>>And using Links and Page or Folder references is simply adding them to the
correct folder to get them included.
>>>>With Links and references the site navigation can be defined 'on top' of the
folder structure.
>>>
>>>+1.  Simple and easy to understand, I like it.
>>>
>>>
>>>
>>>>Regards,
>>>>
>>>>Ate
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>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