Best practices available for Seaside Gemstone?

OK, I'm thoroughly frustrated.... how *do* I load MockGemStone? I've tried just about every incantation of Gofer I can think of (and Gofer project) but nothing can find it.

On Wed, Oct 6, 2010 at 3:34 AM, Norbert Hartl <[hidden email]> wrote:

On 06.10.2010, at 07:18, Friedrich Dominicus wrote:

> Dale Henrichs <[hidden email]> writes:
>> You _could_ use the same Pharo image for developing in Pharo and
>> GemStone, but for me it is too easy to forget where I'm making changes
>> (the code is the same and browsers look similar)..So I prefer to have
>> separate pharo vms: 1 for Pharo-based development and 1 for
>> GemTools-based defelopment.
> Let me be a bit more penetrant. As I understand the suggestion is "NOT"
> using the GemStone Tools (intergrated) into Pharo. But just writing the
> code "happy" away in the Pharo image. If you feel kind of comfortable
> you migrate than?
>

What you describe you have to do anyway. You write code anywhere than you need to create a monticello package and pull that back in into gemstone. I think Dales point was about how you work with images. You can have one image for your application and one for gemtools. Or you can have an image where the application and gemtools is installed. I think that is what Dale means with "you _could_ use the same". The latter approach can be confusing. Shortcuts do work in gemtools and in pharo. So while pressing cmd-B to get a browser it really depends which context you are working in. So you will often get e.g. a pharo system browser when your intension was to get one of gemstone.  All those things can go wrong.
I used the latter approach but I changed that. There are several good reasons for me to have it changed:

- it is indeed confusing if you are working with two different code bases in the same image. And sometimes I changed accidentially code in gemstone which I like to see as my production server and every change should come with monticello not by hand.
- I have several projects that are deployed in gemstone. No need to put the gemtools in every project image I have.
- if you like to be up to date to the pharo enhancements than the gemtools may prevent that. Until a few weeks ago you could only use pharo 1.0 for gemtools. Even in newer versions the tools that have been ported to gemstone are somewhat behind. So to divide project and gemtools image solves this problem

> I understand what you mean with the "Gemstone" image and the Pharo
> image. But the suggestion is doing development in Pharo FIRST?
>

Yep. I think it is not a good idea to work in both directions (pharo->gemstone and gemstone->pharo). In the beginning this might be the case until you are aware of cross platform problems. But to have a stable process is good to have. And that could be (it is nearly the same that Stephan writes):

- develop your application in pharo with the newest cool tools. That maximizes the fun for you
- write as much tests as it needs to trigger most of your code so you can detect errros early
- get used to Grease/SPort for streams and such. That helps to get around the most annoying thing in smalltalk: dialects
- use slime to check your code. Helps ironing out some mistakes that occurr often
- if you have code that needs gemstone internals than use MockGemstone to make it load in pharo and work in gemstone. If something is missing just add it to the MockGemstone package it is supposed to be used like that
- if you need some pharo methods that aren't present in gemstone than you can add them to the Squeak compatibility package in gemstone
- write a metacello configuration to wire all dependent libraries to your project
- write a upgrading/migrating utility class because sometimes you need to adjust something in the remote image and shouldn't do this manually

I like to say that taking all of these into account you will make it to deploy easily in gemstone. There are always nuts and bolts that don't fit that well. But as you get used to the process the rate will be decreasing. With metacello it is easy to have a configuration of the stable version of your application and one for development. You could than install the stable on production servers and the developement version on a test server.

> And you write your code such that it "ends" in a Monticello repository.
> Then you do the migration by checking it out the Monticello repository
> and "start porting" ?
>
>

No, if you take all the advizes from above you just write code that runs in both. Porting is always kind of a last resort. Dale is doing a lot to lower the barrier between pharo and gemstone. For what does not fit there are Squeak compatibility package, MockGemstone and method extensions in monticello. With the advent of metacello you can have a package split into cross-platform code and platform-dependent code. Platform-dependent code is put into a platform package. Metacello can load the right packages automatically. And so on and on and....

hope this gives a little insight,

Norbert

> --
> Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
> Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Worked great, thanks.

Of course, I then couldn't resist poking around in Gofer a little, and I figured out that this incantation will work (though I have no idea how 'optimal' it is):

Gofer new

  gemsource: 'MockGemStone' ;

  package: 'MockGemStone' ;

load.

--chris

On Fri, Oct 15, 2010 at 3:46 AM, Norbert Hartl <[hidden email]> wrote:

On 15.10.2010, at 03:17, Chris Curtis wrote:

OK, I'm thoroughly frustrated.... how *do* I load MockGemStone? I've tried just about every incantation of Gofer I can think of (and Gofer project) but nothing can find it.

That is not your fault :) Gofer is one of the tools that are rather new. They work good but there hasn't been a complete shift towards Gofer (and it probably never will). While there are new tools to load sources they all use monticello which is the package management underneath. Most of the packages you will find in pharo/squeak/gemstone world will be somehow loadable by monticello.

In order to load MockGemStone just do the following:

- Point your browser to http://seaside.gemstone.com/ss/MockGemStone.html

- Copy the snippet in the Registration section to the clipboard.  

- Open a monticello browser

- Press the "+Repository" button followed by the option "HTTP"

- Replace the content shown with the content of the clipboard. Then "Accept"

- If you press "open" on the monticello browser while your new repository is highlighted you will see MockGemStone in the left pane. 

- Select MockGemstone then you got the versions on the right side. Usually you select the top most entry and then you press load

hope this helps,

