Best practices available for Seaside Gemstone?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Best practices available for Seaside Gemstone?

Bart Veenstra
Hi,

I am currently moving from VW/Glorp to Pharo to use Gemstone as my
object database.

Since my mind is still setup in the RDBMS mode, I need to find out
many things to work efficiently with Gemstone.

Are there best practices available somewhere?

Some of the questions i would like have answerd:

- How to model the accessing of the persisted objects.
I saw many posts in this mailing lists where you define a System for
each object you whish to have an access point to. There are a lot of
references made to UserGlobals, but where can I find that? Can that
only be accessed by a Gem?

- How to work with the persisted objects in a development environment.
I use Pharo on my Windows system connecting to Gemstone using the
gemtools client. Can I work with the persisted objects in gemstone
from Seaside running in Pharo?

- Where to setup your local monticello repository.
I moved my code from VW to Pharo using the monticello plugin. MCZ
files are written in .package-cache and I can import them in pharo
mostly without problems. How do you effeciently manage versions in
pharo en gemstone?

- Caveats in developing with gemstone.
What are the limitations or reoccurring annoyances when using Pharo &
Gemstone? Things to be wary of?

Regards,

Bart
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Jon Paynter-2

On 9/30/10, Bart Veenstra <[hidden email]> wrote:
Hi,

I am currently moving from VW/Glorp to Pharo to use Gemstone as my
object database.

Since my mind is still setup in the RDBMS mode, I need to find out
many things to work efficiently with Gemstone.

Are there best practices available somewhere?

Some of the questions i would like have answerd:

- How to model the accessing of the persisted objects.
I saw many posts in this mailing lists where you define a System for
each object you whish to have an access point to. There are a lot of
references made to UserGlobals, but where can I find that? Can that
only be accessed by a Gem?

Ive seen 2 approaches here.
for smaller projects, create a single class with class variables that hold onto collections of your objects.  Then in your methods use something like:
SystemHolder findName: 'George'
SystemHolder findInvoice: '899234'

For medium to large projects (like where I work), we use 1 class per collection: 
SetOfCustomers findName: 'George'
SetOfInvoices findCode: '899234'

A bit more administration to setup, but since you can create a nice class hierarchy out of your collections, its a lot more powerful and flexible.

 

- How to work with the persisted objects in a development environment.
I use Pharo on my Windows system connecting to Gemstone using the
gemtools client. Can I work with the persisted objects in gemstone
from Seaside running in Pharo?

I use Pharo on my Windows system connecting to Gemstone using the
gemtools client. Can I work with the persisted objects in gemstone
from Seaside running in Pharo?

To get at the objects,  you would connect to gemstone with pharo or squeak, but the 99% of your code would be run in gemstone, and only use pharo/squeak as a front end.

- Where to setup your local monticello repository.
I moved my code from VW to Pharo using the monticello plugin. MCZ
files are written in .package-cache and I can import them in pharo
mostly without problems. How do you effeciently manage versions in
pharo en gemstone?

- Caveats in developing with gemstone.
What are the limitations or reoccurring annoyances when using Pharo &
Gemstone? Things to be wary of?
 
Remember when you abort - EVERYTHING since your last commit goes away.  This includes code changes.  Until there is a good way to store your code in a local imge or SCM and upload it to seaside/glass on demand, this is going to be something to watch out for.

 
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Dale Henrichs
In reply to this post by Bart Veenstra
Bart Veenstra wrote:

> Hi,
>
> I am currently moving from VW/Glorp to Pharo to use Gemstone as my
> object database.
>
> Since my mind is still setup in the RDBMS mode, I need to find out
> many things to work efficiently with Gemstone.
>
> Are there best practices available somewhere?
>
> Some of the questions i would like have answerd:
>
> - How to model the accessing of the persisted objects.
> I saw many posts in this mailing lists where you define a System for
> each object you whish to have an access point to. There are a lot of
> references made to UserGlobals, but where can I find that? Can that
> only be accessed by a Gem?

The base GemStone system does not have a dictionary called Smalltalk.
Instead of a single dictionary (Smalltalk), GemStone uses a SymbolList
(list of dictionaries) for global lookup. There is a Globals dictionary
in the SymbolList that is shared by all GemStone users and contains the
base classes. Every user has a UserGlobals dictionary that is unique to
the user in his SymbolList.

The Globals dictionary is owned by SystemUser and is not writable by
other users. The UserGlobals dictionary is owned by each user.

You can directly access these dictionaries:

   Globals at: #Foo
   UserGlobals at: #Foo

or indirectly via the SymbolList:

   System myUserProfile symbolList objectNamed: #Foo

each dictionary in the SymbolList is searched in order until the named
object is found.

In GLASS the class SmalltalkProxy is installed as #Smalltalk in each
user's UserGlobals and objects stored in #Smalltalk are put into
UserGlobals. So one could store things using #Smalltalk so that the code
can work the same in Pharo and GemStone.

