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
|

Re: Best practices available for Seaside Gemstone?

Dale Henrichs
Bart Gauquie wrote:
> Is there any support or plan for the refactor tools in Gemstone/pharo?
>
> Can't live without in Pharo.
>
> Regards,
>
> Bart

Yes, there are plans. One of the original blockades was the fact that
the AST code hadn't been ported to GemStone ... earlier in the summer i
Ported the AST code to GemStone for use in Bibliocello, so Im thnking
that when I integrate the latest omnibrowser changes I'll take a crack
at the refactoring tools ...

Dale
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Bart Veenstra
Time for a new addition to this excellent thread with nice examples..

How do I manage object id's? Do I need to generate GUID's for each
object for having them accessed by an Url? Of use a number as
identifier?

Regards,

Bart

2010/10/1 Dale Henrichs <[hidden email]>:

> Bart Gauquie wrote:
>>
>> Is there any support or plan for the refactor tools in Gemstone/pharo?
>>
>> Can't live without in Pharo.
>>
>> Regards,
>>
>> Bart
>
> Yes, there are plans. One of the original blockades was the fact that the
> AST code hadn't been ported to GemStone ... earlier in the summer i Ported
> the AST code to GemStone for use in Bibliocello, so Im thnking that when I
> integrate the latest omnibrowser changes I'll take a crack at the
> refactoring tools ...
>
> Dale
>
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Jon Paynter-2
I think a better question is why do you need to manage object IDs?  Mostly I find you dont need to, as the gemstone persistance does it for you.

On Mon, Oct 4, 2010 at 12:46 PM, Bart Veenstra <[hidden email]> wrote:
Time for a new addition to this excellent thread with nice examples..

How do I manage object id's? Do I need to generate GUID's for each
object for having them accessed by an Url? Of use a number as
identifier?

Regards,

Bart

2010/10/1 Dale Henrichs <[hidden email]>:
> Bart Gauquie wrote:
>>
>> Is there any support or plan for the refactor tools in Gemstone/pharo?
>>
>> Can't live without in Pharo.
>>
>> Regards,
>>
>> Bart
>
> Yes, there are plans. One of the original blockades was the fact that the
> AST code hadn't been ported to GemStone ... earlier in the summer i Ported
> the AST code to GemStone for use in Bibliocello, so Im thnking that when I
> integrate the latest omnibrowser changes I'll take a crack at the
> refactoring tools ...
>
> Dale
>

Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Bart Veenstra
I know, but I need to access my object graph by URL.

for instance:
sandmin?path=sandmin/questioncategories/questioncategory_general/question_Leeftijd

I use this to traverse to the object and have it displayed. I like
human readable url's. Good for search engines to. Using JQuery address
I even change the url in my ajax application:

http://files.extractivity.com/questionmanager/sandmin#/sandmin/questioncategories/questioncategory_general/question_Leeftijd/questionComponents

The values after path and # are references to unique id's in my object model
Sandmin -> questioncategorylist -> General Question -> Question Leeftijd (age)

But for some things, I would like to have generated id's. What is the
best way to achieve this?
Regards,

Bart



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

> I think a better question is why do you need to manage object IDs?  Mostly I
> find you dont need to, as the gemstone persistance does it for you.
>
> On Mon, Oct 4, 2010 at 12:46 PM, Bart Veenstra <[hidden email]>
> wrote:
>>
>> Time for a new addition to this excellent thread with nice examples..
>>
>> How do I manage object id's? Do I need to generate GUID's for each
>> object for having them accessed by an Url? Of use a number as
>> identifier?
>>
>> Regards,
>>
>> Bart
>>
>> 2010/10/1 Dale Henrichs <[hidden email]>:
>> > Bart Gauquie wrote:
>> >>
>> >> Is there any support or plan for the refactor tools in Gemstone/pharo?
>> >>
>> >> Can't live without in Pharo.
>> >>
>> >> Regards,
>> >>
>> >> Bart
>> >
>> > Yes, there are plans. One of the original blockades was the fact that
>> > the
>> > AST code hadn't been ported to GemStone ... earlier in the summer i
>> > Ported
>> > the AST code to GemStone for use in Bibliocello, so Im thnking that when
>> > I
>> > integrate the latest omnibrowser changes I'll take a crack at the
>> > refactoring tools ...
>> >
>> > Dale
>> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Jon Paynter-2
the text between /'s look to be accessors?  if not, let me know.

