Re: [Bodington-developers] Spring again

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

Alistair Young wrote:
>> But shouldn't the "page which gives information" be a tool? as you  
>> might
>> want it to be permission and hierarchy aware?
> nothing's concrete just now, just poking around trying to avoid yet  
> another method in Facility and also avoiding tools. The ability to  
> have a chat "control page" isn't bod specific so doing it as a tool  
> is a waste.
> The MyModules could be a tool but the demand for it didn't give any  
> time to navigate the bone crushing blackness of bod tools ;) and it's  
> not restricted - you have the right to view your modules anywhere in  
> bod. Interfaces were mentioned then but were poo-pooed in favour of  
> spring, which was coming. Now it's here, tools are back in fashion 8-0
> 
>> polluting the application with the
>> interface.
> that's a bit harsh. How else could one do it without doing a tool?

You can't I don't think. I just wanted to make sure we didn't have our 
wires crossed.

> The only advantage of a tool is the restrictions you can place on it.  
> Something like chat isn't suited to a tool as the user can just say  
> "sod it", leave bod and use their chat client to do the same thing.  
> Why don't they just use their client in the first place? Ask those  
> who produce requirements ;)

Yeah, if bod is just acting as a proxy for a remote service then there 
isn't much point.

>> Facility (and subclass)
> but templates can only use one class. So you can't add functionality  
> to a template that already uses Facility without putting that  
> functionality into Facility.

But if you subclass Facility then you can access your extra functionality.

>> Tool: A Bodington tool that can be deployed somewhere in the tree of
>> resources and is aware of permissions and possibly the hierarchy.
> but requires an onerous overhead of database insertion. You can't  
> distribute bod tools as they require the database to be modified. If  
> you just wanted public functionality you could just add a <plugin>  
> call to a template and supply the jar in the distro. Facility would  
> use the bod plugin interface to load and call it.

Just because you have an extra tool doesn't mean you have modify your 
database schema although you may well have to add extra rows.

> The goal of a plugin was a self contained unit of functionality that  
> could be called from a template. Unfortunately, as templates are  
> restricted to one class, all plugin hooks have to go into Facility.  
> That's where the interface came from. So Facility could be shipped  
> with a plugin method that just loaded and called the desired plugin,  
> defined by the template at run-time.

But then don't the templates still directly depend on the plugin being 
available?

> Of course, if restrictions are required then a tool would be better  
> although that means merge problems and database modifications and  
> leads to site specific code in bod.

I'm not sure it does.

 > Unless you do what we have to do
> and remove all our functionality before committing to bod head. Now  
> that's a waste of everyone's time.

Agreed.

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