One note about the tests of *FaDemoContactsTests*: previously i thought the tests of TestCase were run in alphabetical order. So three of tests may fail if they run before #test1AddingItemsToDB has run. On subsequent runs, the tests should all go green. -cam On Fri, Feb 13, 2015 at 5:36 PM, Cameron Sanders <camsanders@aol.com> wrote:
Stephan,
First let me say, if i can figure out the proper markdown to get color-coded inset-code looking right, i would gladly improve the DebrisDB description with more simple examples. Additionally, i am happy to answer questions in email. I will also consider a few video tutorials soon.
Now, most importantly: I checked in a new version. There was a gross error (#halt) that I accidentally checked in during recent edits ... that ... ahem, that would have caused several tests to fail. My apologies.
I defined a new Example-Contacts that will create a folder under the user home -- at least it works with Pharo on a Mac -- named ContactsApp/data and in that folder will leave a file called FaContactsDB.fdb after you have run the tests. The example consists of these classes:
*FaContactsDB* -- the class you use to get ahold of sessions to your application-specific conceptual DBs. It subclasses from FaDemoContactsAppDB, which subclasses from FaClassNamedDB. The only reason to create FaDemoContactsAppDB (or your specific version) is so that you can redirect all of your #session requests to an entirely different lookup mechanism. One can also redirect on a DB specific basis.
Saying 'FaContactsDB session' is the same as '(FaDBSessionServer instance getSession: #FaContactsDB)' ... given that FaClassNamedDB uses the classname. At Debris, our code is a little different, and we use the db-session lookup key of #contactsDB for this example. This becomes the name prefix for your fuel-file by default. So we can adjust this if desired.
*FaDemoContactsAppDataHub* -- see the class-side method #instance. Its #login: method assumes one repo... and configuration of multiple repos is easy, but i created several new classes in a hurry when i carved our Glorp-like-sessions away from our main code base. The "basic hub" this one uses is one of those "in a hurry" classes, and i like the new perspective it has given me. Admittedly, these are not well tested, but as you can see, simple, and the tests seem to work.
*FaDemoContactsContact* -- this is the only application specific class in this demo, with a very verbose name. This is the contact class that has a name, address and phone number.
*FaDemoContactsTests* -- this class illustrates how to interact with glorp sessions.
Good luck, and please don't hesitate to inquire if you need more info or encounter more problems.
-Cam
On Fri, Feb 13, 2015 at 11:29 AM, Stephan Eggermont <stephan@stack.nl> wrote:
Hi Cam
Interesting. The brain-dead-sample is a bit difficult to get started with. Would you care to talk a bit more about how to do something simple with it? An addressbook, with people having addresses and phone numbers might be an easy to use example.
Cheers, Stephan