Hey, I need some reflection time on the patch and the main problem. Basically, I am not sure if people will expect that depending on the state of your submenu, you will want the link to the menu item and submenu to have a different path and meaning associated with -- unless you also update the label each time ? With internal paths, it always helps to reflect on how a web spider will see your site, or a browser without JavaScript support. And I believe this should be as consistent as possible (no links that change meaning depending on not-so-obvious other state).
That said, making internalPathChanged() virtual does provide alot of added flexibility, and the semantics of this method are quite clear, so I am inclined to do this. But does that provide enough flexibility since your patch changes WMenu and WMenuItem at various places ? > Well, first of all I do not do submenu's like how the examples do, I > needed more control, so in each WMenu I have a container, in that > container I have another WMenu if necessary (and so forth if > necessary). Those containers are subclassed from some generic logic > of my things that handle that with an internalpathchanged. > > In my opinion, internalPathChanged callbacks really need to be > changed. Instead of just handling every single path change, they > should register to a certain part in the hierarchy. It could easily > be handled very efficiently internally by a tri-tree. Hmm, would you > accept a patch if I committed such a change? I have been thinking of this problem too -- and my solution so far (in a branch) is to be able to deploy a WCompositeWidget at a specific internal path, and then have a virtual method which is invoked only if the internal path changes at that level. I think this is very similar to your solution ? Regards, koen ------------------------------------------------------------------------------ _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
