[development] strange inconsistency: 'custom_url_rewrite'

[Bèr Kessels]

Op maandag 26 december 2005 22:45, schreef Jose A. Reyero:
> About breaking the site, this doesn't need to happen. I've used some
> conditional definition in i18n module, cvs, so the module wont work but
> wont break the site either.. And if you want to use that with more than
> one module, I suggest having 'custom_url_rewrite' defined in your
> settings file, then calling the other modules in order, but it would
> need some 'fine tuning' for two modules using it at the same time...

My whole point is: 
I can get it to worrk. No problem. 
Hell, given enough time I can get *anything* to work in Drupal. Just hack the 
core FUBAR.

Now, all I wantedwas to provide a nice small module that chaged or beloveth 
taxonomy into something even cooler. Into something that is going to push 
Drupal full into that web 20 spotlight: nice and clean tag supprt. 
For that, I am working on some (small and simple) modules tagadelic_browser 
and tagadelic_filter (and off course there still is tagadelic for the clouds)

And these modules should -obviously- work out of the box. we seriously cannot 
expect people to hack functions into theyr settings.php or comment away stuff 
in other modules. Especially not since we are now aiming at the installer. 
(or will the installer be so smart that it can write code for us?)

Apparantly this is a brick wall I ran against (head first). A brick wall we 
put there for performace reasons (good reasons, IMO, don't get me wrong).

So I will rephrase my question then:
* Do we want to raise inpentrable brick walls, to gain performance. 
* And if so, where do we raise them? 
* Do we raise more such walls if that helps perfomance (removing hooks, or 
limiting flexibility)
* Who, where and when is decided who needs the flexibility and who needs the 
performance.

I have to note that I recall the days of the nuke. Where a module often had 
the following install:
* unzip this in your nuke root, and answer yes if it asks you to overwrite any 
files.
There was hardly flexibility. A module was often half actual module and half 
rewritten-core-files. 

Personally I can somehow live with this; Somehow. For I am savvy enough to 
hack away. but really, we all know this is a bad habit. And we all know that 
that is no real solution. Adding stuff yo your install like 'you must copy 
paste this piece of PHP inot this and this location in your settings.php' is 
just deadly. Its a bad thing and I prefer not to go down that route. 
hence I am now pondering to just add some nifty drupal_gotos, and let menu + 
callbak handle the rest. I will leave the core-generated taxonomy/ugly/urls 
in place. 

Bèr

-- 
 [ Bèr Kessels | Drupal services www.webschuur.com ]