Re: [Bodington-developers] Plugin interface

[Matthew B. <mat...@ou...>]

Alistair Young wrote:
>> 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.

Ok so what happens when the class.forName() fails?

>> 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.

I'm still moving down in the direction of leaving templates and Facility
for SpringMVC and JSPs.

>> 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.

So how do the templates change so that the MyModules code doesn't get
called?

> 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 could, as I said earlier it just then means you end up with the
possiblity of having HTML related Java throughout the Bodington codebase.

-- 
 -- Matthew Buckett, VLE Developer
 -- Learning Technologies Group, Oxford University Computing Services
 -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/