Allow type definitions to be extended on type hooks.

[lucasconstantino]

For the time beeing, by defining an extension.type hook you are not able to change the settings of the types previously defined in other extensions, as you can only access them in there already processed formats. By allowing the settings of the types to be extended we would not only make the type hook behave like expected (other hooks work this way) but also highly increase the possibility in regards of extending previously declared types.

A common use of this feature would be to add custom fields to already existing types.

[recidive]

I have only one concern by inspecting your changes visually. It looks like it will not pass processed items to collect hooks, that was my initial idea, but may make better sense how you did it.

Have you run Prana tests? Did they all pass?

[lucasconstantino]

I'm not really used to test-driven using mocha, so I just executed mocha on prana's root and it accused 6 successes. Hope this means it's all fine :)

I think we should start planing pre/post sub-hooks on most of the already available hooks. That would probably solve most of the cases.

I gave a thought to it and came with an idea of syntax that might interest you: as function objects can hold properties (and so can common objects), I think we should use hook function properties to define sub-hooks.

/**
 * The type() hook.
 */
extension.type = function (types, next) { ... }

/**
 * The type.alter() hook.
 */
extension.type.alter = function (types, next) { .. }

Of course we would then have to expect the main hook (type) to be either a function or a plain object, but that can be easily handled.

What do you think about it?

[recidive]

We already have post/pre hooks for CRUD operations. Last week I added pre/post callbacks to field types.

I'm not sure I like your syntax, since it requires you to declare the main hook (either as a function or simple object) to be able to declare the alter hooks afterwards.

That was exactly why I wanted to pass the processed items to the collect hooks, since that way you can rely on the dependency chain to make sure the stuff you want to alter is available, that's actually an alternative to alter() hooks and make them unnecessary.

But that can be changed if it makes it will more straightforward. We could add in [typeName]PreProcess() and [typeName]PostProcess() hooks called before and after processing items of all types not only items of type "type".

[recidive]

Fixed in #2. We can now alter type settings direct on the type() hook before they get processed.