Thread: [Bodington-developers] build.xml

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

I have humbly committed an updated build.xml to jar up the res dir and 
bung it in WEB-INF/lib/res.jar

bod is now i18n

Alistair

Should this be updated on head with new location for dtds?

Antony Corfield wrote:
> Should this be updated on head with new location for dtds?
> 

I'm on the case (as per this mail and the recent video-conference!).

-- 
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Alexis O'Connor, VLE Developer (http://bodington.org) |
| OUCS, 13 Banbury Road, Oxford, OX2 6NN, UK.           |
| Tel. +44 (0)1865 283661                               |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - +

email when it's done...

On 11 Jul 2005, at 16:00, Alexis O'Connor wrote:

> Antony Corfield wrote:
>> Should this be updated on head with new location for dtds?
>
> I'm on the case (as per this mail and the recent video-conference!).
>
> -- 
> + - - - - - - - - - - - - - - - - - - - - - - - - - - - +
> | Alexis O'Connor, VLE Developer (http://bodington.org) |
> | OUCS, 13 Banbury Road, Oxford, OX2 6NN, UK.           |
> | Tel. +44 (0)1865 283661                               |
> + - - - - - - - - - - - - - - - - - - - - - - - - - - - +
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in 
> dual
> core and dual graphics technology at this free one hour event hosted 
> by HP, AMD, and NVIDIA.  To register visit 
> http://www.hp.com/go/dualwebinar
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers

Alexis O'Connor wrote:
> Antony Corfield wrote:
> 
>> Should this be updated on head with new location for dtds?
>>
> 
> I'm on the case (as per this mail and the recent video-conference!).
> 

What's the build error people are getting? I don't have any problems 
with my build.

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

Ok the error was file not found i.e. the dtd -thought this may have  
been in build.xml

However because the dtd files have moved (and  
xhtmltemplate1-frameset.dtd is not there anymore) I've changed the  
doctype declaration to:

<!DOCTYPE template PUBLIC  
"http://bodington.org/dtd/xhtml1-frameset.dtd"  
"../../../WEB-INF/classes/org/bodington/servlet/template/xhtml1- 
frameset.dtd">

this builds now thanks.

On 11 Jul 2005, at 18:04, Matthew Buckett wrote:

> Alexis O'Connor wrote:
>> Antony Corfield wrote:
>>> Should this be updated on head with new location for dtds?
>>>
>> I'm on the case (as per this mail and the recent video-conference!).
>
> What's the build error people are getting? I don't have any problems  
> with my build.
>
> -- 
> +--Matthew Buckett-----------------------------------------+
> | VLE Developer, Learning Technologies Group               |
> | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/       |
> +------------Computing Services, University of Oxford------+
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar  
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in  
> dual
> core and dual graphics technology at this free one hour event hosted  
> by HP, AMD, and NVIDIA.  To register visit  
> http://www.hp.com/go/dualwebinar
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers

Antony Corfield wrote:
> Ok the error was file not found i.e. the dtd -thought this may have  
> been in build.xml
> 
> However because the dtd files have moved (and  
> xhtmltemplate1-frameset.dtd is not there anymore) I've changed the  
> doctype declaration to:
> 
> <!DOCTYPE template PUBLIC  
> "http://bodington.org/dtd/xhtml1-frameset.dtd"  
> "../../../WEB-INF/classes/org/bodington/servlet/template/xhtml1- 
> frameset.dtd">
> 
> this builds now thanks.

I just noticed this too.... Yeah because the xhtml1-frameset wasn't used 
on the WebLearn build so I didn't add it to the new location. Because of 
the way I work I created a patch from the weblearn tree to push the 
changes across to Bodington and this patch didn't have the extra DTDs.

Then when you commited your new templates you changed to using the DTD 
that I didn't move and hence the break.

We can either add the xhtmltemplate1-frameset and 
xhtmltemplate1-transitional to the new folder (probably the correct fix).

Or we can change the templates to all use the same DTD.

The reason I orginally created the extra DTDs was to get rid of lots of 
compiler warnings from the XML template compiler about templates having 
elements not defined in the DTDs (frameset).

