Menu
▾
▴
bodington-developers — Mailing list for Bodington developers
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-28 13:36:49
|
Atif Suleman wrote: > Hi > > Would anyone have a problem IF I pushed the following onto bodington head? Yes unless you are going to commit some JUnit tests as well ;-) What have you written tests for? Attached is the current WebLearn build.xml and I think we had the tests working almost identically. Also attached is BuildingServerTest which allows you to do intergration tests on some of the higher level Bodington code. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Atif S. <BM...@bm...> - 2006-03-28 13:28:51
|
Hi Would anyone have a problem IF I pushed the following onto bodington head? Ta Atif. |
|
From: Andrew B. <a.g...@le...> - 2006-03-28 09:21:35
|
I have committed MySQL support to HEAD (documentation in docs). Can I have an opinion about committing the peer-marker tool? Also, I have converted the MCQ tool to the new templates and localised the text, both template and in-code. Shall I commit it? Aggie |
|
From: Matthew B. <mat...@ou...> - 2006-03-27 15:13:32
|
Matthew Buckett wrote: > Matthew Buckett wrote: > >>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 > > > Ok I pulled out the indexes unless someone has a better solution for MSSQL. > The only solutions I can find all seem to invlove allot of mess (triggers, views, computed constraints). http://www.sql-server-performance.com/q&a133.asp -- -- 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-27 15:06:35
|
Matthew Buckett wrote: > 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 Ok I pulled out the indexes unless someone has a better solution for MSSQL. -- -- 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-27 09:02:01
|
Peter Crowther wrote: >>Most tables should probably use the <th> to denote the >>emphasises cells >>as this shows more clearly that these cells are the headings. > > > Mmm. Accessibility rules then state that you have to say what the > headings are *for* - whether they're row headings or column headings, > for example. What do you mean by this? You can use axis, headers and scope to aid accessability: http://www.ferg.org/section508/accessible_tables.html > It wouldn't be an automated change, but I agree that > correctly identifying headers with <th> would be a sound move for > accessibility. It isn't just for accessability. It's easier for developers read the HTML when you use <th> for headers. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Jon M. <jo...@te...> - 2006-03-24 19:38:10
|
I bu**ered up this explanation by getting mixed up with XSL XSLT and CSS and implying a reliance on FO support in the browser. Sorry, I'll do a proper job in a web page and post the URL. Jon Jon Maber wrote: > Now I've had my tea I'll try and describe the plan that I have for my > own application; > > I will have document files as XHTML delivered by Apache in the normal > way. > > They will all reference a virtual XSL style file (not CSS) via a URL > that maps > to a CGI script or Servlet or whatever using the extra path > information in the > URL to specify the same directory that the original document is in. > > There will be an XML file in the same directory as the document that > describes > some colours and dimensions with informaiton about how these can be > transformed. > And there will also be an XSL file. Each user will have a user > directory which > will contain another XML file with user options defined in it. > > The CGI script or servlet or whatever will use an XSLT file to > transform the documents' > XSL file using the current document data file and the user preferences > file. The resulting > transformed XSL file will be cached in the user's directory and sent > to the browser which > it can be used to style the XHTML file. Obviouly if the CGI script (or > whatever) detects > that the cached file is newer than the three input files it will just > send it without > regenerating it. > > I'm saying CGI or Java or whatever because most work would be done by > XSLT. The work could be integrated into Bodington quite easily - you'd > just need to make > templates to ask the users for preferences and output that as XML > preferences files > according to the DTDs that I devise. > > I'm going to do this for my own purposes probably starting mid-April. > It's for use on my > own web site and I wasn't planning to distribute it but I'd be willing > to sell it to bodington.org > after I and you have tested it for distribution under the open source > license. > > Jon > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Jon M. <jo...@te...> - 2006-03-24 18:34:49
|
Now I've had my tea I'll try and describe the plan that I have for my own application; I will have document files as XHTML delivered by Apache in the normal way. They will all reference a virtual XSL style file (not CSS) via a URL that maps to a CGI script or Servlet or whatever using the extra path information in the URL to specify the same directory that the original document is in. There will be an XML file in the same directory as the document that describes some colours and dimensions with informaiton about how these can be transformed. And there will also be an XSL file. Each user will have a user directory which will contain another XML file with user options defined in it. The CGI script or servlet or whatever will use an XSLT file to transform the documents' XSL file using the current document data file and the user preferences file. The resulting transformed XSL file will be cached in the user's directory and sent to the browser which it can be used to style the XHTML file. Obviouly if the CGI script (or whatever) detects that the cached file is newer than the three input files it will just send it without regenerating it. I'm saying CGI or Java or whatever because most work would be done by XSLT. The work could be integrated into Bodington quite easily - you'd just need to make templates to ask the users for preferences and output that as XML preferences files according to the DTDs that I devise. I'm going to do this for my own purposes probably starting mid-April. It's for use on my own web site and I wasn't planning to distribute it but I'd be willing to sell it to bodington.org after I and you have tested it for distribution under the open source license. Jon |
|
From: Andrew B. <a.g...@le...> - 2006-03-24 18:00:25
|
Alistair You are a hero! A trolley of cakes when we next meet (charged to JISC). I hope the poor souls who will end up addressing the fools at Leeds can quote this as they (Leeds) are currently completely and utterly obsessed with portals since they've already forked out a king's ransom for one.=20 Aggie -----Original Message----- From: bod...@li... [mailto:bod...@li...] On Behalf Of Alistair Young Sent: 24 March 2006 16:51 To: bod...@li... Subject: [Bodington-developers] Thought this might be of interest Early days yet but it seems to be possible to wrap bod in portlets: http://www.weblogs.uhi.ac.uk/sm00ay/?p=3D206 have a good weekend bodders. Alistair ------------------------------------------------------- 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=3D= 121642 _______________________________________________ Bodington-developers mailing list Bod...@li... https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Jon M. <jo...@te...> - 2006-03-24 17:46:37
|
Paul Davis wrote: >Problem seems to raise its head on Safari that because of reloading style >sheets the whole system becomes very slow to load one page. It's a very >real issue and one reason why we're thinking of simplifying the CSS >Paul > > P.S. It's not difficult to work out what the browser is doing - you just examine the network traffic on the client computer using tcpdump in the case of Linux or a similar GUI tool on Windows. It's well worth the small effort of doing this as it explains puzzling behaviour fast. The HTTP protocol is particularly easy because most of it is plain text - even when binary files are sent the request and response headers are all plain text. Jon |
|
From: Jon M. <jo...@te...> - 2006-03-24 17:31:38
|
Paul Davis wrote: >Problem seems to raise its head on Safari that because of reloading style >sheets the whole system becomes very slow to load one page. It's a very >real issue and one reason why we're thinking of simplifying the CSS >Paul > > Simpler Java code or simpler for the user to operate? Sounds like a different and opposite bug in Safari. If the settings aren't changing all the time then the first stylesheet that was delivered should be cached in the browser and used for all subsequent template pages. Even the most simple stylesheet use - i.e. plonking a stylesheet file into a directory on a plain old web server and referencing it in plain old HTML files goes wrong for many browsers when the stylesheet is edited and the user reloads the HTML. If only ten year old browsers failed you could tell users to upgrade but when current browsers fail you have to bite the bullet and provide a solution server side. The main thing is to extract all the hardwired creation of CSS statements into a file that looks as much like a CSS file as possible and a processor java class that can do the appropriate substitution of values according to defined algorithms. Jon |
|
From: Alistair Y. <ali...@sm...> - 2006-03-24 16:51:13
|
Early days yet but it seems to be possible to wrap bod in portlets: http://www.weblogs.uhi.ac.uk/sm00ay/?p=206 have a good weekend bodders. Alistair |
|
From: Paul D. <pau...@ou...> - 2006-03-24 16:16:25
|
Problem seems to raise its head on Safari that because of reloading style sheets the whole system becomes very slow to load one page. It's a very real issue and one reason why we're thinking of simplifying the CSS Paul -----Original Message----- From: bod...@li... [mailto:bod...@li...] On Behalf Of Jon Maber Sent: 24 March 2006 14:59 To: bod...@li... Subject: Re: [Bodington-developers] CSS and Colours in Bodington Matthew Buckett wrote: >The colours in the resource properties page will only be used if >"Generate Style Sheet" is set to something other than empty or false. >Although changing this option doesn't seem to force the stylesheet stuff >to get rebuilt so you probably won't see the changes without getting rid >of your session. > > There are serious bugs in some of the web browsers. (Guess which well known software house is worst?) In some cases it is absolutely impossible to get the browser to go back to the server and reload a *.css URL. In the case of the user filtered style sheets this is absolutely intolerable and I put in a solution - the name of the stylesheet actually changes when the users changes options. This guarantees that the browser loads the new stylesheet on the very next page request so the user can decide to keep or change their options. However, I didn't put this same extra effort into the author style sheet options because it means changing the stylesheet name for all currently logged in users. Jon ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Bodington-developers mailing list Bod...@li... https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Jon M. <jo...@te...> - 2006-03-24 16:11:00
|
Next installment.... Matthew Buckett wrote: >Should the the graphic colours not fallback to the standard foreground >and background colours? > >If someone wants to quickly customize the colours of the site they might >expect to be able to just change the foreground and background colours >and have everything update. If the graphics followed these colours then >this would be possible but at the moment they just continue to use light >and dark grey. > > That is a problem - if a box is left blank it inherits from the property of the same name in the closest anscestor resource. In many cases that won't matter too much but the specific example you give is a case that works badly. I can think of a better scheme but it would increase the complexity of the code even more. For example, for any particular foreground colour property which is set to null; if ( the main page foreground colour is also null ) inherit from ancestor resource else inherit from main page foreground colour. Similarly for the various background colours. Jon |
|
From: Matthew B. <mat...@ou...> - 2006-03-24 16:09:42
|
Jon Maber wrote: > Jon Maber wrote: > >> Matthew Buckett wrote: >> >>> >>> One problem is that some of the navigation colours now are used in >>> default templates (manage.html) which are shared between branches and >>> leaves of the tree. If every resource generated it's own CSS you could >>> just fix this with CSS but otherwise you have to have different >>> templates for leaves and branches. >>> >>> >> Someone must have changed that since I last saw it - all of the >> 'added' functionality of rooms etc. used the document styles not the >> navigation styles. The user who is standing in the corridor and >> changes settings can imagine they are accessing a control panel so >> they would see light on dark top and left frame and a dark on light >> right frame until they've completed their work and go back to the menu >> which is posted up on the wallpaper. >> >> Jon > > > Sorry - I'm replying to my own messages now. I've looked at manage.html > in the CVS repository and I can't understand why you're seeing > navigation colours. A template selects navigaton colours by setting the > class attribute of the body tag thus: <body > class="bodington_navigation_page"> The manage.html template under > 'default' doesn't have that so it shouldn't be using navigation colours. Yep, but when managing a floor shouldn't it use the navigation colours? When managing a search tool shouldn't the document colours be used? But at the moment the same template is used for both. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Jon M. <jo...@te...> - 2006-03-24 15:55:25
|
Jon Maber wrote: > Matthew Buckett wrote: > >> >> One problem is that some of the navigation colours now are used in >> default templates (manage.html) which are shared between branches and >> leaves of the tree. If every resource generated it's own CSS you could >> just fix this with CSS but otherwise you have to have different >> templates for leaves and branches. >> >> > Someone must have changed that since I last saw it - all of the > 'added' functionality of rooms etc. used the document styles not the > navigation styles. The user who is standing in the corridor and > changes settings can imagine they are accessing a control panel so > they would see light on dark top and left frame and a dark on light > right frame until they've completed their work and go back to the menu > which is posted up on the wallpaper. > > Jon Sorry - I'm replying to my own messages now. I've looked at manage.html in the CVS repository and I can't understand why you're seeing navigation colours. A template selects navigaton colours by setting the class attribute of the body tag thus: <body class="bodington_navigation_page"> The manage.html template under 'default' doesn't have that so it shouldn't be using navigation colours. |
|
From: Jon M. <jo...@te...> - 2006-03-24 15:34:20
|
Matthew Buckett wrote: > > One problem is that some of the navigation colours now are used in > default templates (manage.html) which are shared between branches and > leaves of the tree. If every resource generated it's own CSS you could > just fix this with CSS but otherwise you have to have different > templates for leaves and branches. > > Someone must have changed that since I last saw it - all of the 'added' functionality of rooms etc. used the document styles not the navigation styles. The user who is standing in the corridor and changes settings can imagine they are accessing a control panel so they would see light on dark top and left frame and a dark on light right frame until they've completed their work and go back to the menu which is posted up on the wallpaper. Jon |
|
From: Jon M. <jo...@te...> - 2006-03-24 14:59:08
|
Matthew Buckett wrote: >The colours in the resource properties page will only be used if >"Generate Style Sheet" is set to something other than empty or false. >Although changing this option doesn't seem to force the stylesheet stuff >to get rebuilt so you probably won't see the changes without getting rid >of your session. > > There are serious bugs in some of the web browsers. (Guess which well known software house is worst?) In some cases it is absolutely impossible to get the browser to go back to the server and reload a *.css URL. In the case of the user filtered style sheets this is absolutely intolerable and I put in a solution - the name of the stylesheet actually changes when the users changes options. This guarantees that the browser loads the new stylesheet on the very next page request so the user can decide to keep or change their options. However, I didn't put this same extra effort into the author style sheet options because it means changing the stylesheet name for all currently logged in users. Jon |
|
From: Jon M. <jo...@te...> - 2006-03-24 14:51:29
|
I think the intention was for emphasised cells to appear anywhere in a table. However, there is also a sad lack of <TH> headers in most (all?) of the templates. Jon Peter Crowther wrote: >>Most tables should probably use the <th> to denote the >>emphasises cells >>as this shows more clearly that these cells are the headings. >> >> > >Mmm. Accessibility rules then state that you have to say what the >headings are *for* - whether they're row headings or column headings, >for example. It wouldn't be an automated change, but I agree that >correctly identifying headers with <th> would be a sound move for >accessibility. > > - Peter > > >------------------------------------------------------- >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 > > > |
|
From: Jon M. <jo...@te...> - 2006-03-24 14:50:40
|
Responses in installments while I think about it........ I'm thinking about a much more generalised way of implementing the CSS accessibility. A key part of it is to modify colours and it is necessary to know which foreground colours are going on top of which background colours. Parsing and transforming a CSS file doesn't really work because you can't easily tell which classes will go on top of which other classes in order to boost contrast or deal with red-green colour blindness contrast etc. Anyway, I have some ideas for using client side DOM for examing styles as actually applied to the HTML and transforming them dynamically according to the user's preferences. A server side version would also be possible by filtering all the output of the web server through a special servlet. I'm likely to work on this in an application of my own rather than Bodington but I'll keep you up to date on progress. Jon Matthew Buckett wrote: >Probably Jon Maber wrote: > > >>I can answer a couple of questions straight off.... >> >> > >Thanks Jon. > > > >>Originally there was a strong distinction between moving about rooms >>etc. (wallpaper and carpet colours) and documents/tools (paper colours). >>So the top frame, the left frame and the menu frame of rooms, suites etc >>all used the navigation set of colours - default ivory text on mid to >>dark teal. Other templates used dark text on light background. >> >> > >Ok that makes more sense. So Navigation colours were used for all >templates related to containers (branches) and document colours were >used on all tools (leaves of the tree). > >One problem is that some of the navigation colours now are used in >default templates (manage.html) which are shared between branches and >leaves of the tree. If every resource generated it's own CSS you could >just fix this with CSS but otherwise you have to have different >templates for leaves and branches. > > > >>The ability to have the whole set of colours change allows a suite of >>rooms for a specific course to 'brand' the colour scheme. Originally >>this was restricted to sysadmin so that course managers etc. wouldn't be >>able to put horrific colour schemes into effect. However, the intention >>of the accessibility transforms of the colours was to allow individual >>users to control legibility in the event of yellow on purple and other >>such abominations, without losing the distinctiveness of the colour >>scheme. (i.e. bright yellow goes to creamy yellow and purple goes to >>purply grey.) >> >> > >Yep I had quick look through PrefferedColourMapper and learnt about HSV >colour model... > > > >>A lot of this seems to be broken in the current release. >> >> > >Yep. > > > |
|
From: Peter C. <Pet...@me...> - 2006-03-24 14:46:34
|
> Most tables should probably use the <th> to denote the=20 > emphasises cells > as this shows more clearly that these cells are the headings.=20 Mmm. Accessibility rules then state that you have to say what the headings are *for* - whether they're row headings or column headings, for example. It wouldn't be an automated change, but I agree that correctly identifying headers with <th> would be a sound move for accessibility. - Peter |
|
From: Matthew B. <mat...@ou...> - 2006-03-24 14:36:23
|
Probably Jon Maber wrote: > I can answer a couple of questions straight off.... Thanks Jon. > Originally there was a strong distinction between moving about rooms > etc. (wallpaper and carpet colours) and documents/tools (paper colours). > So the top frame, the left frame and the menu frame of rooms, suites etc > all used the navigation set of colours - default ivory text on mid to > dark teal. Other templates used dark text on light background. Ok that makes more sense. So Navigation colours were used for all templates related to containers (branches) and document colours were used on all tools (leaves of the tree). One problem is that some of the navigation colours now are used in default templates (manage.html) which are shared between branches and leaves of the tree. If every resource generated it's own CSS you could just fix this with CSS but otherwise you have to have different templates for leaves and branches. > The ability to have the whole set of colours change allows a suite of > rooms for a specific course to 'brand' the colour scheme. Originally > this was restricted to sysadmin so that course managers etc. wouldn't be > able to put horrific colour schemes into effect. However, the intention > of the accessibility transforms of the colours was to allow individual > users to control legibility in the event of yellow on purple and other > such abominations, without losing the distinctiveness of the colour > scheme. (i.e. bright yellow goes to creamy yellow and purple goes to > purply grey.) Yep I had quick look through PrefferedColourMapper and learnt about HSV colour model... > A lot of this seems to be broken in the current release. Yep. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Adam M. <ada...@co...> - 2006-03-24 14:29:12
|
Matthew - could you add the fisrt bit of this (which I deleted) to the bo= d.org wiki? In message <442...@ou...> bod...@li... writes: >=20 > Questions > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > First of all why do we have a different set of colours for the > navigation display? >=20 > With Bodington always displaying the resource tree in the context of > other pages (frames) having different colours set for the resource tree > compared to the rest of the site looks strange. What might make sense > would be to have containers displayed in a different set of colours to > the tools so that it was clearer to a user when he had reached a tool, > although I'm not convinced that this is worth it. If its a lot of effort then I'd say its not worth it either, if somebody = does set a load of crap colours then the best solution is for them to undo the= ir mistake! >=20 > Should the the graphic colours not fallback to the standard foreground > and background colours? >=20 > If someone wants to quickly customize the colours of the site they migh= t > expect to be able to just change the foreground and background colours > and have everything update. yES YOU'RE PROLLY RIGHT > If the graphics followed these colours then > this would be possible but at the moment they just continue to use ligh= t > and dark grey. >=20 > Why is there table emphasis (<td class=3D"blah">) instead of using the > table heading tag (<th>)? A FINE QUESTION -> accessibility issues here I think. >=20 > Most tables should probably use the <th> to denote the emphasises cells > as this shows more clearly that these cells are the headings. There may > still be a call for emphasis in tables (eg the total of your bank > balance) but why not just use the standard emphasis? >=20 > Is it acceptable to use the Navigation Colours outside the navigation p= age? >=20 > In the UHI L&F colours such as the Header Background Colour are used fo= r > things like the header in the creation page and management pages. >=20 > Should the Graphic Colour in the breadcrumb trail follows the graphic > colours to which they pertain? >=20 > The breadcrumb trail in the top frame show the resource as these icons > represent resources higher up the tree wouldn't it make sense if they > followed the colours of the their own resources? This way it would be > easier to use colours to signify different parts of the tree. >=20 > I'll leave it there for now. >=20 > Notes > =3D=3D=3D=3D=3D >=20 > The reason I am looking at this is that we are trying to merge the UHI > creation changes onto WebLearn and there are lots of colours fixed in > the style.css file which means that being able to change the colours no > longer works consistently. It also seems that at the moment more colour= s > are used that are available in the resource properties. >=20 I'm v keen to use UHIs new pages, it's highyl visible and make people thi= nk we've been hard at work (which of course we have been). We need to weigh = up the pros and cons of a not-totally-ideal situation here. adam > --=20 > -- Matthew Buckett, VLE Developer > -- Learning Technologies Group, Oxford University Computing Services > -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ >=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-24 14:26:59
|
I can answer a couple of questions straight off.... Originally there was a strong distinction between moving about rooms etc. (wallpaper and carpet colours) and documents/tools (paper colours). So the top frame, the left frame and the menu frame of rooms, suites etc all used the navigation set of colours - default ivory text on mid to dark teal. Other templates used dark text on light background. The ability to have the whole set of colours change allows a suite of rooms for a specific course to 'brand' the colour scheme. Originally this was restricted to sysadmin so that course managers etc. wouldn't be able to put horrific colour schemes into effect. However, the intention of the accessibility transforms of the colours was to allow individual users to control legibility in the event of yellow on purple and other such abominations, without losing the distinctiveness of the colour scheme. (i.e. bright yellow goes to creamy yellow and purple goes to purply grey.) A lot of this seems to be broken in the current release. Jon Matthew Buckett wrote: >Background >========== > >Bodington allows the colours used in the site to be changed in the >resource properties page. This page is only accessible to the sysadmin. >There are two sets of colours document ones which are used for the >majority of the site and navigation page colours that are used for the >resource tree display (basically just menu.html). Some colours only >exist in one of these sets. > >Resource Properties are set as metadata on the resource and most lookups >go through Resource.getProperty() which searches up through the resource >tree until it finds a match, it starts at the current resource. > >The colours in the resource properties page will only be used if >"Generate Style Sheet" is set to something other than empty or false. >Although changing this option doesn't seem to force the stylesheet stuff >to get rebuilt so you probably won't see the changes without getting rid >of your session. > >There are allot of possible colours to set so here goes at some >documentation of them. > >Background Colour (D,N): The background color for the page. > >Background Image (D,N): The background image to place on the page. > >Foreground Colour (D,N): The colour of the text on the page. > >Emphasis Colour (D,N): The colour of emphsised text on the page >(typically <em> and <strong> tags). > >Link Colour (D,N): There are a whole host of link (unvisited, visited, >active, hover) options that specify how links should look. > >Graphic Colours (D,N): These (foreground/background) colours allow you >to specify the colours that should be used for the navigation icons or >any icon process by processgif servlet. If these are left empty then the >colours #eeeeee and #111111 are used (hardcoded in >Facility.getTemplateGifColourMapper()). > >Then there are some resource menu only colours: > >Background Colour (N): The two background colours that are used for >resource menu items. > >Header Background Colour (N): The resource menu has some headers and >this is the colour that is used to display them. > >Border Colour (N): This is the colour of the border that surrounds the >resource menu items and the containing table. > >There are also some unaccessible colours that are set in the Bodington >database but are not editable through the web interface: > >Table Background Colour (D): This is used to set the background colour >for all the tables used in Bodington that specify the correct CSS class. > >Table Background Emphasis Colour (D): This is used to emphasis some >cells of a table, typically the headers. > >Extra Emphasis Colour (D): This is the colour used when we really need >to tell the user about something. > >Questions >========= > >First of all why do we have a different set of colours for the >navigation display? > >With Bodington always displaying the resource tree in the context of >other pages (frames) having different colours set for the resource tree >compared to the rest of the site looks strange. What might make sense >would be to have containers displayed in a different set of colours to >the tools so that it was clearer to a user when he had reached a tool, >although I'm not convinced that this is worth it. > >Should the the graphic colours not fallback to the standard foreground >and background colours? > >If someone wants to quickly customize the colours of the site they might >expect to be able to just change the foreground and background colours >and have everything update. If the graphics followed these colours then >this would be possible but at the moment they just continue to use light >and dark grey. > >Why is there table emphasis (<td class="blah">) instead of using the >table heading tag (<th>)? > >Most tables should probably use the <th> to denote the emphasises cells >as this shows more clearly that these cells are the headings. There may >still be a call for emphasis in tables (eg the total of your bank >balance) but why not just use the standard emphasis? > >Is it acceptable to use the Navigation Colours outside the navigation page? > >In the UHI L&F colours such as the Header Background Colour are used for >things like the header in the creation page and management pages. > >Should the Graphic Colour in the breadcrumb trail follows the graphic >colours to which they pertain? > >The breadcrumb trail in the top frame show the resource as these icons >represent resources higher up the tree wouldn't it make sense if they >followed the colours of the their own resources? This way it would be >easier to use colours to signify different parts of the tree. > >I'll leave it there for now. > >Notes >===== > >The reason I am looking at this is that we are trying to merge the UHI >creation changes onto WebLearn and there are lots of colours fixed in >the style.css file which means that being able to change the colours no >longer works consistently. It also seems that at the moment more colours >are used that are available in the resource properties. > > > |
|
From: Antony C. <an...@sm...> - 2006-03-24 14:22:34
|
ok Jon thanks for that we didn't want to hack the code just incase there was a very good reason for the way it was! On 24 Mar 2006, at 14:02, Jon Maber wrote: > I think I have a very simple fix; > > In readMultiPart... > > -data.put( parameter_name, readPart() ); > +addFormField( data, parameter_name, readPart() ); > > -data.put( parameter_name, file.getPath() ); > +addFormField( data, parameter_name, file.getPath() ); > > In getParameterValues... > > - String[] v = new String[1]; > - v[0] = (String)data.get( name ); > - if ( v[0]==null ) > - return null; > - return v; > + return (String[])data.get( name ); > > > In getParameter.... > > - return (String)data.get( name ); > > + String[] plist = (String[])data.get( name ); > + if ( plist!=null ) > + return plist[0]; > + return null; > > > Jon > > Antony Corfield wrote: > >> req params are held in 2 hastables data and formdata, the former >> holds String whilst the latter holds String[] >> When content_type.startsWith( "multipart/form-data" ) readMultiPart >> method is used to populate data hashtable not formdata >> The implementation of getParameterValues(name) checks if data is null >> and then returns the String value for the named key as single >> element array >> >> >> >> On 24 Mar 2006, at 13:35, Jon Maber wrote: >> >>> For some reason the Servlet Specs. have never required servlet >>> containers to support multipart/form-data. (Can anyone comment on >>> whether it is now supported by the latest spec?) So servlet authors >>> have had to write their own code for doing all the decoding. Since >>> Bodington wraps the containers Request in it's own that provides >>> the opportunity to improve support - so the readMultiPart() and >>> related methods were intended to make access to fields in mime >>> multipart data work just like the ordinary encoding. >>> >>> However, I think when it was written the servlet spec didn't support >>> multiple fields with the same name. I suppose the solution is to >>> not put field values into the Hashtable but Vectors that hold one >>> or more fields values with the same name. Shouldn't be difficult to >>> implement. >>> >>> Jon >>> >>> Naomi Miles wrote: >>> >>>> Dear peeps >>>> >>>> I have a leedle problem with attachments in the email function that >>>> I'm working on. I think the problem arises from the bod specific >>>> Request. What's happening is that when the template <form> is of >>>> ENCTYPE="multipart/form-data" then the rest of the template's >>>> parameters are not returned correctly, although the attachment part >>>> works like a wee sweetie. Specifically, I am trying to return >>>> checkboxes with the same name, which normally would be returned >>>> into a String Array by the HttpRequest.getParameterValues method. >>>> Using the bod Request.getParameterValues() method only returns >>>> one of the selected checkboxes. >>>> >>>> In Request.java it checks to see whether the form has enctype of >>>> mutipart and then toddles off to a method called readMultiPart() >>>> (nice naming). I suspect that this is where the problem lies, as >>>> the Hashtable 'data' has parameters put into it bsed on their >>>> names, and obviously in this case there could potentially be more >>>> that one parameter with the same name. >>>> >>>> Any ideas/opinions/potential solutions? - I don't wanna just hack >>>> at it as I don't necessarily fully understand what's going on in >>>> the method and I'll probably break something.. >>>> >>>> Cheers, >>>> Naomi. >>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> 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 >> > > > > ------------------------------------------------------- > 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 |
19 messages has been excluded from this view by a project administrator.
