Untangling a web.

This is a working draft of a web design process. Trying to reduce the ugly nature of html, *ml &c code. The likely use of CGI.pm and Template::Toolkit amoung other things should help keep the damage done by html code to a minimum.

The main point of this particular process is to modularize the document peices sufficiently enough to make editing a fairly simple process and to increase the scalability of a particular page or set of pages.

Parts:

Page Template

Contains most of the html code.
Might actually be within a CGI.pm document,
or a POE program.


Data

The actual information, most likely in a database, or in a directory off by itself. Most likely will have to have html in it for links and formatting and the like.



Control Structure

This will link the Data to the Page itself. POE or CGI.pm or whatever else is used will read this structure to decide what goes into the page.

Clicking on a link will change this control structure. It will then be fed back through the same routine. To produce different results.

That is how the page will be kept fairly simple (I hope);

The control structure will be fairly tightly coupled with the template structure, but that's not a terrible PitA.

Ex. of a control structure::

$state->{header} = '/Bob/pretty/mainheader';
$state->{body} = $default;
$state->{copy} = '/Bob/copyright/CC/default.html';
$state->{leftside} = \&ref_to_index;

The first line has the name of a file (presumably a snippet oftext with html code in it) to by inserted by some Perl programinto the webpage that will be made when it's requested.

The second line might act as the first and give the location of a file, or it could contain the document itself for all I know.

The third line is the same as the first, but I figured I'd play with thinking of it like an html document.

The fourth and last line is a bit different; a reference to a subroutine which contains what needs to be done. This might even be nothing more than a further abstraction layer between the final html and the editing process. While it looks interesting, I think that it's likely to be a little redundant.



Ex. Of things made easier- change display/clickability of link to same page using the $state control structure to control it..


for instance::

foreach my $link ($state->{index}){ #array of links inside page

print $link unless $link == $state->{page};

}

Now, the above code isn't quite right, but it's a good start. It would really end up being a little more complex- something that says

If the link has the same string of information that is used to represent the current page, then we shouldn't display the link.

Yes, I rather like that.

Now, there must be an effort to keep the code as loosely coupled with the data as possible. The above snippet might not do that so well unless I am extreamly careful.



So we end up with three layers for a webpage this way.
Form
Data
Control


Now, I remember that there is another model for doing this... some
three letter acronym... Model is one of the words in it, but I can't
remember what the whole thing is.


OK, trying a differnt way to say it::

1. run response.
2. click internal link.
3. this runs a codref? to change values in $state.
4. run response.

continue....



Not a bad way to do things, but I have to be sure that changes
to pages isn't going to be too difficult.