I think adding the extra DTDs is probably the better way to go as it 
keeps the XML compiler warnings to a minimum.

>>
>> What's the build error people are getting? I don't have any problems  
>> with my build.

The reason I wasn't getting any problems was I hadn't pulled in your 
changes. Sorry about the confusion.

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

> We can either add the xhtmltemplate1-frameset and 
> xhtmltemplate1-transitional to the new folder (probably the correct 
> fix).

Yep, I think so too. I'll add these and update the dtd declaration. The 
framset dtd wasn't in these templates before and was causing 
compilation errors (no body element etc).

Cheers,
Antony

Antony Corfield wrote:
>> We can either add the xhtmltemplate1-frameset and 
>> xhtmltemplate1-transitional to the new folder (probably the correct fix).
> 
> 
> Yep, I think so too. I'll add these and update the dtd declaration. The 
> framset dtd wasn't in these templates before and was causing compilation 
> errors (no body element etc).
> 
> Cheers,
> Antony

I have been closely following this thread as certain people were 
suggesting that the build.xml was to blame ;-).

Close observers will now see that this is not the case. However, as I 
was started on that particular garden path I'd started updating it 
anyway before other matters came to light!

I've observed that xhtmltemplate1-frameset.dtd and 
xhtmltemplate1-transitional.dtd have now been added to 
src/org/bodington/servlet/template. There are 8 templates that use 
xhtmltemplate1-frameset.dtd as the DTD. I've altered the DOCTYPE 
declaration in these files, as they can pick up the DTD via the 
CLASSPATH, rather than needing to be hard-wired to some location deep 
under /WEB-INF/.

I took the rather outrageous step of seeing if all the templates can 
compile and be deployed as a running installation. Bizarrely, they can ...

Alexis

> I have been closely following this thread as certain people were 
> suggesting that the build.xml was to blame ;-).
Was the only way to get your attention ;-)

> I've altered the DOCTYPE declaration in these files, as they can pick 
> up the DTD via the CLASSPATH, rather than needing to be hard-wired to 
> some location deep under /WEB-INF/.
About time too!

> I took the rather outrageous step of seeing if all the templates can 
> compile and be deployed as a running installation. Bizarrely, they can 
> ...

Are you crazy!! Never, ever try that again!

Antony Corfield wrote:
>> I have been closely following this thread as certain people were 
>> suggesting that the build.xml was to blame ;-).
> 
> Was the only way to get your attention ;-)
> 
>> I've altered the DOCTYPE declaration in these files, as they can pick 
>> up the DTD via the CLASSPATH, rather than needing to be hard-wired to 
>> some location deep under /WEB-INF/.
> 
> About time too!
> 
>> I took the rather outrageous step of seeing if all the templates can 
>> compile and be deployed as a running installation. Bizarrely, they can 
>> ...
> 
> 
> Are you crazy!! Never, ever try that again!
> 

Steady now ;-). My sarcasm was primarily directly towards the buckster, 
for it seems as though it was he who thoughtfully introduced these 
breakages, but he's not around to defend himself in person today ...

Alexis

Alistair Young wrote:
> I have humbly committed an updated build.xml to jar up the res dir and 
> bung it in WEB-INF/lib/res.jar
> 
> bod is now i18n
> 
> Alistair
> 

OK, time for Alistair to stuff a copy of the Beano annual down the back 
of his shorts again ;-).

Getting there with the build.xml. However, it would be good if the 
res.jar followed the pattern of bodserver.jar. This would mean that the 
resources lie in unpacked form under WEB-INF/classes (for the 
'deploy-local' target to take advantage of) and only get bundled into a 
jar by 'create-war'.

More importantly though, it still doesn't work on Windows :-(. (Stack 
trace attached). An 'escaping backslash in strings' problem. Why are you 
hardcoding the location of bodington.properties? Can you not get hold of 
the properties via BuildingServer?

Alexis

cmon, give me some credit - I don't hard code!

bodingtonProperties is set via  
breq.getRealPath("/WEB-INF/bodington.properties")

