Package loading

Hi...

today I made a quick patch to PackageSelector>>loadPackageFile to
automatically search for prerequisite packages in the image-relative
subdirectories instead of popping up a FileSelector all the time. It went so
well, that I started to build a package with  more sophisticated  features
such as e.g. checking for duplicate package names in my folders and
programmatic package installation.

With the latter I noticed, that the top-level package installation procedure
is coded inside a PackageSelector - a presenter. I had to copy all the
necessary methods over to my own PackageInstaller class to get rid of errors
related to DeafObjects in the Presenter code.
Wouldn't it be better to encapsulate this behaviour in an independent base
system class?

Another question: Is the package version stored in the prerequisite entry?
Whis would allow to resolve automatically even if different versions of the
same package are in the image-relative filesystem subtree (I had some
occurences that I was up to today unaware of, e.g Ians DIB package I had in
versions 4a (inside Steve Warings package subtree) and 5a in Ians
distribution).

Ciao

...Jochen

Jochen

You wrote in message news:[hidden email]...
>
> today I made a quick patch to PackageSelector>>loadPackageFile to
> automatically search for prerequisite packages in the image-relative
> subdirectories instead of popping up a FileSelector all the time. It went
so
> well, that I started to build a package with  more sophisticated  features
> such as e.g. checking for duplicate package names in my folders and
> programmatic package installation.
>
> With the latter I noticed, that the top-level package installation
procedure
> is coded inside a PackageSelector - a presenter. I had to copy all the
> necessary methods over to my own PackageInstaller class to get rid of
errors
> related to DeafObjects in the Presenter code.
> Wouldn't it be better to encapsulate this behaviour in an independent base
> system class?

Certainly it is true that the UI associated with package loading (rather
than the installation procedure) is in PackageSelector. The UI is needed for
tasks such as handling and reporting errors and attempting to locate any
pre-requisites which are not at the paths recorded in the package files. It
wouldn't be appropriate for this to be in the package implementation classes
themselves as these must not have any MVP dependencies. It could however be
moved to the main development system model class, SmalltalkSystem, which
would make it available for use from other tools, and also allow its global
customisation by subclassing SmalltalkSystem, which is one of the preferred
IDE customisation methods.

>
> Another question: Is the package version stored in the prerequisite entry?
> Whis would allow to resolve automatically even if different versions of
the
> same package are in the image-relative filesystem subtree (I had some
> occurences that I was up to today unaware of, e.g Ians DIB package I had
in
> versions 4a (inside Steve Warings package subtree) and 5a in Ians
> distribution).

The package version is purely informational. It is not currently used by the
package loading mechanism.

Regards

Blair



>
> Ciao
>
> ...Jochen
>
>

Hi Blair...
> Certainly it is true that the UI associated with package loading (rather
> than the installation procedure) is in PackageSelector. The UI is needed
for
> tasks such as handling and reporting errors and attempting to locate any
> pre-requisites which are not at the paths recorded in the package files.
It
> wouldn't be appropriate for this to be in the package implementation
classes
> themselves as these must not have any MVP dependencies. It could however
be
> moved to the main development system model class, SmalltalkSystem, which
> would make it available for use from other tools, and also allow its
global
> customisation by subclassing SmalltalkSystem, which is one of the
preferred
> IDE customisation methods.

Yes, sounds good. For now I simply copied all relvant methods in
PackageSelector to my own JRPackageInstaller class, which is subclassed
simply from Object. (This is inconvenient when another Dolphin version or
patch comes up as likely the code in PackageSelector will have changed and I
have to make a new version manually.) It pops up maybe a fileselector and
maybe an alert box, but this could be solved easily with pluggable adapters
or template methods or simply a flag if ui interaction shall be omitted
entirely.

I hope to release my package load/save stuff as an experimental goodie as
soon as I find time to polish it. I find it extremely useful. E.g. I can now
simply issue a JRPackageManager current savePackageListForImage, which saves
a text file with all the packages currently installed from the image
relative path.

JRPackageManager current installPackageListForImage reinstalls them all
without ever popping up anything, e.g in a fresh image. When desired, the
PackageSelector>>openPackageFile can be patched to redirect to a
JTPackageInstaller, which then resolves missing packages silently.
Ciao

...Jochen

Subclassing SmalltalkDevelopmentSystem seems to be a problem to me. How can
several extensions coexist?

"Blair McGlashan" <blair@no spam object-arts.com> schrieb im Newsbeitrag
news:3fcdb785$[hidden email]...
> Jochen
>
> You wrote in message news:[hidden email]...
> >
> > today I made a quick patch to PackageSelector>>loadPackageFile to
> > automatically search for prerequisite packages in the image-relative
> > subdirectories instead of popping up a FileSelector all the time. It
went
> so
> > well, that I started to build a package with  more sophisticated
features base
> > system class?
>
> Certainly it is true that the UI associated with package loading (rather
> than the installation procedure) is in PackageSelector. The UI is needed
for
> tasks such as handling and reporting errors and attempting to locate any
> pre-requisites which are not at the paths recorded in the package files.
It
> wouldn't be appropriate for this to be in the package implementation
classes
> themselves as these must not have any MVP dependencies. It could however
be
> moved to the main development system model class, SmalltalkSystem, which
> would make it available for use from other tools, and also allow its
global
> customisation by subclassing SmalltalkSystem, which is one of the
preferred
> IDE customisation methods.
>
> >
> > Another question: Is the package version stored in the prerequisite
entry?
> > Whis would allow to resolve automatically even if different versions of
> the
> > same package are in the image-relative filesystem subtree (I had some
> > occurences that I was up to today unaware of, e.g Ians DIB package I had
> in
> > versions 4a (inside Steve Warings package subtree) and 5a in Ians
> > distribution).
>
> The package version is purely informational. It is not currently used by
the