Doctrine-style annotated Entities to abstract away ExtendedGraph

[scaleupcto]

Working on #6 and revisiting the complexity of some of our business logic code that uses ExtendedGraph made me consider whether we could use POPOs as the models annotated specially via comments so Tripod knows how to deal with them.

For example consider:

/**
 * @TripodEntity(collection="CBD_user",type="foaf:Person")
 */
class User 
{
    /** @Property(predicate="foaf:name", cardinality=1) */
    protected $name;

    /** @Property(predicate="foaf:mbox") */
    protected $emailAddresses;

    /** @return string */
    public function getName() { ... }
    public function setName($name) { ... }

    /** @return array */
    public function getEmailAddresses() { ... }
    public function setEmailAddresses(array $emailAddresses) { ... }
}

The entities are self documenting and nearly have all the data required to generate the config.json (aside from database connection details, tlogs etc.)

We could even have entities express viewspecs by referencing each other:

/**
 * @TripodEntity(collection="CBD_user",type="foaf:Person")
 */
class User 
{
    /** @Property(predicate="foaf:knows",entity="User") */
    protected $follows;

    /** @return array of Users*/
    public function getFollows() { ... }
    public function setFollows(array $followingUsers) { ... }
}

Here we might end up with a view spec v_user which joins on foaf:knows.

There could be a simple wrapper around Tripod, like Doctrine's EntityManager, which provides some basic operations for these entities. It would simply wrap ITripod and marshal ExtendedGraph objects in and out of instances of Entities.

This would mean we could abstract the graph operations away from end users totally if they wish.

Thoughts?

[scaleupcto]

Like Doctrine ODB and DBAL, core Tripod and Tripod Entites + Manager might be seperate projects...

[rsinger]

This makes a tremendous amount of sense to me in general. I think nearly every actual use case would prefer defined domain objects rather than interacting with the generic graphs. Presumably the graph is still available if you want it.

That said, I don't know about baking this into Tripod itself. It seems to me to be an independent layer that can be used to augment base-Tripod. Kind of like the distinction between an ORM and PDO.

[rsinger]

Of course, now I see the comment where you say EXACTLY THAT.

[rsinger]

Would the plan be for this to eventually support associations?

[scaleupcto]

Yup, see $user->follows example above

[rsinger]

Would you always need to define the expected type of the property?

[rsinger]

I guess what I'm saying is that it seems like things could go pear shaped quickly if you don't know what to expect for any given property. Kind of like RDF itself, I guess :)

[scaleupcto]

LOL. I guess if it is undefined you just get an array of subjects.

[rsinger]

I guess it would just save them as plain literals then?

[scaleupcto]

good question... a special type of id might see it saved as a uri rather than a literal