By alex2005 on

I have developed some Drupal sites
and I realized what the worst thing in Drupal is
that it is impossible to override modules functionality without modifying module source code.

For example, I need use my own taxonomy engine (not stored in Drupal database),
but I want themes and all modules work with it like with standard drupal taxonomy.

I would like to code some functions like
taxonomy_get_childen, taxonomy_get_parents etc.
and have my custom taxonmy ready to use.

But now I should modify taxonomy.module and will have major problems with upgrades.

I've been developing large projects in C++ and I think the following structure will be perfect for drupal:

- each module creates its object with member functions, only those functions can be used by other modules;

- functions like module_invoke_all use not modules list, but list of objects created by modules;

- if you want to override module functionality, you define your class inherited from the module class, and overrive functions you need.

What do you think?

Comments

Steven’s picture

Steven commented

This would probably slow down the module system, as every hook will be called for every module, whether or not it implements it. Also, right now we sometimes attach meaning when a module implements a certain function. This becomes impossible with an OO model, which means that we'd have to add more calls to replace this.

And finally, I don't really see how your inheritance scheme would help you override e.g. taxonomy.module, as those functions you mention are not hooks in the first place, but API functions. Drupal would still need to know somehow to call your module rather than the default functions.

As far as upgrade problems go, even if we had such an OO system like you described, there would be no guarantee that your custom module, based on the old module, would still work with the code that expects the new APIs. It would be safer and easier to keep a patch with your custom changes, and re-apply it with every update.

--
If you have a problem, please search before posting a question.

alex2005’s picture

alex2005 commented

Sorry, it seems like you didn't understand me right.
There will be no slowdown. Drupal hook system is really a simple implementation of virtual functions mechanism. All problems I listed are solved in OO programming, so why not use it ?

To implement what I propose, Drupal should use objects list instead of modules list. Each object is created by its module and provides its API.
When Drupal loads a module that creates object, it adds it to the objects list. Alter all modules loaded, modules and API functions will be accessible like that:

Drupal->Modules->Taxonomy
Drupal->Modules->Taxonomy->GetChildrens($tid)
Drupal->Modules->User->Help()
...

If you want to override API function for example for taxonomy module,
you create new source file (say, taxonomy_custom.module), declare derived class there and code virtual functions you want to override.
Even internal module functions will use overloaded versions.
Drupal should load not taxonomy.module, but taxonomy_custom.module that will create Taxonomy object.
There should be slightly more complex module load mechanism.

If module API functions are realised as virtual functions, you could override them in your derived classes and have no problems with upgrades until API is changed (it won't change with every drupal version). You just replace original module and everything keeps working!
Also, it is very easy to implement API versions control.

I think Drupal has to use all OO functionality provided by PHP5.
If Drupal will not, someone else will do it.

inteja’s picture

inteja commented

I think Drupal has to use all OO functionality provided by PHP5.
If Drupal will not, someone else will do it.

Many other similar projects are on this OO track (eZpublish, Xaraya, Xoops etc), all of which I've tried and rejected. Drupal is clean, compact, fast and its structure is easy to understand for those wishing to extend and theme it. Drupal's development philosophy is what attracted me to it in the first place ...

Brian.

--
Brian.

tag-1’s picture

tag-1 commented

...easy to understand for those wishing to extend...

I think this point is a bit debatable. Docs have certainly improved over time, but an example where the non-OO structure falls short is extending modules, assuming I understand it correctly (and it's very possible I'm totally wrong).

My understanding is that say I want to extend flickr.module, adding a function or two, or modifying some functions. Are my choices not either:

A) modify the source of that module directly, making upgrading it difficult

B) dupe the module source, search/replace the name everywere to 'Flickrx' or whatever, and add my new or modified functions?

This is where OO would be really nice, being able to just do (quasi code):

FlickrX extends Flickr:
   function blah() {
      myNewFeature();
      super.blah()
   }

rather than options A or B above. Is there someway to do this I'm missing?

alex2005’s picture

alex2005 commented

Yes, I need exactly the same you talk about.

torne’s picture

torne commented

I use Drupal cvs on my site, and have many small custom changes to various core modules..etc. I've not had any problems with modifying modules directly, because I use the Quilt patch management system to manage my changes. Each discrete change goes into a seperate patch which can be automatically applied in sequence. When I want to update from Drupal CVS, I just pop all patches off, update, then push them all back on again. Since everything is built out of small patches that make just one functional change each, I can easily update them when one fails to apply to the latest version of a file; also, if something I've done seems like it'd be useful to others, I can send that one patch file to the issue tracker here trivially ;)

