Forum OpenACS Development: Re: Ajax Drop Down Menues for XoWIKI

Collapse
Posted by Gustaf Neumann on
The best approach is to look at the code first. You will notice that the category tree has already two styles. For adding a third one, you should define a mixin class like it is done for the section style. You will most probably loose some functionality of the includelet (like e.g. opening the tree partially the show the current item).
Collapse
Posted by Malte Sussdorff on
Well, if you define an "if {$tree_style}" as the best approach then I wholeheartedly agree with you, that looking at the code would have been sufficient 😊. Okay, enough of the underhanded compliments.

You are using a boolean to differentiate between two styles and if the "other" style is true, you mixin the Categoriy::section_style. Now, if I am using the mixin approach, I still need a way to tell the categories includelet WHICH style to mixin. As you have been using a boolean, I can hardly suggest to change the "tree_style" into a string, as this would not be backwards compatible.

Luckily, the open_item parameter for add_to_category provides me with the currently open item, allowing me to render the top navigation's menu item in a different color, if the currently displayed page is in that navigation. In past projects users solved this issue by having an include (as in XoWIKI include of another XoWIKI page) for the main navigation (without drop down menues, left to right, on top of the page), which I deem not ideal, but it worked for them 😊.

Therefore the question: How can I define the mixin class to use in the categories includelet, which is the approach you would take (as I don't want to duplicate the code for the categories includelet just to be able to call a different rendering mixin class) ?

Collapse
Posted by Gustaf Neumann on
Hi Malte,

the old interface was just for activating tree style (actually an mktree-based tree-style) and the "sections" style. The classical approach in such situation is to define a subclass, which has a more flexible interface but inherits the rest of the code.

Since there is not much code involved, i have updated the interface in cvs HEAD such one can use arbitrary category renderers. One can now define an arbitrary renderer (named ::xowiki::CategoryRenderer=$style) and pass the -style to the includelet. You can define the renderer in an arbitrary -procs file. Let me know, when you need more....

-gustaf neumann

PS: glad to see you back, i thought, we lost you to SAP.

Collapse
Posted by Gustaf Neumann on
A small followup: in order to develop a new viewer for e.g. categories, i would recommend to disable for the development the includelet caching (set parameter "cacheable" of the includelet "categories" to false). Otherwise you have to flush the page fragment cache entries frequently to check the results of your changes.
Collapse
Posted by Malte Sussdorff on
Thanks a lot for the help, I will dig my heels into this today. And good point with the caching, I would certainly have had trouble with that.

As for the loosing part, my website still runs ]project-open[ and some other sites run .LRN, so I'm not gone, just a more passive follower with the occasional odd need. Though I have to admit, the SAP world is more profitable and the Drupal world provides much easier access to developers.