Well, maybe I'm missing something, but to me it seems quite simple:

There is a nodeInterface which holds the stuff relevant to the DOM (so 
tagname & attribute getters and setters and render methods). And then 
there are the interfaces to type/entity/property/collection (which have 
getters and setters for vocabularies, typeof, property and so on). And 
then we have the same concrete classes as right now:

- controller, which implements entityInterface and nodeInterface
- collection, which implements collectionInterface and nodeInterface
- property, which implements propertyInterface and nodeInterface

to simplify things, all three can extend an abstract node class, which 
will automatically give them nodeInterface. And as it is already, stuff 
from the rdf interfaces can be implemented using functions from the node 
interface, i.e.

     function setProperty($name)
     {
         $this->setAttribute('property', $name);
     }

So code-wise, not much would change. I wouldn't do separate 
implementations of the nodeInterface and the rdf interfaces, but I would 
at least leave the possibility open, so that someone can do that in the 
future when the need arises. I'm just proposing to keep them 
conceptually separate, but not implementation-wise.

getChildren and getParent are a bit ambiguous in this situation, because 
a node's children might not be rdf nodes (and not have any of their 
interfaces), and conversely, a node's parent might not be a controller 
(i.e. "entity node"), if there were a "plain HTML" node class.

But this could be easily fixed by having a getProperties method in the 
entity interface and a getEntity method in the property/collection 
interface. This would be cleaner in any case (because right now, a 
property node has a getChildren method, that doesn't make sense in rdf 
context either), and the default implementation could be like it is now 
(e.g. in propertyNode):

     function getEntity()
     {
         return $this->getParent();
     }

This would still not support plain html nodes spliced into the tree, but 
it would be relatively trivial to add support for that later on.

Am 30.07.12 20:04, schrieb David Buchmann:
>> @@ -0,0 +1,111 @@
>> +<?php
>> +
>> +namespace Midgard\CreatePHP\Type;
>> +
>> +/**
>> + * Common base interface for all type definitions
>> + *
>> + * @package Midgard.CreatePHP
>> + */
>> +
>> +interface NodeDefinitionInterface
>
> hm, this is a valid point you make here. but i really don't see how we could handle that without getting even more complicated. before i started with the interfaces, there was just the 3 classes extending node, so everything was mixed together. the interfaces just separate definition and instance and make the inheritance more obvious.
>
> we could have the NodeDefinition contain a type/property/collection instead of having type/property/collection extend the nodedefintion. and the same for concrete instances. but then you would have to ask the node for its rdf element to operate on that. but for the children you would need to have the property/collection know about the node again, otherwise the hierarchy would be lost.
>
> shall i change to code in that way? have the nodedefinition contain a type/propertydefinition/collectiondefinition and render it? then when you ask the node for its children, it could go through its type to give you the node containing that propertydefinition...
>
> i guess the model would indeed be cleaner, but its a hell lot of object models.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/flack/createphp/pull/12/files#r1265694
>