Comments intertwined below, enclosed in double angle-brackets
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
like this...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Regards,
Eric Longman
Atl-Connect Internet Services
+-------------------------------------------------------+
| Atl-Connect Internet Services http://www.atlcon.net |
| 3600 Dallas Hwy Ste 230-288 770 590-0888 |
| Marietta, GA 30064-1685 [EMAIL PROTECTED] |
+-------------------------------------------------------+
----- Original Message -----
From: "Charles Daminato" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 09, 2000 11:34 AM
Subject: Modular Client Code Proposal
Ok...
I've been working on this for some time - but since I'm not a 'programmer'
per se, don't mind the terms I'm using. I expect full feedback on the
list for this discussion - try to keep it pertinent instead of trying to
get 'new' features added as part of the debate.
Modular Client Code...
With each new feature we add to OpenSRS we find ourselves forced to
release a complete version of the client code. Due to severe
customizations that certain customers have made it becomes increasingly
difficult for you to implement the new codebase, and in turn be able to
benefit from the new features being added. With this in mind, we propose
a new client code architecture that is modular in design.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
YEA!! I've been struggling with the challenges of
frequently updating the client, and would appreciate
this approach...new functionality could be added
without me having to dig through existing code and
comparing it to new code to re-integrate my changes!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Base components:
OpenSRS.conf - this will contain the usual login/host information, but
will have another section labelled "Modules". This will allow you to turn
on/off any modules that are currently available, as well as add new
modules as they are released
Client.pm - Responsible for connecting the the server, establishing secure
socket protocol, and simple error checking.
Modular components:
Templates - each new module may need new templates. The proposal is to
have a base template infrastructure (base.html, header.html, footer.html,
etc) and specific APTLY named templates for each new feature and customer
facing screen that encompasses the logic of said feature.
This will remove the need for seperate template directories for each CGI -
there will be one directory
Register/Transfer Domain - this will allow someone to register/transfer a
domain - using common templates and logic derived from 'reg_type'
Batch Register/Transfer - same as above, but with batch capabilities and
the logic that necessarily entails.
Manage Domain - the default, but you should be able to remove some
features altogether - i.e. create custom nameservers
<New Features> - somethings that may be available in the near future are
ccTLDs. Certain name spaces have different requirements. These new
modules may have new templates, or share some that aready exist for
reg/transfer - such as picking a profile.
The use of the 'countries' file already makes the OpenSRS client somewhat
modular - a component is loaded when needed for the appropriate task.
We're looking for suggestions to maximize the potential of this proposed
architecture - as well as usability. Administration must be simple (i.e.
adding a new module...)
Adding a New Module:
- Download module components (cgi, template(s), etc).
- Place CGI in cgi-bin - edit to point to OpenSRS.conf
- Place templates in template directory *(should we make the location of
this configurable?)*
- Edit/Enter line in OpenSRS.conf to enable new module
Should be as simple as that....
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
I very much like the idea of using "global" base.html, header.html and
footer.html files, as I've found it annoying to have to edit the "wrapper"
pages multiple times. I'm not sure I agree that there should be just ONE
templates directory, though. Segregating the module-specific templates into
their own directories helps with managing what's out there, and makes it
easier to compare new releases of a given module to what's currently in
place. Right now, when a new client release is issued, here's what I do:
- I compare the date/time stamps on each of the template files in the new
release to what was in the prior release. While not perfect (you guys seem
to use identical files with slightly different date/time stamps from time to
time), I can pretty easily identify which files you've updated between
releases.
- I add the NEW templates to my templates directory and modify the look and
feel to match the rest of my site.
- I manually update REVISED templates to include any new features you've put
in them. This is VERY time consuming, but I can't find a better way to
merge my already-edited template with your new revised templates.
I would propose that the templates directory be organized as follows:
/templates
/global - Contains "wrapper" templates that are used to set the
overall look and feel of the site. These wrapper
should be utilized by ALL modular template files so
that they can be modified in one place
/reg_system - Contains module-specific templates
/manage - Module-specific templates for managing domains
/whois - Module-specific templates for a whois client
/newmod - Module-specific templates for the NEWMOD module
etc...
HOWEVER, I'm curious about the description of the templates above; it sounds
like what's being suggested is a single template file for each function that
includes ALL of the "screens" needed to effect that function. IMHO, that
would make the templates more difficult to customize. Right now, it's easy
to open the templates in [INSERT YOUR FAVORITE WEB PAGE EDITOR] and make the
changes. As long as you understand that {{these}} are replaceable
parameters that shouldn't be messed with, it's easy enough to create your
own look and feel.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please - copious comments are desired :) On list :)
--
Charles Daminato
OpenSRS Support Manager
[EMAIL PROTECTED]
