This was originally sent to the opensrs dev-list on the weekend, and it a
necessary part of understanding the strong words I used in a following
message. However this message was flagged for manual acceptance due to a
weird spam filter configuration, and evidently nobody in the opensrs team
bothers to read or verify bounced submissions.
Anyway, here's the text of the message. I've removed the patches themselves,
( which is what caused the bounce? ) and put them at
http://www.noc.isite.net/Projects/OpenSRS/
Here's my original message. It also contains my message to Paul, quoted
below. You can subject your questions about rudeness to that message:
I sent this message to Paul 4 (Note: now 8) days ago without a response.
This patch solves most of the problems listed in sourceforge, and allows
the remainder to be fixed. It also sets up the modules correctly, so that
a communications module isn't doing output.
As you'll note in my message, this is only the first patch of several that
would greatly ease the configuration and sustainability of OpenSRS-SF.
Without this patch, one is required to reimplement the Gtld routines inside
hooks, which may not survive the next upgrade. So this patch really makes
the defined goal of opensrs-sf possible.
Since Paul appears incapable of dialog, I'm bringing this patch directly to
the developers list. I'm CERTAIN there are issues here that I have
overlooked. I'm POSITIVE that this needs additional work, and I'm quite
open to the fact that there might be a better way to do this. Please
comment fully! If we can work out a good solution, a group effort might
get Paul to pay attention.
----- Forwarded message from Joe Rhett <[EMAIL PROTECTED]> -----
Date: Tue, 30 Oct 2001 05:04:59 -0800
From: Joe Rhett <[EMAIL PROTECTED]>
To: Paul Sisson <[EMAIL PROTECTED]>
Subject: making hooks really work
Organization: ISite Services, Inc.
The biggest problem with the Gtld.pm object is that it knows too much about
the output method, and it handles the output itself. The object should be
concerned with ordering, and not have any insight into the user interface.
Religion aside, by removing the print_tld functions from the Gtld.pm object
we can allow a hook to call a Gtld function, and then use the results from
that call prior to calling the print_tld routines. This means that I can
write a hook to replace a function, and use that function -- rather than
being forced to reimplement the function inside the hook. This will
preserve longevity of hooks, and all upgrades while retaining a custom
hooks.pl -- the ultimate goal here.
The following patches are my attempt to resolve this. I moved print_tpl
completely out of Gtld.pm, and reset all the functions to return values
-- thus allowing them to be called within hooks. This solves several of
the complaints in the forums, and one of the listed feature requests as well.
Frankly, I consider these changes a half-effort. The next step is to remove
the template file names from the functions entirely, and supply them
inside the HTML submitted. No practical change in the functionality would
occur, and it would allow someone to modify the page flow from the
templates directly, without having to write a hook just to change the
process flow.
I meant to move print_lookup out of the module entirely -- it's not part of
the Gtld, and is definitely specific to the output. That points at moving
the hidden stuff out as well. We could definitely shorten the code in
Gtld.pm by generalizing the stuff you repeat in each routine. But lets see
how/if you like these patches before I spent the time on that.
The first dozen or so changes to order.cgi only fix inconsistent spaces/tabs.
The patches also clear up some simple performance and structure problems. I
see no value in defining new variables which are only used once. You'll see
what I mean.
Note that these are based on work we did with 1.3, and I've moved them over
to 1.43 but I'm not working in a test environment tonight -- these are
untested at the moment. But the idea is clear, and the changes are simple.
Please comment fully on any questions or issues you have with these. I'd
like to keep an open dialog - it will make both our jobs faster and easier,
while improving the code base. I promise no sarcasm ;-)
You can find these patches at
http://www.noc.isite.net/Projects/OpenSRS/
--
Joe Rhett Chief Geek
[EMAIL PROTECTED] ISite Services, Inc.
