Re: [cgiapp] Re: Comments requested
On Sun, 19 Oct 2003, Mark Stosberg wrote: On 2003-10-19, Christopher Hicks [EMAIL PROTECTED] wrote: On Sun, 19 Oct 2003, Mark Stosberg wrote: I think I find the mix-in method the most intuitive way to handle plug-in methods generically. The DBI/DBD model for plug-ins is much more intuitive from the module user perspective, but it does take a lot of work to pull off something that elegant. Any volunteers? :) You mean how there are lots of DBD::* modules which talk to different backends? That seems like a different case to me, since the the DBD::* modules are mostly trying to implement the same interface. With CGI::App plug-ins, I would imagine that each one would mostly be defining it's own interface for unique functionality. If you are referring to something else, could you elaborate? Sure. The DBI::DBD model I was referring to was the fact that DBI.pm can discover all of the DBD's installed by the way they have things setup. It's painless to use - one use DBI line and everything else it finds for itself. One of the nice things about cgiapp (or your own personal inheritance of it) is that you don't have to use tons of different modules. Since the plugin architecture described was based on adding use lines for every plugin my gut reaction was that in some sense it was going backwards. Back to your first point: the DBD::* modules are mostly trying to implement the same interface. With CGI::App plug-ins, I would imagine that each one would mostly be defining it's own interface for unique functionality. Bah. There really aren't that many different kinds of plugins that should be required. Wouldn't 90% of these plug-ins amount to various content generators and authorization schemes? If so, there should be some defined interface so we don't have one interface for checking a file for passwords and a different interface for checking LDAP for passwords. The content generator plug-ins make an even more compelling case for utilizing a DBD-style for plugins. We're all using some templating system right? So I'm sure that we've all experienced being able to fix bugs without going into our cgiapp's Perl code. I'd be happy if more bugs were that easy. So, why make extra reasons to go into the code? If I say I want a counter plugin utilized from a template, my script will crash if I forgot to add the use line for that plugin to that script? Bah. Why should the programmer have to keep up with that sort of housekeeping? To solve these problems in Perl and to continue to strive for making things as data driven as possible you have two choices. (A) Have every possible plugin used in every cgiapp which would lead to horrendous script start times while in CGI mode or more wasted memory in mod_perl. Or (B) move to an architecture where you don't have to do an explicit use to discover and take advantage of the functionality of the component. There are lots of other examples of this sort of technique in other languages. JavaBeans provide a common API to components that are able to explain and negotiate their capabilities with the component user or automatic tools. Many languages have some method of reflection or introspection. http://216.239.37.104/search?q=cache:vScLawy7BKgJ:www.algorithm.com.au/files/reflection/reflection.pdf+object+reflection+componenthl=enie=UTF-8#7 These examples show there are several things worth keeping in mind: - your audience may be a programmer writing code or it may be a dip clicking and dragging and drooling in some visual tool. We don't have a CGIAPP designer yet, but we definitely never will if we don't have a plug-in system that allows it. - a common interface can be built regardless of the disparate purposes of the little black box components. Most JavaBeans have a visual component that the user interacts with in some way, but not all. There are plenty of completely nonvisual components to perform everything imaginable. Regardless there's still varying degrees of common interface that can be shared and we should encourage that. - within these defined common interfaces functionality can be negotiated. Maybe I want my counter to show roman numerals, but the counter I'm using doesn't support that. Oh well, but there should be some way to express I must have roman numerals or I'll die and I want roman numerals, but I want a counter more so these interfaces can be built resiliently. Back to trying spark an effort to utilize the DBD idea in cgiapp, the sticking point is that DBD has a reputation for being tough to deal deal with for the driver writers. The effort is considered to be saved by the users, but the DBD driver writers pull their hair out supposedly. Obviously we don't want that problem either, but I think the idea of having these self-registering modules is a popular enough idea that somebody could take concept behind the DBD/DBI method and write a module that would allow any project to have
Re: [cgiapp] Re: Comments requested
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/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Comments requested
On Sun, 19 Oct 2003, Mark Stosberg wrote: I think I find the mix-in method the most intuitive way to handle plug-in methods generically. The DBI/DBD model for plug-ins is much more intuitive from the module user perspective, but it does take a lot of work to pull off something that elegant. Any volunteers? :) -- /chris What the US needs is a Manhattan Project for alternative energy to oil. They should threaten their enemies with windmills? - BabyDave on /. - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: Comments requested
On 2003-10-19, Christopher Hicks [EMAIL PROTECTED] wrote: On Sun, 19 Oct 2003, Mark Stosberg wrote: I think I find the mix-in method the most intuitive way to handle plug-in methods generically. The DBI/DBD model for plug-ins is much more intuitive from the module user perspective, but it does take a lot of work to pull off something that elegant. Any volunteers? :) You mean how there are lots of DBD::* modules which talk to different backends? That seems like a different case to me, since the the DBD::* modules are mostly trying to implement the same interface. With CGI::App plug-ins, I would imagine that each one would mostly be defining it's own interface for unique functionality. If you are referring to something else, could you elaborate? Thanks, Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