Norbert

On Wed, Oct 6, 2010 at 3:34 AM, Norbert Hartl <[hidden email]> wrote:

On 06.10.2010, at 07:18, Friedrich Dominicus wrote:

> Dale Henrichs <[hidden email]> writes:
>> You _could_ use the same Pharo image for developing in Pharo and
>> GemStone, but for me it is too easy to forget where I'm making changes
>> (the code is the same and browsers look similar)..So I prefer to have
>> separate pharo vms: 1 for Pharo-based development and 1 for
>> GemTools-based defelopment.
> Let me be a bit more penetrant. As I understand the suggestion is "NOT"
> using the GemStone Tools (intergrated) into Pharo. But just writing the
> code "happy" away in the Pharo image. If you feel kind of comfortable
> you migrate than?
>

What you describe you have to do anyway. You write code anywhere than you need to create a monticello package and pull that back in into gemstone. I think Dales point was about how you work with images. You can have one image for your application and one for gemtools. Or you can have an image where the application and gemtools is installed. I think that is what Dale means with "you _could_ use the same". The latter approach can be confusing. Shortcuts do work in gemtools and in pharo. So while pressing cmd-B to get a browser it really depends which context you are working in. So you will often get e.g. a pharo system browser when your intension was to get one of gemstone.  All those things can go wrong.
I used the latter approach but I changed that. There are several good reasons for me to have it changed:

- it is indeed confusing if you are working with two different code bases in the same image. And sometimes I changed accidentially code in gemstone which I like to see as my production server and every change should come with monticello not by hand.
- I have several projects that are deployed in gemstone. No need to put the gemtools in every project image I have.
- if you like to be up to date to the pharo enhancements than the gemtools may prevent that. Until a few weeks ago you could only use pharo 1.0 for gemtools. Even in newer versions the tools that have been ported to gemstone are somewhat behind. So to divide project and gemtools image solves this problem

> I understand what you mean with the "Gemstone" image and the Pharo
> image. But the suggestion is doing development in Pharo FIRST?
>

Yep. I think it is not a good idea to work in both directions (pharo->gemstone and gemstone->pharo). In the beginning this might be the case until you are aware of cross platform problems. But to have a stable process is good to have. And that could be (it is nearly the same that Stephan writes):

- develop your application in pharo with the newest cool tools. That maximizes the fun for you
- write as much tests as it needs to trigger most of your code so you can detect errros early
- get used to Grease/SPort for streams and such. That helps to get around the most annoying thing in smalltalk: dialects
- use slime to check your code. Helps ironing out some mistakes that occurr often
- if you have code that needs gemstone internals than use MockGemstone to make it load in pharo and work in gemstone. If something is missing just add it to the MockGemstone package it is supposed to be used like that
- if you need some pharo methods that aren't present in gemstone than you can add them to the Squeak compatibility package in gemstone
- write a metacello configuration to wire all dependent libraries to your project
- write a upgrading/migrating utility class because sometimes you need to adjust something in the remote image and shouldn't do this manually

I like to say that taking all of these into account you will make it to deploy easily in gemstone. There are always nuts and bolts that don't fit that well. But as you get used to the process the rate will be decreasing. With metacello it is easy to have a configuration of the stable version of your application and one for development. You could than install the stable on production servers and the developement version on a test server.

> And you write your code such that it "ends" in a Monticello repository.
> Then you do the migration by checking it out the Monticello repository
> and "start porting" ?
>
>

No, if you take all the advizes from above you just write code that runs in both. Porting is always kind of a last resort. Dale is doing a lot to lower the barrier between pharo and gemstone. For what does not fit there are Squeak compatibility package, MockGemstone and method extensions in monticello. With the advent of metacello you can have a package split into cross-platform code and platform-dependent code. Platform-dependent code is put into a platform package. Metacello can load the right packages automatically. And so on and on and....

hope this gives a little insight,

Norbert

> --
> Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
> Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

I'm a little late on this, but I thought it was worth mentioning a potential gotcha if you're *not* using something ActiveRecord-ish (that is, you're using regular GS-persisted objects): you can't make temporary changes to the objects. For example, you can't: 

(a) load a persisted UserProfile object,

(b) bind the accessors to form fields,

(c) allow the user to make changes, and then

(d) assume navigating away from the page will discard the changes.

The GemStone port of Seaside commits with every page render, so you can't actually do a rollback. To support this behavior, you'd have to create a (non-persistent) DTO from the persistent object, and then on a user-specified "save' action map the changes from the DTO back to the persistent domain object. Or at least, that's one solution.

As a (related) side note, is anyone aware of any work being done with CQRS in the Smalltalk world? 

On Thu, Sep 30, 2010 at 6:48 PM, Ramon Leon <[hidden email]> wrote:

On 9/30/2010 1:54 PM, Bart Veenstra wrote:

using Monticello. But now I am left with a system with no persistence
at all. I used Glorp with about 25 tables for my domain model,but it
was to hard to maintain, so that i why I moved to Gemstone. With glorp
I used the ActiveRecord approach. On the class side I had different
methods to find instances (by name or paging queries and stuff) and on
the instance side, i could call save or delete.

Since you're familiar with the active record approach and you want something simple to start with, attached is an ActiveRecord system for Gemstone that works pretty much like you'd expect.  Subclass GDActiveRecord, call GDActiveRecord installSubClasses, and use the api found on the class side of GDActiveRecord under queries.  Should get you up and running.  See the unit tests for examples of using it.

--
Ramon Leon
http://onsmalltalk.com