Let me check On Wed, 2004-06-23 at 10:38, Ate Douma wrote: > 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: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>> > >>> > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
