Of course you'd like to do both. For example I have some menus where I have images instead of text for the individual links, but everything else is the same. For this (label . renderer) is used where label keys panes and renderer is a function that renders a view of a pane.
I'm also doing a weblocks-ian to weblocks-dev integration right now and ran into issues where I added a number of things to the selector infrastructure in my branch that have diverged (a remove-pane feature) and added my own dynamic-navigation which allows you to have variable sized menus; shall I add this directly to weblocks while I'm doing the integration or perhaps as a contrib? I can do this after the navigation merge since I'll be touching the menu objects. Ian On Feb 24, 2009, at 6:11 AM, Jan Rychter wrote: > > Vyacheslav Akhmechet <[email protected]> writes: > >> On Mon, Feb 23, 2009 at 6:31 PM, Ian Eslick <[email protected]> >> wrote: >>> My branch treats the function as a custom rendering method which is >>> called th render the menu item. >> I did this too. I left the original behavior, and made render-menu >> use >> the function as a custom renderer only if it's provided instead of a >> cons cell, not as a car of the cons cell. Just an FYI... > > In my version, the cdr of the cons cell is the "target", an uri-token > corresponding to the pane. I would have no problem with functions > being > provided instead of a cons cell. > > But -- is that really useful? It means you can supply a custom > rendering > method, but only for the items, not for the entire menu markup. > > --J. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
