[Perl] More Quad-Pres Planning

Shlomi Fish shlomif at vipe.stud.technion.ac.il
Fri Nov 29 21:49:59 PST 2002

Well, I gave Quad-Pres a lot of extra thought and here are some of the
conclusions I reached:

quadp setup:

After running "quadp setup" it will start with a series of questions
that can be answered by using Term::ReadLine. There will be a
sophisticated menu for doing this and the user can switch to editing a
file containing the keys and answers, and to Curses mode (when I built
one) and to a Perl/Tk mode (again when I built one).

Sample parameters are:

1. The directory on the local hard-disk where the files should be rendered
to. (wml is not real-time and so I intend to cache them there and to
produce static HTML there)

2. The name of the CGI script used to host the dynamically generated
files. (so I can know how to handle quadpres.pl/chapter/
quadpres.pl/chapter/section/url, etc.)

3. An upload site, directory and methodology (FTP, web-dav, rsync,
scp etc.) I almost always view the intermediate site on my local
workstation and then upload it to a Technion server using rsync. I suppose
many other users have similar needs.

4. [Fill in]

After the questions are filled you select "done" and the directory is
created for you. The directory will contain:

1. A Contents.pm file that will contain the logical layout of the
presentation (as is the case in the current quadpres).

2. A template.wml file that the user can customize to customize the look
and feel, define global WML macros, etc.

3. An src directory that will eventually contain the slides. (itself
contains a .quadpres directory with the is_root file present)

4. An executable CGI script that can be used to view the lecture

5. A configuration file containing key-value elements. (preferablly
editable by hand)

The template.wml file:

The template.wml file should be as forward-compatible to future versions
as possible. Thus, a monolithic one like is present now is not a good

What I though about is writing a template.wml like this:

#use quadpres::skins::myskin
#use quadpres::lib::shortcuts


This way, when a new version is upgraded and the skin is modified the
template.wml file need not be changed.

The Three Modes of Rendering:

I can think of three modes for rendering:

1. Server Static HTML - the pages are kept on a directory on the server
and rendered from there.
2. Hard-disk Static HTML - same pages on the hard-disk.
3. Viewed through a CGI script that serves a virtual directory tree.

Now #3 can use the cached pages of #1, and simply emulate its behaviour
exactly. I.e : quadpres.pl/mydir will be redirected to
quadpres.pl/mydir/; quadpres.pl/mydir/hello.html/ will be redirected
to quadpres.pl/mydir/hello.html; . will be filtered out and .. will be
evaluated (while making sure they do not descend out of the root

As for the hard-disk HTML - WML does not support it well. What I can do
is give some macros for accessing relative URLs and then add index.html to
them if necessary.

Managing the Perl Code and the Directory Structure:

My plan is that every invocation of the Quad-Pres utility program will
load the QP modules once and use them for all the operations. I think I'll
pass a COORDS def to wml with the coordinates of the file.

E.g: intro/what_is_wml.html ==> -DCOORDS="0,1"

This will simplify lookups. Whenever I enter a sub-dir of the layout and
need to know the indexes of all the files and sub-dirs under it I can do

$branch->{'indexes'} ||= eval { my $subs = $branch->{'subs'} ; { map {
$subs->[$_]->{'url'} => $_ } (0 .. $#$subs) } } # Don't you _love_ Perl?

And then they will be cached and I can use them further. That way I can
use $branch->{'indexes'}->{'hello'} to determine the index of the 'hello'
sub-dir or page. But I'll need to see when I'll need reverse lookup.

More Random Wish-list items:

1. Footnotes and endnotes.

2. Points appearing one by one.

3. Pages with the same look and feel but out of the flow of the lecture.

4. A web-interface for allowing drag and drop of sections, section
re-arrangement and other basic operations.

5. Editing the slides online.


	Shlomi Fish

Shlomi Fish        shlomif at vipe.technion.ac.il
Home Page:         http://t2.technion.ac.il/~shlomif/

He who re-invents the wheel, understands much better how a wheel works.

More information about the Perl mailing list