I do not know when we removed NewListModel
We should check that.
And probably update clients to use ListModel.
Stef
Hi Torsten,
On 21 Feb 2017, at 14:24, Torsten Bergmann <asta...@gmx.de> wrote:
Hi,
regarding the problem Sven mentioned on
http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2017-February/030542.html
here are my findings:
When I use latest Pharo 6 (Image 60404) and run
Metacello new
smalltalkhubUser: 'Seaside' project: 'MetacelloConfigurations';
configuration: 'Seaside3';
version: #'release3.2';
load
it loads the latest release 3.2 (which internally loads 3.2.1). The
package is "ConfigurationOfSeaside3-JohanBrichau.323.mcz"
Yes that worked for me too.
I then had to load my own project using the same API, so not:
ConfigurationOfBetaNineT3 project bleedingEdge load: 'trackit'.
But:
Metacello new
configuration: 'BetaNineT3';
version: #bleedingEdge;
load: 'trackit'.
This then loaded Bootstrap as needed (with Seaside already present).
This loads fine in Pharo 6 except that after installation the "Tools"
-> "Seaside control panel" is not working anymore as
"NewListModel" is not found anymore. So the control panel is broken.
Dont know what the migration path is for UI's
who used the removed "NewListModel" class.
Here is how I quickly patched the control panel:
WAPharoServerAdapterSpecBrowser>>#initializeWidgets
self instantiateModels: #(
listModel ListModel
textModel TextModel
toolbarModel WAServerAdapterToolbar).
WAPharoServerAdapterSpecBrowser>>initializePresenter
self initializeAdaptors.
textModel aboutToStyle: false.
listModel
whenSelectedItemChanged: [ :selection | adaptor := selection. self
updateUIState];
whenListChanged: [ self updateUIState];
displayBlock: [ :item | (item class name,' ',item statusString)
asStringMorph ];
"icons: [ :item | self iconForAdaptor: item];
iconMaxSize: 16@16;"
menu: [ :aMenu | self adaptorsMenu: aMenu].
self focusOrder
add: listModel;
add: toolbarModel;
add: textModel.
self disableAllButtons
So I replaced NewListModel with ListModel and I commented out the icon
related stuff. This might be a bit too quick&dirty, I don't know.
So yes - one can (by using the above script) use Seaside but currently
has to start the server with a script
until this is fixed. This is good to know - but does not solve the
"loading from catalog" issue.
-----------------------------------------------------------------------------------------------------------------------------------------
So (in a fresh image 60404) I loaded "Bootstrap" from catalog and I
received the error Sven reported.
But ConfigurationOfBootstrap itself is not the problem I guess. Because
it is also only referencing the
"release3.2" version of Seaside and also
"ConfigurationOfSeaside3-JohanBrichau.323.mcz" is loaded.
The Transcript shows the following error output:
Loaded -> ConfigurationOfSeaside3-JohanBrichau.323 ---
http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/ ---
http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/Error:
Name not found: Seaside-Pharo-Development
Also when you try to open the ConfigurationOfSeaside3 using Versionner
I receiver an error "Name not found: Seaside-Pharo-Development".
So there must be something wrong with the Seaside config I thought - or
(what would be worse) with the newer Metacello
version included in Pharo 6. At least the config looks OK and in both
situations "ConfigurationOfSeaside3-JohanBrichau.323" is used.
Additionally I tried:
- when I load the Bootstrap config in a fresh Pharo 5.0 image (50769)
from Catalog all loads fine.
- when I manipulate the Pharo 6 image to have a version 5 signature
SystemVersion newVersion: 'Pharo5.0'. SystemVersion current
inspect.
and load from catalog afterwards it also does not work. So I guess a
Pharo 5.x specific config rule could not be the cause.
Now I checked how Catalog loads the configs. And in class
CatalogProject you will notice that for the catalog we still use Gofer
for loading
installStableVersion
Gofer it
url: self repositoryUrl;
configurationOf: self name;
loadStable
when I change it to Metacello API
installStableVersion
Metacello new
repository: self repositoryUrl, '/',self name;
configuration: self name;
version: #'stable';
load
what a surprise: anything loads fine. I still wonder and do not know
about the difference why Gofer and Metacello loading in Pharo 6
makes a difference now.
So we could fix it for the catalog ... still I have no glue about the
Gofer/Metacello API difference ...
https://pharo.fogbugz.com/f/cases/19736/Catalog-should-use-Metacello-API-instead-of-Gofer-for-Configuration-installation
Thanks
T.
--
Using Opera's mail client: http://www.opera.com/mail/