Add RouteInspector Routine Interface.

Allow implementations to inspect all routes as well as current active route, allMethods, uri etc. just before passing control over to Request.
This is read only functionality as the routes have already been processed and changing won't have any effect.
This will help to be able to build menu's etc based on the configured Route abject.
Add RouteInspector Routine Interface.

Allow implementations to inspect all routes as well as current active route, allMethods, uri etc. just before passing control over to Request.
This is read only functionality as the routes have already been processed and changing won't have any effect.
This will help to be able to build menu's etc based on the configured Route abject.
Removed Proxyable through implpmentation.

Contractuol through method has only a stub implementation so it isn't complete or for whatever reason this is not being used. Removed as it only causes confusion.
All tests stil pass.
Routines refactored.

Introduced two new abstact classes:
   AbstractCallbackList: as apposed to AbstractRoutine which takes a single callback in constructor AbstractCallbackList receives a keyed array of callbacks in the constructor and exposes them.
   AbstractCallbackMediator: Extends AbstractCallbackList and facilitates the choosing of an appropriate callback from the list. It mediates a "when" request authorzation by requiring 4 methods implemented by sub classes to perform the authorization these are:
           identifyRequested: Returns an array, empty or with a list of requested values
           considerProvisions: For each of the requested values the subclass my consider a list of possible provisions based on the requested entry.
           authorize: (not absract - can be overwritten) gets called for each of the provided values to compare if requested can be authorized based on provided (previausly called compareItems)
           notifyApproved: if authorized this method allows the subclasses to react on an approved state
           notifyDeclined: alternatively if authorization was declined allows subclasses to react on the new state (ie. set error headers etc.)

Refactored AbstractAccept to extend AbstractAccept class to extend AbstractCallbackMediator which reduced the complexity of the implementation considerably.
The Accept subclasses were reduced to only the functionality the specificly differ with, this boils down to the way the compare requested and provided in the authorize implementation because these vaalues may differ.
ContentType now does not have to extend AbstractAccept as it did before which was wrong in so many ways, it now extends AbstractCallbackMediator. This slightly increased the amount of code needed as it now cannot rely on Abstract accept anymore but these merely boils down to the new contractual methods that needs to be implemented and the change is not considerable but it is much more structured modular and understandable.
UserAgent also eroneously extended AbstractAccept and can now enjoy the functionality provided by the Callback Mediator without the overhead of the content negatiation.

Some additonal tests were added to test user agent and although more tests are required everything that we had works 100%
AbstractRouteInspector convenienence class.

It's cantractual requirements are the implementation of a routeInfoResponse method which gets called after a nested closure implementation of the through method and includes itself as the Countable, Iterator, Serializable, ArrayAccess delegator to a newly construcned routeInfo set containing the usable routeinformation grouped by route pattern includes all methods, all routines and after the rofactor has easy access to the getKeys (callback keys) whirh these sub-class routines provide. It also creates a dynamic object as url template with extensive magical powers to parseUrl (for now) which will return the actual keyed collection of values in the url.

Outstanding:
More tests still required
extra functionality needed exposed via the Routinable interface to obtain inspection information from routines.
The same might be beneficial for Routables.
It would be beneficial if developers could get information into the inspector from the route implementation for dynamic documontation purposes.
merge head conflicts
That shouldn't be there.
Add RouteInspector Routine Interface.

Allow implementations to inspect all routes as well as current active route, allMethods, uri etc. just before passing control over to Request.
This is read only functionality as the routes have already been processed and changing won't have any effect.
This will help to be able to build menu's etc based on the configured Route abject.
Removed Proxyable through implpmentation.

Contractuol through method has only a stub implementation so it isn't complete or for whatever reason this is not being used. Removed as it only causes confusion.
All tests stil pass.
Routines refactored.

Introduced two new abstact classes:
   AbstractCallbackList: as apposed to AbstractRoutine which takes a single callback in constructor AbstractCallbackList receives a keyed array of callbacks in the constructor and exposes them.
   AbstractCallbackMediator: Extends AbstractCallbackList and facilitates the choosing of an appropriate callback from the list. It mediates a "when" request authorzation by requiring 4 methods implemented by sub classes to perform the authorization these are:
           identifyRequested: Returns an array, empty or with a list of requested values
           considerProvisions: For each of the requested values the subclass my consider a list of possible provisions based on the requested entry.
           authorize: (not absract - can be overwritten) gets called for each of the provided values to compare if requested can be authorized based on provided (previausly called compareItems)
           notifyApproved: if authorized this method allows the subclasses to react on an approved state
           notifyDeclined: alternatively if authorization was declined allows subclasses to react on the new state (ie. set error headers etc.)

Refactored AbstractAccept to extend AbstractAccept class to extend AbstractCallbackMediator which reduced the complexity of the implementation considerably.
The Accept subclasses were reduced to only the functionality the specificly differ with, this boils down to the way the compare requested and provided in the authorize implementation because these vaalues may differ.
ContentType now does not have to extend AbstractAccept as it did before which was wrong in so many ways, it now extends AbstractCallbackMediator. This slightly increased the amount of code needed as it now cannot rely on Abstract accept anymore but these merely boils down to the new contractual methods that needs to be implemented and the change is not considerable but it is much more structured modular and understandable.
UserAgent also eroneously extended AbstractAccept and can now enjoy the functionality provided by the Callback Mediator without the overhead of the content negatiation.

Some additonal tests were added to test user agent and although more tests are required everything that we had works 100%
AbstractRouteInspector convenienence class.

It's cantractual requirements are the implementation of a routeInfoResponse method which gets called after a nested closure implementation of the through method and includes itself as the Countable, Iterator, Serializable, ArrayAccess delegator to a newly construcned routeInfo set containing the usable routeinformation grouped by route pattern includes all methods, all routines and after the rofactor has easy access to the getKeys (callback keys) whirh these sub-class routines provide. It also creates a dynamic object as url template with extensive magical powers to parseUrl (for now) which will return the actual keyed collection of values in the url.

Outstanding:
More tests still required
extra functionality needed exposed via the Routinable interface to obtain inspection information from routines.
The same might be beneficial for Routables.
It would be beneficial if developers could get information into the inspector from the route implementation for dynamic documontation purposes.
Suedo private inner class.
Even though this cancept is foroign to PHP lets not confuse the unit tests to force this unnaturally. Private class now private.
Just to prove the point see:

User Agent now works without all the hack code to just make it pass tests. No problems no fuss, less code = happy pandas.
merge with remote
Merge branch 'develop' into route-inspector
On second thought: lets not use autoloader.

We already know we can do PSR-0 well, there's no question about that.
Now if we care about composer then lets not give control over to it, instead lets munge their collections and just include the classes on hte vendor path ourselves. While we're at it no use in leaving the include path in an unoptimized state, pandas don't like a mess.

The new PSR-0, PEAR and Composer capable bootstrap. If you don't want it in test place it in any folder off root and the absolute paths will still resolve.
Njoy. =)
Remove RouteInspector implementation.
Merge refactored changes from route-inspector branch.

Everything but route-inspector for now. We have some other plans for that.
This does include the introduction of AbstractCallbackList and it's partner in crime AbstractCallbackMediator which resulted in a more abstracted implementation of the keyed array callback already utilized by all the Accepts, ContentType and UserAgent implementations.