on windows it comes out with backslashes as it should, however, this is  
no normal system, this is bodington and the result has to be written as  
code into a java file:

writer.println("bodingtonProperties = \"" + bodingtonProperties +  
"\";");

I could just do bodingtonProperties.replaceAll("\\", "\\\\");

the only reason I need bodingtonProperties is to get the language debug  
level as BuildingContext is incapable of updating bodington.properties  
- it reads it once then forgets it's there, so using  
BuildingContext.getProperty() doesn't work in a dynamic environment -  
unless I've missed something?

the alternative is to store the debug level as a user setting but  
that's overkill. A debug level was specifically requested and  
bodington.properties was the cleanest way to do it.

I hope you meant the hardback edition of the beano annual?

Would you like to do the build file update for res.jar seeing you  
designed the process and are more familiar with it?

Alistair

On 25 May 2005, at 16:23, Alexis O'Connor wrote:

> Alistair Young wrote:
>> I have humbly committed an updated build.xml to jar up the res dir  
>> and bung it in WEB-INF/lib/res.jar
>> bod is now i18n
>> Alistair
>
> OK, time for Alistair to stuff a copy of the Beano annual down the  
> back of his shorts again ;-).
>
> Getting there with the build.xml. However, it would be good if the  
> res.jar followed the pattern of bodserver.jar. This would mean that  
> the resources lie in unpacked form under WEB-INF/classes (for the  
> 'deploy-local' target to take advantage of) and only get bundled into  
> a jar by 'create-war'.
>
> More importantly though, it still doesn't work on Windows :-(. (Stack  
> trace attached). An 'escaping backslash in strings' problem. Why are  
> you hardcoding the location of bodington.properties? Can you not get  
> hold of the properties via BuildingServer?
>
>
> Alexis
> Compilation messages...
> -classpath  
> /C:/j2sdk1.4.2_08/jre/lib/ext/dnsns.jar;/C:/j2sdk1.4.2_08/jre/lib/ext/ 
> ldapsec.jar;/C:/j2sdk1.4.2_08/jre/lib/ext/localedata.jar;/C:/ 
> j2sdk1.4.2_08/jre/lib/ext/pg74.215.jdbc3.jar;/C:/j2sdk1.4.2_08/jre/ 
> lib/ext/sunjce_provider.jar;/C:/j2sdk1.4.2_08/lib/tools.jar;/C:/ 
> Program%20Files/Apache%20Software%20Foundation/Tomcat%205.0/bin/ 
> bootstrap.jar;C:/Program Files/Apache Software Foundation/Tomcat  
> 5.0/common/classes/;C:/Program Files/Apache Software Foundation/Tomcat  
> 5.0/common/endorsed/xercesImpl.jar;C:/Program Files/Apache Software  
> Foundation/Tomcat 5.0/common/endorsed/xml-apis.jar;C:/Program  
> Files/Apache Software Foundation/Tomcat  
> 5.0/common/lib/ant-launcher.jar;C:/Program Files/Apache Software  
> Foundation/Tomcat 5.0/common/lib/ant.jar;C:/Program Files/Apache  
> Software Foundation/Tomcat  
> 5.0/common/lib/commons-collections-3.1.jar;C:/Program Files/Apache  
> Software Foundation/Tomcat  
> 5.0/common/lib/commons-dbcp-1.2.1.jar;C:/Program Files/Apache Software  
> Foundation/Tomcat 5.0/common/lib/commons-el.jar;C:/Program  
> Files/Apache Software Foundation/Tomcat  
> 5.0/common/lib/commons-pool-1.2.jar;C:/Program Files/Apache Software  
> Foundation/Tomcat 5.0/common/lib/jasper-compiler.jar;C:/Program  
> Files/Apache Software Foundation/Tomcat  
> 5.0/common/lib/jasper-runtime.jar;C:/Program Files/Apache Software  
> Foundation/Tomcat 5.0/common/lib/jsp-api.jar;C:/Program Files/Apache  
> Software Foundation/Tomcat 5.0/common/lib/naming-common.jar;C:/Program  
> Files/Apache Software Foundation/Tomcat  
> 5.0/common/lib/naming-factory.jar;C:/Program Files/Apache Software  
> Foundation/Tomcat 5.0/common/lib/naming-java.jar;C:/Program  
> Files/Apache Software Foundation/Tomcat  
> 5.0/common/lib/naming-resources.jar;C:/Program Files/Apache Software  
> Foundation/Tomcat 5.0/common/lib/servlet-api.jar;C:/Program  
> Files/Apache Software Foundation/Tomcat  
> 5.0/common/lib/tools.jar;C:/Program Files/Apache Software  
> Foundation/Tomcat 5.0/shared/classes/;/C:/Program Files/Apache  
> Software Foundation/Tomcat  
> 5.0/webapps/bodington/WEB-INF/lib/activation.jar;/C:/Program  
> Files/Apache Software Foundation/Tomcat  
> 5.0/webapps/bodington/WEB-INF/lib/bodserver.jar;/C:/Program  
> Files/Apache Software Foundation/Tomcat  
> 5.0/webapps/bodington/WEB-INF/lib/ldap.jar;/C:/Program Files/Apache  
> Software Foundation/Tomcat  
> 5.0/webapps/bodington/WEB-INF/lib/log4j.jar;/C:/Program Files/Apache  
> Software Foundation/Tomcat  
> 5.0/webapps/bodington/WEB-INF/lib/mail.jar;/C:/Program Files/Apache  
> Software Foundation/Tomcat 5.0/webapps/bodington/WEB-INF/lib/res.jar;
> C:\Program Files\Apache Software Foundation\Tomcat  
> 5.0\webapps\bodington\WEB- 
> INF\template_classes\working\style_default_default\template_useroptions 
> _en.java:19: illegal escape character
> bodingtonProperties = "C:\Program Files\Apache Software  
> Foundation\Tomcat 5.0\webapps\bodington\WEB-INF\bodington.properties";
>                           ^
> C:\Program Files\Apache Software Foundation\Tomcat  
> 5.0\webapps\bodington\WEB- 
> INF\template_classes\working\style_default_default\template_useroptions 
> _en.java:19: illegal escape character
> bodingtonProperties = "C:\Program Files\Apache Software  
> Foundation\Tomcat 5.0\webapps\bodington\WEB-INF\bodington.properties";
>                                         ^
> C:\Program Files\Apache Software Foundation\Tomcat  
> 5.0\webapps\bodington\WEB- 
> INF\template_classes\working\style_default_default\template_useroptions 
> _en.java:19: illegal escape character
> bodingtonProperties = "C:\Program Files\Apache Software  
> Foundation\Tomcat 5.0\webapps\bodington\WEB-INF\bodington.properties";
>                                                                    ^
> C:\Program Files\Apache Software Foundation\Tomcat  
> 5.0\webapps\bodington\WEB- 
> INF\template_classes\working\style_default_default\template_useroptions 
> _en.java:19: illegal escape character
> bodingtonProperties = "C:\Program Files\Apache Software  
> Foundation\Tomcat 5.0\webapps\bodington\WEB-INF\bodington.properties";
>                                                                         
>        ^
> C:\Program Files\Apache Software Foundation\Tomcat  
> 5.0\webapps\bodington\WEB- 
> INF\template_classes\working\style_default_default\template_useroptions 
> _en.java:19: illegal escape character
> bodingtonProperties = "C:\Program Files\Apache Software  
> Foundation\Tomcat 5.0\webapps\bodington\WEB-INF\bodington.properties";
>                                                                         
>                          ^
> 5 errors
>
> Compilation exit code = 1

