[prev] [thread] [next] [lurker] [Date index for 2002/10/16]
YAY! Finally, I get 5 minutes to sit down and reply to this.
On Sun, Oct 13, 2002 at 06:03:03PM -0400, Gavin Estey said:
>
> I started hacking at the web interface and got it working with the
> changes to the class structure (I just got show-lists / show-list from
> nacho done).
Cool. I have some ideas about the web interface that I'll detail below.
> I started to think that this was a bad thing to do. It seems sensible to
> have
> Siesta::Interface (better name?) which is used by nacho / web interface
> / email interface. Then you could just write:
>
> if (my $hr = $siesta->do($action)) {
> $t->process('template', $hr);
> } else {
> die $siesta->error;
> }
I don't think that this would work, although I'm willing to be proved
wrong. nacho is already a really thin layer which cleans input and
formats output. This really has to be done on an application by
application basis because you could have a CLI based interface, a web
interface, a GTK interface, a ... you get the point.
Although I do like the idea I think that what you'd end up doing is,
instead of writing code like what's in nacho you end up writing a
template for every function, complete with cleansing stuff and that
wouldn't be a net win.
> This would also mean that we could test things easily, and feel proud
> that we have a trendy MVC framework :)
True <grin>
> p.s. my boss is happy for me to hack on siesta, and it looks like we
> might be using it as a basis for our new mailer.
Cool. I've always like it when projects I've worked on have a definite
goal in mind, even if it's not the one it started with. It gives a
project momentum.
Anyway, back to my ideas for the web interface. More a kind of bullet
point list of thoughts.
1. There are two modes - user and administrator. Currently we have no
administrator user and we don't have passwords.
2. Administrator mode is essentially what nacho provides ...
administering users and lists. It should also allow you to set the
default and per-list preferences for all plugins as well as letting you
specify the order and existence of plugins in a list.
3. User mode will only let a user sign up to a list and set per-user and
per-user-per-list preferences for plugins.
4. Plugins (should) provide a method which returns a hashref. The keys
of this hashref are the different preferences that a plugin provides,
what type that preference is and what the preferred widget for that
preference is. This should make it easy for a single template to
automatically generate the html for configuring the preferences in a
plugin. For example, in ReplyTo
sub options {
return {
'munge' => {
'description' =>
'should we munge the reply-to address of the message to be
the list post',
'type' => 'boolean',
'default' => 1,
'widget' => 'checkbox',
}
};
}
Simon
Generated at 13:56 on 01 Jul 2004 by mariachi 0.52