Proposal for Standards & Interface Repository

[Dr Livingston]

Umm...

What I need at the moment, is for example the user is working on one task, and that persists (the state at that given time of the task), so they can then go and do something else, but allow them to share the data of the first task, with the new task, if you see what I mean?

At the end of the day, the UI would manage this via drag & drop for example. For example, an administrator could give a new user their rightfull groups, simply by dragging a group from the 'Manage Groups' task, to the 'Create User' task, and dropping it there.

A very simple example, but I hope you get the point? How that is achieved easily and cleanly behind the UI is what I'm looking into at the moment. Ajax has a part to play in it as well, but that's something else.

Anyways, sorry for going off topic

[Selkirk]

Will checkout that version and base my assumptions from it... I'm tired of having to look up CVS commands

Which is why I linked to the web browsable for datasource.inc.php CVS archive in my last post.

[Selkirk]

For a long while now, I've wanted to create, in some manner or another, a series of interfaces/concrete classes which would be designed well enough (through either dependency injection, or another less un-intrusive technique) to competely unplug from the framework and share with other projects.

Welcome. We share goals. Perhaps we can end up sharing code.

BTW, i think dependency injection is turning out to be the less intrusive technique.

$obj->getAttrContainer()->get('val'); 

Why is that better than this:

$obj->val 

which would you rather see

$area = $obj->getAttrContainer()->get('width') * $obj->getAttrContainer()->get('length');

// or 

$area = $obj->width * $obj->length. 

[Selkirk]

Has anyone ever done a benchmark of this? Code-wise, it's no different to do $string = "value" than $string = new Value("value"). I'm not wedded to the idea, but I can see its usefulness.

I have. Extensively. The speed of property access is the single biggest performance bottleneck in WACT. Thats one reason I'm keen on the __get style. It allows for the $obj->property notation, which is pretty much as fast as it can possibly get, while allowing for alternate implementations with more features when necessary. I refer you to the MyDatabaseConfiguration use case in post #36

In my testing, its not unusual for there to be about 600 calls to __get in a moderately complex example. That doesn't include the cost of setting up the object to support the __get calls. Many properties are set, but never accessed. I'm afraid that value objects will be prohibitively expensive as well as being more verbose to access.

[Selkirk]

I guess this really depends on one thing though. Do we want the Datasource/Container to be able represent data in the database and serve as a crude model, or are we after a fancy array?

Both. The purpose of the DataSource interface is to provide a generic interface for other parties to access the properties of an object.

You might want to check out Key value coding from Objective C. Its the same concept and Apple's WebObjects and EnterpriseObjects frameworks are based on it as well as their GUI MVC implementation. Its a mature and well liked role model for what we are doing here. (Of course KVC has a Objective C flavor and DataSource should have a PHP flavor, hence __get, __set, __isset, and __unset.) KVC is an apt fit because of the similiar, dynamic nature of both PHP and Objective C.

Another thing to reference would be the property portions of the Javabeans specification. I think the things to take away from this are the use cases, the meta data definitions and the concept of keeping the metadata separate from the object itself.

[Travis S]

At the end of the day, the UI would manage this via drag & drop for example. For example, an administrator could give a new user their rightfull groups, simply by dragging a group from the 'Manage Groups' task, to the 'Create User' task, and dropping it there.

A very simple example, but I hope you get the point? How that is achieved easily and cleanly behind the UI is what I'm looking into at the moment. Ajax has a part to play in it as well, but that's something else.

Anyways, sorry for going off topic

Not at all... Just the kind of thing we need to think about. I think code will more easily explain it:

$group = $session->getItem('/path/to/groups/administrators');
$user = $session->getItem('/path/to/users/newAdmin');
$user->setProperty('group', $group->getUUID(), PropertyType::REFERENCE);
// or
$user->setProperty('groups', array($group->getUUID(), etc.), PropertyType::REFERENCE);

// later in the code - possibly a Parameterized Specification
if (!$user->hasProperty('group')) {
   // take default action?
}
elseif ($user->getProperty('group')->getValue() == 'administrators') {
  echo "Welcome home sir...";
} 

Of course, this is implementation specifics at this point. You could store them however you want. You might want to have a Groups workspace and a Users workspace, or a System workspace that contains all of the various admin-only parts of the repository. If you want to cross workspaces, you'll need to have some sort of Unique Universal ID set up so that "123" references only one particular node in the repository, regardless of the current workspace view. You'll notice that's what I stored as the property of the user.

Again... these are all implmentation specifics at this point, but you get the idea.

[Selkirk]

I have one though about the interface of DataSource/DataSpace/Node/ValueObject. The implementations discussed so far, imply a flat collection of properties (like properties of an object). A basic ArrayDataSpace would map theese to keys in an underlying array. What happens when this array is a jagged array - Eg. one of the properties is an array ? Should the DataSpace then return the array, or should it return a new ArrayDataSpace wrapper around it ? Also - how intelligent should such a DataSpace be ? Should it be possible to select with an xpath-like query, into a subnode ? Perhaps we should operate with two interfaces - a base IDataSpace and an extended IHierarichalDataSpace ?

Excellent questions. The issue also comes up with storing an object (possibly even another DataSource) inside of a DataSource.

I think __get should return the object or array. However, it can be useful to have path based access..

For example, using a dot notation:

$obj->getViaPath('obj.prop.array.key'); 

KVC supports this as do the WACT datasource classes.

The setViaPath case is more complicated because of the issue of what to do when an element of the path does not exist. WACT just creates arrays to flesh out the whole path. There are several other complications in the set implementation, however.

It can be useful to know if a path exists, so how about a hasPath()?

There is also the issue of __unseting a path. unsetPath()?

Interface DataSource {
    ...
    public hasPath($path);
    public setViaPath($path, $value);
    public getViaPath($path);
    public unsetViaPath($path)
} 

Path access is incredibly useful. So much so, that I would put this in the DataSource interface itself instead of creating a separate interface. That leaves us with the need for an exception:

class PathAccessNotSupported extends exception {} 

And some meta data:

interface DataSourceInfo {
    ...
    canAccessViaPath();
} 

Note that path access gets more complicated when accessor methods are introduced. Exception raising complicated.

[Travis S]

For example, using a dot notation:

$obj->getViaPath('obj.prop.array.key'); 

Why deviate from XPath? If we do - which I can understand wanting to use other path seperators, I would suggest adding a read-only $pathSeperator to the default interface, which could then be overridden to change the type of seperator used.

There is also the issue of __unseting a path. unsetPath()?

Interface DataSource {
    ...
    public hasPath($path);
    public setViaPath($path, $value);
    public getViaPath($path);
    public unsetViaPath($path)
} 

This seems overly complex. Why not Container->getItem('/path/to/item')->remove()? The above code makes the assumption that paths will always be used. In simplier cases, hierarchy doesn't make sense. Though I do agree with "Path access is incredibly useful." I don't know whether or not it should be forced or not. The idea of JCR was to keep it simple by allowing both path and ID based access (in an ID based system, instead of getItem('/path/to/node') it would be getItemByUUID('123') or getItem('/123')). I wonder if maintaining a path and relationship is not a Decorator of the more basic container of properties.

I think the idea here is to create interfaces that are as simple as possible, then work with way to add the various - and arguably needed - complexity to them.

That leaves us with the need for an exception:

class PathAccessNotSupported extends exception {} 

And some meta data:

interface DataSourceInfo {
    ...
    canAccessViaPath();
} 

Note that path access gets more complicated when accessor methods are introduced. Exception raising complicated.

I've got to chuckle... You left out PathNotFoundException as well. We're getting really close to phpCR again...

Re: DataSourceInfo - wouldn't that be something more likely to happen at the "repository" level? Check out the Repository interface. With that, there's a set number of constants that an Repository can set on their own - or inherit - that outline all the various expected behaviors. You can then check against getDescriptor($key) or getDescriptorKeys() to see if it's supported.

[Selkirk]

Why deviate from XPath? If we do - which I can understand wanting to use other path seperators, I would suggest adding a read-only $pathSeperator to the default interface, which could then be overridden to change the type of seperator used.

