alter existing handlers (handler overrides)

I want to build a module (some modules), that will implement features, that views don't want to implement by design. For example regexp/php field value rewriting. There are some modules doing things like this (views_customfield), but as i wrote before, i think a better concept (on how to extend views functionality in general) would be not to have to change the type of the field every time to a new one, but only to enable the module implementing it. I'm talking about an existing view of course. I as a user would expect views and modules extending it to be working like this.

What about multiple interface inheritance?

@dereine: If i change the path to the handler using hook_views_handlers_alter, the original handler is not loaded, so i cannot inherit from it, am i right? So i have to copy the original handler and add my code to it. Is this what we want?

Or if files from both paths are loaded, i can inherit from it, but the problem with the cascade of inherited handlers still remains, cos other handlers still inheriting from the original handler.

What's changed in d7? :)

@dereine: the hook_views_handlers_alter + copying the handler seems to be quite less work and in advance it not only apply for views original handlers but other modules' handlers too :)

@merlinofchaos: what's your opinion?

Of course this is oop, but with copying i mean exactly copying the handler's file somewhere in your module and adding lines of code to that file.

Cos other handlers are inheriting from the original handler, i'm talking about disabling the loading of the original handler's file and loading my file with the handler extended but with same name (because of the other handlers that inherit from it to work).

As i understand your hook_views_handlers_alter (if it exists) solution right.

It's not fixed i still want to read merlinofchaos's opinion :)

Ok that multiple interface inheritance was bullshit.

What do you think about using mixins in views handlers? Is that possible?

Forgive me for my lack of education in oop and design patterns, i have never studied informatics at university, therefore i'm trying to educate myself this way too. :)

I know that there is no multiple inheritance in php, but there is a way to "simulate" this mixins. You can take a look at this article ("Mixin" section) if you have time and interest. That's what i'm talking about. I think design like this one can be useful in this case. Maybe.

The point is, i'm trying to find a way how to modify a handler with not having to register a new one.

Imagine the situation like this. Views with their cascade of fields handlers, each handler registered under it's name. If you want to use a handler that has a different functionality, you have to add a new field (in the ui). That makes sence in views core because in fact you're (as a user) not actually thinking in handlers, you not want a new handler (a new functionality) but a new field. One field has it's one handler, that knows how to deal with it, one "description" how it may function.

Ok, now other modules are registering default views, for example (the example i'm trying to improve) table wizard is generating a view for the migrate module for the purpose of data migrations. This view is using one of the handlers from the views core handlers, of course because authors of the module want that basic functionality the handler is offering.

Now here comes the user. He sets up the view in the table wizard and realizes that he needs to alter the view's fields (set by the table wizard) somehow differently that views itself is offering to him. He needs the php altering for example. He installs the views_customfield module hoping when he installs it, that his fields in his view would have this new php-rewrite-field functionality. But it's not like that. He has to change the handler for every field in his view. In views ui there's no ability to change the handler.

So now the situation with the handlers is different than in views core. The user wants one field "with two descriptions how to function". I'm talking about a situation with three elements of code reusing. Views is offering some functionality, a module is implementing it and another module wants to speak to it.

And this is achivable with hook_views_data_alter?

Or maybe the situation only needs a mechanism how to change the handler used in a view by this views_customfield after it is set by the table wizard.

This here is a module for testing purposes (yet), with one handler, which is a copy of a handler from views_customfield module. The module rewrites a chosen handler registered in views data and all handlers, which are inherited from it with it's own handlers. Then it dynamically generates and loads the code for handlers corresponding classes. So the functionality provided in the used views_customfield handler (a php rewrite textarea) is available in every views field.

This goes beyond horizontal reuse, which was discussed before, because it extends handlers not provided only by views core, but by other modules too. So one can have multiple modules aware of themselves, extending their features in a line ordered by modules weights.

The module needs a new hook for loading the code right before the new handler's instantiation. I think there is some work needed for rewriting default views registered by modules. Maybe a big part of the code should be in views core not in the module itself. This is just a sketch. So tell me what do you think about this.

against 6.x-3.x

any feedback please

I've red your article before. As dereine mentioned here few comments back, using these "mixins" will make the code more complicated (to follow). Depends on the implementation, but at least you have to (or the developer of the new handler) register methods, etc. I mainly agree with him.

Can you please give a link to these "extenders", where this was mentioned, i wasn't able to google anything.
I don't think these traits will resolve this, cos they are not dynamic. You have to write explicitly in the code, which traits you're using. Anyway we cannot wait till php 5.4 is released and gets adoption. Could be years. :)

From the point of "code clearness" of the handler class i think using of eval() is ok. If we can put the generating mechanism inside views; all the class/parents names generation, loading the "code template", modifying it and evil eval() itself too; and if we can build a good interface for it (maybe it doesn't need a new hook at all)... Well i don't know nothing about performance of it now, that's true. Can you please explain more in detail why eval() is not good here?

Extenders, now i know what you're talking about, wrong search sorry. How i see it, that's again a kind of dirty __call magic + wrapper staff. Talking about performance it's using call_user_func_array. Using eval we can at least avoid the extender class here (SelectQueryExtender in the case of database extenders).

Another concept. I moved a lot of the code into views itself. The interface got more simpler, we don't need a new hook here. So the "views_fieldrewrite" module is now small and clean. I get rid of evil eval(). Instead of that, there is a "file cache". The central idea of this is, that files containing classes that "decorates" normal handlers are being generated and saved within the files folder. It's ok in this case, cos the "handlers schema" is changing only when introducing new handlers, so we don't need to rebuild those files on every page load. The slow part, the generation of files is done after clear cache/install module and then there are only classes relying on inheritance, directly expanding original handlers, no call magic, no wrappers. This is also ready for the memcache too.

I would like to ask a question on memcache. What is more effective in terms of performance with memcache, to have many small files or one big?

I've tried to put ale the code outside of Views, tried to make it more generic and here is what comes from it.

• Decorator module is where all those file generating, caching takes place.
• Views Decorator module deals with hook_views_handlers() and hook_views_data_alter() to determine the handlers that are going to be generated, uses Decorator for generating them and sends them back to Views.
• Views Field Rewrite module implements a hook_views_decorators() for registering these "decorators" template handlers in Views Decorator.