bodington-developers

[Bodington-developers] Plugin interface

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

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 i=
t
to write stuff to the screen.

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.

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 loa=
d
it via Class.forName as a Plugin and call it's run method.

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.

Any opinions on org.bodington.contrib.Plugin interface?

--=20
Alistair Young
Senior Software Engineer
UHI@Sabhal M=F2r Ostaig
Isle of Skye
Scotland

Re: [Bodington-developers] Plugin interface

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

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/

Re: [Bodington-developers] Plugin interface

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

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

Re: [Bodington-developers] Plugin interface

[Adam M. <ada...@co...>]

Plugins are something that Boding desparately needs, perhaps we should de=
dicate
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 =20
> from me!
>=20
> > Can you create a subclass of Facility?
> I think Facility is a lost cause. We'll wait for Tetra!
>=20
> Thinking about maybe specific plugins - ScreenPlugin - writes to =20
> screen, DBPlugin - does stuff with the DB. It's just a way to =20
> refactor code out of Facility into small packages of functionality =20
> that can better be merged etc. Dare I even say, configured at run =20
> time too, ala struts/spring (I see cabbages heading my way).
>=20
> The basic idea is to have, say, a plugins package in bod:
>=20
> org.bodington.plugin
>=20
> and have specific interfaces in there:
>=20
> ScreenPlugin
> DBPlugin
>=20
> public interface ScreenPlugin {
>    public void run(Request req, PrintWriter writer) throws UP;
> }
>=20
> not saying that's what they should be called, just to illustrate.
>=20
> Template then calls Facility.writeModuleLinks
>=20
> Facility.writeModuleLinks (Request req, PrintWriter writer) {
>    ScreenPlugin minerva =3D (ScreenPlugin)Class.forName=20
> ("org.bodington.contrib.Minerva");
>    minerva.run(req, writer):
> }
>=20
> maybe as you say, use a subclass of Facility as a facade for the plugin=
.
>=20
> public class MinervaHelper extends Facility {
>    writeModuleLinks( ... ) {
>      ScreenPlugin ...
>    }
> }
>=20
> so a template calls a plugin's facade - MinervaHelper - class instead =20
> of Facility
>=20
> Can a template call methods in more than one class though? i.e. it =20
> might need functionality that's in more than one plugin.
>=20
> Alistair
>=20
>=20
>=20
> On 22 Mar 2006, at 10:17, Matthew Buckett wrote:
>=20
> > 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 =20
> >> we don't
> >> want to pollute Facility. However, a template must call facility =20
> >> 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 =20
> >> about
> >> the class to delegate to it - it has to cast to call methods etc, =20
> >> so it
> >> has to know about the specific class.
> >
> > At least the delegate methods should be small. This is how I pulled =20
> > 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 =20
> >> 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 =20
> >> 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 =20
> > think
> > this is a good move as then it becomes move difficult to refactor cod=
e
> > 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 =20
> > idea of
> > linking a template with a Facility in a configuration file breaks =20
> > down.
> >
> >
> > --=20
> >  -- 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 =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?=20
> > cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
> > _______________________________________________
> > Bodington-developers mailing list
> > Bod...@li...
> > https://lists.sourceforge.net/lists/listinfo/bodington-developers
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting lang=
uage
> that extends applications into web and mobile media. Attend the live we=
bcast
> and join the prime developer group breaking into this new coding territ=
ory!
> 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
>=20

--=20
--
Dr AC Marshall (Bodington developer) OUCS, 13, Banbury Rd. Oxford. OX2 6N=
N
               Cheese of the month: Smoked Wensleydale

Re: [Bodington-developers] Plugin interface

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

I'm happy to pursue this Adam, if we can agree on how to implement 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 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 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 plugi=
n.
>>
>> 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 tha=
t
>> > 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 co=
de
>> > as you can't be sure without recompiling the templates if a method i=
s
>> > 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 Service=
s
>> >  -- 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?cmd=3Dlnk&kid=3D110944&bid=3D241720&da=
t=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. 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
>

Re: [Bodington-developers] Plugin interface

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

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

Re: [Bodington-developers] Plugin interface

[Colin T. <col...@ou...>]

Alistair Young wrote:
> either I'm not getting messages again or it's all gone quiet.
;-)