I actually looked at supporting XPath for this. The problem is that a Path segment can be either an object or a PHP associative array. XPath is not really suited for the associative array, so I kept the dot notation to specifically distinguish it from XPath. Additionally, the simple dot notation provides 95% of the benefit with 5% of the complexity of XPath.

A configurable pathSeparator would destroy any possibility of interoperability between components. There can be only one.

[illusina]

Hello again,

Been sleeping -- this thread sure moves fast .

 $area = $obj->getAttrContainer()->get('width') * $obj->getAttrContainer()->get('length'); 
  
 // or  
  
 $area = $obj->width * $obj->length. 

I have only one motivation for the first of the two approaches. Simply put, the second approach typically only allows a single data namespace per object. For 90% of object applications, this is fine, however, there are many objects that do require more than one datanamespace, therefore acting within a code convention is required.

 Interface DataSource { 
     ... 
     public hasPath($path); 
     public setViaPath($path, $value); 
     public getViaPath($path); 
     public unsetViaPath($path) 
 } 

I don't see why all of this is necessary -- that functionality can be emulated using a straight set/get routine. If one wanted to extend/decorate the base DataSource class the provide the path-specific queries, shouldn't that be the goal?

 $group = $session->getItem('/path/to/groups/administrators'); 
 $user = $session->getItem('/path/to/users/newAdmin'); 
 $user->setProperty('group', $group->getUUID(), PropertyType::REFERENCE); 
 // or 
 $user->setProperty('groups', array($group->getUUID(), etc.), PropertyType::REFERENCE); 
  
 // later in the code - possibly a Parameterized Specification 
 if (!$user->hasProperty('group')) { 
    // take default action? 
 } 
 elseif ($user->getProperty('group')->getValue() == 'administrators') { 
   echo "Welcome home sir..."; 
 } 

This looks something like the way Mojavi current does sessions. Currently, for sessions, you have User class implementations (a front end) and Session Storage Containers (back end). The entire session is loaded in at framework load, then flushed out at framework end.

 $user->getProperty('group')->getValue() == 'administrators' 

Shall I just assume that someone has created a "String" object? If so, why? Wouldn't the better approach be to have PHP Internals fellows provide type-hinting on basic variables as opposed to moving towards a heavier, java-esque implementation?

Regards,

Tyler Tompkins

[Selkirk]

The above code makes the assumption that paths will always be used. In simplier cases, hierarchy doesn't make sense. Though I do agree with "Path access is incredibly useful." I don't know whether or not it should be forced or not.

I have no problem with offering the four path access methods on a separate interface.

[Selkirk]

Why not Container->getItem('/path/to/item')->remove()?

We have a fundamental difference in perspective here. What is it gonna take to make you come around to my point of view?

Making every property an object is a deal breaker for me and I think it would relegate any standard to obscurity. I strongly feel that its best to "go with the flow" of PHP here and embrace __get, __set, __isset, and __unset and native PHP values.

[Selkirk]

I've got to chuckle... You left out PathNotFoundException as well. We're getting really close to phpCR again...

Nice catch.

[Selkirk]

 $area = $obj->getAttrContainer()->get('width') * $obj->getAttrContainer()->get('length'); 
  
 // or  
  
 $area = $obj->width * $obj->length. 

I have only one motivation for the first of the two approaches. Simply put, the second approach typically only allows a single data namespace per object. For 90% of object applications, this is fine, however, there are many objects that do require more than one datanamespace, therefore acting within a code convention is required.

I'm not exactly sure what you mean, but if an object is exposing two different data interfaces, it seems to me like there should really be two different objects (or even three).

The Template example from earlier in the thread is a good example of this. Many template engines (and WACT too in the early days) put assign on the template. Over time, I found that splitting the Template up into two separate objects, the Template object and a DataSource object vastly improved the flexibility of the design. For trivial simple cases it seems more complex because it introduces a two stage process:

$data->set('var', 'value');
$template->registerDataSource($data);

instead of

$template->assign('var', 'value'); 

Instead, it turned out that the way templates get used in a production application it was no more complicated at all and the flexibility made other things simpler and other things possible that were not possible before.

[Selkirk]

Quick note... All Exceptions should extend from RuntimeException which is being introduced in PHP 5.1. Until then, you can do a check to see if it exists and define it as a straight extends Exception. RuntimeException doesn't add anything to Exception, just helps denote that it happened during the course of excution.

Sigh. BC in PHP is so frustrating. I think that requiring conditional declaration in a standard might not be the best approach. Is there any thing wrong with just sticking with inheriting from Exception until support for 5.0 is dropped.

[illusina]

Selkirk,

The Template example from earlier in the thread is a good example of this. Many template engines (and WACT too in the early days) put assign on the template. Over time, I found that splitting the Template up into two separate objects, the Template object and a DataSource object vastly improved the flexibility of the design. For trivial simple cases it seems more complex because it introduces a two stage process:

I think your approach is better after a bit of examination. The decoupling of the dataspace from the template is certainly more flexible.

[arborint]

Selkirk,


I think your approach is better after a bit of examination. The decoupling of the dataspace from the template is certainly more flexible.

I was looking at what I am currently using an I noticed that my Template inherits DataSpace so you can do either:

$datasource->variable = 'value';
$template->import($datasource);

or

$template->set('variable', 'value'); 

I am just using Template as an example here because we have noted that it is a worst case scenario in PHP. But I do want to note the question of purity vs practice. I think implementing an interface for Template without "$template->set('variable', 'value')" would be to ignore practice for purity. Maybe we want to, maybe we don't.

[Selkirk]

For a long while now, I've wanted to create, in some manner or another, a series of interfaces/concrete classes which would be designed well enough (through either dependency injection, or another less un-intrusive technique) to competely unplug from the framework and share with other projects.

In addition to dependency injection, the other enabling technology is the PEAR channel mechanism. If the process in this thread turned out some suitable interfaces (and even basic implementations), then that code could be hosted on a PEAR Channel. Then if WACT and Mojavi both created a channel, the PEAR installer would work out all the dependencies.

Eventually the PEAR guys are going to catch the DI bug, too.

[illusina]

In addition to dependency injection, the other enabling technology is the PEAR channel mechanism. If the process in this thread turned out some suitable interfaces (and even basic implementations), then that code could be hosted on a PEAR Channel. Then if WACT and Mojavi both created a channel, the PEAR installer would work out all the dependencies.

Eventually the PEAR guys are going to catch the DI bug, too.

I'm curious as to whether going the PEAR route as a distrobution method (I believe that's what you're referring to PEAR as) would be the best route. It has all the facilities in place, but shouldn't this codebase (if you want to call it that) be a seperate entity? Wasn't that within the author of this thread's original intention?

Edit: To expand:

I also feel that this particular project (if it becomes one) has a peculiar merit in that it's not really a "component" repository (as I percieve it), but rather something of a "pieces of components" repository. An example might clarify: Something that might be in PEAR would be a component (such as PEAR::LiveUser). Something like LiveUser is composed of various "pieces", such as a session mechanism, and role tracking mechanism, and so on. Now, while these things are certainly whole within themselves, I would aim to break these down, perhaps, to one more fundamental level (a la Container/DataSpace), then build upon that -- thereby achieving maximum code-reuse and a very malleable codebase. I think the word malleable is the best way I can describe how it seems this codebase should "feel".

Here's what I percieved as being the direction of this post:

* The creation of interfaces to allow design-by-contract.
* The creation of, possibly, some concrete implementations (standard usage implementation) of these interfaces
* Perhaps a DI mechanism (might be part of the codebase?) to lace these pieces together such that any PHP Programmer can almost "shop" through the repository and use various pieces of it.

Thoughts?

Regards,

Tyler Tompkins

[Travis S]

I don't want to gloss over the other points, but I think this list gets at the heart of things...

* The creation of interfaces to allow design-by-contract.
* The creation of, possibly, some concrete implementations (standard usage implementation) of these interfaces
* Perhaps a DI mechanism (might be part of the codebase?) to lace these pieces together such that any PHP Programmer can almost "shop" through the repository and use various pieces of it.

Yes, no, sort of.