Another thing is, what is your starting point?  im guessing you have a holder object named 'questioncategories'  and then work from there?  
What are you looking to do that your existing URL approach doesnt do? (other than keep the URL short).

Its possible to access objects by their oop number, but then your bypassing your object model, which leads to its own set of headaches.

On Mon, Oct 4, 2010 at 1:08 PM, Bart Veenstra <[hidden email]> wrote:
I know, but I need to access my object graph by URL.

for instance:
sandmin?path=sandmin/questioncategories/questioncategory_general/question_Leeftijd

I use this to traverse to the object and have it displayed. I like
human readable url's. Good for search engines to. Using JQuery address
I even change the url in my ajax application:

http://files.extractivity.com/questionmanager/sandmin#/sandmin/questioncategories/questioncategory_general/question_Leeftijd/questionComponents

The values after path and # are references to unique id's in my object model
Sandmin -> questioncategorylist -> General Question -> Question Leeftijd (age)

But for some things, I would like to have generated id's. What is the
best way to achieve this?
Regards,

Bart



2010/10/4 Jon Paynter <[hidden email]>:
> I think a better question is why do you need to manage object IDs?  Mostly I
> find you dont need to, as the gemstone persistance does it for you.
>
> On Mon, Oct 4, 2010 at 12:46 PM, Bart Veenstra <[hidden email]>
> wrote:
>>
>> Time for a new addition to this excellent thread with nice examples..
>>
>> How do I manage object id's? Do I need to generate GUID's for each
>> object for having them accessed by an Url? Of use a number as
>> identifier?
>>
>> Regards,
>>
>> Bart
>>
>> 2010/10/1 Dale Henrichs <[hidden email]>:
>> > Bart Gauquie wrote:
>> >>
>> >> Is there any support or plan for the refactor tools in Gemstone/pharo?
>> >>
>> >> Can't live without in Pharo.
>> >>
>> >> Regards,
>> >>
>> >> Bart
>> >
>> > Yes, there are plans. One of the original blockades was the fact that
>> > the
>> > AST code hadn't been ported to GemStone ... earlier in the summer i
>> > Ported
>> > the AST code to GemStone for use in Bibliocello, so Im thnking that when
>> > I
>> > integrate the latest omnibrowser changes I'll take a crack at the
>> > refactoring tools ...
>> >
>> > Dale
>> >
>
>

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,

For generating uniqueId's that can be used as ids in URLs, you should
use persistent shared counters (see System class>parsistentCounter* and
System class>>_updateSharedCounterAt:by:withOpCode: for details). The
counters can be accessed/updated without crossing a transaction boundary
... the counter is persistent so it has all of the ACID properties
associated with normal persistence...

As Jon mentioned, you should avoid the temptation to use the oop of the
object as an object id ... oops are recycled by the system after garbage
collection so the oop of an object cannot be said to be a truly unique
object id ... persistent counters _can_ ...

You will either want to create a dictionary (RCKeyValueDictionary to
avoid concurrent update conflicts) that uses the generated object ids as
keys or crate an index on the collection holding the objects ... the
dictionary approach will work on both Pharo and GemStone, while the
index approach will have to be simulated on Pharo (possibly by using
brute force lookups - I don't know of anyone who has mocked up the
indexing api on Pharo yet)...

Dale

Bart Veenstra wrote:

> I know, but I need to access my object graph by URL.
>
> for instance:
> sandmin?path=sandmin/questioncategories/questioncategory_general/question_Leeftijd
>
> I use this to traverse to the object and have it displayed. I like
> human readable url's. Good for search engines to. Using JQuery address
> I even change the url in my ajax application:
>
> http://files.extractivity.com/questionmanager/sandmin#/sandmin/questioncategories/questioncategory_general/question_Leeftijd/questionComponents
>
> The values after path and # are references to unique id's in my object model
> Sandmin -> questioncategorylist -> General Question -> Question Leeftijd (age)
>
> But for some things, I would like to have generated id's. What is the
> best way to achieve this?
> Regards,
>
> Bart
>
>
>
> 2010/10/4 Jon Paynter <[hidden email]>:
>> I think a better question is why do you need to manage object IDs?  Mostly I
>> find you dont need to, as the gemstone persistance does it for you.
>>
>> On Mon, Oct 4, 2010 at 12:46 PM, Bart Veenstra <[hidden email]>
>> wrote:
>>> Time for a new addition to this excellent thread with nice examples..
>>>
>>> How do I manage object id's? Do I need to generate GUID's for each
>>> object for having them accessed by an Url? Of use a number as
>>> identifier?
>>>
>>> Regards,
>>>
>>> Bart
>>>
>>> 2010/10/1 Dale Henrichs <[hidden email]>:
>>>> Bart Gauquie wrote:
>>>>> Is there any support or plan for the refactor tools in Gemstone/pharo?
>>>>>
>>>>> Can't live without in Pharo.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Bart
>>>> Yes, there are plans. One of the original blockades was the fact that
>>>> the
>>>> AST code hadn't been ported to GemStone ... earlier in the summer i
>>>> Ported
>>>> the AST code to GemStone for use in Bibliocello, so Im thnking that when
>>>> I
>>>> integrate the latest omnibrowser changes I'll take a crack at the
>>>> refactoring tools ...
>>>>
>>>> Dale
>>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Bart Veenstra
In reply to this post by Jon Paynter-2
Nope. not really. The model is an hiearchy one. Each node seperated by
'/' is accessed by its unique name from within the parents node.
Unreckognized nodes will go to a 404. You always need to start from
the root in the url, which in my case is the sandmin

How I traverse through the nodes is like this:

| root node |
        anArray isEmpty ifTrue: [^self].
       
        root := anArray first .
        "The first element MUST match the root model"
        (root notNil and: [root ~= self rootModel uniqueName]) ifTrue: [self
error: 'Root is missing'].
        "traverse all children to get the selected node "
        node := self rootModel.
        anArray allButFirst do:
                        [:each |
                        | child |
                        child := node findChildByUniqueName: each.
                        child ifNil: [self error: 'Child not found'].
                        node := child].
        ^node

I know it is not the best code to get around, but it does it's job
pretty well :)

I  can access all my stuff with this url without clicking through a
GUI to get to my object. Also makes bookmarking fun again :) (except
when i change the unique name)...

Regards,

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

