You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(41) |
May
(353) |
Jun
(133) |
Jul
(534) |
Aug
(401) |
Sep
(219) |
Oct
(86) |
Nov
(144) |
Dec
(61) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(200) |
Feb
(130) |
Mar
(345) |
Apr
(153) |
May
(247) |
Jun
(338) |
Jul
(222) |
Aug
(70) |
Sep
(39) |
Oct
(27) |
Nov
(76) |
Dec
(30) |
2007 |
Jan
(81) |
Feb
(44) |
Mar
(9) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(34) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(6) |
2008 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Matthew B. <mat...@ou...> - 2006-03-23 10:55:12
|
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/ |
From: Alistair Y. <ali...@sm...> - 2006-03-23 10:45:49
|
> 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 |
From: Matthew B. <mat...@ou...> - 2006-03-23 10:37:47
|
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/ |
From: Matthew B. <mat...@ou...> - 2006-03-23 10:21:43
|
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/ |
From: Alistair Y. <ali...@sm...> - 2006-03-23 10:16:04
|
> 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 |
From: Alistair Y. <ali...@sm...> - 2006-03-23 10:14:17
|
> 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 |
From: Colin T. <col...@ou...> - 2006-03-23 09:59:56
|
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 |
From: Matthew B. <mat...@ou...> - 2006-03-23 09:56:47
|
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/ |
From: Alistair Y. <ali...@sm...> - 2006-03-23 09:34:36
|
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 |
From: Peter C. <Pet...@me...> - 2006-03-22 16:44:08
|
> From: Andrew Booth > As part of the SOCKET project, we have to set up QuestionMark=20 > Perception. >=20 > This runs on IIS with SQL Server as the back end. (Yes, I know). >=20 > Has anyone purchased SQL Server recently? Is the free SQL=20 > Server Express worth getting For development (and low-end production) purposes, yes. Does Perception support SQL Server 2005 yet? The alternative would be MSDE 2000, which is also free. The SP3a installer can bite you as it doesn't install any network protocols by default, so install on the same computer (and use the shared memory netlib) or enable network protocols as you run setup. > or can anyone advise on which licence to get? > Looks like the > old days have gone when it was ridiculously cheap for=20 > educational purposes. The 80% educational discount is still there, I think - but the MSDE / Express versions should do what you want at even less cost. If you want to discuss the options, feel free to call me - DDI below. - Peter -- Peter Crowther, Director, Melandra Limited Barnett House, 53 Fountain Street, Manchester M2 2AN DDI: 0161 233 7178 Fax: 0161 233 7179 |
From: Andrew B. <a.g...@le...> - 2006-03-22 16:32:48
|
As part of the SOCKET project, we have to set up QuestionMark Perception. This runs on IIS with SQL Server as the back end. (Yes, I know). Has anyone purchased SQL Server recently? Is the free SQL Server Express worth getting or can anyone advise on which licence to get? Looks like the old days have gone when it was ridiculously cheap for educational purposes. Aggie ____________________________________________ Andrew G Booth Professor of On-Line Learning and Associate Professor of Biochemistry Garstang Building Faculty of Biological Sciences University of Leeds Leeds LS2 9JT U.K. Tel: +44-113-343-3142 Fax: +44-113-343-3167 email: a.g...@le... personal email should be sent to: an...@ag... ____________________________________________ |
From: Alistair Y. <ali...@sm...> - 2006-03-22 14:51:50
|
we've done some simple stress tests here with HttpUnit - we log in as every user in UHI and do some navigation, watch it fall over ;) --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Selwyn Lloyd wrote: >> talking of test... can anyone point us at some open source testing too= ls >> for pressure testing web apps please? > > http://jakarta.apache.org/jmeter/ > > Although it's a little rough around the edges. > > -- > -- 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 > |
From: Matthew B. <mat...@ou...> - 2006-03-22 14:47:10
|
Selwyn Lloyd wrote: > talking of test... can anyone point us at some open source testing tools > for pressure testing web apps please? http://jakarta.apache.org/jmeter/ Although it's a little rough around the edges. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
From: Alistair Y. <ali...@sm...> - 2006-03-22 14:32:55
|
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 > |
From: Alistair Y. <ali...@sm...> - 2006-03-22 14:30:59
|
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 > |
From: Selwyn L. <sel...@ph...> - 2006-03-22 13:42:47
|
talking of test... can anyone point us at some open source testing tools for pressure testing web apps please? Alistair Young wrote: > I don't trust this list anymore! > > > ------------------------------------------------------- > 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 > > |
From: Adam M. <ada...@co...> - 2006-03-22 13:38:05
|
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 |
From: Jon M. <jo...@te...> - 2006-03-22 12:37:04
|
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 > |
From: Alistair Y. <ali...@sm...> - 2006-03-22 11:49:09
|
I don't trust this list anymore! |
From: Alistair Y. <ali...@sm...> - 2006-03-22 11:00:43
|
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 |
From: Matthew B. <mat...@ou...> - 2006-03-22 10:18:41
|
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/ |
From: Alistair Y. <ali...@sm...> - 2006-03-21 17:12:56
|
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 |
From: Adam M. <ada...@co...> - 2006-03-21 16:47:40
|
In message <441...@ou...> bod...@li... writes: > Peter Crowther wrote: > >> From: Colin Tatham > >> I think there are two possible approaches: > >> > >> 1. Use regular expressions to find possible matches of the=20 > >> search term=20 > >> in the identical_table Hashtable keys, or > >> > >> 2. Execute an SQL query with wildcards on the table that contains th= e=20 > >> tokens. > >=20 > > 3. Bite the bullet, throw away the homebrew XML repository and use > > somebody else's work. My candidate would be eXist, which has much of > > this functionality already built in to XQuery. >=20 > For real flexible searching use something specifically for it like=20 > Lucene http://lucene.apache.org/java/docs/ >=20 > I see moving to eXist for XML storage as a related but different issue,= =20 > at the moment it happens that the XML storage is use for searching but=20 > we may find this limiting in the future if the XML structure doesn't=20 > lead to the searches we need. I would co-ordinate with Howard on this one. It would make sense for us b= oth to use the same code adam |
From: Matthew B. <mat...@ou...> - 2006-03-21 09:59:42
|
Jon Maber wrote: > The problem lies with the change to uploaded_files.sql which was checked > in 3 weeks ago. It adds this unique index; > > CREATE UNIQUE INDEX uploaded_files_unq_name ON uploaded_files > (parent_uploaded_file_id, name) > GO > > This constraint is ok for files and sub folders because they all have a > parent_uploaded_file_id but the root folder for each resource has a null > parent_uploaded_file_id and always has the same name. Consequently this > constraint is bound to prevent uploading of files to any new resource > other than the first resource that files were uploaded to since > installation. > > A change is needed urgently - removing the constraint would be the most > obvious first step. Was there a bug report that led to the addition of > the constraint? Is there another way round that bug? The simple change is to remove the constraint as it was a belt a braces solution. Shall I remove them from the upgrade script and uploaded files SQL file? -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
From: Matthew B. <mat...@ou...> - 2006-03-21 09:58:23
|
Peter Crowther wrote: >> From: Matthew Buckett >> Nulls don't end up in the index on PostgreSQL > > Ah. Oh. Oh dear. > >> Sounds like this is a PostgreSQL/MSSQL/HSQLDB difference. > > It is. Not sure whether / which way ANSI mandates this, but (as we've > seen) the behaviour cannot be relied upon. And MSSQL doesn't support partial indexes either? CREATE UNIQUE INDEX uploaded_files_unq_name ON uploaded_files (parent_uploaded_file_id, name) WHERE parent_uploaded_file_id IS NOT NULL -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |