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: Jon M. <jo...@te...> - 2006-07-28 05:55:35
|
v shrt msgs get thru luk @ dis; http://gauss.ffii.org/PatentView/EP1192615 |
|
From: Jon M. <jo...@te...> - 2006-07-28 04:55:12
|
Another productive late night session! What about the last run of testing that I promised to do? I'm ready to do it now so perhaps people should hold off committing a torrent of weird and wonderful new functionality for a day or two. What do you think? Jon |
|
From: Jon M. <jo...@te...> - 2006-07-27 19:39:21
|
Following on from previous posts.... Michael and I have been having nasty problems with LDAP. The authenticator discussed earlier on the list was deployed last Friday and the log is showing randomly occurring exceptions ever since. A connection, bind and search are carried out O.K. but almost randomly the next() method called on the search results throws an exception which indicates an internal error on the LDAP server but provides a message suggesting that a bind is required. Although nearly random there are some searches for particular users that always fail. I wrote a little application based on the authenticator which carries out the same operations in a loop. Although unable to reproduce the same exception, other exceptions were thrown randomly. The nature of the exceptions strongly suggests programming errors in the Novell/OpenLDAP API (which perhaps only occur when connecting to Active Directory). I say this because the exceptions are not thrown in the main program thread but within LDAP API worker threads and refer to illegal access to semaphores. It looks like a fundamental problem handshaking within the LDAP protocol. Anyway, the point of all this explanation is that it leads me to the conclusion that a switch to JNDI and to the Sun LDAP provider is essential. I think JNDI is far more likely to be well debugged against many different LDAP servers and more importantly if anyone has problems with the Sun provider in connection with their own little used LDAP server they may be able to plug in a specific provider for it. Any thoughts on this? Jon P.S. we can't be 100% certain that there isn't a problem at the Active Directory end of the LDAP but another web service at Leeds, based on uPortal is successfully authenticating to it via JNDI. |
|
From: Jon M. <jo...@te...> - 2006-07-27 18:35:28
|
v shrt msgs get thru - luk @ dis; gauss.ffii.org/PatentView/EP1192615 |
|
From: Jon M. <jo...@te...> - 2006-07-27 18:28:52
|
Can I get a message through? |
|
From: Alexis O'C. <ale...@ou...> - 2006-07-27 11:02:49
|
Sean Mehan wrote: > Boders, > > abox$ cvs -z3 - > d:ext:you...@bo...:/cvsroot/ > bodington co -P -r bodington_2_8_0 bodington > Sterling work otherwise Sean, but in keeping with previous branches this should have been called bodington_2_8. Matthew informs that it might be possible to rename branches ;-). Alexis |
|
From: Jon M. <jo...@te...> - 2006-07-27 10:58:54
|
Just seeing if I can get a message through now... |
|
From: Sean M. <se...@sm...> - 2006-07-26 21:13:21
|
Boders,
abox$ cvs -z3 -
d:ext:you...@bo...:/cvsroot/
bodington co -P -r bodington_2_8_0 bodington
will get you the latest production branch, e.g.:
iolair:/Volumes/Home/Users/sean/duh/bodington sean$ cvs log LICENSE
sea...@bo...'s password:
RCS file: /cvsroot/bodington/bodington/LICENSE,v
Working file: LICENSE
head: 1.2
branch:
locks: strict
access list:
symbolic names:
bodington_2_8_0: 1.2.0.2
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
----------------------------
revision 1.2
date: 2006/07/26 19:49:18; author: seanskye; state: Exp; lines:
+175 -48
Update of license to Apache 2.0
----------------------------
revision 1.1
date: 2006/07/06 08:52:59; author: ozzard; state: Exp;
Make the license explicit at the root of the project, rather than
merely included in each source file.
========================================================================
=====
which is the other big bit of news...
A package release can be made tomorrow. I need a beer or three.
Finally, I have tagged HEAD:
File: build.xml Status: Up-to-date
Working revision: 1.54
Repository revision: 1.54 /cvsroot/bodington/bodington/
build.xml,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
bodington_2_9_0 (revision: 1.54)
bodington_2_8_0 (branch: 1.54.2)
bodington_boddix_2_6 (branch: 1.46.4)
bodington_2_6_0 (revision: 1.46)
bodington_uhi (branch: 1.47.2)
bodington_2_6 (branch: 1.46.2)
bodington_2_5_5 (revision: 1.46)
bodington_2_5_4 (revision: 1.46)
bodington_2_5_3 (revision: 1.40)
bodington_2_5_2_uhi (branch: 1.25.2)
bodington_2_5_2 (revision: 1.25)
bodington_2_4_3 (revision: 1.3.2.4)
bodington_2_5_1 (revision: 1.16)
bodington_2_4_2 (revision: 1.3.2.2)
bodington_2_4_1 (revision: 1.3.2.1)
bodington_2_1_1_rc4_SPWS (branch: 1.3.6)
bodington_2_5_0 (revision: 1.3)
Head (branch: 1.3.4)
bodington_2_4_0 (revision: 1.3)
bodington_2_4 (branch: 1.3.2)
bodington_2_3_1 (revision: 1.3)
so lets get committing! how about jsp support!-)
xxooxx
s
|
|
From: Jon M. <jo...@te...> - 2006-07-25 09:26:52
|
Alistair Young wrote: > Last time I took down HEAD on sf, maybe 3 weeks ago, it didn't work > in Safari. You couldn't logout as the thin bit at the top was too thin. > > Alistair > Yes, that's the problem that Colin was talking about and I devised a solution and posted a demo URL to this list with that proposed change demonstrated and then I posted lots of screen shots of various versions of Safari loading that URL. It is that which I committed so it ought to be fixed. Jon |
|
From: Alistair Y. <ali...@sm...> - 2006-07-25 07:53:27
|
Last time I took down HEAD on sf, maybe 3 weeks ago, it didn't work in Safari. You couldn't logout as the thin bit at the top was too thin. Alistair On 25 Jul 2006, at 08:51, Colin Tatham wrote: > Jon Maber wrote: >> O.K. I've committed the version that corresponds to the many screen >> shots I showed you some weeks ago. > > Great! Thanks Jon, I'll have a look. > > > -- > ____________________________________ > Colin Tatham > VLE Team > Oxford University Computing Services > > http://www.oucs.ox.ac.uk/ltg/vle/ > http://bodington.org > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Colin T. <col...@ou...> - 2006-07-25 07:52:00
|
Jon Maber wrote: > O.K. I've committed the version that corresponds to the many screen > shots I showed you some weeks ago. Great! Thanks Jon, I'll have a look. -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
|
From: Jon M. <jo...@te...> - 2006-07-24 21:50:44
|
Jon Maber wrote: > > Freeze away.... > Is the plan to stop adding anything new, let me spend my last day of testing anything fixed since my last round of testing, fix the one or two bugs caused by the bug fixes and then stick a tag in the CVS? If so yippee! I can finally send in an invoice for the completed testing work ;-} Jon |
|
From: Jon M. <jo...@te...> - 2006-07-24 19:26:31
|
Jon Maber wrote: >> ...except that the current code for displaying the top frame looks really awful, esp in IE. I think >> Jon had a later version (we saw screenshots) but AFAIK that hasn't been committed yet. I would vote >> for rolling those changes back if we can't get the latest version in in time. >> >> Colin >> >> > Sorry, I've been tied up a bit with LDAP stuff and not paying much > attention to the list. Assuming no one objects I'll commit changes that > match the last demonstration layout that I posted to this list earlier > in the month. Otherwise it would be wise as Colin says to roll back > since my first attempt at the fix was not good across all browsers. > O.K. I've committed the version that corresponds to the many screen shots I showed you some weeks ago. Freeze away.... Jon |
|
From: Jon M. <jo...@te...> - 2006-07-24 16:20:28
|
> > ...except that the current code for displaying the top frame looks really awful, esp in IE. I think > Jon had a later version (we saw screenshots) but AFAIK that hasn't been committed yet. I would vote > for rolling those changes back if we can't get the latest version in in time. > > Colin > Sorry, I've been tied up a bit with LDAP stuff and not paying much attention to the list. Assuming no one objects I'll commit changes that match the last demonstration layout that I posted to this list earlier in the month. Otherwise it would be wise as Colin says to roll back since my first attempt at the fix was not good across all browsers. Jon |
|
From: Colin T. <col...@ou...> - 2006-07-24 13:58:16
|
Colin Tatham wrote: > Sean Mehan wrote: >>In anticipation of a 2.8 release, is it possible to commit last bits >>and bobs to head by Tuesday, 25/7, 15:00. I will then make a release >>of 2.8 with a branch on Wed. >> >>Is this agreeable? > Yup, fine with us. ...except that the current code for displaying the top frame looks really awful, esp in IE. I think Jon had a later version (we saw screenshots) but AFAIK that hasn't been committed yet. I would vote for rolling those changes back if we can't get the latest version in in time. Colin -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
|
From: Alistair Y. <ali...@sm...> - 2006-07-24 11:17:12
|
> Facility number and Object ID ok, Object ID is Resource ID and is hard coded in Resource.java? Where does Facility number come from? I heard that that's hard coded in the Resource but I can't find any examples. > I think we're at a point where it could be maintained with a little > effort, and that will make > future code more easily understood then that's a ++ from me once we've sorted the IDs, then it's working out what all those methods do, resourceMenuItem, ooh the pain! oh for some javadocs! but there will be once I get the HelloWorldResource working and documented. Alistair On 24 Jul 2006, at 12:06, Colin Tatham wrote: > > I think we need to make a decision before releasing 2.8 whether > we're going to keep the mapping > between the Facility number and Object ID (to use Matthew's > terminology). > I think we're at a point where it could be maintained with a little > effort, and that will make > future code more easily understood (downside is that we have to > maintain the mapping in future tools.) > > The new ones in my Bod installation are: > > type | table_name > ------+----------------------------- > 56 | quick_links > 59 | log_book_section_hierarchy > 60 | log_book_question_hierarchy > 105 | web_auth_user > 106 | sp_auth_user > 300 | peer_mark_papers > 301 | peer_mark_questions > 302 | peer_mark_responses > 303 | peer_mark_results > > I'd say that the only one that needs changing is > > 106 | sp_auth_user > as that's in the Oxford range. > > Arguably quick_links should be in either Oxford or UHI's range too... > > > Would changing sp_auth_user cause anyone any headaches? > > Colin > > > > > Alistair Young wrote: >>> HelloWorld facility should take 203 >> >> concise answer, thanks Alexis! >> >> Alistair >> >> >> On 24 Jul 2006, at 10:48, Alexis O'Connor wrote: >> >> >>> Alistair Young wrote: >>> >>>>>> 300-303 are used for the PeerMarker resources >>>> >>>> not according to our version of head Aggie! >>>> RESOURCE_PEERMARKER = 300 >>>> or am I looking in the wrong place again? >>>> >>>> >>>>> Facility and Resource IDs are completely unrelated >>>> >>>> Facility id? haven't seen any of them! >>>> >>>> HelloWorldResource.sql: >>>> INSERT INTO classes (type, super_type, db_name, table_name, >>>> java_class) >>>> VALUES(28, 10, null, null, >>>> 'org.bodington.server.resources.HelloWorldResource') >>>> GO >>>> >>>> is "28" the Resource ID or the Facility ID then? I presume it's the >>>> resource id. >>>> >>>> so what's the advice if any? is there any way to avoid collisions? >>>> e.g. I've just chosen 301 but PeerMarker uses that although it's >>>> not >>>> defined anywhere. >>>> >>>> Alistair >>>> >>>> >>> >>> My take on the situtation is that if UHI have got facility numbers >>> 201 - 300 and Aggie has >>> 301 - 400, then: >>> >>> Peermarker should probably be bumped upto 301 (from 300). >>> Alistairs HelloWorld facility should take 203, which is the next >>> available number after >>> 202 (Announcements) within the UHI range on bodington HEAD. >>> >>> Alexis > > -- > ____________________________________ > Colin Tatham > VLE Team > Oxford University Computing Services > > http://www.oucs.ox.ac.uk/ltg/vle/ > http://bodington.org > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Colin T. <col...@ou...> - 2006-07-24 11:06:39
|
I think we need to make a decision before releasing 2.8 whether we're going to keep the mapping
between the Facility number and Object ID (to use Matthew's terminology).
I think we're at a point where it could be maintained with a little effort, and that will make
future code more easily understood (downside is that we have to maintain the mapping in future tools.)
The new ones in my Bod installation are:
type | table_name
------+-----------------------------
56 | quick_links
59 | log_book_section_hierarchy
60 | log_book_question_hierarchy
105 | web_auth_user
106 | sp_auth_user
300 | peer_mark_papers
301 | peer_mark_questions
302 | peer_mark_responses
303 | peer_mark_results
I'd say that the only one that needs changing is
106 | sp_auth_user
as that's in the Oxford range.
Arguably quick_links should be in either Oxford or UHI's range too...
Would changing sp_auth_user cause anyone any headaches?
Colin
Alistair Young wrote:
>>HelloWorld facility should take 203
>
> concise answer, thanks Alexis!
>
> Alistair
>
>
> On 24 Jul 2006, at 10:48, Alexis O'Connor wrote:
>
>
>>Alistair Young wrote:
>>
>>>>>300-303 are used for the PeerMarker resources
>>>
>>>not according to our version of head Aggie!
>>>RESOURCE_PEERMARKER = 300
>>>or am I looking in the wrong place again?
>>>
>>>
>>>>Facility and Resource IDs are completely unrelated
>>>
>>>Facility id? haven't seen any of them!
>>>
>>>HelloWorldResource.sql:
>>>INSERT INTO classes (type, super_type, db_name, table_name,
>>>java_class)
>>> VALUES(28, 10, null, null,
>>>'org.bodington.server.resources.HelloWorldResource')
>>>GO
>>>
>>>is "28" the Resource ID or the Facility ID then? I presume it's the
>>>resource id.
>>>
>>>so what's the advice if any? is there any way to avoid collisions?
>>>e.g. I've just chosen 301 but PeerMarker uses that although it's not
>>>defined anywhere.
>>>
>>>Alistair
>>>
>>>
>>
>>My take on the situtation is that if UHI have got facility numbers
>>201 - 300 and Aggie has
>>301 - 400, then:
>>
>>Peermarker should probably be bumped upto 301 (from 300).
>>Alistairs HelloWorld facility should take 203, which is the next
>>available number after
>>202 (Announcements) within the UHI range on bodington HEAD.
>>
>>Alexis
--
____________________________________
Colin Tatham
VLE Team
Oxford University Computing Services
http://www.oucs.ox.ac.uk/ltg/vle/
http://bodington.org
|
|
From: Andrew B. <a.g...@le...> - 2006-07-24 10:54:15
|
Fine. Aggie -----Original Message----- From: bod...@li... [mailto:bod...@li...] On Behalf Of Sean Mehan Sent: 21 July 2006 16:42 To: Bodington developers Subject: [Bodington-developers] Freeze of head for Tuesday Bodders, In anticipation of a 2.8 release, is it possible to commit last bits and bobs to head by Tuesday, 25/7, 15:00. I will then make a release of 2.8 with a branch on Wed. Is this agreeable? -s ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bodington-developers mailing list Bod...@li... https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Matthew B. <mat...@ou...> - 2006-07-24 09:58:51
|
Alistair Young wrote: >>> 300-303 are used for the PeerMarker resources > not according to our version of head Aggie! > RESOURCE_PEERMARKER = 300 > or am I looking in the wrong place again? The constants in Resource can be completly different to the other numbers. It depends how they are used outside the Resource class. >> Facility and Resource IDs are completely unrelated > Facility id? haven't seen any of them! > > HelloWorldResource.sql: > INSERT INTO classes (type, super_type, db_name, table_name, java_class) > VALUES(28, 10, null, null, > 'org.bodington.server.resources.HelloWorldResource') > GO > > is "28" the Resource ID or the Facility ID then? I presume it's the > resource id. Yep that is the resource ID as I described in my previous email, but that is a bad term (not all database objects map to a resource). Maybe it should just be Object ID. > > so what's the advice if any? is there any way to avoid collisions? The right way to solve this is to have the mapping determined at deploy time rather than development time. > e.g. I've just chosen 301 but PeerMarker uses that although it's not > defined anywhere. Ok I'll at what I think the state is at the moment: Facility No. - This is numeric number of a facility instance. This is stored against a resource (getHttpFacilityNo()) so that we know which facility to use to display it. This is in the bodington-default.properties file with lines such as: buildingservlet.facility.alias=25,org.bodington.servlet.facilities.AliasFacility with 25 being the Facility No. Object ID. - This is the number that the database layer uses for mapping rows to Java Objects. It is hard coded in the .sql files and ends up in the classes, fields and objects tables. It shouldn't be used outside the database layer(?). Resource Constants. - These are the constants defined in Resource that allow you to check what type of resource you are dealing with. The reason that they exist is because we can't do instanceof checks because lots of resources are different only by which facility handles them. Really these are redundant as you can gain this information from the facility information. The only reason to have them is if we intent to have the same resource handle by different facilities in the same installation of Bodington. I believe that there needs to be no correlation between these numbers but could be wrong. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Alistair Y. <ali...@sm...> - 2006-07-24 09:55:51
|
> HelloWorld facility should take 203 concise answer, thanks Alexis! Alistair On 24 Jul 2006, at 10:48, Alexis O'Connor wrote: > Alistair Young wrote: >>>> 300-303 are used for the PeerMarker resources >> not according to our version of head Aggie! >> RESOURCE_PEERMARKER = 300 >> or am I looking in the wrong place again? >> >>> Facility and Resource IDs are completely unrelated >> Facility id? haven't seen any of them! >> >> HelloWorldResource.sql: >> INSERT INTO classes (type, super_type, db_name, table_name, >> java_class) >> VALUES(28, 10, null, null, >> 'org.bodington.server.resources.HelloWorldResource') >> GO >> >> is "28" the Resource ID or the Facility ID then? I presume it's the >> resource id. >> >> so what's the advice if any? is there any way to avoid collisions? >> e.g. I've just chosen 301 but PeerMarker uses that although it's not >> defined anywhere. >> >> Alistair >> >> > > My take on the situtation is that if UHI have got facility numbers > 201 - 300 and Aggie has > 301 - 400, then: > > Peermarker should probably be bumped upto 301 (from 300). > Alistairs HelloWorld facility should take 203, which is the next > available number after > 202 (Announcements) within the UHI range on bodington HEAD. > > Alexis > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Colin T. <col...@ou...> - 2006-07-24 09:53:28
|
Sean Mehan wrote: > Bodders, > > In anticipation of a 2.8 release, is it possible to commit last bits > and bobs to head by Tuesday, 25/7, 15:00. I will then make a release > of 2.8 with a branch on Wed. > > Is this agreeable? Yup, fine with us. -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
|
From: Alexis O'C. <ale...@ou...> - 2006-07-24 09:47:33
|
Alistair Young wrote: >>> 300-303 are used for the PeerMarker resources > not according to our version of head Aggie! > RESOURCE_PEERMARKER = 300 > or am I looking in the wrong place again? > >> Facility and Resource IDs are completely unrelated > Facility id? haven't seen any of them! > > HelloWorldResource.sql: > INSERT INTO classes (type, super_type, db_name, table_name, java_class) > VALUES(28, 10, null, null, > 'org.bodington.server.resources.HelloWorldResource') > GO > > is "28" the Resource ID or the Facility ID then? I presume it's the > resource id. > > so what's the advice if any? is there any way to avoid collisions? > e.g. I've just chosen 301 but PeerMarker uses that although it's not > defined anywhere. > > Alistair > > My take on the situtation is that if UHI have got facility numbers 201 - 300 and Aggie has 301 - 400, then: Peermarker should probably be bumped upto 301 (from 300). Alistairs HelloWorld facility should take 203, which is the next available number after 202 (Announcements) within the UHI range on bodington HEAD. Alexis |
|
From: Alistair Y. <ali...@sm...> - 2006-07-24 09:39:05
|
>> 300-303 are used for the PeerMarker resources not according to our version of head Aggie! RESOURCE_PEERMARKER = 300 or am I looking in the wrong place again? > Facility and Resource IDs are completely unrelated Facility id? haven't seen any of them! HelloWorldResource.sql: INSERT INTO classes (type, super_type, db_name, table_name, java_class) VALUES(28, 10, null, null, 'org.bodington.server.resources.HelloWorldResource') GO is "28" the Resource ID or the Facility ID then? I presume it's the resource id. so what's the advice if any? is there any way to avoid collisions? e.g. I've just chosen 301 but PeerMarker uses that although it's not defined anywhere. Alistair On 24 Jul 2006, at 10:23, Matthew Buckett wrote: > Andrew Booth wrote: >> 300-303 are used for the PeerMarker resources. > > This has come up before. > > http://sourceforge.net/mailarchive/message.php?msg_id=12528832 > > Facility and Resource IDs are completely unrelated. The resource ID is > used by the database layer to work out how to map a set of rows in the > database to a Java object and the facility No is used to work out > how to > display a resource over the web. A java object is not always a > resource. > > There has been a convention that they matched but there is no > requirement. There will always be more resource IDs than Facility IDs > because some objects don't have a facility (events, users, etc). > > -- > -- Matthew Buckett, VLE Developer > -- Learning Technologies Group, Oxford University Computing Services > -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Matthew B. <mat...@ou...> - 2006-07-24 09:23:05
|
Andrew Booth wrote: > 300-303 are used for the PeerMarker resources. This has come up before. http://sourceforge.net/mailarchive/message.php?msg_id=12528832 Facility and Resource IDs are completely unrelated. The resource ID is used by the database layer to work out how to map a set of rows in the database to a Java object and the facility No is used to work out how to display a resource over the web. A java object is not always a resource. There has been a convention that they matched but there is no requirement. There will always be more resource IDs than Facility IDs because some objects don't have a facility (events, users, etc). -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Andrew B. <a.g...@le...> - 2006-07-24 09:06:24
|
300-303 are used for the PeerMarker resources. Aggie -----Original Message----- From: bod...@li... [mailto:bod...@li...] On Behalf Of Matthew Buckett Sent: 24 July 2006 09:52 To: Bodington developers Subject: Re: [Bodington-developers] HelloWorld negotiation Alistair Young wrote: > oh dear, I've just started on a HelloWorldFacility with javadocs and > full documentation before it morphs into a chat tool. So a Facility > is registered (hard coded) into Resource? hmmm A resource has a HttpFacilityUINumber which then gets mapped to a facility. The mapping from the number can be changed at deploy time through the Bodington properties file. > I need an id for it. The first free one we have here is 301. This be > ok for everyone else? or is that taken in other versions of bod? We don't have 301 in use. > Or is this not a good way to choose? Seems there are random numbers > all over the shop. There was some plan whereby each major partner would have a chunk of the Facility numbers but I can't remember which chunks we all got. http://sourceforge.net/mailarchive/message.php?msg_id=12464769 Seems to indicate Oxford would use 101-200 and UHI would use 201-300. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ 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.