Yes - the main goal that I'm after here is a series of contracts that everybody, WACT, Mojavi, SimpleTest, d51GreatestThingEver, etc., etc., can use to build their code off of. There are parts of every codebase that could be reused. By creating a standard set of abstract "pieces", my hope is that developers will start thinking of their code that way. It generally leads to better coding all around.

No - while we will undoubtedly have to use concrete use cases to figure out what interfaces will work the best, I don't see this as another repository of code. It would be great if other projects sprung up along side it to offer implementations for all the interfaces. But if I've said it once, I'll say it again... Even with the exact same API, five different programmers will come up with five different implementations. And, unless lastcraft is one of the programmers, none will be more right than the others...

Sort of - I would like to see a basic DI/CL container interface implemented so Phemto, Pico, and my last bit of code (warning: shameless self plug there) can all be interchangeable. Right now, I'm just playing with the idea, but if in a few week or a few months I want to switch over to Phemto or Pico because it becomes obvious they're being more actively developed, making sure we're implementing the same interfaces makes that possible.

Actually, looking at the Pico codebase is one of the things that really got me thinking about this. Every single class he creates implements an interface and all type hinting is done relying on the interface making it possible to drop your own pieces of code into Pico. A lightbulb went off and I started thinking wouldn't it be cool if we could do this for bigger apps and with wider reach. And now you guys have been subjected to this thread

You are right though... I like the idea of being able to "shop" around for code. Say I get into Mambo and like it at the start. Do up a couple custom modules to display things, but then want to switch to b2evolution. Currently, I'd have to re-write all my custom stuff from Mambo. If they were both implementing a common repository interface though, I could change without too much hassle. Instead of learning new APIs, it would just be a matter of learning new locations for data.

[Travis S]

We have a fundamental difference in perspective here. What is it gonna take to make you come around to my point of view?

Making every property an object is a deal breaker for me and I think it would relegate any standard to obscurity. I strongly feel that its best to "go with the flow" of PHP here and embrace __get, __set, __isset, and __unset and native PHP values.

Ok... PHP 4.4 got in the way or I would have responded earlier

One thing - I'm not a fan of relying exclusively on __get()/__set() (see my original extension of DataSource - something along the lines of MagicalDataSource). I think their use is an implementation decision that's best left up to the implementor. If you code relies on it, then rely on MagicalDataSource.

As for the broader issue of Properties being stored inside containers themself, I'm open for ideas here. phpCR currently allows direct access to a property via the path - I don't know that it's necessarily a bad or a good thing. Given that PHP doesn't have the "everything is an object" type mandate that Java has, maybe we should drop that in favor of Node's keeping track of named values? Referring back to the UML diagram last night, I did ask for comments on whether or not Property was even worthwhile.

I actually looked at supporting XPath for this. The problem is that a Path segment can be either an object or a PHP associative array. XPath is not really suited for the associative array, so I kept the dot notation to specifically distinguish it from XPath. Additionally, the simple dot notation provides 95% of the benefit with 5% of the complexity of XPath.

Hmm... I need to see a sample use case for this. As I see it, if you assign a child to the container (any sort of value) that is not an implementation of Node/DataSource/etc, then it is assumed that it is a dead-end and returned as a straight value (tentatively, a raw PHP variable). As you work through the path, you're working through nodes, or branches of container relationships. Once you get to the end of the road, there's no need to inspect any further into the tree. Unless, of course, it's a child, in which case it is returned by getNode() instead of getProperty() (generally speaking here...).

Where have I gone wrong?

[paulyG]

I don't want to gloss over the other points, but I think this list gets at the heart of things...

Yes, no, sort of.

Yes - the main goal that I'm after here is a series of contracts that everybody, WACT, Mojavi, SimpleTest, d51GreatestThingEver, etc., etc., can use to build their code off of. There are parts of every codebase that could be reused. By creating a standard set of abstract "pieces", my hope is that developers will start thinking of their code that way. It generally leads to better coding all around.

No - while we will undoubtedly have to use concrete use cases to figure out what interfaces will work the best, I don't see this as another repository of code.

Would you mean agreeing and maintaining a kind of Archi-SimpleTest for each "contract"?

[Selkirk]

I'm curious as to whether going the PEAR route as a distrobution method (I believe that's what you're referring to PEAR as) would be the best route.

