The new menu builder WayFinder is ready for Testing

Quote from: rthrash at Jul 17, 2006, 08:06 PM

And here’s a quick tutorial for the testers. The following is how you would convert the popular Mollio Menu template menus with Wayfinder. I think you’ll see how much easier it will be to create dynamic, nested menus compared to DropMenu. This is totally untested, but it should work...

Nice, I’ll definitely try this today after I get from work and report the results. Yea, I had to do a bit of hacks to the existing DropMenu to get it work in Mollio.. the side menu needed activeTreeMenuOnly hack and I also did some other changes, what I can’t remember..

Quote from: Dimmy at Jul 18, 2006, 02:29 AM

Nice but what if I just call it like this? [[wayfinder]] wil it give me a plain unsorted list with a .here class? I hope so.

It can be made to use a default theme so if nothing is specified then it will load the default templates.

another thing I saw a couple times is this regclientcss or other regclient stuff is this in the API or is this just php? in a snippet susan made that i changed later called simpleslideshow she used this also but it did not work on my redhead apache server with php4, so if we gonna use somthing like this we must make shure that it always works.

The regclient stuff are part of MODx. They are used to insert CSS and JS scripts inside an html document. From what I understand there where a bug in earlier versions of MODx that caused those apis to not work. You might want to either check the latest SVN or use the reg functions that I’ve uploaded in the new parser.

These are all great ideas, and I should hopefully get some work done on this in the next few days.

Here is a list of things I plan to add:

Theme support
Fix nesting error
create default theme to ship with snippet
add regclientcss to make theme support easy

I hope to have these changes done by the end of the week. I am heading to Las Vegas from saturday to monday, so hopefully I can get it before then. I definatly won’t get anything done there

Had a thought on the theme support.

Should we make it so that each theme would be in a folder under assets/snippets/wayfinder/themes/

Then each theme would have its own folder that way you could include images with your theme file and referecne them.

So it would look something like this:

assets/
snippets/
wayfinder/
themes/
moolio/
moolio.theme.html
image1.jpg
image2.jpg
myCustomTheme/
myCustom.theme.html
default/
default.theme.html

Let me know what you think

Quote from: kylej at Jul 18, 2006, 08:06 AM

Theme support
Fix nesting error
create default theme to ship with snippet
add regclientcss to make theme support easy

Hi Kyle,

I think we need to at a standard format for using/creating themes. The list outlined by Ryan is something that we have had some discussions about last night. I think it should follow the steps stated in Ryan’s post.

I’m thinking of something like a $modx->loadSnippetTheme($themefile). This would return an array containing the theme parameters as keys.

Should we make it so that each theme would be in a folder under assets/snippets/wayfinder/themes/

Yes I’m in agreement with that.

[Written before I read the last message]

nesting
Quote from: kylej at Jul 17, 2006, 06:15 PM

It is a "glaring omission", I will get the code to nest correctly.

Glad my testing was useful.

defaults
Quote from: rthrash at Jul 17, 2006, 07:51 PM

perhaps (and my preference) we should just add a very basic and minimum set of templates hard coded so some output will result.

I absolutely agree with you and Susan - especially if this is the new "core" menu builder.

I’d be tempted to make startId=`0` the default, but I appreciate that there is a great timesaving in having it default to the current page, as it isn’t particularly obvious how else you’d pass that (without recursive parser).

But still, the ideally basic [[Wayfinder? &startID=`0`]] should output a sensible menu.

With that in mind, I must ask you to please please please change the default &textOfLinks.
Currently it defaults to pagetitle! Really the default text for a MODx menu should be menutitle. Otherwise, what is the point of that field?
The &titleOfLinks is OK to stay as pagetitle - if you have the &titleOf different to the &textOf, the benefit of mouseover text is apparent. Of course, not everyone has different pagetitle/menutitle/longtitle text for their pages but actually it’s one of the things I like most about MODx.

Also, why are some booleans defaulting to 0, and some to false? I’d rather this was consistent. This is probably just a documentation issue, they’re probably the same, but I think that using "false" instead of 0 would make things clearer to people.

Passing code in the snippet
I’d like to be able to pass code in the snippet call itself, ie &innerTplCode=`<ul id="nav">[+wf.wrapper+]</ul>` but I appreciate that some characters would need escaping.