> We'd  like 
> to put org.bodington.plugin and some interfaces in for 2.8 so we  can 
> factor out our My Modules but still leave a hook in Facility.
> 
> This ok with bod.org?

I think it's a bit to soon to add it to 2.8. It's a new approach and I 
think it would be sensible to give it more time -- once something's in a 
release version it's messy to change. I realise that doesn't help with 
your problem. I think MyModules could be useful to other users, so it 
would be good if it was available...


Colin


> 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  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  
>> Facility.
>>
>> -- 
>> Alistair Young
>> Senior Software Engineer
>> UHI@Sabhal Mòr Ostaig
>> Isle of Skye
>> Scotland
>>
>>> Plugins are something that Boding desparately needs, perhaps we  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 = (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
>>>>
>>>
>>> -- 
>>> -- 
>>> Dr AC Marshall (Bodington developer) OUCS, 13, Banbury Rd. Oxford.  
>>> 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=lnk&kid0944&bid$1720&dat1642
>>> _______________________________________________
>>> 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&kid0944&bid$1720&dat1642
>> _______________________________________________
>> 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=k&kid0944&bid$1720&dat1642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
> 
> 


-- 
____________________________________
Colin Tatham
VLE Team
Oxford University Computing Services

http://www.oucs.ox.ac.uk/ltg/vle/
http://bodington.org

Re: [Bodington-developers] Plugin interface

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

> I think it's a bit to soon to add it to 2.8
fair enough, yes.

> it would be good if it was available
there's the rub - we don't want to have to merge in tons of stuff =20
when it's uhi specific.

That's where the plugin idea came from:

<plugin ... /> tag in template
Plugin interface and implementation
Configged at runtime.

Can I go back to struts please? I've had enough Facility!

Alistair


On 23 Mar 2006, at 09:58, Colin Tatham wrote:

> Alistair Young wrote:
>> either I'm not getting messages again or it's all gone quiet.
> ;-)
>
>> We'd  like to put org.bodington.plugin and some interfaces in for =20
>> 2.8 so we  can factor out our My Modules but still leave a hook in =20=

>> Facility.
>> This ok with bod.org?
>
> I think it's a bit to soon to add it to 2.8. It's a new approach =20
> and I think it would be sensible to give it more time -- once =20
> something's in a release version it's messy to change. I realise =20
> that doesn't help with your problem. I think MyModules could be =20
> useful to other users, so it would be good if it was available...
>
>
> Colin
>
>
>> On 22 Mar 2006, at 14:32, Alistair Young wrote:
>>> I'm happy to pursue this Adam, if we can agree on how to =20
>>> implement  them
>>> for v1. Lots to think about. We have a concrete use case for a =20
>>> plugin
>>> though, which means minimal merging of Facility.
>>>
>>> The real quesion is whether it's good or bad to let templates =20
>>> 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 =20
>>>>> the  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 =20=

>>>>>>> know
>>>>>>> about
>>>>>>> the class to delegate to it - it has to cast to call methods =20
>>>>>>> etc,
>>>>>>> so it
>>>>>>> has to know about the specific class.
>>>>>>
>>>>>>
>>>>>> At least the delegate methods should be small. This is how I =20
>>>>>> pulled
>>>>>> the
>>>>>> StyleSheet code out on WebLearn HEAD. There is still the =20
>>>>>> 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 =20=

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

>>>>> 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
>>>>>
>>>>
>>>> --=20
>>>> --=20
>>>> Dr AC Marshall (Bodington developer) OUCS, 13, Banbury Rd. =20
>>>> Oxford.  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 =20
>>>> 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=121=
642
>>>> _______________________________________________
>>>> Bodington-developers mailing list
>>>> Bod...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking =20
>>> scripting  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=1216=
42
>>> _______________________________________________
>>> 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=3Dk&kid=110944&bid$1720&dat=121642
>> _______________________________________________
>> Bodington-developers mailing list
>> Bod...@li...
>> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>
>
> --=20
> ____________________________________
> Colin Tatham
> VLE Team
> Oxford University Computing Services
>
> http://www.oucs.ox.ac.uk/ltg/vle/
> http://bodington.org
>
>
> -------------------------------------------------------
> 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?=20
> cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers

Re: [Bodington-developers] Plugin interface

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

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/

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

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/

Re: [Bodington-developers] Plugin interface

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

> Ok so what happens when the class.forName() fails?
localised error message

