Re: [Bodington-developers] Plugin interface

[Alistair Y. <ali...@sm...>]

> Otherwise just hardwire it
that's the whole point of the plugin - so we don't have to merge and  
ship uhi specific code. If we hardwire it then Facility needs to know  
about our classes. All we need is a hook in Facility that our  
templates can call. If templates could call any class then we  
wouldn't need the hook in Facility.

> pull this
> from a configuration file somewhere
more than likely we will - we want to get away from dumping stuff in  
Facility. I heard a rumour that Oxford have modules too so they could  
use our templates but provide their own plugin via config file.

> It seems that basically the "Plugin" is just code behind the Facility
> facade
yes, although I don't want to use Facility *at all*. It's just that  
the templates can only call Facility and nothing else.

> traditionally a plugin
> is a body of code that can be added/removed at runtime to augment
> functionality
that's what I'm doing! add the plugin to the template and you get My  
Modules functionality. Remove the plugin from the template and you  
don't! All at runtime.

Perhaps if I  say that the plugin includes associated template tag.  
<plugin ... /> ?

Why can't templates call any class? It would be sooo much easier to  
add functionality like this without bloating Facility further.

We have to get away from Facility. Think outside Facility. Forget  
Facility exists.

Alistair


On 23 Mar 2006, at 09:56, Matthew Buckett wrote:

> 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):
>> }
>
> Firstly why do the Class.forName().newInstance() unless you pull this
> from a configuration file somewhere. Otherwise just hardwire it as it
> makes tracing the code in an IDE much easier.
>
> Secondly checking of modules/plugins should be done at startup time so
> that you don't have to test all pages to make sure that you have  
> all the
> correct plugins loaded/linked.
>
>> 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.
>
> It seems that basically the "Plugin" is just code behind the Facility
> facade. Calling it a plugin I think is confusing, traditionally a  
> plugin
> is a body of code that can be added/removed at runtime to augment
> functionality.
>
> -- 
>  -- 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