MODx 0.9.7 alpha (rev 2218)

Just asking: why not to replace old-style calls to new-style ones during upgrade? Do we expect people would want to downgrade from 0.9.7 to 0.9.5?

For users, that want to manualy migrate their content only - ie make a new install and then import the content, chunks and tvs from 0.9.5 - we could provide a simple scipt which would do the replace.

Well, the idea was to support both to maintain compatibility with existing components, but I think you might have the best solution here. However, I need to make sure this is the only problem, as certain combinations of nested tags may also be causing inconsistent results when the processing does not remove unprocessed tags until the final iteration of the parser. Give me just a little more time to work with it and see if I can work it out and if not, one-time translation may be the better choice.

Quote from: sottwell at Jan 05, 2007, 01:06 AM

Looks like regClientStartupScript doesn’t quite work (that’s why the AjaxSearch isn’t working on sottwell.com).

It’s including the filenames for external javascript files (scriptaculous.js and prototyp.js) but not a bit of dynamically generated javascript code that gets inserted into the document head.

Also isn’t doing regClientCSS.

Cool, I have the parser working much better with mixed tags now, just had to delay some old tag translation (noncacheable snippets and placeholders) until all other tags have been translated to avoid the false matching on [[! and !] or [[+ and +] in some situations.

I’ll take a look at the reg* functions today...

One step at a time Amazing, being able to watch the development of such a nice piece of code from the inside, as it were!

About the new parser, quick question : does it rely on Raymond’s work on the parser, e.g does his documentation apply here or not ?
I gather it has evolved a lot since it does not involve regexp or much less than before but are all previous tags from Raymond’s parser available (I remember there was much debate about conditionnal testing between you two) ?

If not, which are ?
Or, where should I look in document.parser.class.inc.php to get an understanding of how the parser works (and also where do I find the tag list...) ?
Thanks for bearing with me here...

As far as I can tell, document.parser. whatever isn’t even used any more. The core is in the "core" folder, and there are a few scripts that seem to do the parsing. I’m still a little (well, a lot actually) hazy about the exact details, though.

Quote from: davidm at Jan 09, 2007, 03:34 AM

About the new parser, quick question : does it rely on Raymond’s work on the parser, e.g does his documentation apply here or not ?

My question is related but far more general. I’ll try to be as explicit as I can.

How does the change in the core of 0.9.7 influenc the deployment pattern of a new MODx site? How far things have changed compared to 0.9.5 in regards to architecture planning of MODx site? In simpler words, how should I plan to use chunks/snippets/plugins? What to put into them, and what not to put?

Excuse me, if that doesn’t sound clear. After all, English will always be a foreign language for me

You can find all of the api here:

core\xpdo\om\modx095\modx.class.php

and the parser is loacated in

core\xpdo\om\modx095\modparser.class.php

with an extension for backwards compatibility in

core\xpdo\om\modx095\modparser095.class.php

That really is the main directory that makes everything work, there are also files in there for caching, session handling, and db. The mysql folder that is inside of that, contains all of the object mappings to the database and the classes to access the database objects.

Hope that helps, Jason should be able to expand more on all of this if needed.

p.s. Jason, let me know if I spoke incorrectly on anything

Thanks Kyle it helps a lot, off to do some reading