> I'm still moving down in the direction of leaving templates and  
> Facility
maybe you've got other ideas then Matthew - I'm coming from a  
desperate need to get away from Facility!

> So how do the templates change so that the MyModules code doesn't get
> called?
they don't call the plugin. e.g. out left.html has a call to Facility  
to output the module links. Just remove that call and the plugin is  
never called.

> ossiblity of having HTML related Java throughout the Bodington  
> codebase
possibility? you've just described Facility!

Alistair


On 23 Mar 2006, at 10:21, Matthew Buckett wrote:

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

Re: [Bodington-developers] Plugin interface

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

Alistair Young wrote:
>> Ok so what happens when the class.forName() fails?
> 
> localised error message

But you don't want this at runtime. You want it at startup time. You
need to be able to check that you have all the correct code so that when
someone uses some obscure tool they don't get a nice error message.

>> I'm still moving down in the direction of leaving templates and  Facility
> 
> maybe you've got other ideas then Matthew - I'm coming from a  desperate
> need to get away from Facility!

I have some code that people are welcome to look at if they are
interested but it's not documented (apart from JavaDoc).

>> So how do the templates change so that the MyModules code doesn't get
>> called?
> 
> they don't call the plugin. e.g. out left.html has a call to Facility 
> to output the module links. Just remove that call and the plugin is 
> never called.

Shouldn't having a different left.html be part of the plugin design so
that it is difficult to get templates that call code that doesn't exist
in the Java?

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

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
>

Re: [Bodington-developers] Plugin interface

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

Subclassing Facility is ok if it's a new resource as you say Jon but I'm
against subclassing Facility for small packages of functionality. That's =
a
lot of dead wood just coz a template *has* to call Facility or it's
subclasses.

I'd suggest changing it to let templates call any class they want, though
I don't know how big a job that would be - can you put your consultant ha=
t
on and advise?

Also, letting templates call plugins directly means they're coupled to th=
e
implementation. I'd rather they called a facade that delegated to the
plugin. That way, if the plugin architecture needs tweaked, which it most
likely will in the first instance, then templates don't have to change
with it.

> class Facility
eek - can we get away from Facility for non facility classes like the My
Modules functionality we're building into CLAN?

> Plugin getPlugin
I don't think there will be such a Plugin - probably abstract. Templates
would be more interested in the discrete functionality of specific
plugins.

> FacilityPlugin and
> PluginSession
or HTMLPlugin - for writing html to the response
and whatever *Plugin other interfaces are required. Don't know yet.

What I think I'm talking about is abstracting the functionality of
Facility into discrete work packages that affect targeted areas of the bo=
d
system - html output/db/logging etc.

A *Plugin interface for each one plus a facade class to insulate the
templates from the turmoil and mayhem underneath.

> Then the template can directly call methods in the plugin
I'm just not happy with that Jon. I'd rather use a facade class that
delegates to it's plugin. Who knows, maybe a plugin repo will build up fo=
r
bod on the net and facades can pull plugins from the net at run time?

--=20
Alistair Young
Senior Software Engineer
UHI@Sabhal M=F2r Ostaig
Isle of Skye
Scotland

> 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 =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 plugi=
n.
>>
>> 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 cod=
e
>>> 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=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?cmd=3Dlnk&kid=3D110944&bid=3D241720&da=
t=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?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>

Re: [Bodington-developers] Plugin interface

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

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.

How about using the existing Bodington facility for doing this that is
used for the Recycle building? So you:

Subclass Facility - Create
  public class UhiFacility extends Facility .... adding the Uhi specific
functionality.

For the changes to the template create a new template style
/tomcatadd/webapps/bodington/templates/style_1/ and copy and change any
templates that need to be different for the UHI code.

Edit the bodington-defaults and replace references to Facility with
UhiFacility.

Change the database so that the style of the root resource is 1 so that
templates are first loaded from the UHI template folder (style_1).

The only problem that I can see at the moment is that for Facility
subclasses they still extend the standard facility so things like
questionnaire facility wouldn't have the extra UHI functionality.

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

Re: [Bodington-developers] Plugin interface

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

It's just too complicated for me Matthew, plus I don't want anything  
to do with Facility! My Modules is not a facility so it shouldn't  
subclass it. We're still being hoodwinked by the template processor.  
I want to call any class, not just Facility.

Look into my eyes, not around the eyes, into them.... there is no  
Facility :)

