Wayfinder Configs - is there any hope?

Is there any chance that the Wayfinder standard config files will work in Revolution in the near future?

At present, Wayfinder "includes" the config file but doesn’t process the $cssTpl parameter and the config parameter is missing from the default properties.

When I wrote code to handle the $cssTpl parameter and put a config parameter in the Wayfinder tag, I got the various menus. All were styled with CSS and included the correct images (mostly) but none actually worked for various reasons in Revo (they all work, more-or-less, in Evo). In Revo, the layout is somewhat wrong, sometimes items overlap, and many sub-menu items can’t actually be selected. They’re close enough that I’m sure the config file and the CSS files are read.

The only thing I can think of is that either they depend on other CSS settings in the MODx demo site, or the Revo Wayfinder call isn’t setting the classes correctly (or both). I did find and report some Wayfinder bugs, but I don’t think they would cause the problems I’m seeing.

I’d like to write about the config files because I think they’re a good starting point (and some of them are actually pretty useful for new users).

I’m just wondering if I should forget about them or if there is something planned.

Bump . . .

Wayfinder is not being actively developed by the core team. If anyone wants new features, they will have to:

- Contribute to Wayfinder development and add them in to the Revo version
- Talk to the author of Wayfinder and request they be added in / fixed

Quote from: splittingred at Oct 28, 2009, 12:52 PM

Wayfinder is not being actively developed by the core team. If anyone wants new features, they will have to:

- Contribute to Wayfinder development and add them in to the Revo version
- Talk to the author of Wayfinder and request they be added in / fixed

Fair enough, but I don’t want new features -- I want the old features described in the Wayfinder docs but not working in the Revo version.
It is kind of a critical add-on, IMO, and the current state could definitely break some sites ported from Evo to Revo.

I did suggest some fixes on Jira, but in addition to the config issue, there are some bugs that I described but don’t understand Wayfinder well enough to know the best approach to fixing (and, like you, I’m supposed to be working on something else ).

Did Kyle do the Revo version?

Quote from: BobRay at Oct 28, 2009, 03:06 PM

Fair enough, but I don’t want new features -- I want the old features described in the Wayfinder docs but not working in the Revo version.
It is kind of a critical add-on, IMO, and the current state could definitely break some sites ported from Evo to Revo.

Right, which is why we’re focused on getResources, as well as other snippets, that can be alternatives to Wayfinder.

Did Kyle do the Revo version?

It was ported by garry/jason/I from the 2.0 version of Wayfinder a long time ago. All we did was adjust some basic things, and move the queries to xPDO.

Is it the intention that getResources will completely replace Wayfinder?

I tried to see the extent to which that would be possible, but getResources has no readme.txt and no default properties so I had to look at the code.

I don’t see any way of implementing things like &hideSubmenus, &config, &includeDocs, &excludeDocs, &displayStart, &showHidden, &cssTpl. &ph and some others. And some of those appear to be broken in the Revo version of Wayfinder. Then there are all the custom classes that allow complex menu styling in Wayfinder (&hereClass, &levelClass, &parentClass, etc). Also, I don’t think that the default classes are being assigned correctly in all cases in Wayfinder.

I don’t mean to be at all critical here. I’m just trying to figure out what to do in the book about Wayfinder parameters, and classes, that are missing or don’t work in Revo. I don’t want to omit them or say they don’t work if they’ll be fixed.

Quote from: BobRay at Oct 28, 2009, 05:12 PM

I tried to see the extent to which that would be possible, but getResources has no readme.txt and no default properties so I had to look at the code.

That will be remedied in later versions of getResources.

I don’t see any way of implementing things like &hideSubmenus, &config, &includeDocs, &excludeDocs, &displayStart, &showHidden, &cssTpl. &ph and some others.

- hideSubmenus would be easy.
- config is really unnecessary now do to Property Sets, but that’s debatable still.
- includeDocs/excludeDocs would also be easy.
- displayStart, again, simple.
- showHidden is a simple toggle.
- cssTpl is an easy regClientCSS call.

tbh, Bob, I don’t see how this would be that difficult to add these features to getResources.

And some of those appear to be broken in the Revo version of Wayfinder. Then there are all the custom classes that allow complex menu styling in Wayfinder (&hereClass, &levelClass, &parentClass, etc). Also, I don’t think that the default classes are being assigned correctly in all cases in Wayfinder.
I don’t mean to be at all critical here. I’m just trying to figure out what to do in the book about Wayfinder parameters, and classes, that are missing or don’t work in Revo. I don’t want to omit them or say they don’t work if they’ll be fixed.

tbh, I don’t know. It all depends if we get the time, the community effort, and the money to do it. This is open source - it goes as fast as the community makes it go. As for your book - as I’m sure you’re aware, trying to write a book on a product not yet finished will result in some unknowns. I hate to say it, but Wayfinder is far lower on Jason and I’s priority list than getting food on the table, finishing the Revo core to RC1, writing basic Revo documentation, and getting the manager rc-worthy stable.

If someone else would like to champion this, we’d be all for it. But we’re maxed out. I’m sorry Bob, that’s all I can give you.

Fair enough.

I agree that those would not be hard to add (although the custom classes, not so much), but they’re not there now and it’s hard to say when they might be.

I hope someone will jump in and contribute. Personally, I think I’d rather see Wayfinder match the Evo version and keep getResources lean and mean, though I could be convinced otherwise (and I wish it were called GetResources -- probably too late for that).

I can see doing &config for Wayfinder with packages containing the files and custom property sets, although I think we might need some more properties and possibly code changes in Wayfinder to support them. Wayfinder would probably have to match its Evo behavior first -- that would make the conversion infinitely easier.

Quote from: BobRay at Oct 28, 2009, 05:42 PM

I agree that those would not be hard to add (although the custom classes, not so much), but they’re not there now and it’s hard to say when they might be.

I hope someone will jump in and contribute. Personally, I think I’d rather see Wayfinder match the Evo version and keep getResources lean and mean, though I could be convinced otherwise (and I wish it were called GetResources -- probably too late for that).

Yes, we need more component developers to jump in ASAP; it’s going to take more examples of original and ported components to build any momentum here and we could definitely use some help from folks interested in getting familiar with Revo component development.

More importantly, I agree 100% regarding seeing Wayfinder match the latest Evo version, though if the implementation can be improved at the same time, I encourage it. The key thing to remember when porting is that we have to make the migration from Evo to Revo as smooth as possible for folks. We can’t solve every difference, but we can at least try to make things work the same in the components that are ports of existing Evo components.

Quote from: BobRay at Oct 28, 2009, 05:42 PM

I can see doing &config for Wayfinder with packages containing the files and custom property sets, although I think we might need some more properties and possibly code changes in Wayfinder to support them. Wayfinder would probably have to match its Evo behavior first -- that would make the conversion infinitely easier.

Matching behavior in the ports where possible should be the #1 goal. The second goal though is to exemplify code best practices in the ported components, and this is what takes some time. Of course accounting for the changes in the way the new parser works and other differences in the new architecture make some of the original behavior difficult or impossible to achieve as-is, and in some cases we will have to make some adjustments and possibly some migration pages in the documentation to describe how these changes would affect legacy usage. We can explore migration automation/assistance once we have fully-baked ports.

Jason, what’s your thinking on bells and whistles versus minimalism for getResources?

I’m thinking it may get somewhat bloated if we try to make it replace both Wayfinder and Ditto. OTOH, it would be kind of nice to have a Swiss Army Knife snippet.