The pear Channel mechanism allows third parties to publish packages which the PEAR installer can manage. It could for example pull one package from channel.mojavi.org and one package from channel.phpwact.org.

Lets assume that the result of this thread is a datasource.face.php containing interface and exception definitions. There's no reason why we couldn't release just this as an independent package. PEAR Channels provide the distribution mechanism. Check out Greg Beaver's blog for more information on channels. I think he has done some amazing work there.

* The creation of interfaces to allow design-by-contract.

Check.

* The creation of, possibly, some concrete implementations (standard usage implementation) of these interfaces

I think the interfaces and exceptions alone should be an independent package. A few concrete base implementations is cool with me.

* Perhaps a DI mechanism (might be part of the codebase?) to lace these pieces together such that any PHP Programmer can almost "shop" through the repository and use various pieces of it.

The point of DI is that the object is not aware of the repository instantiating it. There is no need to agree on a common DI mechanism as long as we agree to use DI.

I'll add that I can contribute at least a hundred test cases for the __set, __get, setViaPath and getViaPath methods alone.

[jayboots]

Sorry to interrupt you guys but I think I lost the plot of this one. There seems to be a lot of excellent discussion but I think maybe also some neglect of the differences that PHP poses compared to other languages. I tend to agree with Selkirk: there ought be more reliance on __get/__set magic and less obtuse class hierarchy mechanics. I see things being proposed like: hasProperty, getProperty, setProperty, etc. Why do such a thing when hasProperty is the same thing semantically as isset($this->property) and get is just $this->property when using the magic methods? Don't other people think that get*/set* is ugly for property access and unrequired in PHP? If all that ends up happening as a result of the interface standardization is overtly complicated accesses, then I don't think it will have wide appeal.

Another thing: why define all this property definition mechanics as class interfaces? Considering that PHP is not a compiled language, wouldn't we be better off using configuration files for that sort of thing so that dynamic objects become what their configuration file dictates? Once the object is active, we shouldn't really need those mechanics and if we do, I think they should be part of a factory rather than the object itself. In other words, why is all this abstraction being surfaced to the in-use objects?

Perhaps I have it wrong, though: there is a difference between class hierarchies and dynamic objects. I tend to prefer the latter for building applications and the former for building toolsets. The whole reason I like the __get/__set (and other magic interfaces) is that they foster very cool dynamics objects like DI containers and JS-like proto-typable objects, etc. They also help bridge the static class hierarchies and dynamic object realms. I was surprised how simple it was to build a container that had all of its access proxied to other standard objects so that behaviours could be added, compounded or removed at will and further, could have behaviours added from anonymous sources down to the method level or even magic method level. What impresses me about that is the flexibility and fluidity and how much of the details can be hidden from users accessing the objects.

So I guess I'm asking: is there any chance that there are like minded folks? I'm not keen on watching the JSR's being reimplemented in PHP though more power to you if that is your inclination. OTOH, I am interested in working with others who are looking to leverage PHP's dynamic features. I have some designs and I know others do as well (it appears a few in this thread have at least some common issues) -- I just get the feeling that it would be inappropriate to post them to this thread at this point.

Feel free to straighten me out if I'm a backasswards here. Again, I don't mean to rain on the picnic or hamper progress. I just think I might have different goals and if so, I might as well look for different pastures -- or go back to living in my happy little bubble world.

Greetings.

(of course, by the time I post this, no doubt 10 messages will have already been posted on this thread addressing my points much better than I ever could...)

[illusina]

jayboots,

You know, I appreciate that post. Really, I do. I feel like I've just been given a little jolt with being told that I'm writing in PHP, and not in a compiled language. Leveraging the features of PHP should be a major priority, as well as designing this thing to best of our capabilities. Dynamic objects are certainly a better route than the route I was going to have taken. I feel like I just woke up from a long sleep...

Anyways, I'd like to see if I can get Selkirk, Travis S, and whoever else on IRC to chat about this stuff, because the latency here sometimes bothers me . Having something concrete to work towards is definately a goal of mine. I do not want this thread to die like the many other very useful sitepoint threads.

Regards,

Tyler Tompkins