Alistair Young wrote:
> cmon, give me some credit - I don't hard code!
> 
> bodingtonProperties is set via  
> breq.getRealPath("/WEB-INF/bodington.properties")
> 
> on windows it comes out with backslashes as it should, however, this is  
> no normal system, this is bodington and the result has to be written as  
> code into a java file:
> 
> writer.println("bodingtonProperties = \"" + bodingtonProperties +  "\";");
> 
> I could just do bodingtonProperties.replaceAll("\\", "\\\\");
> 
> the only reason I need bodingtonProperties is to get the language debug  
> level as BuildingContext is incapable of updating bodington.properties  
> - it reads it once then forgets it's there, so using  
> BuildingContext.getProperty() doesn't work in a dynamic environment -  
> unless I've missed something?
> 
> the alternative is to store the debug level as a user setting but  
> that's overkill. A debug level was specifically requested and  
> bodington.properties was the cleanest way to do it.

I think I understand better now. Don't worry, I think Windoze is a pile 
of w*nk too, but I believe they have quite a big share of the desktop 
market, so I think we're kinda obliged to support it ;-).

> 
> I hope you meant the hardback edition of the beano annual?
> 

Is there any other!? ;-).

> Would you like to do the build file update for res.jar seeing you  
> designed the process and are more familiar with it?
> 

