Re: [Bodington-developers] HelloWorld negotiation

[Matthew B. <mat...@ou...>]

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/