One can also store persitent objects in class variables or class
instance variables....

I would ask other users to comment on the pros and cons of using
class-based storage of persistent objects versus globals-based storage.

As far as moving from GLORP/RDMS-based storage to object-based storage,
I would suggest that you read this post:

http://gemstonesoup.wordpress.com/2009/05/19/gemstone-101-making-the-leap-from-rdbms-to-persistent-objects/

The short answer is that with GemStone as your persistence layer, there
is no need to do anything special. Create an object model that best
suits your problem space.

>
> - How to work with the persisted objects in a development environment.
> I use Pharo on my Windows system connecting to Gemstone using the
> gemtools client. Can I work with the persisted objects in gemstone
> from Seaside running in Pharo?

When running GemTools you are working with objects that reside in the
GemStone space. Pharo is simply a fairly thin UI layer ...

You asked "Can I...?" and the answer is "Yes you can, but....".

Many/most commercial customers use a combination of GemStone for
persistence and a client smalltalk for the user interface. They use a
product called GBS (GemBuilder for Smalltalk) that allows one to
"transparently" work with persistent GemStone objects directly in the
client smalltalk. The free version of GLASS does not support GBS, so
that option is not available for GLASS users.

GemTools actually works by manipulating persistent GemStone objects in
the Pharo image, but it is at a very basic level (painfully so:).

So technically you can, but I don't recommend that you do it that way.

When folks talk about developing in Pharo and deploying in GemStone,
that means that they write their application using image-based
persistence - a persistence model shared by GemStone and Pharo.

Developing in Pharo lets you take advantage of the full set of Pharo
development tools. Developing in Pharo is faster, since all interaction
with the tools in a GemTools environment involves communication over the
wire...

>
> - Where to setup your local monticello repository.
> I moved my code from VW to Pharo using the monticello plugin. MCZ
> files are written in .package-cache and I can import them in pharo
> mostly without problems. How do you effeciently manage versions in
> pharo en gemstone?

I'll let other folks comment, but I assume that the best solution here
is to set up a separate directory-based repository for storing your mcz
files that can be easily shared between Pharo and GemStone.

>
> - Caveats in developing with gemstone.
> What are the limitations or reoccurring annoyances when using Pharo &
> Gemstone? Things to be wary of?

I'll let other folks comment on this too, although I understand that
using Slime is a good idea to ensure that you are writing code that is
portable between GemStone and Pharo...

You see I try to do all of my own development exclusively using GemTools
in an attempt to "eat my own dog food"....

Dale
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Dale Henrichs
In reply to this post by Jon Paynter-2
Jon Paynter wrote:

>     - Caveats in developing with gemstone.
>     What are the limitations or reoccurring annoyances when using Pharo &
>     Gemstone? Things to be wary of?
>
>  
> Remember when you abort - EVERYTHING since your last commit goes away.  
> This includes code changes.  Until there is a good way to store your
> code in a local imge or SCM and upload it to seaside/glass on demand,
> this is going to be something to watch out for.
>
>  

Just one note that by default in the GemTools environment, a commit is
automatically performed after every menu item is executed (including
doits), so you don't have to worry about loosing code during normal
development.

Also when using Seaside, you don't have to use transactions (typically),
  since the aborts and commits are done in the framework and not your
application code.

Dale
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Bart Veenstra
Thanks for the answers!

One thing I don't quite understand is when I define my model in pharo
and create objects in say a class level variable, how these objects
will go into gemstone. Is that when I package the app as a MCZ or is
that automatically done when using GemTools (sorry for the newbie
questions ;))

2010/9/30 Dale Henrichs <[hidden email]>:

> Jon Paynter wrote:
>
>>    - Caveats in developing with gemstone.
>>    What are the limitations or reoccurring annoyances when using Pharo &
>>    Gemstone? Things to be wary of?
>>
>>  Remember when you abort - EVERYTHING since your last commit goes away.
>>  This includes code changes.  Until there is a good way to store your code
>> in a local imge or SCM and upload it to seaside/glass on demand, this is
>> going to be something to watch out for.
>>
>>
>
> Just one note that by default in the GemTools environment, a commit is
> automatically performed after every menu item is executed (including doits),
> so you don't have to worry about loosing code during normal development.
>
> Also when using Seaside, you don't have to use transactions (typically),
>  since the aborts and commits are done in the framework and not your
> application code.
>
> Dale
>
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

SeanTAllen
They dont go into gemstone. That is probably why you are having a hard time understanding how they move.
Think of pharo as a single image object database and gemstone as a multiple image one. Two totally different databases.
You would want to create test/mock data in pharo for use while developing. That is another good reason to go
with the global 'System' approach. It is easy to setup and tear down when testing compared to dealing with class side variables.
If you have a single global at the top of your system, reinitializing your development data is as simple as remove and rerun your development data creation code. 

On Thu, Sep 30, 2010 at 1:50 PM, Bart Veenstra <[hidden email]> wrote:
Thanks for the answers!

One thing I don't quite understand is when I define my model in pharo
and create objects in say a class level variable, how these objects
will go into gemstone. Is that when I package the app as a MCZ or is
that automatically done when using GemTools (sorry for the newbie
questions ;))

2010/9/30 Dale Henrichs <[hidden email]>:
> Jon Paynter wrote:
>
>>    - Caveats in developing with gemstone.
>>    What are the limitations or reoccurring annoyances when using Pharo &
>>    Gemstone? Things to be wary of?
>>
>>  Remember when you abort - EVERYTHING since your last commit goes away.
>>  This includes code changes.  Until there is a good way to store your code
>> in a local imge or SCM and upload it to seaside/glass on demand, this is
>> going to be something to watch out for.
>>
>>
>
> Just one note that by default in the GemTools environment, a commit is
> automatically performed after every menu item is executed (including doits),
> so you don't have to worry about loosing code during normal development.
>
> Also when using Seaside, you don't have to use transactions (typically),
>  since the aborts and commits are done in the framework and not your
> application code.
>
> Dale
>

Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

James Foster-8
In reply to this post by Bart Veenstra
Bart,

In addition to the excellent comments from others, I would invite you to try my tutorial at http://seaside.gemstone.com/tutorial.html. With it you walk through developing an application in Pharo and then deploying it in GemStone. Several of your questions will be answered as you work through the examples. You can also watch videos of me going through the tutorial.

James

On Sep 30, 2010, at 11:46 AM, Bart Veenstra wrote:

> Hi,
>
> I am currently moving from VW/Glorp to Pharo to use Gemstone as my
> object database.
>
> Since my mind is still setup in the RDBMS mode, I need to find out
> many things to work efficiently with Gemstone.
>
> Are there best practices available somewhere?
>
> Some of the questions i would like have answerd:
>
> - How to model the accessing of the persisted objects.
> I saw many posts in this mailing lists where you define a System for
> each object you whish to have an access point to. There are a lot of
> references made to UserGlobals, but where can I find that? Can that
> only be accessed by a Gem?
>
> - How to work with the persisted objects in a development environment.
> I use Pharo on my Windows system connecting to Gemstone using the
> gemtools client. Can I work with the persisted objects in gemstone
> from Seaside running in Pharo?
>
> - Where to setup your local monticello repository.
> I moved my code from VW to Pharo using the monticello plugin. MCZ
> files are written in .package-cache and I can import them in pharo
> mostly without problems. How do you effeciently manage versions in
> pharo en gemstone?
>
> - Caveats in developing with gemstone.
> What are the limitations or reoccurring annoyances when using Pharo &
> Gemstone? Things to be wary of?
>
> Regards,
>
> Bart

Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Bart Veenstra
Hi James,

I am pretty familiar with Seaside. I have been working on it for 1.5
years developing public facing web applications where customers can
apply for insurances and stuff. But this is still done using RDBMS
systems.
I read through all the Tutorials and they came in very handy for
understanding Pharo. I only had experience with Seaside in VA and VW,
but now I can add Pharo to that list as well.

Today I spent most of my day sneezing (it's fall and I know it...) and
between the sneezing, i managed to load all my VW classes into Pharo
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.

I know that that is radically different on an OODB.

So I am looking into patterns on how to access my data.

Should I use class variables to hold my instances? Or should I create
"repositories" for these instances? and what should they look like.

In java there are numerous ways/patterns to get hold of your data from
RDBMS systems. I was wondering if there are approaches as widely
described as in Java available for gemstone.

Regards,

Bart

2010/9/30 James Foster <[hidden email]>:

> Bart,
>
> In addition to the excellent comments from others, I would invite you to try my tutorial at http://seaside.gemstone.com/tutorial.html. With it you walk through developing an application in Pharo and then deploying it in GemStone. Several of your questions will be answered as you work through the examples. You can also watch videos of me going through the tutorial.
>
> James
>
> On Sep 30, 2010, at 11:46 AM, Bart Veenstra wrote:
>
>> Hi,
>>
>> I am currently moving from VW/Glorp to Pharo to use Gemstone as my
>> object database.
>>
>> Since my mind is still setup in the RDBMS mode, I need to find out
>> many things to work efficiently with Gemstone.
>>
>> Are there best practices available somewhere?
>>
>> Some of the questions i would like have answerd:
>>
>> - How to model the accessing of the persisted objects.
>> I saw many posts in this mailing lists where you define a System for
>> each object you whish to have an access point to. There are a lot of
>> references made to UserGlobals, but where can I find that? Can that
>> only be accessed by a Gem?
>>
>> - How to work with the persisted objects in a development environment.
>> I use Pharo on my Windows system connecting to Gemstone using the
>> gemtools client. Can I work with the persisted objects in gemstone
>> from Seaside running in Pharo?
>>
>> - Where to setup your local monticello repository.
>> I moved my code from VW to Pharo using the monticello plugin. MCZ
>> files are written in .package-cache and I can import them in pharo
>> mostly without problems. How do you effeciently manage versions in
>> pharo en gemstone?
>>
>> - Caveats in developing with gemstone.
>> What are the limitations or reoccurring annoyances when using Pharo &
>> Gemstone? Things to be wary of?
>>
>> Regards,
>>
>> Bart
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

SeanTAllen

I know that that is radically different on an OODB.

So I am looking into patterns on how to access my data.

Should I use class variables to hold my instances? Or should I create
"repositories" for these instances? and what should they look like.

Dont use class variables. That isnt going to work out long term.  
Start by thinking of it this way... How many interfaces do you need to your data?
For example... a to do application... everything can be managed by 1 interface.
add to do's, remove to do's etc. if you have multiple users, you need to manage them,
so you have a user system.

Create an over arching system that is all your other systems... it contains references
to your To Do System and User System. Now if you want to run multiple copies
of your application, it isnt a problem. Just create another global w/ a new system instance.

This work for gemstone and it works for pharo. The only difference is, in pharo, you are
tied to a single image. You would have to route all traffic for that application to that one
image. With gemstone, you don't have to worry about that.

Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

James Foster-8
In reply to this post by Bart Veenstra
Hi Bart,

On Sep 30, 2010, at 4:54 PM, Bart Veenstra wrote:

> Hi James,
>
> I am pretty familiar with Seaside. I have been working on it for 1.5
> years developing public facing web applications where customers can
> apply for insurances and stuff. But this is still done using RDBMS
> systems.
> I read through all the Tutorials and they came in very handy for
> understanding Pharo. I only had experience with Seaside in VA and VW,
> but now I can add Pharo to that list as well.

I'm glad you got a chance to work through the tutorial. Although I haven't updated it for Seaside 3.0, I hope it helped answer some of your question. Did the persistence approach in chapter 10 make sense? Did chapter 14 provide much help with setting up a Monticello repository? Did chapter 16 help in moving things to GemStone?

> Today I spent most of my day sneezing (it's fall and I know it...) and
> between the sneezing, i managed to load all my VW classes into Pharo
> 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.
>
> I know that that is radically different on an OODB.
>
> So I am looking into patterns on how to access my data.
>
> Should I use class variables to hold my instances? Or should I create
> "repositories" for these instances? and what should they look like.

I lean toward the approach that Sean suggested (a 'system' object to hold your collections), but you won't go far wrong starting with anything that works, including class instance variables.

> In java there are numerous ways/patterns to get hold of your data from
> RDBMS systems. I was wondering if there are approaches as widely
> described as in Java available for gemstone.

Since the persistence problem isn't as complicated in GemStone as it is with Java, I don't think that as much effort has gone into solving it.

James

> Regards,
>
> Bart
>
> 2010/9/30 James Foster <[hidden email]>:
>> Bart,
>>
>> In addition to the excellent comments from others, I would invite you to try my tutorial at http://seaside.gemstone.com/tutorial.html. With it you walk through developing an application in Pharo and then deploying it in GemStone. Several of your questions will be answered as you work through the examples. You can also watch videos of me going through the tutorial.
>>
>> James
>>
>> On Sep 30, 2010, at 11:46 AM, Bart Veenstra wrote:
>>
>>> Hi,
>>>
>>> I am currently moving from VW/Glorp to Pharo to use Gemstone as my
>>> object database.
>>>
>>> Since my mind is still setup in the RDBMS mode, I need to find out
>>> many things to work efficiently with Gemstone.
>>>
>>> Are there best practices available somewhere?
>>>
>>> Some of the questions i would like have answerd:
>>>
>>> - How to model the accessing of the persisted objects.
>>> I saw many posts in this mailing lists where you define a System for
>>> each object you whish to have an access point to. There are a lot of
>>> references made to UserGlobals, but where can I find that? Can that
>>> only be accessed by a Gem?
>>>
>>> - How to work with the persisted objects in a development environment.
>>> I use Pharo on my Windows system connecting to Gemstone using the
>>> gemtools client. Can I work with the persisted objects in gemstone
>>> from Seaside running in Pharo?
>>>
>>> - Where to setup your local monticello repository.
>>> I moved my code from VW to Pharo using the monticello plugin. MCZ
>>> files are written in .package-cache and I can import them in pharo
>>> mostly without problems. How do you effeciently manage versions in
>>> pharo en gemstone?
>>>
>>> - Caveats in developing with gemstone.
>>> What are the limitations or reoccurring annoyances when using Pharo &
>>> Gemstone? Things to be wary of?
>>>
>>> Regards,
>>>
>>> Bart
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Ramon Leon-5
In reply to this post by Bart Veenstra
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

GemstoneDb-rjl.22.mcz (8K) Download Attachment
GemstoneDbTests-rjl.2.mcz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

FDominicus
In reply to this post by Dale Henrichs
Dale Henrichs <[hidden email]> writes:

>
> When folks talk about developing in Pharo and deploying in GemStone,
> that means that they write their application using image-based
> persistence - a persistence model shared by GemStone and Pharo.
Can you elaborate a bit on the above paragraph? So does it mean they do
not connect to the Gemstone Server but are working on the Pharo
side. And if they "store" things they store it really in the Pharo
image?


>
> Developing in Pharo lets you take advantage of the full set of Pharo
> development tools. Developing in Pharo is faster, since all
> interaction with the tools in a GemTools environment involves
> communication over the wire...
Sorry but I understand if I do use the Pharo tools then there might be
troubles getting this run into Gemstone. Am I mistaken  about that?
Not all classes available in Pharo can be used unchanged in Gemstone or
am I wrong?

Regards
Friedrich

--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

NorbertHartl

On 01.10.2010, at 08:01, Friedrich Dominicus wrote:

Dale Henrichs <[hidden email]> writes:


When folks talk about developing in Pharo and deploying in GemStone,
that means that they write their application using image-based
persistence - a persistence model shared by GemStone and Pharo.
Can you elaborate a bit on the above paragraph? So does it mean they do
not connect to the Gemstone Server but are working on the Pharo
side. And if they "store" things they store it really in the Pharo
image?

Yes, the image is an object memory/store. So if you create objects and attach them anywhere they just persist (in the sense of not being garbage collected). If you save your image the objects are persistent as well. For testing it is sufficient. Taking gemstone you do the same "creating an object and attach it". The difference is that in gemstone the object is then persisted automatically most of the time. But from the view of developing you can consider the persistence model to be equal. 
In addition I use Sixx to serialize my objects from gemstone and deserialize it in pharo to have more real data to play with.


Developing in Pharo lets you take advantage of the full set of Pharo
development tools. Developing in Pharo is faster, since all
interaction with the tools in a GemTools environment involves
communication over the wire...
Sorry but I understand if I do use the Pharo tools then there might be
troubles getting this run into Gemstone. Am I mistaken  about that?
Not all classes available in Pharo can be used unchanged in Gemstone or
am I wrong?

That is right. There are things that are missing on one or the other side. Talking about developing in pharo and deploying in gemstone you do a couple of things. First you do not use gemstone specific stuff in your code but that is ovious as long as you are developing in pharo. Next is the things that are present in pharo but not in gemstone. The easiest way is to add that is to add it to the compatibility package (Squeak) in gemstone to have it available. For syntax problems you should check you code with slime at least. If it comes to things that are just different in gemstone than in pharo you can try to avoid using them or you need some nasty workaround. Probably grease and/or sport help you out on that one.
I would say take all of the bold font terms from above and add a little experience with your tools and you should be on the safe side.

Norbert
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Bart Veenstra
I am charmed at the way Norbert Hartl uses this "System" approach:

Quote: "
I'm late in the thread. There were quite a few very good response. As
I don't know where to reply I just do it to the first message. I don't
know if I can add some valuable but I want to share my experience on
this.

I started to use class vars for holding instances a while ago. It bit
me every single time I upgraded something. Knowing that you just need
to copy your instances from an old class version makes it easier but
the overall setup becomes error prone. The same goes for using a class
as key somewhere. Back then I also tried something like

UserGlobals at: MyClass

This does not work either. After an upgrade the class MyClass is just
different from the class when you used it as a key. Sorry but true
these are two rules for me to make my life easier: avoid using class
vars for persistent data and don't use classes directly as key
anywhere.

As I am a lazy person I changed the setup to work more generic than to
care for every single domain class in *System approach.

Now I use this approach (which is nearly the same as you advized).

HRModel class>>default
        ^ default ifNil: [ default := HRModel new ]

HRModel class>>instancesOf: aClass
        ^ self default instancesOf: aClass

HRModel>>root
        ^ root ifNil: [ root := IdentityDictionary new ]

HRModel>>at: aString
        ^ self root at: aString ifAbsentPut: [ OrderedCollection new ]

HRModel>>instancesOf: aClass
        ^ self at: aClass name

Then in the base class or any class of my model I add

HRSomeThing class>>instances
        ^ HRModel instancesOf: self

This way I avoid using class vars and the classes are resolved by
name. Works out pretty well so far.

For the other topic about providing safe cancel operations I like to
put Magritte in the mix. It does exactly this. It handles mementos of
your object model as long as you are working on it. The memento itself
has a save and cancel operation to write the content back to the
object or throw it away. From a gemstone point of view where
everything is written as soon as it has been changed it is the perfect
match. Well, it is another piece of not-so-lightweight software but I
think it is worth it.
"

Is there only one instance of this HRModel which holds all the
instances of the rest of his domain model? Or should I define a System
for each domain object which needs an access point

Like User has  UserSystem and Images has a ImageSystem with methods to
work with these instances.

Regards.

Bart


2010/10/1 Norbert Hartl <[hidden email]>:

>
> On 01.10.2010, at 08:01, Friedrich Dominicus wrote:
>
> Dale Henrichs <[hidden email]> writes:
>
>
> When folks talk about developing in Pharo and deploying in GemStone,
>
> that means that they write their application using image-based
>
> persistence - a persistence model shared by GemStone and Pharo.
>
> Can you elaborate a bit on the above paragraph? So does it mean they do
> not connect to the Gemstone Server but are working on the Pharo
> side. And if they "store" things they store it really in the Pharo
> image?
>
> Yes, the image is an object memory/store. So if you create objects and
> attach them anywhere they just persist (in the sense of not being garbage
> collected). If you save your image the objects are persistent as well. For
> testing it is sufficient. Taking gemstone you do the same "creating an
> object and attach it". The difference is that in gemstone the object is then
> persisted automatically most of the time. But from the view of developing
> you can consider the persistence model to be equal.
> In addition I use Sixx to serialize my objects from gemstone and deserialize
> it in pharo to have more real data to play with.
>
> Developing in Pharo lets you take advantage of the full set of Pharo
>
> development tools. Developing in Pharo is faster, since all
>
> interaction with the tools in a GemTools environment involves
>
> communication over the wire...
>
> Sorry but I understand if I do use the Pharo tools then there might be
> troubles getting this run into Gemstone. Am I mistaken  about that?
> Not all classes available in Pharo can be used unchanged in Gemstone or
> am I wrong?
>
> That is right. There are things that are missing on one or the other side.
> Talking about developing in pharo and deploying in gemstone you do a couple
> of things. First you do not use gemstone specific stuff in your code but
> that is ovious as long as you are developing in pharo. Next is the things
> that are present in pharo but not in gemstone. The easiest way is to add
> that is to add it to the compatibility package (Squeak) in gemstone to have
> it available. For syntax problems you should check you code with slime at
> least. If it comes to things that are just different in gemstone than in
> pharo you can try to avoid using them or you need some nasty workaround.
> Probably grease and/or sport help you out on that one.
> I would say take all of the bold font terms from above and add a little
> experience with your tools and you should be on the safe side.
> Norbert
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

NorbertHartl

On 01.10.2010, at 14:56, Bart Veenstra wrote:

> I am charmed at the way Norbert Hartl uses this "System" approach:
>
:)

> Quote: "
> I'm late in the thread. There were quite a few very good response. As
> I don't know where to reply I just do it to the first message. I don't
> know if I can add some valuable but I want to share my experience on
> this.
>
> I started to use class vars for holding instances a while ago. It bit
> me every single time I upgraded something. Knowing that you just need
> to copy your instances from an old class version makes it easier but
> the overall setup becomes error prone. The same goes for using a class
> as key somewhere. Back then I also tried something like
>
> UserGlobals at: MyClass
>
> This does not work either. After an upgrade the class MyClass is just
> different from the class when you used it as a key. Sorry but true
> these are two rules for me to make my life easier: avoid using class
> vars for persistent data and don't use classes directly as key
> anywhere.
>
> As I am a lazy person I changed the setup to work more generic than to
> care for every single domain class in *System approach.
>
> Now I use this approach (which is nearly the same as you advized).
>
> HRModel class>>default
>        ^ default ifNil: [ default := HRModel new ]
>
> HRModel class>>instancesOf: aClass
>        ^ self default instancesOf: aClass
>
> HRModel>>root
>        ^ root ifNil: [ root := IdentityDictionary new ]
>
> HRModel>>at: aString
>        ^ self root at: aString ifAbsentPut: [ OrderedCollection new ]
>
> HRModel>>instancesOf: aClass
>        ^ self at: aClass name
>
> Then in the base class or any class of my model I add
>
> HRSomeThing class>>instances
>        ^ HRModel instancesOf: self
>
> This way I avoid using class vars and the classes are resolved by
> name. Works out pretty well so far.
>
> For the other topic about providing safe cancel operations I like to
> put Magritte in the mix. It does exactly this. It handles mementos of
> your object model as long as you are working on it. The memento itself
> has a save and cancel operation to write the content back to the
> object or throw it away. From a gemstone point of view where
> everything is written as soon as it has been changed it is the perfect
> match. Well, it is another piece of not-so-lightweight software but I
> think it is worth it.
> "
>
> Is there only one instance of this HRModel which holds all the
> instances of the rest of his domain model? Or should I define a System
> for each domain object which needs an access point
>
> Like User has  UserSystem and Images has a ImageSystem with methods to
> work with these instances.
>
I think that is purely a matter of style. If you have only a few domain classes than a single "System" class might be sufficient. If you have a lot of classes the "System" class gets cluttered really quick. On the other hand if you can partition your domain model in a senseful way than having a system for each is feasible. Think about the lookup/query/helper methods you will have. If you partion your "System" classes than you shouldn't have the need to call a lot of other "System" classes while providing lookup/query/helper methods. Maybe this view sheds some light how to do it right. Otherwise I would suggest to start with a single one and separate them when it gets more complex and feel the need to do so.

Norbert

>
> 2010/10/1 Norbert Hartl <[hidden email]>:
>>
>> On 01.10.2010, at 08:01, Friedrich Dominicus wrote:
>>
>> Dale Henrichs <[hidden email]> writes:
>>
>>
>> When folks talk about developing in Pharo and deploying in GemStone,
>>
>> that means that they write their application using image-based
>>
>> persistence - a persistence model shared by GemStone and Pharo.
>>
>> Can you elaborate a bit on the above paragraph? So does it mean they do
>> not connect to the Gemstone Server but are working on the Pharo
>> side. And if they "store" things they store it really in the Pharo
>> image?
>>
>> Yes, the image is an object memory/store. So if you create objects and
>> attach them anywhere they just persist (in the sense of not being garbage
>> collected). If you save your image the objects are persistent as well. For
>> testing it is sufficient. Taking gemstone you do the same "creating an
>> object and attach it". The difference is that in gemstone the object is then
>> persisted automatically most of the time. But from the view of developing
>> you can consider the persistence model to be equal.
>> In addition I use Sixx to serialize my objects from gemstone and deserialize
>> it in pharo to have more real data to play with.
>>
>> Developing in Pharo lets you take advantage of the full set of Pharo
>>
>> development tools. Developing in Pharo is faster, since all
>>
>> interaction with the tools in a GemTools environment involves
>>
>> communication over the wire...
>>
>> Sorry but I understand if I do use the Pharo tools then there might be
>> troubles getting this run into Gemstone. Am I mistaken  about that?
>> Not all classes available in Pharo can be used unchanged in Gemstone or
>> am I wrong?
>>
>> That is right. There are things that are missing on one or the other side.
>> Talking about developing in pharo and deploying in gemstone you do a couple
>> of things. First you do not use gemstone specific stuff in your code but
>> that is ovious as long as you are developing in pharo. Next is the things
>> that are present in pharo but not in gemstone. The easiest way is to add
>> that is to add it to the compatibility package (Squeak) in gemstone to have
>> it available. For syntax problems you should check you code with slime at
>> least. If it comes to things that are just different in gemstone than in
>> pharo you can try to avoid using them or you need some nasty workaround.
>> Probably grease and/or sport help you out on that one.
>> I would say take all of the bold font terms from above and add a little
>> experience with your tools and you should be on the safe side.
>> Norbert

Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Dale Henrichs
In reply to this post by FDominicus
Friedrich Dominicus wrote:
> Dale Henrichs <[hidden email]> writes:
>
>> When folks talk about developing in Pharo and deploying in GemStone,
>> that means that they write their application using image-based
>> persistence - a persistence model shared by GemStone and Pharo.
> Can you elaborate a bit on the above paragraph?

I was referring to the fact that Pharo and GemStone share the
image-based _model_ of storage, not that they share the same object graph.

> So does it mean they do
> not connect to the Gemstone Server but are working on the Pharo
> side. And if they "store" things they store it really in the Pharo
> image?

When developing in Pharo, you are using a standard Pharo image (no
connection to GemStone) and you write your code using the image-based
persistence model.

When developing in GemTools, the Pharo vm is connected to GemStone and
all GemTools are manipulating the objects in the GemStone VM.

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.

Dale
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Jon Paynter-2


On Fri, Oct 1, 2010 at 9:49 AM, Dale Henrichs <[hidden email]> wrote:
Friedrich Dominicus wrote:
Dale Henrichs <[hidden email]> writes:

When folks talk about developing in Pharo and deploying in GemStone,
that means that they write their application using image-based
persistence - a persistence model shared by GemStone and Pharo.
Can you elaborate a bit on the above paragraph?

I was referring to the fact that Pharo and GemStone share the image-based _model_ of storage, not that they share the same object graph.


So does it mean they do
not connect to the Gemstone Server but are working on the Pharo
side. And if they "store" things they store it really in the Pharo
image?

When developing in Pharo, you are using a standard Pharo image (no connection to GemStone) and you write your code using the image-based persistence model.

When developing in GemTools, the Pharo vm is connected to GemStone and all GemTools are manipulating the objects in the GemStone VM.

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.

Also - depending on what or where your client is going to be,  you could save save a lot of hassle, and start your development directly in gemstone.  Then there are no worries of future issues with porting or syntax or subtle behavior differences.  Like Dale says - the code is the same, and the browsers look the same.
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Bart Veenstra
I can do that when I use a classbrowser in GemTools? That would be
very very cool!

2010/10/1 Jon Paynter <[hidden email]>:

>
>
> On Fri, Oct 1, 2010 at 9:49 AM, Dale Henrichs <[hidden email]> wrote:
>>
>> Friedrich Dominicus wrote:
>>>
>>> Dale Henrichs <[hidden email]> writes:
>>>
>>>> When folks talk about developing in Pharo and deploying in GemStone,
>>>> that means that they write their application using image-based
>>>> persistence - a persistence model shared by GemStone and Pharo.
>>>
>>> Can you elaborate a bit on the above paragraph?
>>
>> I was referring to the fact that Pharo and GemStone share the image-based
>> _model_ of storage, not that they share the same object graph.
>>
>>> So does it mean they do
>>> not connect to the Gemstone Server but are working on the Pharo
>>> side. And if they "store" things they store it really in the Pharo
>>> image?
>>
>> When developing in Pharo, you are using a standard Pharo image (no
>> connection to GemStone) and you write your code using the image-based
>> persistence model.
>>
>> When developing in GemTools, the Pharo vm is connected to GemStone and all
>> GemTools are manipulating the objects in the GemStone VM.
>>
>> 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.
>
> Also - depending on what or where your client is going to be,  you could
> save save a lot of hassle, and start your development directly in gemstone.
>  Then there are no worries of future issues with porting or syntax or subtle
> behavior differences.  Like Dale says - the code is the same, and the
> browsers look the same.
>
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Bart Gauquie
In reply to this post by Jon Paynter-2
Is there any support or plan for the refactor tools in Gemstone/pharo?

Can't live without in Pharo.

Regards,

Bart

On Fri, Oct 1, 2010 at 7:17 PM, Jon Paynter <[hidden email]> wrote:


On Fri, Oct 1, 2010 at 9:49 AM, Dale Henrichs <[hidden email]> wrote:
Friedrich Dominicus wrote:
Dale Henrichs <[hidden email]> writes:

When folks talk about developing in Pharo and deploying in GemStone,
that means that they write their application using image-based
persistence - a persistence model shared by GemStone and Pharo.
Can you elaborate a bit on the above paragraph?

I was referring to the fact that Pharo and GemStone share the image-based _model_ of storage, not that they share the same object graph.


So does it mean they do
not connect to the Gemstone Server but are working on the Pharo
side. And if they "store" things they store it really in the Pharo
image?

When developing in Pharo, you are using a standard Pharo image (no connection to GemStone) and you write your code using the image-based persistence model.

When developing in GemTools, the Pharo vm is connected to GemStone and all GemTools are manipulating the objects in the GemStone VM.

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.

Also - depending on what or where your client is going to be,  you could save save a lot of hassle, and start your development directly in gemstone.  Then there are no worries of future issues with porting or syntax or subtle behavior differences.  Like Dale says - the code is the same, and the browsers look the same.



--
imagination is more important than knowledge - Albert Einstein
Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein
Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein
The true sign of intelligence is not knowledge but imagination. - Albert Einstein
However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill
It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

SeanTAllen
In reply to this post by Jon Paynter-2


On Fri, Oct 1, 2010 at 1:17 PM, Jon Paynter <[hidden email]> wrote:


On Fri, Oct 1, 2010 at 9:49 AM, Dale Henrichs <[hidden email]> wrote:
Friedrich Dominicus wrote:
Dale Henrichs <[hidden email]> writes:

When folks talk about developing in Pharo and deploying in GemStone,
that means that they write their application using image-based
persistence - a persistence model shared by GemStone and Pharo.
Can you elaborate a bit on the above paragraph?

I was referring to the fact that Pharo and GemStone share the image-based _model_ of storage, not that they share the same object graph.


So does it mean they do
not connect to the Gemstone Server but are working on the Pharo
side. And if they "store" things they store it really in the Pharo
image?

When developing in Pharo, you are using a standard Pharo image (no connection to GemStone) and you write your code using the image-based persistence model.

When developing in GemTools, the Pharo vm is connected to GemStone and all GemTools are manipulating the objects in the GemStone VM.

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.

Also - depending on what or where your client is going to be,  you could save save a lot of hassle, and start your development directly in gemstone.  Then there are no worries of future issues with porting or syntax or subtle behavior differences.  Like Dale says - the code is the same, and the browsers look the same.

The one issue there is that, you don't have the same level of tool support when just developing in Gemstone rather than doing in Pharo first. Hernan, Joel and I spent 9 months working on a large Seaside based application that would run on Gemstone. Aside from one issue with my realizing at the last moment that we were using Swazoo for Seaside serving and the Soap package uses Hyper ( which do not place nice together ), our entire time 'porting' from Pharo to Gemstone was less than 1 day. Add in my marathon session to do a version of Hyper & Soap that didnt have class name conflicts with Swazoo ( a nasty endeavor ) and it was 2 days tops.

123