Re: A small idea

> ALTHOUGH I UNDERSTAND YOUR POINT (I HAVE TO UPDATE SOME
PLUGINS TOO TO REFLECT
> THAT CHANGE TOO, AND I ALREADY SEE THE FORUM BEEN HIT
BY A WAVE OF "WHERE DOES
> THIS '%' COME FROM" THREADS ;)), I THINK THAT THE
INTRODUCTION OF A NEW $CONF
> SETTING, JUST TO PREVENT "COSMETICAL" BUGS IN
PLUGINS, WOULD LEAD TO A MUCH
> MORE UNWANTED SITUATION, NAMELY THAT THE PLUGIN AUTHORS
DON'T EVEN NOTICE THAT
> SOMETHING HAS CHANGED AND THAT THEY NEED TO UPDATE
THEIR PLUGINS ACCORDINGLY.


THIS MEANS THAT A SUBSET OF USERS WILL BE STUCK IN A
SITUATION LIKE "I CAN'T UPDATE MY WIKI BECAUSE THE NEW
RELEASE IS INCOMPATIBLE WITH PLUGIN X, BUT THE AUTHOR OF X
HAS GONE AWAY AND I'M NOT A PROGRAMMER". WHAT ABOUT A
MIDDLE GROUND LIKE: MAKE THIS AN OPTION BUT SET IT TO OFF BY
DEFAULT (IE. THERE IS A CHECKBOX IN THE ADMINISTRATION
INTERFACE WHERE IT SAYS "AUTO-GENERATE OLD DATE FORMAT
STRING" WHICH IS UNCHECKED BY DEFAULT)?

PS. A SMALL CRITIQUE: IT IS BAD PRACTICE (IMHO) TO CHANGE
THE INTERFACE OF A SOFTWARE (AND BY INTERFACE I MEAN THE
PROGRAMMATIC WAY OF INTERACTING WITH IT, NOT THE GUI) IN A
WAY WHICH IS PURPOSEFULLY INCOMPATIBLE WITH THE OLD ONE
(LIKE CHANGING THE FORMAT OF A CONFIGURATION VARIABLE). EVEN
MORE SO WHEN THE GIVEN INTERFACE IS SEMI-PUBLIC AND IT IS
KNOWN THAT THIRD-PARTY CODE RELIES ON IT. GIVEN HOW FLEXIBLE
DYNAMIC PROGRAMMING LANGUAGES LIKE PHP ARE, IT IS MUCH NICER
TO INTRODUCE A NEW PROPERTY WITH THE DESIRED MEANING AND LET
THE OLD PROPERTY ALONE.

BEST REGARDS.




     
___________________________________________________________ 
RISE TO THE CHALLENGE FOR SPORT RELIEF WITH YAHOO! FOR GOOD 


HTTP://UK.PROMOTIONS.YAHOO.COM/FORGOOD/
--
DOKUWIKI MAILING LIST - MORE INFO AT
HTTP://WIKI.SPLITBRAIN.ORG/WIKI:MAILINGLIST

Balazs Attila-Mihaly (Cd-MaN) wrote:
> This means that a subset of users will be stuck in a
situation like "I can't
> update my wiki because the new release is incompatible
with plugin X, but
> the author of X has gone away and I'm not a
programmer". What about a middle
> ground like: make this an option but set it to off by
default (ie. there is
> a checkbox in the administration interface where it
says "auto-generate old
> date format string" which is unchecked by
default)?

Ok, I've made some research on this topic. From the ~370
plugins listed at
wiki.splitbrain.org the following are relying on the
$conf['dformat'] setting:

plugin:content              last update 2005-09-27
plugin:diskussion_forum     last update 2006-06-25
plugin:userhistory          last update 2007-01-1
plugin:timer                last update 2005-08-01
plugin:lastmod              last update 2005-10-10
plugin:newpagetemplate      last update 2007-02-24
plugin:loglog               last update 2007-10-19

plugin:gtd                  updated in devel (if not I'll
update it)
plugin:blog                 updated in devel
plugin:discussion           updated in devel
plugin:editor               updated in devel
plugin:include              updated in devel
plugin:pagelist             updated in devel
plugin:feed                 updated in devel
plugin:task                 updated in devel
plugin:var                  will be updated by me
plugin:gtd                  will be updated by me
plguin:lastfm               will be updated by me (atm
broken anyway)
plugin:linkback             I am 1000% sure it will be
updated by foosel
plugin:bloglinks            I am 1000% sure it will be
updated by foosel

I might missed 1-5 but you get the picture. I'll be happy to
post fixes for
the 7 plugins mentioned above on the their plugins pages or
contact their
authors via mail if necessary .

> PS. A small critique: it is bad practice (imho) to
change the interface of a
> software (and by interface I mean the programmatic way
of interacting with
> it, not the GUI) in a way which is purposefully
incompatible with the old
> one (like changing the format of a configuration
variable). Even more so
> when the given interface is semi-public and it is known
that third-party
> code relies on it. Given how flexible dynamic
programming languages like PHP
> are, it is much nicer to introduce a new property with
the desired meaning
> and let the old property alone.

Full ack from my side on this! However, in this particular
case there is IMHO
no harm done, because, first, it's a cosmetic thing, it
doesn't make the wiki
unusable, second, the fix for the third party code is
trivial, third, the list
of affected plugins is short compared to the plugins
available ... and the
most popular plugins (blog suite and the like) will be
updated the day the new
DW release sees the light anyway .

Best Regards,
    Chi

-- 
Michael Klier

www:    http://www.chimeric.de
jabber: chijabber.shipdown.de
key:    http://downloads
.chimeric.de/chi.asc
key-id: 0x8308F551