Re: [cgiapp] Re: Comments requested

[Christopher Hicks <suppressed>]

On Mon, 20 Oct 2003, Mark Stosberg wrote:
> I'm also not sure I fully understand your proposal yet. Can you offer a
> code sample as example, or you are still working at the conceptual,
> theoretical level with the idea?  

The concept is that if I call a plug-in in a template that the cgiapp
plug-in manager will semiautomagically find that plug-in, load it, and
include it's output as desired.  The use case I feel likes keeps getting
ignored is "a nonprogrammer edits a template to add a plug-in".  There's
no reason for this person to need to know Perl at all.  There's no reason
they should have to edit the Perl to add simple new functionality.  So the
only code would be (from a TT2 perspective):

[%- PLUGIN FINIcounter prefs="roman=want" params="id=demo,title=API Demo" -%]

I'm sure there are prettier ways to do this and obviousy it will vary
from templating system to templating system how the plugin system would be
accessed, but the same things would always be there: the name or generic
class of a plugin, preferences, and parameters.

Presumably for now this won't be part of the core CGI::Application so 
there will need to be a line in the code which loads the plug-in system.

use CGI::Application::Plugins (qw(-tt2));

Loading this loads the framework without loading each and every available
plug-in into memory.  Since you've asked for code we're getting to grimier 
details like "one of the plugin types that we'll need is a connector for 
the major flavors of templating systems".  Or at least H:T and TT2.  :)

If someone wanted to use a plugin from Perl instead there would need to be 
something like this:

my $mgr = new CGI::Applications::Plugins::Manager; # a singleton actually
my $plugin = $mgr->findPlugin({
			class => 'counter.text', 
			license => 'noncomm',
	});

$plugin->whatever('xxx');

Of course folks wanting to write code generators might enjoy:

my @funcs = $plugin->methodnames(); # normal list
my $methods = $plugin->methods();   # reference to hash of hashes
my $fields = $plugin->fields();     # reference to hash of hashes

Is this making more sense?

There are some other things I'm hoping for:

- the ability to set defaults for a given plug-in at a server, virtual 
host, or application level.  It wouldn't be too hard if we have a choice 
of compatible session storage plug-ins to use that storage for storing a 
users defaults for a given plug-in.

- something like the idea of interfaces in Java where there's one 
definition for how counters should fit into the system and a few different 
implementations.  In oopwonkese, I want an abstract virtual base class for 
each and every type of plug-in.  All plug-ins aimed at drooling into the 
page somewhere should work as similarly as is reasonable, so there would 
be a hierarchy going from Plugin to ContentPlugin to CounterClass to 
WankyCounter to whatever people want to derive from there.

- I really think so much has been done along these lines already that if 
someone were willing to spend the time to research the different ways this 
has been tried in the past you could end up with something really popular.  
VB shows the idea can be popular if it's done minimally well.  Delphi 
shows it can be done and not make real programmers want to nuke Redmond.  
JavaBeans seem to live on in the seemingly popular J2EE world.  
Considering how much work Java is that's really too bad.

- This whole idea is something that could live up to the "Perl makes the 
easy things easy and the hard things doable" philosophy.

-- 
</chris>

No, no, you're not thinking, you're just being logical.
-Niels Bohr, physicist (1885-1962)


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed