Upgrading to x9.5

I’ve been thinking.

Why not let the current parser run side-by-side with the new Parser? This will make upgrades a breeze!

I’ve notices that if we where going to change the structure of the system to support widgets we would also have to change a few of the variable names inside the parse to keep things in sync.

My suggestion there is that we merge the snippets/chunks/plugins into widgets and add a field to identify Compatibility mode. This means that a snippet that was designed of pre x9.5 will still work without any modifications.

Travis had suggested sometime ago that we add something like a compatibility setting in order to load the compatibility parser.

I’m thinking that if we add a compatibility setting (for pre x9.5) then we don’t have to modify the existing parser at all. What we need to do is code the system as if it’s a new system then when in Compatibility mode we load the old parser:

// inside index.php (front page)
if($cms_compat_mode==1) {
include_once($manager_basepath."includes/document.parser.class.inc.php");
$modx = new DocumentParser;
$etomite = &$modx; // for backward compatibility
}

// here we load our new syntax parser
include_once($manager_basepath."includes/syntax.parser.class.inc.php");
$cms = new SyntaxParser;

New codes will user the $cms parser while old code will use the $modx or $etomite parser

What do you think?

That’s a great idea. As we introduce more and more functionality this will be more and more important. I’ll work on getting this incorporated into the widgets code.

Quote from: aNoble at Nov 23, 2005, 12:28 PM

I’ll work on getting this incorporated into the widgets code.

Sounds great as I’ll be need those updates real soon

I’m working on the parser stuff and will post an update soon.

I love it!

Raymond and I discussed this at length, and I think I got him to agree that we should re-implement support for old parser API calls and behavior via a plugin that is only triggered if a template, document, snippet, or other entity being rendered specifies it needs to run in compatibility mode (add a binary flag to the various components to indicate this as necessary). In this way, the extra bloat of the old API functions and support for the old tags when parsing the content could be left out unless needed by a specific page request containing legacy code or tags.

Plus it shows off our architecture even more.

Did I summarize that alright Raymond? I’m sure he’ll correct me where I’ve taken too much liberty of thought.

Quote from: xwisdom at Nov 23, 2005, 01:20 PM

Sounds great as I’ll be need those updates real soon
I’m working on the parser stuff and will post an update soon.

I’m pretty ecited about getting the widgets working so I’ll probably be spending a lot of time working on it in the next few days.

Quote from: OpenGeek at Nov 23, 2005, 02:23 PM

Did I summarize that alright Raymond?  I’m sure he’ll correct me where I’ve taken too much liberty of thought. 

It’s perfect

Just to note the new Content manager object (not just Parser) will be accessed as follows:

$cms = new ConentManager();

I think we can further extend the debuging capabilities a bit:



e.g.:

You know, I’ve been further thinking, this really presents us with an opportunity to be very cutting edge, but still support "legacy" systems... this is great!

We actually could take it a step farther and possibly decide to support the latest-greatest PHP/MySQL in our new API (PHP 5.1/MySQL 5.0).

We could back-port things into the legacy API as possible, giving them a chance to slowly adapt. This would give the "true" developers who probably have access to a more controlled PHP/MySQL environment the opportunity to take advantage of more modern technologies: SQL triggers/stored procedures, a better OOP model in PHP 5.1, better performance over all, PHP enhancements and bugfixes, and other MySQL improvements.

I still think we cannot ignore at least the up-to-date, security-minded PHP4 user, and there is really no reason to do so in the core itself. We’ve got plenty of OO capabilities that work across PHP4 & 5. So in a sense, we can objectify the API along with the new ContentManager class, without doing any of the PHP 5/MySQL 5 only stuff. If we do it correctly however, there are definitely plenty of places we can abstract out functionality that might benefit from these platform exclusive features and possibly isolate those specific behaviors to a modularized extension, or pluggable widget (i.e. plugin widget of the future, not UI widget for a TV).

Just my view for now; I always change my mind though...

It depends in my opinion on the time frame you think to release this new code.
For a project I’m working on, I decided to go with the Qt4 toolkit, and no longer be compatible with the older version Qt3.
The very reason was that Qt4 offered some features (thread save event posting) which was really hard to code by myself.
Target release date for this application is within a couple of years, by then, every distro will have Qt4 installed ...

So, if you like to release this new code within half a year, I suppose it’s bad to be not compatible with php4...

And the new parser will be amazing fast anyway, no? :-P

Greetz,

Remon