Gems problem

[Jim Byrne]

Ok thanks Ken,

It seems that when a gem is uploaded both the type and creator are stripped
(or not captured in the first place). Which means that any script designed
to make sure the resulting gem has the appropriate type/creator would have
to rely on the file extension. So a table that matches file extensions to
file type and creator would be handy - no? Before I go to the bother of
making one up - does anyone else have such a thing?

Or am I barking up the wrong tree?

JIm 

on 18/9/01 4:55 pm, Ken Dow at Me@KenDow.Com wrote:

> Hi Jim,
> 
> // More non-newbie technical goo follows!
> 
>> where in the process of adding/accessing a Gem is
>> mainResponder.getFileMimeType called? I have added some lines to this script
>> to debug the problem - but they are not being called at any point.
> 
> I was referring to Frontier's ability to _serve_ a gem properly, with
> or without a type, by falling back on the extension. I believe the
> gems code simply writes the binary to disk -
> manilaSuite.gems.createNewGem and manilaSuite.gems.writeToDisk are
> the main routines, and have no Mac type-related code.
> 
> I did notice that manilaSuite.gems.newPage, which builds the gem
> upload form, uses the #urls table to decide where to post the form,
> as follows:
> 
> htmlText = manilaSuite.gems.newGemForm
> (pta^.urls^.editorialGems, pta^.urls^.gemPostMessage)
> 
> So you could change gemPostMessage to point to a new script, based on
> existing code, and have it set the type and creator as you see fit.
> HTH.
> 



 
-- 
Jim Byrne Project Director, The Making Connections Unit, Glasgow Caledonian
University, Glasgow G4 OBA, 0141 331 3893

Everything you need to know about publishing accessible information on the
Web.

Connections Disability: http://www.connections.gcal.ac.uk/

Scottish Disability Information Mailing list:
http://www.connections.gcal.ac.uk/MailList/DisList.html