Decorator API

[augustohp]

The first decorator API sucked, this second tend to suck less but still there is something bothering me into the Traversable decorator, but lets go to considerations: @alganet what you think of this idea at all?

PS: I know this is slow, but it keeps things simple. This was the most simple way to implement them I came up with ...

Some things this API should be able to do, and are not coded yet:

• Use child elements from a node as template elements
• Support (later on) ways of inserting custom behaviours (plugins)

[alganet]

We have essentially 3 kinds of data to put into templates (coudn't think of any other):

• Dictionaries (key/value data) that may come up in form of an object with public attributes or an associative array and be represented in
• Vectors or lists, as numerical arrays
• Other scalars (text, numbers, objects implementing __toString)

We can't predict how the data will behave before checking out the destination element. For example, a custom Date object could have three properties (for day, month and year) that will lead to three SELECT elements on the template if fed to a specific fieldset. But the same object, implementing __toString could be fed to an SPAN tag and lead to the string representation of that tag.

Summing up: I don't know!

[augustohp]

• Dictionaries sounds good to me
• Vectors (to me) are just containers for multiple elements. For instance, an array with key=>value used in a is interpreted as a Dictionary and not a Vector (Traversable). The intention is to used Traversable just to recursive iterate and decorate elements in the tree
  Scalars are Strings, is a big deal to just ask developers to manually convert objects to strings and so on before sending them to template? Transforming data sent between back and front just doesn't sound good to me
  alganet commented 12 years ago

  I agree. We have a PHP-side starting point, now we need to list all HTML tags and cross them to decide each behavior. Maybe create a class for each combination, such as Respect\Html\Injectors\Dictionary\Ul and Respect\Html\Injectors\Scalar\Acronym. By the way, I also believe "Injector" is a better name than "Decorator" for this class purpose.

  We may have a "Struct" type as well. An html A tag need the TITLE and HREF attributes, and they would probably be injected using an array-like structure.

  augustohp commented 12 years ago

  We don't need to create a class for each possible combination, we can narrow it down to just a few, we will generalize and then specialize each thing as we need ...

  The Struct is something I thought as Adapters from Backend data to HTML data and I'm already implementing them as I saw it as the next "big" step ... And I need some example where Dictionaries are needed, because for me, they enter on the Adapter use case.

  Injector is a better name from a user point of view, it may make more sense but it depends on the point of view. If you think of Design Patterns, Decorator makes much more sense than Injector as Adapter makes more sense then Structure. But it can make more sense in my troubled head also, who knows. If you really believe Injector is a better name, I also agree with you already .. =P

  • © Githubissues.
  • Githubissues is a development platform for aggregating issues.

[alganet]

I agree. We have a PHP-side starting point, now we need to list all HTML tags and cross them to decide each behavior. Maybe create a class for each combination, such as Respect\Html\Injectors\Dictionary\Ul and Respect\Html\Injectors\Scalar\Acronym. By the way, I also believe "Injector" is a better name than "Decorator" for this class purpose.

We may have a "Struct" type as well. An html A tag need the TITLE and HREF attributes, and they would probably be injected using an array-like structure.

[augustohp]

We don't need to create a class for each possible combination, we can narrow it down to just a few, we will generalize and then specialize each thing as we need ...

The Struct is something I thought as Adapters from Backend data to HTML data and I'm already implementing them as I saw it as the next "big" step ... And I need some example where Dictionaries are needed, because for me, they enter on the Adapter use case.

Injector is a better name from a user point of view, it may make more sense but it depends on the point of view. If you think of Design Patterns, Decorator makes much more sense than Injector as Adapter makes more sense then Structure. But it can make more sense in my troubled head also, who knows. If you really believe Injector is a better name, I also agree with you already .. =P