Package postInstall or Class initializeAfterLoad

What are the pro's and cons of using a postInstall script in the package
browser or simply implementing an #initializeAfterLoad on a class?

I can see that in some cases you might want to use package preInstall stuff
if you need something to be in place before your classes load, but other
than that it seems like its much easier to use the class
#initializeAfterLoad method where the tools are better, and you get
references to etc.

Am I missing something really important?

Tim

TimM wrote:

> What are the pro's and cons of using a postInstall script in the package
> browser or simply implementing an #initializeAfterLoad on a class?

It's more normal to override the class-side #initialize method (there are many
examples in the image).  You /can/ override #initializeAfterLoad if you need
to, but you very rarely need that extra complexity.

There is no defined order in which classes are initialised, so it can sometimes
be awkward to perform some system-wide initialisation from #initialize, since
the participating classes may not all be initialised yet.  There are various
ways around that, one of the simplest is to invoke the global setup from the
post install script.  That way the individual classes can concentrate on
initialising /themselves/, and the final (system-wide) initialisation is
invoked later.

BTW, even in that case, I would put the code for the system-wide initialisation
into a class-side method somewhere, and the post install script would simply
invoke that.  There's no point in putting complex code in a post-install
script.

    -- chris

Chris Uppal wrote:
> BTW, even in that case, I would put the code for the system-wide initialisation
> into a class-side method somewhere, and the post install script would simply
> invoke that.  There's no point in putting complex code in a post-install
> script.
I've made somewhat different experiences. My class initialization takes
initializes only the classes themselves and does not refer to other
classes of the package. The reason for that is that I made the painful
experience that you can not rely on class loading order.

I.e. if I need to wire up some classes from the package I do this in the
postinstall script - thus being sure that all classes are loaded.

The other use is initialization which does not belong to any class.
Prominent example is extending View's MessageMap to handle additional
windows messages.

CU,

Udo

Udo Schneider escribió:
> Chris Uppal wrote:

>> BTW, even in that case, I would put the code for the system-wide
>> initialisation
>> into a class-side method somewhere, and the post install script would
>> simply
>> invoke that.  There's no point in putting complex code in a post-install
>> script.

> I.e. if I need to wire up some classes from the package I do this in the
> postinstall script - thus being sure that all classes are loaded.
> The other use is initialization which does not belong to any class.
> Prominent example is extending View's MessageMap to handle additional
> windows messages.

Another solution which is a mix between Chris' class method and
Udo's postInstall script
is to reify the initialization/install as a class, which belongs to
the package.

In this way you put in your postInstall script:

YourPackageInstaller new setUp


Then, you can develop all the complex start up and shut down,
testing, and assertions needed
to activate (or not) your package, but you can develop it using the
standard development tools
(i.e. class browser, etc). And not as a single script in a
workspace. Plus, you can version it,
test it, and similar.

Best regards.

--
Esteban.