> the text between /'s look to be accessors?  if not, let me know.
> Another thing is, what is your starting point?  im guessing you have a
> holder object named 'questioncategories'  and then work from there?
> What are you looking to do that your existing URL approach doesnt do? (other
> than keep the URL short).
> Its possible to access objects by their oop number, but then your bypassing
> your object model, which leads to its own set of headaches.
> On Mon, Oct 4, 2010 at 1:08 PM, Bart Veenstra <[hidden email]>
> wrote:
>>
>> I know, but I need to access my object graph by URL.
>>
>> for instance:
>>
>> sandmin?path=sandmin/questioncategories/questioncategory_general/question_Leeftijd
>>
>> I use this to traverse to the object and have it displayed. I like
>> human readable url's. Good for search engines to. Using JQuery address
>> I even change the url in my ajax application:
>>
>>
>> http://files.extractivity.com/questionmanager/sandmin#/sandmin/questioncategories/questioncategory_general/question_Leeftijd/questionComponents
>>
>> The values after path and # are references to unique id's in my object
>> model
>> Sandmin -> questioncategorylist -> General Question -> Question Leeftijd
>> (age)
>>
>> But for some things, I would like to have generated id's. What is the
>> best way to achieve this?
>> Regards,
>>
>> Bart
>>
>>
>>
>> 2010/10/4 Jon Paynter <[hidden email]>:
>> > I think a better question is why do you need to manage object IDs?
>> >  Mostly I
>> > find you dont need to, as the gemstone persistance does it for you.
>> >
>> > On Mon, Oct 4, 2010 at 12:46 PM, Bart Veenstra <[hidden email]>
>> > wrote:
>> >>
>> >> Time for a new addition to this excellent thread with nice examples..
>> >>
>> >> How do I manage object id's? Do I need to generate GUID's for each
>> >> object for having them accessed by an Url? Of use a number as
>> >> identifier?
>> >>
>> >> Regards,
>> >>
>> >> Bart
>> >>
>> >> 2010/10/1 Dale Henrichs <[hidden email]>:
>> >> > Bart Gauquie wrote:
>> >> >>
>> >> >> Is there any support or plan for the refactor tools in
>> >> >> Gemstone/pharo?
>> >> >>
>> >> >> Can't live without in Pharo.
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> Bart
>> >> >
>> >> > Yes, there are plans. One of the original blockades was the fact that
>> >> > the
>> >> > AST code hadn't been ported to GemStone ... earlier in the summer i
>> >> > Ported
>> >> > the AST code to GemStone for use in Bibliocello, so Im thnking that
>> >> > when
>> >> > I
>> >> > integrate the latest omnibrowser changes I'll take a crack at the
>> >> > refactoring tools ...
>> >> >
>> >> > Dale
>> >> >
>> >
>> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Dale Henrichs
Bart,

Since you already have a lookup mechanism defined, you won't need to use
a dictionary or indexed collection ... you just need to persistent
counter for generating unique ids...

Dale

Bart Veenstra wrote:

> Nope. not really. The model is an hiearchy one. Each node seperated by
> '/' is accessed by its unique name from within the parents node.
> Unreckognized nodes will go to a 404. You always need to start from
> the root in the url, which in my case is the sandmin
>
> How I traverse through the nodes is like this:
>
> | root node |
> anArray isEmpty ifTrue: [^self].
>
> root := anArray first .
> "The first element MUST match the root model"
> (root notNil and: [root ~= self rootModel uniqueName]) ifTrue: [self
> error: 'Root is missing'].
> "traverse all children to get the selected node "
> node := self rootModel.
> anArray allButFirst do:
> [:each |
> | child |
> child := node findChildByUniqueName: each.
> child ifNil: [self error: 'Child not found'].
> node := child].
> ^node
>
> I know it is not the best code to get around, but it does it's job
> pretty well :)
>
> I  can access all my stuff with this url without clicking through a
> GUI to get to my object. Also makes bookmarking fun again :) (except
> when i change the unique name)...
>
> Regards,
>
> Bart
> 2010/10/4 Jon Paynter <[hidden email]>:
>> the text between /'s look to be accessors?  if not, let me know.
>> Another thing is, what is your starting point?  im guessing you have a
>> holder object named 'questioncategories'  and then work from there?
>> What are you looking to do that your existing URL approach doesnt do? (other
>> than keep the URL short).
>> Its possible to access objects by their oop number, but then your bypassing
>> your object model, which leads to its own set of headaches.
>> On Mon, Oct 4, 2010 at 1:08 PM, Bart Veenstra <[hidden email]>
>> wrote:
>>> I know, but I need to access my object graph by URL.
>>>
>>> for instance:
>>>
>>> sandmin?path=sandmin/questioncategories/questioncategory_general/question_Leeftijd
>>>
>>> I use this to traverse to the object and have it displayed. I like
>>> human readable url's. Good for search engines to. Using JQuery address
>>> I even change the url in my ajax application:
>>>
>>>
>>> http://files.extractivity.com/questionmanager/sandmin#/sandmin/questioncategories/questioncategory_general/question_Leeftijd/questionComponents
>>>
>>> The values after path and # are references to unique id's in my object
>>> model
>>> Sandmin -> questioncategorylist -> General Question -> Question Leeftijd
>>> (age)
>>>
>>> But for some things, I would like to have generated id's. What is the
>>> best way to achieve this?
>>> Regards,
>>>
>>> Bart
>>>
>>>
>>>
>>> 2010/10/4 Jon Paynter <[hidden email]>:
>>>> I think a better question is why do you need to manage object IDs?
>>>>  Mostly I
>>>> find you dont need to, as the gemstone persistance does it for you.
>>>>
>>>> On Mon, Oct 4, 2010 at 12:46 PM, Bart Veenstra <[hidden email]>
>>>> wrote:
>>>>> Time for a new addition to this excellent thread with nice examples..
>>>>>
>>>>> How do I manage object id's? Do I need to generate GUID's for each
>>>>> object for having them accessed by an Url? Of use a number as
>>>>> identifier?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Bart
>>>>>
>>>>> 2010/10/1 Dale Henrichs <[hidden email]>:
>>>>>> Bart Gauquie wrote:
>>>>>>> Is there any support or plan for the refactor tools in
>>>>>>> Gemstone/pharo?
>>>>>>>
>>>>>>> Can't live without in Pharo.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Bart
>>>>>> Yes, there are plans. One of the original blockades was the fact that
>>>>>> the
>>>>>> AST code hadn't been ported to GemStone ... earlier in the summer i
>>>>>> Ported
>>>>>> the AST code to GemStone for use in Bibliocello, so Im thnking that
>>>>>> when
>>>>>> I
>>>>>> integrate the latest omnibrowser changes I'll take a crack at the
>>>>>> refactoring tools ...
>>>>>>
>>>>>> Dale
>>>>>>
>>>>
>>
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:
> 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?

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

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" ?

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?