If My Modules is useful for someone, they would add the <plugin ... / 
 > tag to their template and get the functionality. If they hadn't  
installed the plugin, they'd get an error message. Can't see anything  
wrong with that.

I think we're keeping our templates in our cvs rather than sf. We  
just need a hook into Facility to display our stuff. Of course, if a  
template can call any class we wouldn't need the hook.

I think we're only having this conversation coz Facility rules the  
roost in bod. It should be deposed, now!

Alistair

On 23 Mar 2006, at 10:37, 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.
>
> How about using the existing Bodington facility for doing this that is
> used for the Recycle building? So you:
>
> Subclass Facility - Create
>   public class UhiFacility extends Facility .... adding the Uhi  
> specific
> functionality.
>
> For the changes to the template create a new template style
> /tomcatadd/webapps/bodington/templates/style_1/ and copy and change  
> any
> templates that need to be different for the UHI code.
>
> Edit the bodington-defaults and replace references to Facility with
> UhiFacility.
>
> Change the database so that the style of the root resource is 1 so  
> that
> templates are first loaded from the UHI template folder (style_1).
>
> The only problem that I can see at the moment is that for Facility
> subclasses they still extend the standard facility so things like
> questionnaire facility wouldn't have the extra UHI 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

Re: [Bodington-developers] Plugin interface

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

Alistair,

could you give a rough description of what logic is contained in your My 
Modules plugin?

So far as I can see, I think your My Modules plugin idea is perfectly 
reasonable. However, I do think there are some details of implementation 
that need to be sorted out so I have some questions.

1) Instantiation of the Plugin.
One instance per Bodington web app?
One instance per resource?
One instance per template?
One instance per user session?

2) Initialisation.
Instantiated when web app initialises?
Instantiated when first accessed by template?

3) Calls out from plugin
Does the plugin use just standard runtime packages or does it hook into 
Bodington classes? For example?

4) Calls into the plugin.
Does your plugin have multiple functionality?
Does it use parameters to its method calls?


Jon

Re: [Bodington-developers] Plugin interface

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

> Instantiation of the Plugin
at the moment, one instance per template with shared functionality in  
that instance. It's in it's infancy just now so that's likely to change.

> Initialisation
at first instantiation

> Calls out from plugin
uses some bod methods to get current user

> Calls into the plugin
> Does your plugin have multiple functionality?
no

> Does it use parameters to its method calls?
no

It's functionality is implied by it's interface contract - it's an  
HTMLPlugin so that's all it does, outputs HTML. Facility just calls  
it's run() method.

It connects to a database to get the info to generate the HTML.

Alistair

On 23 Mar 2006, at 12:11, Jon Maber wrote:

> Alistair,
>
> could you give a rough description of what logic is contained in  
> your My Modules plugin?
>
> So far as I can see, I think your My Modules plugin idea is  
> perfectly reasonable. However, I do think there are some details of  
> implementation that need to be sorted out so I have some questions.
>
> 1) Instantiation of the Plugin.
> One instance per Bodington web app?
> One instance per resource?
> One instance per template?
> One instance per user session?
>
> 2) Initialisation.
> Instantiated when web app initialises?
> Instantiated when first accessed by template?
>
> 3) Calls out from plugin
> Does the plugin use just standard runtime packages or does it hook  
> into Bodington classes? For example?
>
> 4) Calls into the plugin.
> Does your plugin have multiple functionality?
> Does it use parameters to its method calls?
>
>
> Jon
>
>
>
> -------------------------------------------------------
> 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

Re: [Bodington-developers] Plugin interface

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

Alistair,

Basically your plugin is a servlet. You could implement it as a subclass 
of HttpServlet, deploy it by referencing the class in the web app 
config. file and access it from the Bodington template as a servlet 
include. You could even update the class and the standard Tomcat class 
loader will reload and instantiate the new version. If there is 
something about the templates that stops the call to "include" that 
could be easily fixed and should be fixed because calling installed 
servlets is a very obvious thing that people will want to do.

In the future people might want runtime installable modules that really 
interact with Bodington and that would require a more involved solution.

This is my recommendation as an unpaid consultant - if you don't like it 
pay me to give you the answer you want ;-)

Jon


Alistair Young wrote:

>> Instantiation of the Plugin
>
> at the moment, one instance per template with shared functionality in  
> that instance. It's in it's infancy just now so that's likely to change.
>
>> Initialisation
>
> at first instantiation
>
>> Calls out from plugin
>
> uses some bod methods to get current user


>
>> Calls into the plugin
>> Does your plugin have multiple functionality?
>
> no
>
>> Does it use parameters to its method calls?
>
> no
>
> It's functionality is implied by it's interface contract - it's an  
> HTMLPlugin so that's all it does, outputs HTML. Facility just calls  
> it's run() method.
>
> It connects to a database to get the info to generate the HTML.
>
> Alistair
>
> On 23 Mar 2006, at 12:11, Jon Maber wrote:
>

Re: [Bodington-developers] Plugin interface

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

That's interesting Jon. I take you mean http://www.clan.uhi.ac.uk/ 
mymodules

Can you provide an exmaple of how a template would do  
RequestDispatcher.include() ?

if it can't then I'd argue not to bother implementing it as we're  
back to the same thing. The plugin is neither a facility nor a servlet.

It's a good idea for static output though, i.e. a news feed maybe and  
it's worth looking into. Be good for a /status servlet.

However, the plugin can't be accessed outwith it's context - it means  
nothing until it's invoked by a template and it can get access to  
current user environment.

Worth looking into though, thanks for the pointer.

My only concern is exposing functionality to the world - that's a lot  
of security updates to maintain as every plugin is accessible via  
it's servlet. Each parallel servlet will have access to the bod  
environment but the difference will be they're publicly accessible  
and attackable. A plugin isn't.

I'm still not convinced though. My Modules is just like a private JSP  
that lives in WEB-INF. It can't be accessed via a browser. Only a  
template can access it.

I don't think you can get a "private" servlet but I haven't looked  
into it enough.

I'm resisting labelling it anything other than a plugin - coz that's  
what it is.

Interesting discussions, keep 'em coming :)

Alistair

On 23 Mar 2006, at 12:47, Jon Maber wrote:

> Alistair,
>
> Basically your plugin is a servlet. You could implement it as a  
> subclass of HttpServlet, deploy it by referencing the class in the  
> web app config. file and access it from the Bodington template as a  
> servlet include. You could even update the class and the standard  
> Tomcat class loader will reload and instantiate the new version. If  
> there is something about the templates that stops the call to  
> "include" that could be easily fixed and should be fixed because  
> calling installed servlets is a very obvious thing that people will  
> want to do.
>
> In the future people might want runtime installable modules that  
> really interact with Bodington and that would require a more  
> involved solution.
>
> This is my recommendation as an unpaid consultant - if you don't  
> like it pay me to give you the answer you want ;-)
>
> Jon
>
>
> Alistair Young wrote:
>
>>> Instantiation of the Plugin
>>
>> at the moment, one instance per template with shared functionality  
>> in  that instance. It's in it's infancy just now so that's likely  
>> to change.
>>
>>> Initialisation
>>
>> at first instantiation
>>
>>> Calls out from plugin
>>
>> uses some bod methods to get current user
>
>
>>
>>> Calls into the plugin
>>> Does your plugin have multiple functionality?
>>
>> no
>>
>>> Does it use parameters to its method calls?
>>
>> no
>>
>> It's functionality is implied by it's interface contract - it's  
>> an  HTMLPlugin so that's all it does, outputs HTML. Facility just  
>> calls  it's run() method.
>>
>> It connects to a database to get the info to generate the HTML.
>>
>> Alistair
>>
>> On 23 Mar 2006, at 12:11, Jon Maber wrote:
>>
>
>
>
> -------------------------------------------------------
> 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

Re: [Bodington-developers] Plugin interface

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

Alistair Young wrote:

> That's interesting Jon. I take you mean http://www.clan.uhi.ac.uk/ 
> mymodules

No, I'd suggest a Servlet made specifically for including HTML into 
another servlet's output.

> Can you provide an exmaple of how a template would do  
> RequestDispatcher.include() ?

No, but I'm sure minimal alteration to the Template code would be needed.

> if it can't then I'd argue not to bother implementing it as we're  
> back to the same thing. The plugin is neither a facility nor a servlet.

It is a servlet in the sense that it is invoked, gets information from a 
request object and outputs HTML via a response object. The only unusual 
feature is that it never outputs a whole page of HTML and is only used 
to insert output in the output of another servlet.

> However, the plugin can't be accessed outwith it's context - it means  
> nothing until it's invoked by a template and it can get access to  
> current user environment.

It _does_ have context. The request object provides the link to the user 
environment - since it is the request object built by the Bodington 
system. Also, the BuldingContext is available since it is stored against 
the thread ID and the thread that calls your *servlet* is the same 
thread that called the template.

> My only concern is exposing functionality to the world - that's a lot  
> of security updates to maintain as every plugin is accessible via  
> it's servlet. Each parallel servlet will have access to the bod  
> environment but the difference will be they're publicly accessible  
> and attackable. A plugin isn't.

The servlet does _not_ need to be exposed on its own URL. The servlet 
knows if it is being called directly or via an include and can refuse to 
deliver content. It can even tell if the include is coming from 
Bodington or from another servlet.

> I don't think you can get a "private" servlet but I haven't looked  
> into it enough.

Yes you can! If you 'include' a servlet only the security constraints of 
the URL that was originally accessed apply. So, you simply put your 
servlet in the web app with a 'noone can access ever' constraint.

> I'm resisting labelling it anything other than a plugin - coz that's  
> what it is.

A rose would smell as sweet....

Jon







P.S.  IT'S A SERVLET!

Re: [Bodington-developers] Plugin interface

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

Jon Maber wrote:
> Alistair Young wrote:

>> if it can't then I'd argue not to bother implementing it as we're 
>> back to the same thing. The plugin is neither a facility nor a servlet.
> 
> 
> It is a servlet in the sense that it is invoked, gets information from a
> request object and outputs HTML via a response object. The only unusual
> feature is that it never outputs a whole page of HTML and is only used
> to insert output in the output of another servlet.
> 
>> However, the plugin can't be accessed outwith it's context - it means 
>> nothing until it's invoked by a template and it can get access to 
>> current user environment.
> 
> 
> It _does_ have context. The request object provides the link to the user
> environment - since it is the request object built by the Bodington
> system. Also, the BuldingContext is available since it is stored against
> the thread ID and the thread that calls your *servlet* is the same
> thread that called the template.

Also as you normally pass through the request object it should have all
the stuff setup by BuildingServlet although you will need to cast it
back to a Bodington request.
> 
>> My only concern is exposing functionality to the world - that's a lot 
>> of security updates to maintain as every plugin is accessible via 
>> it's servlet. Each parallel servlet will have access to the bod 
>> environment but the difference will be they're publicly accessible 
>> and attackable. A plugin isn't.
> 
> The servlet does _not_ need to be exposed on its own URL. The servlet
> knows if it is being called directly or via an include and can refuse to
> deliver content. It can even tell if the include is coming from
> Bodington or from another servlet.
> 
>> I don't think you can get a "private" servlet but I haven't looked 
>> into it enough.
> 
> Yes you can! If you 'include' a servlet only the security constraints of
> the URL that was originally accessed apply. So, you simply put your
> servlet in the web app with a 'noone can access ever' constraint.

You just need to define it by name but place no mappings on the servlet
and that way you can only access it through the
RequestDispatcher.include() for JSPs you just dump them inside WEB-INF/
as then only included/forwarded requests can get at them.

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

Re: [Bodington-developers] Plugin interface

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

Alistair Young wrote:

> I'm still not convinced though. My Modules is just like a private JSP  
> that lives in WEB-INF. It can't be accessed via a browser. Only a  
> template can access it.

By the way - what is a JSP page?  Yes, you got it - a servlet.

Jon

Re: [Bodington-developers] Plugin interface

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

> a servlet
the end result is a "servlet" - the jsp is made for the purpose  
though, rather than cobbling together the same functionalty from a  
real servlet, i.e. building one then restricting it to everything bar  
a template.

It's like implementing OOP in C. Why bother - just use C++.

If I wanted this functionality in a normal webapp, I'd use taglibs.  
(looks at watch, checks which year it is, yes, it *really* is 2006) ;)

Alistair


On 23 Mar 2006, at 13:23, Jon Maber wrote:

> Alistair Young wrote:
>
>> I'm still not convinced though. My Modules is just like a private  
>> JSP  that lives in WEB-INF. It can't be accessed via a browser.  
>> Only a  template can access it.
>
> By the way - what is a JSP page?  Yes, you got it - a servlet.
>
> Jon
>
>
>
> -------------------------------------------------------
> 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