Hi Ross,

On Wed, 02 Jan 2002 19:20:34 -0800 Ross Boylan <RossBoylan at stanfordalumni.org> wrote:
>I've noticed the following problems when I publish a project:
>
>1. Several objects in the project are related through the #when:send:to 
>event mechanism.  Not all the dependencies survive intact, though it looks 
>as if some do.  The one that didn't involved one of the published Morphs as 
>a receiver; the others had non-graphical receivers.  It may also matter 
>that the source of the notifications kept its dependencies in the 
>system-wide EventsFields, rather than its own instance variable (like 
>EventModel).

>From a quick look at the code, events registered on EventModel or Morph subinstances should be exported correctly, but events registered on other kinds of objects likely will not be. Similarly, dependents registered on Model subinstances should be handled correctly while others would not be. I would suggest checking to be sure which events/dependencies you are losing and perhaps implementing #myEvents and/or #myDependents for those classes in a manner like the current non-Object implementations.

>2. The key data are rooted in a class variable of one of the project's 
>classes.  The data made it across, but the variable is nil.

A class variable is a handy place to stash things that have no other logical home, but they will be missed in the project exporting mechanism. Why not store the value as a property of the world in which your project lives? That way it will be exported and imported without problem.

>Can anyone suggest a work around or fix for these problems?  I think I 
>remember someone else commenting that publishing can break 
>dependencies.  I'm not sure how it works for update/changed stuff.
>
>Is there a way to get prolog and cleanup code into the project (e.g., in 
>its change set)?  If so, I could try (for problem 2) something horrible like
>MyClass setClassVariable: MyClass allInstances first
>since there's only one instance.  I'm not sure if things would be in a 
>proper state for it to work, though.

You can put a postscript on the project change set, but this will be run before the project itself has been loaded, so there will not be any instances to refer to. You could change the method that accesses this variable from

getClassVarRoss
	^ClassVarRoss

to

getClassVarRoss
	^ActiveWorld valueOfProperty: #ClassVarRoss ifAbsent: [
		ActiveWorld setProperty: #ClassVarRoss toValue: ClassVarRoss.
		ClassVarRoss
	].

This way, the varible will be obttained from the world, except for the very first time when it will come from the class variable slot.

>
>
>3. I also found an interesting problem and solution.  I had a class accessor
>MyClass>>ross
>	^RossInstance
>where RossInstance was a global variable.  When I tried to read the 
>resultant project in I got an unrecognized key error.  I got around this by 
>deleting the method from the change set.  (It seems likely that rewriting 
>to Smalltalk at: #RossInstance might fix the problem also.)

I think the moral of several of these issues is to try to avoid globals. It's probably better for objects that need to refer to another object to have an instance variable for it or a way to talk to another object that does. Using Smalltalk itself or classes to serve this purpose does not mesh well with the project exporting mechanism.

>
>4. Is there a way to move a project you have published to your local disk 
>to the server without going through the entire publishing process?  I'm 
>publishing locally to test that it's working.  When it is, it would be nice 
>to be able to ship the project file off directly.

That depends on the server, but it's probably not worth the trouble. The code you would need to emulate is toward the end of Project>>exportSegmentWithChangeSet:fileName:directory: and there are a number of steps required to get it all lined up correctly.

Cheers,
Bob