Stephan Eggermont-3

On 6 okt 2010, at 07:18, Friedrich Dominicus wrote:
> I understand what you mean with the "Gemstone" image and the Pharo
> image. But the suggestion is doing development in Pharo FIRST?
>
> 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" ?

That is what we do. To make it work:
- do not take large steps, but integrate often (preferably automated)
- run Slime over your code. It detects a lot of incompatibilities.
- use Grease and Mock Gemstone

Stephan Eggermont

Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

NorbertHartl
In reply to this post by FDominicus

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

Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Bart Veenstra
Thank you for very helpfull tips! i'll install
http://seaside.gemstone.com/ss/MockGemStone.html asap.



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

>
> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Jon Paynter-2
ok im a little confused here.

While everything Norbert said works great - whats stopping you from starting your development in gemstone and just using the Pharo image as a front end?

On Wed, Oct 6, 2010 at 12:48 AM, Bart Veenstra <[hidden email]> wrote:
Thank you for very helpfull tips! i'll install
http://seaside.gemstone.com/ss/MockGemStone.html asap.



2010/10/6 Norbert Hartl <[hidden email]>:
>
> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Dale Henrichs
On 10/06/2010 10:07 AM, Jon Paynter wrote:
> ok im a little confused here.
>
> While everything Norbert said works great - whats stopping you from
> starting your development in gemstone and just using the Pharo image as
> a front end?

Jon,

The free version of the GemStone license doesn't support GBS (no
traversal buffers), which makes writing an app that uses Pharo as the UI
a bit more difficult (as opposed to a web-based GUI which the free
license is aimed at supporting).

Obviously GemTools is an application that uses Pharo as a UI, but the
object manipulation is at a pretty low level and the lack of traversal
buffers makes passing complex graphs to Pharo difficult at best. In
GemTools I believe that a collection of Text instances is the most
complicated object graph passed across the interface.

Most of the "develop in Pharo, deploy in GemStone" projects are based on
Seaside, so the gui is web-based.

Dale