The skin/theme concept
xwisdom’s idea is to load in variables from another file. And moving the chunk html to the variable value is not unlike my suggestion above. If you added to the core snippet execution functionality the ability to load in variables from another file, and every snippet that allowed chunks also allowed you to pass through HTML code directly, then you have a standard MODx "theme" function for every snippet. All you’d add would be

and the snippet would have all the settings from the call and all the settings from the file.

You could also have Settings as another type of MODx database content, like Snippets and Chunks. If they are to be files, I think that all the settings would end up nestling in the same directory, as there may be benefits from using the exact same call on both a WayFinder snippet and a WayFinder2 snippet.

In terms of code re-use, this is greatly beneficial whenever largely the same menu appears on multiple templates, as it is not just about the templates but any setting.

With the recursive parser and some conditional code you could potentially be using variables to decide which Settings file to load - thus different menu output from the same page depending on who is logged in, and their preferred style, etc etc.

So I think that theme settings are better added to MODx rather than to this snippet, but being able to pass code in directly would make the theme setting file more viable.

[reads 3 newly added posts]

Quote from: kylej at Jul 18, 2006, 08:12 AM

Should we make it so that each theme would be in a folder under assets/snippets/wayfinder/themes/

Then each theme would have its own folder that way you could include images with your theme file and reference them.

Whichever way we do themes, I would rather reference
assets/images/snazzy/image2.jpg
than
assets/snippets/wayfinder/themes/snazzy/image2.jpg

not least because many "skin" backgrounds can be reused in different parts of a page and it is better to have them all reference the same image than to have
assets/snippets/wayfinder/themes/snazzy/image2.jpg
and
assets/snippets/ditto/themes/snazzy/image2.jpg
be the same image.

Similarly in terms of themes, I’d rather it went
themes/snazzy/wayfinder
themes/snazzy/ditto

so that people could plug in "MODx" themes which had elements for multiple functions rather than Wayfinder themes.

Quote from: xwisdom at Jul 18, 2006, 08:20 AM

I’m thinking of something like a $modx->loadSnippetTheme($themefile). This would return an array containing the theme parameters as keys.

That sounds like a great idea, this functionality could be used in a lot of snippets. So I guess we need to decide on a standard format for the theme files so we can setup an api function to process them.

Anyone have any ideas on what the file format might look like? maybe something like this:

&parameter:’ ’;
&parameter:’ ’;
etc...

maybe this needs its own topic?

I hadn’t read xwisdom’s most recent post when I posted. Yes this needs splitting. I don’t have the power here.

Quote from: xwisdom at Jul 18, 2006, 08:20 AM

I think we need to at a standard format for using/creating themes. The list outlined by Ryan is something that we have had some discussions about last night. I think it should follow the steps stated in Ryan’s post.

I’m thinking of something like a $modx->loadSnippetTheme($themefile). This would return an array containing the theme parameters as keys.

My lengthy post proposes having that step invisible to the snippet; the theme/settings file parameters would have been loaded as keys just as if they were in the call. Any keys set in the snippet call would override whatever was in the theme.

Quote from: xwisdom at Jul 18, 2006, 08:20 AM

Should we make it so that each theme would be in a folder under assets/snippets/wayfinder/themes/

Yes I’m in agreement with that.

I’m in disagreement with this point, but I’m not actually fussed as long as there’s a standard.

Quote from: kylej at Jul 18, 2006, 08:36 AM

Anyone have any ideas on what the file format might look like? maybe something like this:

&parameter:’ ’;
&parameter:’ ’;
etc...

I would rather we use the same format when passing parameters to a snippet.

@Paul,

Similarly in terms of themes, I’d rather it went
themes/snazzy/wayfinder
themes/snazzy/ditto

I’m in total agreement with paul’s suggestion on using a themes folder (assets/themes) for code reuse.

I think I’m gonna disagree on the Themes issue slightly, but only in default behavior implementation. Putting it all in one place for Wayfinder makes adding a theme images for the menu a simple upload of one folder. This would make the addition of menu designs painless. And it should also make for far fewer support requests ... which is key!

However, for advanced users I think we should make an optional override parameter that is &imageBasePath. This would give you the ability to store their images with the rest of them by telling it what the base path is. Otherwise it uses "assets/snippet/wayfinder/themes/insert-theme-name-here". We might need to look at relative vs. absolute paths, but this would give the ultimate in flexibility.

Good thoughts folks!