The only problem is when the file underneath changes too much for the patch to trivially apply; but the same change to a base class in an OO system would likely need the derived class to be updated anyway.. so far there has been only one time where I needed to do more than increase the fuzz factor by one on the patch application, and the changes there took me less than ten minutes.

Quilt is very useful for developing a set of local changes to a standard codebase; try it ;)

tag-1’s picture

tag-1 commented

This request/question comes up every so often. I came to Drupal and thought the same, but quickly realized full-OO for Drupal is not really thought highly of by some of the main devs, and anyway would be a huge amount of rewriting in core. Just letting you know what to expect here...

javanaut’s picture

javanaut commented

One of the things I've been considering is a mechanism for specifying the order in which hooks are applied. For instance, the mailhandler module iterates through all modules that implement the mailhandler hook until one of them modifies the arguments. Further modules in the list are ignored. I realize that this wouldn't be an end-all solution nor would it compare to inheritance (not that php4 does much of that very well), but you may find that changing the order in which module hooks are invoked could solve many logistical problems.

Additionally, it would be nice if you could "disable" a particular hook from running. If, say, a module implements a hook that you wanted to override, you could just implement it in your module and disable it from the other module. Cheap-hack workaround. It would only involve a little modification to node_list() I think. It would be a manual way of overriding a module's hook.

None of this would help your taxonomy problem, though, as it doesn't use module hooks (as Steven pointed out).

carlmcdade’s picture

carlmcdade commented

I have done two classes. It does work to a certain extent. One problem I keep havng is that the objects keep replicating themselves.

The other is that they become too tied into the structure of Drupal so any changes there create errors.

I have just been sitting here today thinking of a way to do exactly what you are describing (I do my best code thinking while in Photoshop). I had thought of implementing a "god" class or octopus of sorts. But then I got stuck because I don't know enough about design patterns. I would like to use a factory but this stupid object replication makes me think singleton , which whould be very hard to do with Drupal.

I need more books ;)
---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia

alex2005’s picture

alex2005 commented

I reviewed some modules and found out that all functionality is strictly based on DB structure and API functions called by its names.
There is no way to change taxonomy behaviour without modifiing its source code.
If I create its copy with different name, other modules will still call taxonomy_... functions.

So, the only solution for me is to make changes in standard modules and never upgrade them (and probably also Drupal core) :(((

It is the same problem I faced in other CMSes - I need more custom functionality for my sites than standard modules can provide, and there is no way to change anything without modifying source code :(

boris mann’s picture

boris mann commented

This is very, very, very easy if you use a multi-site install.

1) set up for multi-site, with a main "modules" directory that has core install
2) in the sites/ directory, for your specific site (e.g. mydomain.com), set up a modules directory
3) drop in your custom taxonomy.module, which is a modified version of core -- this will override the core module completely

Done.

And your comment on "I need more custom functionality....no way to change anything without modifying source code"...well, of course. How do you think this would work? You either make a separate module, or modify core, and if you modify core without contributing patches, you'll have to update it yourself.

Of course, if you modify core, you could also suggest changes/improvements so that they get merged. Yep, it's a longer process, but if you go that route you don't have to worry about supporting the whole thing yourself.

One other tip: if you just need different display, check out the various "theme" functions -- you can include lots of code there that overrides core functions, but will let you continue to upgrade core.

carlmcdade’s picture

carlmcdade commented

Yes, that is probably why my idea did not work as expected.

I have been looking at expressionengine, or at least glancing at it. They have managed to create a system where any free standing application can be connected to the CMS.

---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia

carlmcdade’s picture

carlmcdade commented

This has been bugging in my sleep of late because I keep having to go into the core modules to change things. But why doesn't module_invoke_ all or Drupal use data caching? This would allow modules to override functions by writing to the cache. When checking for the hook there could be an extra maintenance string added. this is just notes code not real or perfect.

function module_invoke($module, $hook, $a1 = NULL, $a2 = NULL, $a3 = NULL, $a4 = NULL) {
 
  $function = $module .'_'. $hook;
 

  if (function_exists(${$function.'_extended'})) {

     return addToCache($function_extended($a1, $a2, $a3, $a4));

 } else {

    return addToCache($function($a1, $a2, $a3, $a4));

  } 
}

---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia