Ampersands in Snippet Calls

OK, first of all, this is what the menu looks like on our site:



The menu can do various things that are not shown, such as have disabled items, and items that function as inline category headers. This is controlled by having entering markup into the document fields -- for example to disable a field, you enter %%DISABLED%% in front of its name.

Here’s what the source menu looks like in SoThink DHTML Menu:



This way, you can go nuts and design your menu in a GUI environment. The code rearranges the menu to fit with the MODx tree, and applies the various "commands" entered as markup in document fields.

This is a DHTML/Java menu, which renders a bit slow in IE, but blazing fast in Firefox and Safari. Actually, many things render slow in IE.

Best,

Per

The Revo parser doesn’t care about what’s inside the backticks FYI. Bolting the Revo parser on top of Evo isn’t something that’s trivial however. They work in two completely different ways.

Hi Ryan,

I’m honored!

I thought as much, since you have changed the snippet/chunk wrapper character as well to make it parse more efficiently -- so I assumed you used the opportunity to limit the parsing of these naturally occuring characters.

We’ll stick with Evo for the next year or so, and when you take Revo into production, I’ll set it up on a staging server and port our site slowly.

May I say, sir, that you have done an incredible job with this CMF. You should be very proud.

Best,

Per

A way around the character issues in snippet calls is to embed the call data into a wrapper snippet, then you would not need to worry about the parser. However, you loose the ability to edit the parameters in the call itself.

You can also use a config type setup to manage the setup or put the call parameters into in a chunk as an array and get it straight from the DB bypassing the parser...like an include file. It all depends on the flexibility you are looking for.

The flexibility I’m looking for is to be able to say:

[[TextBox? &title=`Mix & Match` &body=`Check out this link: http://www.yahoo.com/test.php?source=me&page=2` ]]

Certainly it’s possible to bury it in a database or an include file, but then it loses the editability that’s the entire point -- suddenly you need a file editor to change website text. With those options, doing str_replace is far better, but still utterly clumsy and prevents copy/paste in any meaningful way, which is a real problem for a website where the text is carefully written in a word processor. Then you say:

[[TextBox? &title=`Mix %%AMP%% Match` &body=`Check out this link: http://www.yahoo.com/test.php%%QUE%%source%%EQU%%me%%AMP%%page%%EQU%%2` ]]

That’s a mess if there ever was one It’s terribly uneditable, it makes copy/paste impossible, and longer sections of regular English text literally need to be converted in order for MODx to be able to print it on the screen. If you’re non-English, this problem is 10 times worse, because every other letter is an Ӓ

But thankfully, I now understand that this has been fixed in Revolution. I’ll suffer the str_replace for a while, because at least it’ll be backwards compatible, and then I can revert the text when we upgrade to Revolution.

Best,

Per

You won’t have to wait a year for Revo, either.

HI Ryan,

The question is this, and you’re probably the best person to answer it:

Is Revo stable enough, and is the API locked enough, that it would be safe to quickly convert the site to Revo before launching? Obviously, I’d rather be set for the new environment, because then subsequent updates will become much easier. But on the website, you just make a point of advising people not to use Revo in production. I also assume that there are no full-blown converter scripts at this point?

Thanks,

Per

Quote from: perholmes at Jun 19, 2009, 06:33 AM

OK, first of all, this is what the menu looks like on our site:



The menu can do various things that are not shown, such as have disabled items, and items that function as inline category headers. This is controlled by having entering markup into the document fields -- for example to disable a field, you enter %%DISABLED%% in front of its name.

Here’s what the source menu looks like in SoThink DHTML Menu:



This way, you can go nuts and design your menu in a GUI environment. The code rearranges the menu to fit with the MODx tree, and applies the various "commands" entered as markup in document fields.

This is a DHTML/Java menu, which renders a bit slow in IE, but blazing fast in Firefox and Safari. Actually, many things render slow in IE.

Best,

Per

Thx for the graphics. What type of code does SoThink produce? I have checked their site and it looked to me like they were tables?

cheers/k

Quote from: perholmes at Jun 19, 2009, 07:51 AM

Is Revo stable enough, and is the API locked enough, that it would be safe to quickly convert the site to Revo before launching? Obviously, I’d rather be set for the new environment, because then subsequent updates will become much easier. But on the website, you just make a point of advising people not to use Revo in production. I also assume that there are no full-blown converter scripts at this point?

Do as I say, not as I do. I LOVE Revo. It makes building and maintaining sites so much more fluid and it scales like crazy. (The MODx site itself has been running Revo since midway through the Alphas and we’ve been really happy with how it works.)

Today, I would start building a site in Evo most likely. Converting to Revo should be relatively straightforward if you’re not doing a lot of crazy things with internal API calls. What snippets are you using now? If you’re OK with helping convert some snippets and don’t need ManagerManager though I’d dive right into Revo (from SVN ... Quick Update on Elements is so nice). Revo Beta 2 should be out soon with lots of tweaks and fixes over the initial Beta 1 release.

Hi,

No, they first include a javascript file with some functions that are ultra-condensed so you can hardly read them.

Then the code looks like this (short snippet):



SoThink are not eager to reveal what all this means because it would allow people to generate menus without needing to buy their software. But they have said on their website that customers can contact them for an explanation.

But the point is neither to circumvent licenses (it’s really cheap software anyway), nor is it to fully understand what the code means. The goal is simply to be able to extract the code the designer application has generated and rearrange it according to the MODx tree.

Best,

Per