Core Extensions

Hi,

Based on the separation work that Remon has done with the Tattoo() parser I would like to present the following extensions to the $cms obect:

$cms->db // database API object
$cms->parser // parser API object
$cms->document // document API object (current document)
$cms->event // event API object
$cms->user // user API object (current user)
$cms->cache // cache API object

Each extension can be loaded using the $cms->loadExtension() funtion

The above is by no means limited. We can add others as time rolls on.

Exciting; this is exactly what I wanted the Etomite API to look like when I discovered it. I think you’re reading my mind Raymond.

Quote from: OpenGeek at Nov 25, 2005, 05:25 AM

Exciting; this is exactly what I wanted the Etomite API to look like when I discovered it.  I think you’re reading my mind Raymond. 

Sounds great Jason

Question, do you think we should add the invoke methods to the $cms object or to the $cms->event object?

example:

or

What about this:



Don’t know if php has const references, but $cms->eventObject() would then look like:



I still have to figure out how references work in php. The const thing is to avoid deletion, modification, other of the event Object, not sure if it’s possible like this...
Could be usefull too, to make public and private functions, to seperate internal functions from the public API ;-)

Remon

Hi Remon,

Sounds great!

The $cms->loadExtension() function is design to handle multiple calls. This means that if the object already exist then it will not be recreated:

// loads the event once


We could also do something like:

I wonder if a developer should worry about loading extensions at all.
Thats why I liked the way it is done in my previous post.
A developer only has to call the getObject function, and doesn’t have to bother about which extension to load, in fact, he even doesn’t know it’s an extension after all.

By using a getter function, and making the objects a private instance of the cms class, we avoid possible issues with modifying the object or something similar....

What do you think about this?

Remon

I lean towards not having to load things, but then again, I’m coming at it from the perspective of a non-coder, but advanced-user, perspective.

I think if we allow loading of the core ContentManager class implementation to be defined, we can let that specific implementation worry about loading whatever extensions it wants. But dynamically loading extensions might be useful in some cases, especially to allow user-defined extensions to the API.

And yes, we need to structure the classes in more traditional patterns, including the use of getXXX() methods for public access vars, setXXX() methods for mutable (i.e. changeable) public access vars, but we can’t use the language to make things public or private without sacrificing PHP 4 compatability. I think we should move incrementally to that point where PHP 5 is required when PHP 4 is no longer widely used, or possibly maintain a legacy branch for PHP 4 people while we use the latest and greatest language features of PHP 5.

I’m hoping database compatability can be completely abstracted from the equation; imagine everything is an object that extends the base persistence class and implements it’s own unique behaviors on top of this. Then the relational persistence is all handled by the DB layer while all you do is create new instances of objects and call the appropriate method to get or set the data you want. Makes me weepy... :’( or is that geeky?

You’re just a huge dork hiding behind a stick-slinging-skin-beating-long-haired-wearing rock star persona.

:P

Hmmmm,

The goal is to try and make it simple but powerful. Having both options loadExtension() and getExtension() will allow the developer to choose which method to use.

I don’t think we should use extension special method names (e.g. getEventObject()) and these would have to be hardcoded into the core.