No worries on this score. I was working on a fix as your reply popped 
into my inbox. Should be committed back very soon!

Alexis

I've humbly put a new XmlTemplate on head that should fix the windows 
problem

Alistair

On 25 May 2005, at 16:49, Alexis O'Connor wrote:

> Alistair Young wrote:
>> cmon, give me some credit - I don't hard code!
>> bodingtonProperties is set via  
>> breq.getRealPath("/WEB-INF/bodington.properties")
>> on windows it comes out with backslashes as it should, however, this 
>> is  no normal system, this is bodington and the result has to be 
>> written as  code into a java file:
>> writer.println("bodingtonProperties = \"" + bodingtonProperties +  
>> "\";");
>> I could just do bodingtonProperties.replaceAll("\\", "\\\\");
>> the only reason I need bodingtonProperties is to get the language 
>> debug  level as BuildingContext is incapable of updating 
>> bodington.properties  - it reads it once then forgets it's there, so 
>> using  BuildingContext.getProperty() doesn't work in a dynamic 
>> environment -  unless I've missed something?
>> the alternative is to store the debug level as a user setting but  
>> that's overkill. A debug level was specifically requested and  
>> bodington.properties was the cleanest way to do it.
>
> I think I understand better now. Don't worry, I think Windoze is a 
> pile of w*nk too, but I believe they have quite a big share of the 
> desktop market, so I think we're kinda obliged to support it ;-).
>
>> I hope you meant the hardback edition of the beano annual?
>
> Is there any other!? ;-).
>
>> Would you like to do the build file update for res.jar seeing you  
>> designed the process and are more familiar with it?
>
> No worries on this score. I was working on a fix as your reply popped 
> into my inbox. Should be committed back very soon!
>
>
> Alexis
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: GoToMeeting - the easiest way to 
> collaborate
> online with coworkers and clients while avoiding the high cost of 
> travel and
> communications. There is no equipment to buy and you can meet as often 
> as
> you want. Try it 
> free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers

Alistair Young wrote:
 >
> the only reason I need bodingtonProperties is to get the language debug  
> level as BuildingContext is incapable of updating bodington.properties  
> - it reads it once then forgets it's there, so using  
> BuildingContext.getProperty() doesn't work in a dynamic environment -  
> unless I've missed something?

Having some properties that can be updated while bodington is running 
and others that require a restart causes confusion and seems messy. Is 
there a reason why this property can't be read at startup only?

I'd really like Bodington to be re-configurable without requiring a 
restart but I think this would come with a move to a more sensible 
configuration setup (commons-configuration) and maybe property listeners.

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

> is there a reason why this property can't be read at startup only?
it changes based on what you choose in useroptions. If you're having 
trouble seeing some strings in templates, you go to useroptions and set 
up the localisation debug level and it tells you things like the bundle 
and classpath it was looking in.

maybe bodington.properties is the wrong place to store it - but I 
couldn't find anywhere else.

Alistair

On 25 May 2005, at 16:51, Matthew Buckett wrote:

