Re: [Bodington-developers] Plugin interface

[Jon M. <jo...@te...>]

I think the idea is basically a good one.  The decision to create a 
plugin or to subclass Facility depends on whether you want to create a 
new type of resource with it's own specific funtionality (subclass 
Facility) or you want to add a new package of  functionality to all 
resources (subclass and install Plugin).

However, I think I'd suggest a different mechanism for exposing the 
Plugin to the templates;

class Facility
{
    Plugin getPlugin( String registered_plugin_name )
    {
    ....
    }
}

Then the template can directly call methods in the plugin.

I'd also suggest that there continues to be a separation between HTTP 
handling + HTML markup code and manipulation of data in the database. 
That would be somthing like a pair of classes - FacilityPlugin and 
PluginSession.

Jon


Alistair Young wrote:

> damn list - I didn't get the original of this message and it came  
> from me!
>
>> Can you create a subclass of Facility?
>
> I think Facility is a lost cause. We'll wait for Tetra!
>
> Thinking about maybe specific plugins - ScreenPlugin - writes to  
> screen, DBPlugin - does stuff with the DB. It's just a way to  
> refactor code out of Facility into small packages of functionality  
> that can better be merged etc. Dare I even say, configured at run  
> time too, ala struts/spring (I see cabbages heading my way).
>
> The basic idea is to have, say, a plugins package in bod:
>
> org.bodington.plugin
>
> and have specific interfaces in there:
>
> ScreenPlugin
> DBPlugin
>
> public interface ScreenPlugin {
>   public void run(Request req, PrintWriter writer) throws UP;
> }
>
> not saying that's what they should be called, just to illustrate.
>
> Template then calls Facility.writeModuleLinks
>
> Facility.writeModuleLinks (Request req, PrintWriter writer) {
>   ScreenPlugin minerva = (ScreenPlugin)Class.forName 
> ("org.bodington.contrib.Minerva");
>   minerva.run(req, writer):
> }
>
> maybe as you say, use a subclass of Facility as a facade for the plugin.
>
> public class MinervaHelper extends Facility {
>   writeModuleLinks( ... ) {
>     ScreenPlugin ...
>   }
> }
>
> so a template calls a plugin's facade - MinervaHelper - class instead  
> of Facility
>
> Can a template call methods in more than one class though? i.e. it  
> might need functionality that's in more than one plugin.
>
> Alistair
>
>
>
> On 22 Mar 2006, at 10:17, Matthew Buckett wrote:
>
>> Alistair Young wrote:
>>
>>> Bodders, I've been delurked, damn, to ask opinions.
>>>
>>> We have a requirement for My Modules, which is specific to us so  we 
>>> don't
>>> want to pollute Facility. However, a template must call facility  to 
>>> get it
>>> to write stuff to the screen.
>>
>>
>> Can you create a subclass of Facility?
>>
>>> The writing is delegated to another class which is currently in
>>> org.bodington.contrib on our HEAD but Facility still needs to know  
>>> about
>>> the class to delegate to it - it has to cast to call methods etc,  
>>> so it
>>> has to know about the specific class.
>>
>>
>> At least the delegate methods should be small. This is how I pulled  the
>> StyleSheet code out on WebLearn HEAD. There is still the problem that
>> Facility ends up with 100s of method calls.
>>
>>> A better way would be to define, e.g.
>>>
>>> package org.bodington.contrib;
>>>
>>> public interface Plugin {
>>>   public void run(Request req, PrintWriter writer) throws
>>> SomeOrribleException;
>>> }
>>>
>>> then our class could implement Plugin and Facility would only have  
>>> to load
>>> it via Class.forName as a Plugin and call it's run method.
>>
>>
>> Can you explain the call graph a little more.
>>
>>> It reduces the code in Facility and brings a sort of IOC/dependancy
>>> injection to Facility.
>>>
>>> What would be even better though is allowing templates to call  
>>> whatever
>>> class they wanted and not just Facility or a subclass thereof.
>>
>>
>> I added support for making static calls from template but I don't  think
>> this is a good move as then it becomes move difficult to refactor code
>> as you can't be sure without recompiling the templates if a method is
>> actually used. At the moment you only have todo this checking when
>> working with public methods in Facility. It also means that the  idea of
>> linking a template with a Facility in a configuration file breaks  down.
>>
>>
>> -- 
>>  -- Matthew Buckett, VLE Developer
>>  -- Learning Technologies Group, Oxford University Computing Services
>>  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the  live 
>> webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Bodington-developers mailing list
>> Bod...@li...
>> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>