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: Alistair Y. <ali...@sm...> - 2005-07-15 13:15:10
|
Bodington isn't designed to be run in an environment without a JDK. If yo= u want to shoehorn it into such an environment for the sake of ease of deployment you're opening a huge can of worms. If you want people to see what it's like give them PDFs! or install a public version that they can login to and play with. You can't give them a shaky halfway house that works for a defined period of time, or are you planning on circumventing the timestamp checking for such a deployment? It seems your concerns are addressed by the knoppix CD anyway. Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Alexis O'Connor wrote: >> Alistair Young wrote: >> >>>> If not then we >>>> are changing Bodington so that it is no longer possible to deploy on= a >>>> machine without a JDK. >>> >>> >>> yep. that's bod though. What other web application *compiles* it's ow= n >>> pages? Don't you need a JDK anyway? What happens when XmlTemplate >>> decides >>> the class file is out of date and tries to recompile the template? >>> >>> By allowing the absence of the JDK you're telling users "you may neve= r >>> customise your templates". > > Yep. But if we are trying to make it easy for people to try Bodington I > think this is acceptable. > >> Funnily enough I agree with Alistair on this one ;-). Requiring a JDK = is >> reasonable enough for these very reasons. > > If we are going to say people need a JDK this needs to be well > documentation and Bodington needs to have a very clear error message > when you try to run it on a machine without one (not a stack trace). > > I still think we should run without a JDK if they want too, especially > with the quickstart WAR. > >> It would be cool if we could get the Eclipse JDT compiler of Tomcat 5.= 5 >> to compile Bodington templates. > > Indeed. > > -- > +--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: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Matthew B. <mat...@co...> - 2005-07-15 13:03:17
|
Alexis O'Connor wrote: > Alistair Young wrote: > >>> If not then we >>> are changing Bodington so that it is no longer possible to deploy on a >>> machine without a JDK. >> >> >> yep. that's bod though. What other web application *compiles* it's own >> pages? Don't you need a JDK anyway? What happens when XmlTemplate decides >> the class file is out of date and tries to recompile the template? >> >> By allowing the absence of the JDK you're telling users "you may never >> customise your templates". Yep. But if we are trying to make it easy for people to try Bodington I think this is acceptable. > Funnily enough I agree with Alistair on this one ;-). Requiring a JDK is > reasonable enough for these very reasons. If we are going to say people need a JDK this needs to be well documentation and Bodington needs to have a very clear error message when you try to run it on a machine without one (not a stack trace). I still think we should run without a JDK if they want too, especially with the quickstart WAR. > It would be cool if we could get the Eclipse JDT compiler of Tomcat 5.5 > to compile Bodington templates. Indeed. -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Alistair Y. <ali...@sm...> - 2005-07-15 13:02:46
|
> Has anyone got a few hours they can donate to me, I don't mind doing this. I know a lot more about the bod soup now than when I started i18n, so I'm happy to put that new info to use. Is 2.8 ok for youz? If the templates become too slow we can always rollback to the 2.6 way of doing it. Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Alistair Young wrote: >> So what about, for 2.8: >> >> Template classes that query User.getLanguage() at run time. >> >> Localiser chain with the preferred language delegating to the default >> language for missing strings? >> >> This just isn't possible for 2.6. Maybe it might have been if we'd had >> this debate at the start of the process ;) > > Sounds very sensible. Has anyone got a few hours they can donate to me, > I'm running a little short ;-) > > -- > +--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: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Peter C. <Pet...@me...> - 2005-07-15 12:56:32
|
> From: bod...@li...=20 > it's only when you start doing=20 > something in anger that all the issues crystallise in one's=20 > (my) mind ;-). There's considerable evidence that software design is a wicked problem (http://en.wikipedia.org/wiki/Wicked_problems) - we have certainly seen parts 1, 2 and 3 of Conklin's four defining characteristics in the case of Bodington i18n; I'd like to think 4 won't apply in this case, but that has yet to be seen. - Peter |
|
From: Matthew B. <mat...@co...> - 2005-07-15 12:47:56
|
Alistair Young wrote: > So what about, for 2.8: > > Template classes that query User.getLanguage() at run time. > > Localiser chain with the preferred language delegating to the default > language for missing strings? > > This just isn't possible for 2.6. Maybe it might have been if we'd had > this debate at the start of the process ;) Sounds very sensible. Has anyone got a few hours they can donate to me, I'm running a little short ;-) -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Alexis O'C. <ale...@co...> - 2005-07-15 12:47:44
|
Alistair Young wrote: > So what about, for 2.8: > > Template classes that query User.getLanguage() at run time. > > Localiser chain with the preferred language delegating to the default > language for missing strings? Yes on both scores for me! > > This just isn't possible for 2.6. Maybe it might have been if we'd had > this debate at the start of the process ;) Yes, I understand. I kind of had reservations at the back of my mind when it was being discussed, but's it's only when you start doing something in anger that all the issues crystallise in one's (my) mind ;-). Alexis |
|
From: Alistair Y. <ali...@sm...> - 2005-07-15 11:33:38
|
> string.properties but you've just binned strings.properties! only joking, I know what you m= ean. > This is how ResourseBundle works: really? well I never ;) Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Alistair Young wrote: >>>Isn't it better to have some parts of the application >>>localised than none? >> >> agreed - do you want this for 2.6? could probably delegate missing >> strings >> to the default language. > > Should we have > > string.properties - Contains the english language strings > string_fr.properties - Contains the french language properties. > > This way if someone selects english as the language it just uses the > defaults (which happen to be english). > > Otherwise if someone selects french then the _fr files are used but we > fall back to english if a property doesn't exist. > > If someone selects russian then they still see the english? > > This is how ResourseBundle works: > > http://java.sun.com/j2se/1.4.2/docs/api/java/util/ResourceBundle.html > > -- > +--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: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Alistair Y. <ali...@sm...> - 2005-07-15 11:30:18
|
So what about, for 2.8: Template classes that query User.getLanguage() at run time. Localiser chain with the preferred language delegating to the default language for missing strings? This just isn't possible for 2.6. Maybe it might have been if we'd had this debate at the start of the process ;) > You're not still using Tomcat 4 no no! I'm just forever thinking of optimisations. A hangover from my real-time days. Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland >> >> What Alexis would prefer is English and Russian users get >> template_thingy.class which contains logic to query the User object, g= et >> their language preference and load the appropriate strings. >> >> I can't see how that improves on the current design. Every page access >> would then have the extra overhead of all that User centric logic. >> >> Alistair >> > > Exactly! > > I think the performance issue is a misnomer. Sure we'd have to profile > it, but in the general scheme of things we find that at Oxford Bodingto= n > spends relatively very little time in the servlet container and lots of > time in the database. > > You're not still using Tomcat 4 instead of 5 are you? The performance > increase is considerable ;-). > > Alexis > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Alexis O'C. <ale...@co...> - 2005-07-15 11:26:24
|
Alistair Young wrote: >>If not then we >>are changing Bodington so that it is no longer possible to deploy on a >>machine without a JDK. > > yep. that's bod though. What other web application *compiles* it's own > pages? Don't you need a JDK anyway? What happens when XmlTemplate decides > the class file is out of date and tries to recompile the template? > > By allowing the absence of the JDK you're telling users "you may never > customise your templates". > > Alistair > > Funnily enough I agree with Alistair on this one ;-). Requiring a JDK is reasonable enough for these very reasons. It would be cool if we could get the Eclipse JDT compiler of Tomcat 5.5 to compile Bodington templates. It was the way my thinking was going with the CompilerFacade to cater for this (and jikes) but I backed out (until such time) such wrappers for these compilers were fully implemented. (In the short-term, just wrapping javac with a facade seemed like obfuscatory overkill!). Alexis |
|
From: Matthew B. <mat...@co...> - 2005-07-15 11:24:38
|
Alistair Young wrote: >>Isn't it better to have some parts of the application >>localised than none? > > agreed - do you want this for 2.6? could probably delegate missing strings > to the default language. Should we have string.properties - Contains the english language strings string_fr.properties - Contains the french language properties. This way if someone selects english as the language it just uses the defaults (which happen to be english). Otherwise if someone selects french then the _fr files are used but we fall back to english if a property doesn't exist. If someone selects russian then they still see the english? This is how ResourseBundle works: http://java.sun.com/j2se/1.4.2/docs/api/java/util/ResourceBundle.html -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Alexis O'C. <ale...@co...> - 2005-07-15 11:20:13
|
> > What Alexis would prefer is English and Russian users get > template_thingy.class which contains logic to query the User object, get > their language preference and load the appropriate strings. > > I can't see how that improves on the current design. Every page access > would then have the extra overhead of all that User centric logic. > > Alistair > Exactly! I think the performance issue is a misnomer. Sure we'd have to profile it, but in the general scheme of things we find that at Oxford Bodington spends relatively very little time in the servlet container and lots of time in the database. You're not still using Tomcat 4 instead of 5 are you? The performance increase is considerable ;-). Alexis |
|
From: Alistair Y. <ali...@sm...> - 2005-07-15 11:18:29
|
> If not then we > are changing Bodington so that it is no longer possible to deploy on a > machine without a JDK. yep. that's bod though. What other web application *compiles* it's own pages? Don't you need a JDK anyway? What happens when XmlTemplate decides the class file is out of date and tries to recompile the template? By allowing the absence of the JDK you're telling users "you may never customise your templates". Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Peter Crowther wrote: >>>From: bod...@li... >>>I think the fact that templates for different languages get >>>compiled is >>>inherently duff. Conceptually, there should be one single >>>generic set of >>>templates that dynamically pull in the resource bundles at run-time. >> >> >> I thought that when I first saw the design, but have since moved to th= e >> opposite point of view. One of the reasons for compiling templates in >> the first place is efficiency, and we have a *lot* of templaces given >> the number of frames and framesets in Bod. I've come round to the vie= w >> that it probably makes sense* to remove the calls to the property >> retrieval functions from the execution path of each page display. > > So are we going to distribute Bodington precompiled for all the > available languages? If so the size of the distribution will become hug= e > (compiled versions of english are 5.5MB on my machine). If not then we > are changing Bodington so that it is no longer possible to deploy on a > machine without a JDK. > > -- > +--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: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Alistair Y. <ali...@sm...> - 2005-07-15 11:13:05
|
> Isn't it better to have some parts of the application > localised than none? agreed - do you want this for 2.6? could probably delegate missing string= s to the default language. Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Alistair Young wrote: > >> There's nothing stopping someone changing the language to "ru" and >> getting >> an unusable bod. > > Shouldn't Bod just display the default strings (english?) if the > translated version of some resource doesn't exist. > > Otherwise we get to the situation that someone does a translation to > french for example. Then we add some new tools (eg my ACL tool) which > uses i18n. > > Now we have the situation where unless someone translates the ACL tool > french users won't be able to upgrade as they will no longer be able to > select french as the language. > > We need to have the idea of a default language that the localiser falls > back to if it can't find the localised version of that string. This way > we don't have to delay software releases so that all the translators ca= n > do thier work. Isn't it better to have some parts of the application > localised than none? > > > -- > +--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: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Alistair Y. <ali...@sm...> - 2005-07-15 11:09:04
|
> I thought that when I first saw the design, but have since moved to the > opposite point of view. you got the cheque then ;) We had a debate ages ago where either the language specific template classes had the strings from the Localiser hard coded in them, or they ha= d calls to the Localiser instead. It was decided that the dynamic method would be best as you could then update the translations without having to recompile the templates. It als= o meant I didn't have to do more code to tie properties files into the timestamp checking process of the template compiler. I really can't see what the problem is. XmlTemplate is asked to return a template instance, which is what it's always done. If the template class doesn't exist or it's out of date, XmlTemplate compiles it. Again, it's always done that. All that happens now is it adds a language variable int= o the process. So if you're a user with their language preference as "English" you get template_thingy_en.class. If you're a user with "Russian" you get template_thingy_ru.class What Alexis would prefer is English and Russian users get template_thingy.class which contains logic to query the User object, get their language preference and load the appropriate strings. I can't see how that improves on the current design. Every page access would then have the extra overhead of all that User centric logic. Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland >> From: bod...@li... >> I think the fact that templates for different languages get >> compiled is >> inherently duff. Conceptually, there should be one single >> generic set of >> templates that dynamically pull in the resource bundles at run-time. > > I thought that when I first saw the design, but have since moved to the > opposite point of view. One of the reasons for compiling templates in > the first place is efficiency, and we have a *lot* of templaces given > the number of frames and framesets in Bod. I've come round to the view > that it probably makes sense* to remove the calls to the property > retrieval functions from the execution path of each page display. > > - Peter > > * This year. Moore's Law continues its apparently inexorable > progress... > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Matthew B. <mat...@co...> - 2005-07-15 11:08:23
|
Peter Crowther wrote: >>From: bod...@li... >>I think the fact that templates for different languages get >>compiled is >>inherently duff. Conceptually, there should be one single >>generic set of >>templates that dynamically pull in the resource bundles at run-time. > > > I thought that when I first saw the design, but have since moved to the > opposite point of view. One of the reasons for compiling templates in > the first place is efficiency, and we have a *lot* of templaces given > the number of frames and framesets in Bod. I've come round to the view > that it probably makes sense* to remove the calls to the property > retrieval functions from the execution path of each page display. So are we going to distribute Bodington precompiled for all the available languages? If so the size of the distribution will become huge (compiled versions of english are 5.5MB on my machine). If not then we are changing Bodington so that it is no longer possible to deploy on a machine without a JDK. -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Matthew B. <mat...@co...> - 2005-07-15 11:06:08
|
Alistair Young wrote: > There's nothing stopping someone changing the language to "ru" and getting > an unusable bod. Shouldn't Bod just display the default strings (english?) if the translated version of some resource doesn't exist. Otherwise we get to the situation that someone does a translation to french for example. Then we add some new tools (eg my ACL tool) which uses i18n. Now we have the situation where unless someone translates the ACL tool french users won't be able to upgrade as they will no longer be able to select french as the language. We need to have the idea of a default language that the localiser falls back to if it can't find the localised version of that string. This way we don't have to delay software releases so that all the translators can do thier work. Isn't it better to have some parts of the application localised than none? -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Alistair Y. <ali...@sm...> - 2005-07-15 10:58:20
|
> there should be one single generic set of > templates that dynamically pull in the resource bundles at run-time there's only one set of templates for all languages and compiling them at build time tells you they're valid xml etc. The template *class* is language specific in that it has a pointer to a language specific Localiser, to get it's strings. Bod isn't ever in "one" language, it can be in hundreds at the same time. You can have French, Italian, Russian, Gaelic users all using the same bod and all seeing the templates in their own language. At the time there were two options to do this: 1 - have a language specific resource url - wouldn't work for tracking etc. (you haven't viewed your document, yes I have, I viewed the Russian one) 2 - have a language specific template class and have the template compile= r return that. Now that I know more about the gloabl soup of bod I could perhaps do away with language specific template classes and write logic into the template class to get the current user, get their language and grab an instance of a Localiser for that language. It then comes down to performance. Either XmlTemplate "redirects" to the language specifc template class, as it does just now, or the template class itself works out which language it should work in. I'd be interested to hear your opinion on all this Alexis as you know a lot more about the bod guts than me (thank goodness!) Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Alistair Young wrote: >> Thanks Alexis. >> >> I'm not sure what you mean by language agnostic. Bod is now an i18n >> application so the template compiler must be language aware. By that I >> mean the compiler has to know which language variant to build. >> > > Ok, it's not *really* that much of a problem, but you've drawn me, so I > shall respond ;-). > > I think the fact that templates for different languages get compiled is > inherently duff. Conceptually, there should be one single generic set o= f > templates that dynamically pull in the resource bundles at run-time. > When you compile the templates stand-alone, you're really just wanting > to see that their valid (i.e. are valid XML and can compile into java). > The available languages should be neither here nor there. The current > situtation implies that you need to seperately compile the templates fo= r > all the languages that you know about. > > As I say, no need for anyone to get upset ;-). > > Alexis > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Peter C. <Pet...@me...> - 2005-07-15 10:49:32
|
> From: bod...@li...=20 > I think the fact that templates for different languages get=20 > compiled is=20 > inherently duff. Conceptually, there should be one single=20 > generic set of=20 > templates that dynamically pull in the resource bundles at run-time. I thought that when I first saw the design, but have since moved to the opposite point of view. One of the reasons for compiling templates in the first place is efficiency, and we have a *lot* of templaces given the number of frames and framesets in Bod. I've come round to the view that it probably makes sense* to remove the calls to the property retrieval functions from the execution path of each page display. - Peter * This year. Moore's Law continues its apparently inexorable progress... |
|
From: Alexis O'C. <ale...@co...> - 2005-07-15 10:41:02
|
Alistair Young wrote: > Thanks Alexis. > > I'm not sure what you mean by language agnostic. Bod is now an i18n > application so the template compiler must be language aware. By that I > mean the compiler has to know which language variant to build. > Ok, it's not *really* that much of a problem, but you've drawn me, so I shall respond ;-). I think the fact that templates for different languages get compiled is inherently duff. Conceptually, there should be one single generic set of templates that dynamically pull in the resource bundles at run-time. When you compile the templates stand-alone, you're really just wanting to see that their valid (i.e. are valid XML and can compile into java). The available languages should be neither here nor there. The current situtation implies that you need to seperately compile the templates for all the languages that you know about. As I say, no need for anyone to get upset ;-). Alexis |
|
From: Alistair Y. <ali...@sm...> - 2005-07-15 10:20:29
|
Thanks Alexis. I'm not sure what you mean by language agnostic. Bod is now an i18n application so the template compiler must be language aware. By that I mean the compiler has to know which language variant to build. The old style of template class naming is gone: template_useroptions.class -> template_useroptions_en.class so the template compiler has to know the language. As the default is "en" in build.properties 99% of people won't even know about languages or need to change anything. It's the 1% of deployers who want it in another language who will have to modify the default. Just as long as they have the resource files to back it up. There's nothing stopping someone changing the language to "ru" and gettin= g an unusable bod. A way to stop that happening would be for the build to check res/generic/languages_en.properties - this lists the available languages for that version of bod. If what they choose in build.properties isn't in res/generic/languages_en.properties then the build should abort and slap them on the back of the head :) Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Alistair Young wrote: >> >> "en" is a hard code though. Alexis, what's your opinion on adding a >> language option to build.properties and setting it to "en" by default= . >> If you want to compile bod in another language you change the languag= e >> setting in build.properties? >> >> XmlTemplate doesn't need patched, just >> TemplateBuilderTask.iterateTemplates() >> >> Alistair >> > > OK, this is now in CVS. > > What I did: > > TemplateBuilderTask.java: added 'language' property. This calls > XmlTemplate.setLanguage(String). > > build.xml: set the language attribute of the template-compiler task via > the property 'build.templates.language'. > > sample.build.properties: added a placeholder for the property > 'build.templates.language'. > > The defaults in the files above for 'language' are 'en'. > > > Alexis > > P.S. Prehaps we could make template compilation language-agnostic for > v2.8+ ;-). > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Alexis O'C. <ale...@co...> - 2005-07-15 10:01:04
|
Alistair Young wrote: > > "en" is a hard code though. Alexis, what's your opinion on adding a > language option to build.properties and setting it to "en" by default. > If you want to compile bod in another language you change the language > setting in build.properties? > > XmlTemplate doesn't need patched, just > TemplateBuilderTask.iterateTemplates() > > Alistair > OK, this is now in CVS. What I did: TemplateBuilderTask.java: added 'language' property. This calls XmlTemplate.setLanguage(String). build.xml: set the language attribute of the template-compiler task via the property 'build.templates.language'. sample.build.properties: added a placeholder for the property 'build.templates.language'. The defaults in the files above for 'language' are 'en'. Alexis P.S. Prehaps we could make template compilation language-agnostic for v2.8+ ;-). |
|
From: Colin T. <col...@co...> - 2005-07-14 16:34:50
|
...but don't get too excited, it's incredibly slow! http://bodington.sourceforge.net/phpwiki-1.3.11/ Just a test installation now, so don't put anything worthwhile up, it'll probably disappear! -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
|
From: Peter C. <Pet...@me...> - 2005-07-14 14:48:09
|
> From: Brian Peter Clark [mailto:bm...@bm...]=20 > And, like God, Bodington sometimes works=20 > in mysterious ways...) However, unlike any gods, there is little dispute that Bodington exists and that it is none of omnipotent, omniscient, eternal... and certainly not omnibenevolent. - Peter |
|
From: Brian P. C. <bm...@bm...> - 2005-07-14 14:31:51
|
> Brian Peter Clark wrote: > > Do you want a standard format for <h2></h2> etc? > > > > For example: > > > > h2.1 > > h2.2 > > > > headingtwo.1 > > headingtwo.2 > > > > heading_two.1 > > heading_two.2 > > > > page.h2.1 > > page.h2.2 > > > > page.headertwo.1 > > > > para.h2.1 > > > > Regards, > > > > Brian > > > > Thank you - most sensible. I just asked because para.x with a p might just have had some relationship with <p> (in a non- semanticish sense). (And, like God, Bodington sometimes works in mysterious ways...) Brian > > You shouldn't be adopting a markup-oriented approach, but a semantic / > content oriented one. Seperation of presentation from content is a basic > principle. If the template currently says: > > <h2>Messaging Room</h2> > > You should put something like ... > > messaging.room=Messaging Room > > ... in the (English) properties file, and leave behind ... > > <h2><localise id="messaging.room" /></h2> > > ... in the template. Let the template handle the markup / presentation > concerns. > > > Alexis > > > ------------------------------------------------------- > 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 > |
|
From: Alexis O'C. <ale...@co...> - 2005-07-14 11:46:47
|
Alistair Young wrote: > yes, that's what I was afraid of, localising enums. The nested literals > were there from day 1 so I just left them as is. > >> Shall I commit all my style_default/default changes back now!!?!! > > yes please > > Alistair > No worries. The above is now done. I shall now proceed with the Oxford assigned messaging room templates in a similar fashion! Alexis |
19 messages has been excluded from this view by a project administrator.
