On Wed, 24 Sep 2003, Lukas Renggli wrote:

> > After entered the info related to a repository, I can load in my image
> > some packages stored on it. But, each loaded package does not have any
> > reference to the repository where they came from. This mean when I
> > want to save my package, I need to enter again the info for the
> > repository.
>
> - deselect any selected package
> - middle-click on the repository you want to assign to a package
> - click on 'add to package ...'

Lukas, nice to see someone figured out my cryptic UI :).

> - In my opinion the entries should be ordered in reverse direction with
> the version number, so the biggest number is on top and the lowest at
> the bottom. If there are several versions of the same package with the
> same number they should be ordered according to the authors initials.
> Correct me if I am wrong, but this doesn't seem to be the current
> behaviour of HTTPRepository.

No, it's not.  The current behavior is to request from the server that
they be sorted by date, although I think this only works for some versions
of apache.  Sorting by version number would be fine.  But what do you do
with versions that are named, or don't use the default sequential
versions?  For example, you might have a list like this:

Foo-import
Foo-ab.1
Foo-ab.2
Foo-0.9
Foo-jf.3
Foo-ab.7
Foo-ab.bar1
Foo-ab.bar2
Foo-1.0

> - The available versions should be filtered to the selected package, so
> only versions of this package are visible; if there is no package
> selected the list should show all the packages as in the current version.
> In our case this would shrink the list of files to at most about 100
> entries.

Strictly speaking, you can't filter by package just from the filenames,
since the naming conventions aren't enforced.  Realistically, though, yes,
you could do this, as a stopgap until we have the "VersionInfo feed" we
were talking about earlier.

> - Still there are far too much entries in that list. So I suggest to
> display only the 10 versions with the biggest numbers and preselect the
> 'latest' one, as it is very likely that the user wants to load that. An
> additional menu-item called 'all versions' should allow to see the wohle
> list.

Why are we sticking to menus?  With a list that long, wouldn't it maybe be
better to bring up a dialog with a scrollbar?
Then you could also have Load, Merge buttons as well as Open, in case you
already know the exact version you want.

> Ok, this are just a few ideas, some of them have been probably already
> discussed in the list. If you want me to implement them, just ask :)

Go for it.

> Btw, I updated my Monticello-SeaMan-Web-Interface to support
> repositories and to work the current Monticello release. I really like
> the way how easily it is possible integrate the model into a different
> ui, however - and I'm complaining again about the same thing - opening
> versions was not that easy as I expected as one can't call #morphicOpen
> to archive this task. What I did was to write a class extension with the
> message #seasideOpen:, but this doesn't seem to be very clean as some of
> the code is then duplicated form #morphicOpen. I would rather prefer
> calling a message #open that throws a notification to collect the
> necessary data from the gui and keep the repository-model clean, exactly
> as it is done when saving a version to a repository.

Well, the difference here is that it is always the UI itself that is
calling #open - so there is no need for the indirection of an exception,
the UI can easily know whether to call #morphicOpen or #seasideOpen:.

You could do something like this:

pickVersion: aBlock
  picked := aBlock value: self allVersions.
  ...

morphicOpen
  self pickVersion: [:list | ....]

seasideOpen:
  self pickVersion: [:list | ...]

Or maybe some OpenVersionDialog model that you could build both Seaside
and Morphic views from (hey, just a random thought - have you looked at
MCTool?  Could one build a Seaside renderer for the #widgetSpecs?)