Wonderful, thank you.
While I think Seaside is a framework which really benefits by the
power of Metacello (multi-platform, etc.), it seems to continue to
face challenges in meeting all the catalog requirements.
Like, right here, right now, I have my learning-seaside.image, with
Seaside-3.1.2 loaded, and I would like to load (or, preferably, _merge_,
because my studious activities have caused a few dirty packages) the
packages of this 126.96.36.199 release of Seaside. But, as I tried to do:
I get an error:
'Vversion '188.8.131.52' is not defined in ConfigurationOfSseaside3.
Possible versions include #(#bleedingEdge #development #release3..."
So I guess there can be an advantage to not using symbolic version
names -- because if someone told me, "184.108.40.206 is the new stable version" and
I were to install "#stable," I might erroneously think I
got 220.127.116.11 loaded even though I didn't (!), because I first needed to
load the "latest Metacello" in order to get the latest definitions.
Unfortunately, the upgrade of Metacello doesn't succeed. The
installation instructions for Metacello at
fails the 2nd time with:
MetacelloCommonMCSpecLoader DNU: #loadPackageDirective:gofer:.
The simple SqueakMap procedures enjoy a property of idempotence,
something that must be expected of system configuration scripts, and
Metacello must master, if Seaside is to meet all of the catalog
> This will install OmniBrowser for the SeasideControlPanel.
> I have an alternative one written in ToolBuilder for Squeak, so we no longer
> depend on OB for just the SCP.
> HOWEVER, WebClient-Seaside assumes the SCP to be present.
> I have to break that up to make that more modular.
> Gimme some time there ;)
> I'll test with 3.2 as soon as I get around to do that.
Okay, thank you! I have direct need for JQAjax>>#callback:json: right
now, but is not introduced until 3.2.
seaside-dev mailing list