Re: [Bodington-developers] Plugin interface

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

either I'm not getting messages again or it's all gone quiet. We'd =20
like to put org.bodington.plugin and some interfaces in for 2.8 so we =20=

can factor out our My Modules but still leave a hook in Facility.

This ok with bod.org?

Alistair

On 22 Mar 2006, at 14:32, Alistair Young wrote:

> I'm happy to pursue this Adam, if we can agree on how to implement =20
> them
> for v1. Lots to think about. We have a concrete use case for a plugin
> though, which means minimal merging of Facility.
>
> The real quesion is whether it's good or bad to let templates call any
> class they want. That would free up plugin developers from using =20
> Facility.
>
> --=20
> Alistair Young
> Senior Software Engineer
> UHI@Sabhal M=F2r Ostaig
> Isle of Skye
> Scotland
>
>> Plugins are something that Boding desparately needs, perhaps we =20
>> should
>> dedicate
>> some time to work with Al after our new WebLearn release?
>>
>> adam
>>
>> In message <7A5...@sm...>
>> bod...@li... writes:
>>> 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 =3D (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 =20
>>> plugin.
>>>
>>> public class MinervaHelper extends Facility {
>>>    writeModuleLinks( ... ) {
>>>      ScreenPlugin ...
>>>    }
>>> }
>>>
>>> so a template calls a plugin's facade - MinervaHelper - class =20
>>> 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 =20=

>>>> 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/=20
>>>>> 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 =20
>>>> refactor code
>>>> as you can't be sure without recompiling the templates if a =20
>>>> 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 =20
>>>> 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=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
>>>> _______________________________________________
>>>> 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?=20
>>> cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
>>> _______________________________________________
>>> Bodington-developers mailing list
>>> Bod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>>>
>>
>> --
>> --
>> Dr AC Marshall (Bodington developer) OUCS, 13, Banbury Rd. Oxford. =20=

>> OX2 6NN
>>                Cheese of the month: Smoked Wensleydale
>>
>>
>> -------------------------------------------------------
>> 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=3Dlnk&kid=110944&bid$1720&dat=12164=
2
>> _______________________________________________
>> 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 =20
> language
> that extends applications into web and mobile media. Attend the =20
> live webcast
> and join the prime developer group breaking into this new coding =20
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642=

> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers