Created a jetspeed 2 wiki and I just finished putting your initial summary out there.
http://wiki.apache.org/portals/PortalNavigation 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]
