[Seaside-dev] Seaside 3.1 ready

[Philippe Marschall]

On Wed, May 9, 2012 at 5:14 PM, Dale Henrichs <dhenrich at vmware.com> wrote:
>
>
> ----- Original Message -----
> | From: "Philippe Marschall" <philippe.marschall at gmail.com>
> | To: "Seaside - developer list" <seaside-dev at lists.squeakfoundation.org>
> | Sent: Wednesday, May 9, 2012 12:20:23 AM
> | Subject: Re: [Seaside-dev] Seaside 3.1 ready
> |
> | On Tue, May 8, 2012 at 10:08 PM, Dale Henrichs <dhenrich at vmware.com>
> | wrote:
> | > Philippe,
> | >
> | > Hmmmm, I don't have a lot of extra time right now, to port
> | > Seaside3.1 to GemStone and build configurations:( Some advance
> | > warning would have been nice... If I'd known you were aiming for a
> | > release in this time frame...ah, well...
> |
> | Sorry about that. There is a slight chance that the existing code
> | just works.
> |
>
> I've branched a Seaside-Core and one or two other packages, so the "just works" depends upon how different 3.1 is ...

Not that much different [1]. There are new methods on GRPlatform but
they have default implementations. There's now a cache on WASession
for the document handlers. That's what comes to mind.

> Speaking of differences: will it be possible to upgrade from Seaside30 to Seaside31?

Hard to tell. In theory yes, but then I haven't actually tried it. You
surely need to get rid of sessions first and reset application
configurations. Apart from that, I don't really know.

> | > Regarding the 256 literal limit, would you be amenable to breaking
> | > Seaside3.1 up into smaller chunks? I think that it is high time
> | > that the configuration for Seaside be revisited and revamped
> | >
> | > I have spent zero time looking at Seaside3.1 so I have no idea
> | > that's been going on there, but things like the javascript support
> | > and REST and JSON and Examples and etc. could actually be managed
> | > in separate configurations. Splitting those things out into
> | > separate configurations would not only reduce the number of
> | > literals needed in the monolithic version spec, but would make it
> | > easier for people to understand what is optional and what is
> | > required ...
> | >
> | > What do you say?
> |
> | Sounds interesting. Just to be sure, we'd end up with configuration
> | classes like
> |
> | ConfigurationOfSeaside31
> | ConfigurationOfJQuery
> | ConfigurationOfSeasideRest
>
> Yeah, that would be the idea ... if JQuery and SeasideRest are bound to a particular Seaside3x version then you might find it useful to include 31 in the name...

IC, thanks.

 [1] http://code.google.com/p/seaside/wiki/Seaside310Changelog#Porters

Cheers
Philippe