|
|
SUB-WEBS
|
|
|
|
The aim of the sub-web system is to allow groups access to
the technology that we at the LIBC have worked hard to
produce for our website. In other words, let others use
existing technology, existing maintenance and existing
support.
|
|
|
How do they work?
|
|
|
The sub-web area is made up of a series of "templates"
derived from the templates used in the main web. One set of
templates is common to all the individual sub-webs.
When we set up a new sub-web we just add a new record to the
sub-web master database containing a name, editor, username,
password, etc. If a club only wants to show Noticeboard and
Leagues in their sub-web, we just set a switch that "hides"
the other areas.
Once the sub-web has been initiated, the registered editor
can log in using their individual username and password.
They can then enter data for their sub-web using a series of
data-entry templates relating to the individual areas (of
the sub-web).
For example, when a reader clicks on the sub-web link "Bowls
Lincolnshire (Men)" the browser URL area displays
".../ClubHome.aspx?ClubID=35". That is received at the
server by our code which translates it into a command to
load the ClubHome.aspx "template" with data from
our databases
related to sub-web ID 35 - Bowls Lincolnshire (Men).
That data will be part of the collection of the words,
numbers and results as entered by the sub-web's editor. When
you click on a link within a sub-web, more of that data is
displayed in another template applicable to the link
clicked. And so on.
Apart from words and numbers (and switches!!) all sub-webs
are the same (....in terms of design, templates and handling
code). They only differ by their content - data held in the
databases. |
|
|
The advantages of database driven templates.
|
|
|
|
Simple - design once, use often. If we didn't use this
method we could not offer sub-webs. Its as simple as that. |
|
|
The downsides!!
|
|
|
|
A couple of points - |
|
|
- Design changes that sound simple can involve a
considerable level of modification. Simple sounding changes
may well require us to :-
- Redesign, modify and test the handling code (currently
well used and very stable).
- Redesign, modify and test the templates (again currently
well used and very stable).
- Redesign, modify and test the relational databases (again
curr........etc.).
- Migrate everyone's data to the new design.
- Any design change of any sort will affect the design of
ALL the sub-webs!!
|
|
This isn't to say that we shouldn't ever change things, but
any change should require both agreement from ALL the
sub-web editors and our having time to do the work. Requests
for change will be much better received if the sub-web
editors "gang up" on us, as that will mean general
agreement! |
|
|
|
Next read ---
|
|
|
|