Best practices available for Seaside Gemstone?
Locked
123
123
Best practices available for Seaside Gemstone?
 
|
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 |
Re: Best practices available for Seaside Gemstone?
|
|
On 9/30/10, Bart Veenstra <[hidden email]> wrote:
Hi, Ive seen 2 approaches here. For medium to large projects (like where I work), we use 1 class per collection: 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 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. 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.
|
Re: Best practices available for Seaside Gemstone?
|
|
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 |
Re: Best practices available for Seaside Gemstone?
|
|
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 |
Re: Best practices available for Seaside Gemstone?
|
|
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 > |
Re: Best practices available for Seaside Gemstone?
|
|
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! |
Re: Best practices available for Seaside Gemstone?
|
|
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 |
Re: Best practices available for Seaside Gemstone?
|
|
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 > > |
Re: Best practices available for Seaside Gemstone?
|
|
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. |
Re: Best practices available for Seaside Gemstone?
|
|
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 >> >> |
Re: Best practices available for Seaside Gemstone?
|
|
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)
Re: Best practices available for Seaside Gemstone?
|
|
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 |
Re: Best practices available for Seaside Gemstone?
|
|
On 01.10.2010, at 08:01, Friedrich Dominicus wrote: 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. 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
|
Re: Best practices available for Seaside Gemstone?
|
|
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 |
Re: Best practices available for Seaside Gemstone?
|
|
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. > 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 |
Re: Best practices available for Seaside Gemstone?
|
|
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 |
Re: Best practices available for Seaside Gemstone?
|
|
On Fri, Oct 1, 2010 at 9:49 AM, Dale Henrichs <[hidden email]> wrote:
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.
|
Re: Best practices available for Seaside Gemstone?
|
|
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. > |
Re: Best practices available for Seaside Gemstone?
|
|
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:
-- 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 |
Re: Best practices available for Seaside Gemstone?
|
|
In reply to this post by Jon Paynter-2
On Fri, Oct 1, 2010 at 1:17 PM, Jon Paynter <[hidden email]> wrote:
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.
|
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |