Event Model and Parser Overhaul

I love OOP

Seriously, if modx uses OOP, then a seperate class (being included or not) for the parser really makes sense.

And if it needs to include the parser file, don’t be worried about that 0.00001 second of overhead it involves ;-)
(If there is really any overhead at all. Most people have a php accelerator installed, so it in fact not even parses the included class, but uses the bytecode in the accelerators cache.
At least, that’s what they told me)

Oh, and I couldn’t measure any difference being it in file or included

If there is basically a non-measurable penalty in performance, let’s keep it separated. If we have a good caching system in place, our parser will be used much less than currently!

On my local PC it did make a difference when compared to eto’s embedded parser.

I’ll make it into an object ($cms->parser) based on Remons tag.parser class but it will be integrated. if we need to then we can separate it later without the user knowing anything.

Ah, ok. It seems we compared different files ;-)

The point why I liked to have it into a seperate class file was that member variables are split, which can be hard to accomplish when it’s integrated, making seperation later on a little harder.

Main point for me to split this code, was having a minimal base only for serving a page, and loading functionality on demand.
Having only a minimal parser loaded verser a minimal one with the tagparser integrated possibly doesn’t yield much in respect to performance, but the process will use less memory.
That was the idea behind splitting it into these classes....

Ok,

Sounds great! I’ve have a look at it. Also have a look at what I’ve done with content.manager.class.php