Skip to content
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.

Alternative Description architecture #25

Open
dantleech opened this issue Jun 5, 2016 · 0 comments
Open

Alternative Description architecture #25

dantleech opened this issue Jun 5, 2016 · 0 comments

Comments

@dantleech
Copy link
Member

dantleech commented Jun 5, 2016

We could use objects for the Descriptors and access them by their class name:

$description->addDescriptor(new HtmlLinksDiscriptor([
    HtmlLinksDescriptor::EDIT => '/path/to/edit/1',
    HtmlLinksDescriptor::REMOVE => '/path/to/remove/1',
    // ...
]);

$description->addDescriptor(new ChildClassesDescriptor([
     FooClass::class,
     BarClass::class
]);


$linkUrl = $description->getDescriptor(HtmlLinksDescriptor::class)->getEditUrl();

if ($description->hasDescriptor(ChildClassesDescriptor::class)) {
    $childClasses = $description->getDescriptor(ChildClassesDescriptor::class)->getChildClasses();
}

It can then be assumed that if the client is requesting the descriptor by class name, that they know what to do with it (i.e. it can have its own public API).

Unfortunately this is very verbose in Twig:

<h1>Hello</h1>
<a href="{{ description.hasDescriptor('Name\Space\Descriptor\HtmlLinksDescriptor') ? description.descriptor('Name\Space\Descriptor\HtmlLinksDescriptor').editLink }}">Edit</a>

This approach solves the current ambiguity problem posed by having a simple key/value store, but increases the verbosity, especially in Twig and when consumed through the REST service.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant