[Seaside-dev] question on value of startup and shutdown lists being required

[Philippe Marschall]

2008/3/23, Dale Henrichs <dale.henrichs at gemstone.com>:
> Philippe Marschall wrote:
>  > One thing to keep in mind is package loading and package
>  > initialzation. Right now is looks like this:
>  > - provide Continuation
>  > - provide SeasidePlatformSupport
>  > - "normally" load Seaside-Core where "normally" means at the end
>  > happends class initialization
>  >
>  > The way I interpret 3 between loading the code and #initalize-ing the
>  > classes some other code has to be loaded in this case WAExternalId
>  > class >> #registerForStartup.
>  >
>  > Cheers
>  > Philippe
>  >
>
> In my earlier attempt at 3, #startup and #registerForStartup need to be
>  platform specific methods. I can make startup platform independent (with
>  a platform-specific extension method to Random), but I'm stuck with
>  #registerForStartup as a problem - it would be nice if there were a post
>  Seaside-Core platform-specific package.
>
>  Perhaps we can create a Seaside-Squeak-Extensions (and
>  Seaside-GemStone-Extensions) package for the handful of extensions that
>  are currently needed (including the squeak-specific 'cyclic dependency'
>  extensions).
>
>  This approach would certainly solve the registerForStartup problem right
>  now. I assume that as I move forward with my port, I will find other
>  places where a post core load will be useful. There already is a
>  platform-specific package for development extensions, so I assume the
>  we'll end up with platform-specific core extensions in more areas.
>
>  You know, if we use a platform-specific extensions package, we can
>  eliminate SeasidePlatformSupport - I don't know if that would be a good
>  or bad thing. It is convenient to manage things in one spot, but given
>  a  thorough test suite (which is already in place for most if not all of
>  the base class extensions) it isn't necessary....95% of the references
>  to SeasidePlatformSupprt messages are from a single method or a single
>  class.
>
>  If we do eliminate SeasidePlatformSupport, then the platform Core
>  package (except for Continuations) can be loaded after Seaside Core.
>
>  What do you think?

It makes loading classes harder and knowing what to implement harder.

Right now you can use normal class initialization in Seaside-Core
(class >> #initialize) and you can expect SeasidePlatformSupport to be
present. With your change initialization of classes in Seaside-Core
would have to happen in Seaside-Platform-Extensions.

If you want to know what methods you have to implement you can look at
WASqueakPlatform and you should have most of them.

As for the file stuff a lot of this can be implemented with SPort and
has already been done so in Seaside-Sport-Core.

Cheers
Philippe