SquirrelMail Sprockets

[Paul J. T. <th...@ok...>]

> I've been playing with FastTemplate some more this past
> weekend, and REALLY like it, but you bring up some good
> concerns.  With FastTemplate (or any good template engine),
> we won't be stuck to HTML at all.  The folder tree idea
> could be implemented in a javascript/HTML template.
>
> The only real problem that I have run into is doing frames
> with the templates.  I can't figure out how without special
> code in the Squirrelmail core.

I have come up with an odd idea for how we setup our User Interface 
API. It is a little strange. However, the point of it is to provide a 
very modular, maintainable, flexible, and robust framework for the SM 
2.0 UI. This plan is just a suggestion, though presented in present 
tense.

SquirrelMail Sprockets
----------------------

The UI of SquirrelMail 2.0 will be broken up into a collection of 
pieces, each known as a Sprocket. Each of these Sprockets will have 
various modes which it can take on. The specifics of those modes are 
indivual to each Sprocket. Each Sprocket would be defined clearly, 
giving information about the SCOPE of the Sprocket, and the modes it 
can take on. The scope of the Sprocket (which I do not yet completely 
understand) would describe the extent and boundaries of that Sprocket 
within SquirrelMail. The sope may simply be a fancy name for a 
desciption of the Sprocket. Here are some examples.

  Sprocket: User Interface Main
  Scope: Defines the main interface for SquirrelMail
  Modes: Standard (no frames), Frames, XML

  Sprocket: Folder View
  Scope: Presents the list of folders to the user
  Modes: Standard, Tree

  Sprocket: Message View
  Scope: Presents a list of messages to the user
  Modes: Standard, Threaded

The reason to go this complexity of this crazy Sprocket system is 
that various "enhancements" and "options" for the SquirrelMail 
frontend will require different ways of doing things in the data 
handling portion of SquirrelMail. These "different ways of doing 
things in the data handling portion of SquirrelMail" need to stay 
distinctly different so that code may be fast and clean. However, 
people writing UI Templates will need a clear set of boundaries 
defining what is required to create a new SquirrelMail template.

Take the Sprocket (as I have given) "User Interface Main". A template 
may implement either the "standard", "frames", and/or "xml" modes. 
That means a standard (no frames) template can just worry about 
making a nice frameless template, without our frame code getting in 
the way.

However, this provides a clean mechanism for us to be able to provide 
ways for templates to hook into the system. Templates would be 
required to implement these Sprockets just by providing the 
appropriate Template files for them.

Note that a SquirrelMail 2.0 Template (according to my idea, here) 
still consists simply of a set of Template files (FastTemplate, or 
whatever system we chose) which define various aspects of the User 
Interface.

Basically, a template would have a couple routes to take, each 
defined by the set of Sprocket template files required for 
implementation. There would be one set of requirements for each mode 
of the "User Interface Main" Sprocket. If a template implemented more 
then one of the UI Main modes, the union of those requirement sets 
would be taken, giving the requirement set for the multi-mode 
template. Briefly...

  Mode: Standard
  Template must implement Sprockets foo, bar, bob, fred...

  Mode: Frames
  Template must implement Sprockets foo, bar, bob, john...

  Mode: XML
  Template must implement Sprockets bob, charlie, blah, hob...

(Note: those are random sprocket names :)

Anyways, that's the basic concept. What do you guys think?

> I'm still playing with it, and I encourage others to play
> with it (and other templating engines as well).  Please
> suggest anything you find.

We should check out XML Stylesheets as an option, as they are a 
little more industry standard.

-- 
Paul Joseph Thompson
Oklahoma State University
th...@ok...