views:

48

answers:

2

When you get a description of some project that should be made with Drupal, and requires some extra-functionality (beyond core and most popular modules), how do you decide how're going to do it?

Do you spend a day or two (or week?) searching for all possible modules, narrowing down the list? What is the cricial point to start writing own module? What is the cricial point to start altering some more or less suitable module?

To be more precise, lets imagine I am going to do a time Booking system in Drupal 5, but there are no modules that do exactly what I want.

What are the most important pros and cons when it comes to selecting the ground to build the Drupal project upon?

+1  A: 

I'd say it really depends on what it is you want to do. If what you want to do is not to complicated, and you can't find a module for it. Chances are that even if you do find one or one that is close, that you end up spending more time searching that would have spent making your own. Where that line is, depends on how skilled you are and how intimate you are with Drupal. After doing lots of small custom modules you end up with a lot of snippets you can reuse making writing new modules quite fast.

Sometimes you can even take a module and make your own to modify it, to make the origin fit your needs. For me, I usually never spend more than a few houres trying to find a module. If I can't find it by then, it's usually

  1. Not maintained and way old.
  2. Still in development

Even if you can get a bit of a head start you might end up struggling in the end, with bad database designs and the like. But it's hard to say where the breaking point of using others halfway there code is. It depends on how hard or how much time YOU have to spend, to make it, vs the struggles you get using it.

googletorp
+1  A: 

I will use a pre-built module only if:

  • it is for UI purposes. For example, an image gallery.
  • it is really, really well consolideted (like the views module for example, or imagecache), is specialized in one task and does it well, and if it serves my purpose whithout any modification (because it just fits, because I can adapt the requirements to make them fit, or because it offers extension points like an api or such)
  • what I need to achieve is peripheral to the system, and there exists a module which will do something similar, and it is easy to modify it and then maintain it

I will make my own if:

  • the functionality is "core" to my system and there is not a module which fits
  • the modules I found are new, not actively maintained, messy coded, etc...

In fact I usually prefer coding my own modules, which I have total control over, than adopt foreing ones, with the risk of having more troubles with them than advantages...

Palantir
I guess if the module I need includes some business logic, e.g. 3-4 grid/record screens interacting, it's highly likely I better play it safe and write the code myself?
PHP thinker
That's my thinking usually, yes. The fact is that if you do it yourself you are 100% sure what does it do, and you can always fix things. If the module is not yours, you have less predictable times to fix things or extend them. If your business logic will be all inside this module, and you have not found anything 100% suitable yet, then I believe you should code it yourself
Palantir