> Alistair Young wrote:
> >
>> the only reason I need bodingtonProperties is to get the language 
>> debug  level as BuildingContext is incapable of updating 
>> bodington.properties  - it reads it once then forgets it's there, so 
>> using  BuildingContext.getProperty() doesn't work in a dynamic 
>> environment -  unless I've missed something?
>
> Having some properties that can be updated while bodington is running 
> and others that require a restart causes confusion and seems messy. Is 
> there a reason why this property can't be read at startup only?
>
> I'd really like Bodington to be re-configurable without requiring a 
> restart but I think this would come with a move to a more sensible 
> configuration setup (commons-configuration) and maybe property 
> listeners.
>
> -- 
> +--Matthew Buckett-----------------------------------------+
> | VLE Developer, Learning Technologies Group               |
> | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/       |
> +------------Computing Services, University of Oxford------+
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: GoToMeeting - the easiest way to 
> collaborate
> online with coworkers and clients while avoiding the high cost of 
> travel and
> communications. There is no equipment to buy and you can meet as often 
> as
> you want. Try it 
> free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers

Alistair Young wrote:
>> is there a reason why this property can't be read at startup only?
> 
> it changes based on what you choose in useroptions. If you're having 
> trouble seeing some strings in templates, you go to useroptions and set 
> up the localisation debug level and it tells you things like the bundle 
> and classpath it was looking in.

So is it a system wide property? If so who can change it? Just the 
sysadmin? Does it need to persist between restarts of the context if it 
is mainly used for debugging? If not could it be a context attribute? 
How many questionmarks can I put in one paragraph?

> maybe bodington.properties is the wrong place to store it - but I 
> couldn't find anywhere else.

I'd probably say it is the wrong place but Bodington doesn't exactly 
give many other options.

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

I agree entirely Mathew. You inspired me to rake about in bod and I've
switched to using the request. The template's process() method gets passe=
d
a Request object so BuildingServlet, which handles the debug switching
form now sets the attribute instead of putting it in bodington.properties=
.
Don't know why I didn't see that earlier.

Windows problems should now all be solved as no path info is used any mor=
e.

Anyway, it works a treat without touching bodington.properties

I also changed the template's resource-file attribute to resources as it
now supports multiple resources.

Hopefully that should be it now:

http://www.weblogs.uhi.ac.uk/sm00ay/?p=3D91

Alistair

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

> Alistair Young wrote:
>>> is there a reason why this property can't be read at startup only?
>>
>> it changes based on what you choose in useroptions. If you're having
>> trouble seeing some strings in templates, you go to useroptions and se=
t
>> up the localisation debug level and it tells you things like the bundl=
e
>> and classpath it was looking in.
>
> So is it a system wide property? If so who can change it? Just the
> sysadmin? Does it need to persist between restarts of the context if it
> is mainly used for debugging? If not could it be a context attribute?
> How many questionmarks can I put in one paragraph?
>
>> maybe bodington.properties is the wrong place to store it - but I
>> couldn't find anywhere else.
>
> I'd probably say it is the wrong place but Bodington doesn't exactly
> give many other options.
>
> --
> +--Matthew Buckett-----------------------------------------+
> | VLE Developer, Learning Technologies Group               |
> | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/       |
> +------------Computing Services, University of Oxford------+
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: GoToMeeting - the easiest way to collabor=
ate
> online with coworkers and clients while avoiding the high cost of trave=
l
> and
> communications. There is no equipment to buy and you can meet as often =
as
> you want. Try it
> free.http://ads.osdn.com/?ad_id=3D7402&alloc_id=3D16135&op=3Dclick
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>

Alistair Young wrote:
> I agree entirely Mathew. You inspired me to rake about in bod and I've
> switched to using the request. The template's process() method gets passed
> a Request object so BuildingServlet, which handles the debug switching
> form now sets the attribute instead of putting it in bodington.properties.
> Don't know why I didn't see that earlier.
> 
> Windows problems should now all be solved as no path info is used any more.
> 
> Anyway, it works a treat without touching bodington.properties
> 
> I also changed the template's resource-file attribute to resources as it
> now supports multiple resources.
> 
> Hopefully that should be it now:
> 
> http://www.weblogs.uhi.ac.uk/sm00ay/?p=91
> 
> Alistair
> 
> 

Credit where credit's due: it does appear to work now.

(... once I built it with the changes that were committed at 09.22 today 
rather than when I first got in this morning ;-) ).

Alexis