>
> On Wed, Oct 6, 2010 at 12:48 AM, Bart Veenstra <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Thank you for very helpfull tips! i'll install
>     http://seaside.gemstone.com/ss/MockGemStone.html asap.
>
>
>
>     2010/10/6 Norbert Hartl <[hidden email]
>     <mailto:[hidden email]>>:
>      >
>      > On 06.10.2010, at 07:18, Friedrich Dominicus wrote:
>      >
>      >> Dale Henrichs <[hidden email] <mailto:[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
>      >
>      >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

NorbertHartl
In reply to this post by Jon Paynter-2

On 06.10.2010, at 19:07, Jon Paynter wrote:

ok im a little confused here.

While everything Norbert said works great - whats stopping you from starting your development in gemstone and just using the Pharo image as a front end?

Well, nothing :) What I wrote is just the complete process. After I started with gemstone I did exactly this. I had a local installation on my laptop and I just connected from pharo to the gemstone and developed there. It is working well, only the development tools are a bit older and there is some latency between keyboard actions and visual feedback but ok.
If you are planning to work on a remote gemstone than you will immediately see that it does not work that well. The performance of gemtools has been enhanced but the latency between your local and the remote image is cumbersome. 
With this approach you save yourself completely from the cross-platform hussle. And that might be a big reason to make it this way. It is just that we think the pharo to gemstone is good approach that is why everybody is telling it the same way :) 

That's all.

Norbert

On Wed, Oct 6, 2010 at 12:48 AM, Bart Veenstra <[hidden email]> wrote:
Thank you for very helpfull tips! i'll install
http://seaside.gemstone.com/ss/MockGemStone.html asap.



2010/10/6 Norbert Hartl <[hidden email]>:
>
> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Jon Paynter-2
On Wed, Oct 6, 2010 at 10:40 AM, Norbert Hartl <[hidden email]> wrote:

On 06.10.2010, at 19:07, Jon Paynter wrote:

ok im a little confused here.

While everything Norbert said works great - whats stopping you from starting your development in gemstone and just using the Pharo image as a front end?

Well, nothing :) What I wrote is just the complete process. After I started with gemstone I did exactly this. I had a local installation on my laptop and I just connected from pharo to the gemstone and developed there. It is working well, only the development tools are a bit older and there is some latency between keyboard actions and visual feedback but ok.
If you are planning to work on a remote gemstone than you will immediately see that it does not work that well. The performance of gemtools has been enhanced but the latency between your local and the remote image is cumbersome. 
With this approach you save yourself completely from the cross-platform hussle. And that might be a big reason to make it this way. It is just that we think the pharo to gemstone is good approach that is why everybody is telling it the same way :) 

That's all.

Ok having better dev tools makes a world of sense now.
Also what Dale said about having your gemstone access on a remote (slower) location.  I guess im spoiled by having mine run as a vmware appliance on my dev pc.

Thanks!
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

FDominicus
In reply to this post by NorbertHartl
Norbert Hartl <[hidden email]> writes:

> On 06.10.2010, at 19:07, Jon Paynter wrote:
>
>
>     ok im a little confused here.
>
>     While everything Norbert said works great - whats stopping you from
>     starting your development in gemstone and just using the Pharo image as a
>     front end?
>
>
> Well, nothing :) What I wrote is just the complete process. After I started
> with gemstone I did exactly this. I had a local installation on my laptop and I
> just connected from pharo to the gemstone and developed there. It is working
> well, only the development tools are a bit older and there is some latency
> between keyboard actions and visual feedback but ok.
> If you are planning to work on a remote gemstone than you will immediately see
> that it does not work that well.
May I ask something here again. So I have my Gemstone running on the
same machine as the GemTools so I see the latency even while working in
"local" mode. It's not much but one "sees" it. So you are not even
having a kind of "development" gemstone, but really am just working in
the Pharo image?

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?

SeanTAllen


On Thu, Oct 7, 2010 at 1:09 AM, Friedrich Dominicus <[hidden email]> wrote:
Norbert Hartl <[hidden email]> writes:

> On 06.10.2010, at 19:07, Jon Paynter wrote:
>
>
>     ok im a little confused here.
>
>     While everything Norbert said works great - whats stopping you from
>     starting your development in gemstone and just using the Pharo image as a
>     front end?
>
>
> Well, nothing :) What I wrote is just the complete process. After I started
> with gemstone I did exactly this. I had a local installation on my laptop and I
> just connected from pharo to the gemstone and developed there. It is working
> well, only the development tools are a bit older and there is some latency
> between keyboard actions and visual feedback but ok.
> If you are planning to work on a remote gemstone than you will immediately see
> that it does not work that well.
May I ask something here again. So I have my Gemstone running on the
same machine as the GemTools so I see the latency even while working in
"local" mode. It's not much but one "sees" it. So you are not even
having a kind of "development" gemstone, but really am just working in
the Pharo image?

 
GemTools is a client application that happens to run in Pharo. It connects to a server - Gemstone -
and allows you to manipulate code, data etc on the server. That is, it can be used for development,
debugging, maintenance etc for Gemstone. It is an alternative to topaz. 

If you are using Gemtools, you are not developing in Pharo. 

Does that make sense?
Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

dassi
In reply to this post by Bart Veenstra

Am 04.10.2010 um 22:08 schrieb Bart Veenstra:

> I know, but I need to access my object graph by URL.
>
> for instance:
> sandmin?path=sandmin/questioncategories/questioncategory_general/
> question_Leeftijd
>
> I use this to traverse to the object and have it displayed. I like
> human readable url's. Good for search engines to. Using JQuery address
> I even change the url in my ajax application:
>
> http://files.extractivity.com/questionmanager/sandmin#/sandmin/ 
> questioncategories/questioncategory_general/question_Leeftijd/
> questionComponents
>
> The values after path and # are references to unique id's in my  
> object model
> Sandmin -> questioncategorylist -> General Question -> Question  
> Leeftijd (age)
>
> But for some things, I would like to have generated id's. What is the
> best way to achieve this?

I had a similar need in an application, where I send out emails to  
users with a link back to the application. The link will contain an ID  
of a piece of content which will then be displayed. I am using  
instances of UUID (id := UUID new.) to generate a unique ID which  
identifies the object to display. I like the Uuid approach better than  
an increasing integer counter, because it adds extra "security", since  
it is much harder to guess existing IDs.

Greetings, Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Best practices available for Seaside Gemstone?

Bart Veenstra
I agree that it adds extra security, but the length is quite long (36
byte string). Do you also use these UID as key in a dictionary with
every instance, even from different classes.  for lookup?

2010/10/7 Brodbeck Andreas <[hidden email]>:

>
> Am 04.10.2010 um 22:08 schrieb Bart Veenstra:
>
>> I know, but I need to access my object graph by URL.
>>
>> for instance:
>>
>> sandmin?path=sandmin/questioncategories/questioncategory_general/question_Leeftijd
>>
>> I use this to traverse to the object and have it displayed. I like
>> human readable url's. Good for search engines to. Using JQuery address
>> I even change the url in my ajax application:
>>
>>
>> http://files.extractivity.com/questionmanager/sandmin#/sandmin/questioncategories/questioncategory_general/question_Leeftijd/questionComponents
>>
>> The values after path and # are references to unique id's in my object
>> model
>> Sandmin -> questioncategorylist -> General Question -> Question Leeftijd
>> (age)
>>
>> But for some things, I would like to have generated id's. What is the
>> best way to achieve this?
>
> I had a similar need in an application, where I send out emails to users
> with a link back to the application. The link will contain an ID of a piece
> of content which will then be displayed. I am using instances of UUID (id :=
> UUID new.) to generate a unique ID which identifies the object to display. I
> like the Uuid approach better than an increasing integer counter, because it
> adds extra "security", since it is much harder to guess existing IDs.
>
> Greetings, Andreas
>
>
123