Would a macruby-newbie List Be Worthwhile?
There are a number of questions I know I have coming from a Ruby/Rails and not a Cocoa background. These questions can be difficult to answer in the context of Objective-C (and heck, Ruby makes a lot of the Objective-C syntactic vinegar just go away). They are also not specifically about MacRuby, but rather about how it interacts with the framework. Because MacRuby can open up Cocoa to developers who really didn't want to mess around with [[obj alloc] init] and all that stuff. Many of you on this list did go through that learning experience but have already answered these same questions before in a different context but shouldn't be imposed upon to answer them again. Would a newbie list be worth creating? I find myself coming up with seemingly stupid questions that I simply don't want to trouble the list with but that take hours to dig out of the documentation. That would be the proposed purpose. Post some code, expected results, and what's actually happening. Maybe an example: I want a single pane Core Data application but I forgot to select the template that creates an appDelegate. How do I get a managedObject context and how do I add some seed data to that collection once it's bound to an NSTableView. See? Complicated n00b question that requires IB steps and Ruby steps. Takes quite a bit of trekking around in the documentation to figure out. But someone who's walked the same path before could answer it right away. Comments?
Hi "S",
Would a newbie list be worth creating?
I would encourage you to just go ahead and ask on this list, for several reasons: a) The people who would answer are here, so they may as well answer b) It could be a bug, in which case it belongs here c) It helps us understand usage issues, which may inform features and documentation The more interesting question to me is when do we create a macruby-users list for those using the "stable" version -- or move development OF macruby to a "macruby-core"? I guess it depends on when MacRuby is stable enough and popular enough. At any rate, it isn't yet. -enp On Dec 15, 2009, at 11:21 AM, s.ross wrote:
There are a number of questions I know I have coming from a Ruby/Rails and not a Cocoa background. These questions can be difficult to answer in the context of Objective-C (and heck, Ruby makes a lot of the Objective-C syntactic vinegar just go away). They are also not specifically about MacRuby, but rather about how it interacts with the framework.
Because MacRuby can open up Cocoa to developers who really didn't want to mess around with [[obj alloc] init] and all that stuff. Many of you on this list did go through that learning experience but have already answered these same questions before in a different context but shouldn't be imposed upon to answer them again. Would a newbie list be worth creating? I find myself coming up with seemingly stupid questions that I simply don't want to trouble the list with but that take hours to dig out of the documentation. That would be the proposed purpose. Post some code, expected results, and what's actually happening.
Maybe an example: I want a single pane Core Data application but I forgot to select the template that creates an appDelegate. How do I get a managedObject context and how do I add some seed data to that collection once it's bound to an NSTableView. See? Complicated n00b question that requires IB steps and Ruby steps. Takes quite a bit of trekking around in the documentation to figure out. But someone who's walked the same path before could answer it right away.
Comments? _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Thanks for your feedback... On Dec 15, 2009, at 4:19 PM, Ernest N. Prabhakar, Ph.D. wrote:
Hi "S",
Point taken :)
Would a newbie list be worth creating?
I would encourage you to just go ahead and ask on this list, for several reasons:
a) The people who would answer are here, so they may as well answer
That's what someone says every time somebody else suggests forking a list. I hope it's the right answer because a lot of my questions would be off topic both on this list and the Cocoa Developers list.
b) It could be a bug, in which case it belongs here
Yeah, but at this point, I think many of us can tell when it's our own fault :)
c) It helps us understand usage issues, which may inform features and documentation
Again, point taken.
The more interesting question to me is when do we create a macruby-users list for those using the "stable" version -- or move development OF macruby to a "macruby-core"?
I guess it depends on when MacRuby is stable enough and popular enough. At any rate, it isn't yet.
-enp
On Dec 15, 2009, at 11:21 AM, s.ross wrote:
There are a number of questions I know I have coming from a Ruby/Rails and not a Cocoa background. These questions can be difficult to answer in the context of Objective-C (and heck, Ruby makes a lot of the Objective-C syntactic vinegar just go away). They are also not specifically about MacRuby, but rather about how it interacts with the framework.
Because MacRuby can open up Cocoa to developers who really didn't want to mess around with [[obj alloc] init] and all that stuff. Many of you on this list did go through that learning experience but have already answered these same questions before in a different context but shouldn't be imposed upon to answer them again. Would a newbie list be worth creating? I find myself coming up with seemingly stupid questions that I simply don't want to trouble the list with but that take hours to dig out of the documentation. That would be the proposed purpose. Post some code, expected results, and what's actually happening.
Maybe an example: I want a single pane Core Data application but I forgot to select the template that creates an appDelegate. How do I get a managedObject context and how do I add some seed data to that collection once it's bound to an NSTableView. See? Complicated n00b question that requires IB steps and Ruby steps. Takes quite a bit of trekking around in the documentation to figure out. But someone who's walked the same path before could answer it right away.
Comments? _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Steve, I agree with Ernie. I am always happy to answer questions if I think the person is not rude, or asking me to write their entire app - and that is, so far, rare on this list. Usually when I get it wrong other people pipe up ;-). Some seemingly simple questions do often lead to a bug fix too. Regarding your example, I not sure whether you did it or not, here is what I would do (i just tried this - so I know it works). (Apropos Core Data: I have created a Core Data Document Template for XCode - it probably needs a bit of testing - but if anyone is interested let me know and i will post it somewhere) Imagine you have created a (non document) app with out any CoreData infrastructure, then: 1. Create a new file in your project - standard ruby class, name it AppDelegate (or whatever you like). 2. Copy and paste the boiler plate code that you would get if you had an AppDelegate created from the Core Data template (eg from another project) to this file, change the name of the xml file you are saving to (about line 50 in the current template). Also add/create a new mapping model (thats in the resource section when creating a new file), it will be used automatically. or alternatively: 1&2. Create a new CoreData project from the template, and just drag these two files into the old project (in Xcode - not the finder). 3. in IB drag an nsobject into the ib project from the library, set the class to be the AppDelegate (or whatever you class is called that holds the boilerplate Core Data stuff above), also set the window iboutlet in the app delegate to the window (not actually sure if this is necessary - but the template comes like that). And make sure the application delegates to your app delegate (control drag from the application to your new app delegate). 4. Continue as you would normally with a core data app. The second part, filling with data (presumably you will only need to do this once, because then the data can be saved with the app). There are many ways to add data. The easiest I reckon, is to add a method to the AppDelegate - called applicationDidFinishLaunching(notification) (delegated from the application singleton) and in that method you can do something like: new_student = NSEntityDescription.insertNewObjectForEntityForName("Student", inManagedObjectContext:self.managedObjectContext). Then set the attributes for that obj, eg student.name = "Bill". This was at a high-ish level - if there is something that you don't understand, feel free to ask - but ask in the next 7 hours, because I will be traveling and incommunicado for a couple of days. Cheers, John On Dec 16, 2009, at 7:37 , steve ross wrote:
Thanks for your feedback...
On Dec 15, 2009, at 4:19 PM, Ernest N. Prabhakar, Ph.D. wrote:
Hi "S",
Point taken :)
Would a newbie list be worth creating?
I would encourage you to just go ahead and ask on this list, for several reasons:
a) The people who would answer are here, so they may as well answer
That's what someone says every time somebody else suggests forking a list. I hope it's the right answer because a lot of my questions would be off topic both on this list and the Cocoa Developers list.
b) It could be a bug, in which case it belongs here
Yeah, but at this point, I think many of us can tell when it's our own fault :)
c) It helps us understand usage issues, which may inform features and documentation
Again, point taken.
The more interesting question to me is when do we create a macruby-users list for those using the "stable" version -- or move development OF macruby to a "macruby-core"?
I guess it depends on when MacRuby is stable enough and popular enough. At any rate, it isn't yet.
-enp
On Dec 15, 2009, at 11:21 AM, s.ross wrote:
There are a number of questions I know I have coming from a Ruby/Rails and not a Cocoa background. These questions can be difficult to answer in the context of Objective-C (and heck, Ruby makes a lot of the Objective-C syntactic vinegar just go away). They are also not specifically about MacRuby, but rather about how it interacts with the framework.
Because MacRuby can open up Cocoa to developers who really didn't want to mess around with [[obj alloc] init] and all that stuff. Many of you on this list did go through that learning experience but have already answered these same questions before in a different context but shouldn't be imposed upon to answer them again. Would a newbie list be worth creating? I find myself coming up with seemingly stupid questions that I simply don't want to trouble the list with but that take hours to dig out of the documentation. That would be the proposed purpose. Post some code, expected results, and what's actually happening.
Maybe an example: I want a single pane Core Data application but I forgot to select the template that creates an appDelegate. How do I get a managedObject context and how do I add some seed data to that collection once it's bound to an NSTableView. See? Complicated n00b question that requires IB steps and Ruby steps. Takes quite a bit of trekking around in the documentation to figure out. But someone who's walked the same path before could answer it right away.
Comments? _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Dec 16, 2009, at 1:07 AM, John Shea wrote:
The second part, filling with data (presumably you will only need to do this once, because then the data can be saved with the app). There are many ways to add data.
The easiest I reckon, is to add a method to the AppDelegate - called applicationDidFinishLaunching(notification) (delegated from the application singleton) and in that method you can do something like: new_student = NSEntityDescription.insertNewObjectForEntityForName("Student", inManagedObjectContext:self.managedObjectContext). Then set the attributes for that obj, eg student.name = "Bill".
Let me be more specific about *why* this is important to me. My app goes out to a Web Service for data, so I have to fill some of it in programmatically, then it refreshes only occasionally. I decided this would be best in the controller, so it could be triggered by the user. To emulate that, I wanted to prepopulate the managedObject collection, and that I did in awakeFromNib. Warning: Make sure to call super! So what it boiled down to what this method in the controller: def new_image(image = {}) object = NSEntityDescription.insertNewObjectForEntityForName("Image", inManagedObjectContext:managedObjectContext) object.setValue image[:fileid], forKey: 'fileid' object.setValue image[:title], forKey: 'title' puts "#{object} #{object.fileid} : #{object.title}" end I used the setters explicitly when I was confused about why the bound tableview was blank. I'm beginning to get this a bit more under control, but the IB/CoreData/Cocoa Bindings is even magical to a Ruby person :) See? I told you it was a dumb question. Thanks, Steve
On Wed, Dec 16, 2009 at 9:11 AM, steve ross <cwdinfo@gmail.com> wrote:
On Dec 16, 2009, at 1:07 AM, John Shea wrote:
The second part, filling with data (presumably you will only need to do this once, because then the data can be saved with the app). There are many ways to add data.
The easiest I reckon, is to add a method to the AppDelegate - called applicationDidFinishLaunching(notification) (delegated from the application singleton) and in that method you can do something like: new_student = NSEntityDescription.insertNewObjectForEntityForName("Student", inManagedObjectContext:self.managedObjectContext). Then set the attributes for that obj, eg student.name = "Bill".
Let me be more specific about *why* this is important to me. My app goes out to a Web Service for data, so I have to fill some of it in programmatically, then it refreshes only occasionally. I decided this would be best in the controller, so it could be triggered by the user. To emulate that, I wanted to prepopulate the managedObject collection, and that I did in awakeFromNib. Warning: Make sure to call super! So what it boiled down to what this method in the controller:
def new_image(image = {}) object = NSEntityDescription.insertNewObjectForEntityForName("Image", inManagedObjectContext:managedObjectContext) object.setValue image[:fileid], forKey: 'fileid' object.setValue image[:title], forKey: 'title' puts "#{object} #{object.fileid} : #{object.title}" end
I used the setters explicitly when I was confused about why the bound tableview was blank. I'm beginning to get this a bit more under control, but the IB/CoreData/Cocoa Bindings is even magical to a Ruby person :)
See? I told you it was a dumb question.
Thanks,
Steve _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
If MacRuby is your first exposure to mac programming and all of the associated tools and techniques, starting out by jumping into an IB-based project that uses CoreData & Bindings is going to be really confusing. I'd break up the tasks into pieces small enough that you can actually understand what's going on. You shouldn't feel like things are happening "magically". If that is the case, then try to take a step back and figure out how the magic trick works. For example, if you want to tackle CoreData first, then start with just CoreData. Build a command-line program that creates a CoreData stack by reading in your compiled .xcdatamodel (or create the model in code!), add some data, and save it. Once you've got that working, then make it download data from your web service and save it. Here is the approach I would take: 1. If you haven't already, read through the Core Data Programming guide: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDa... At the very least, browse through this to get a feel for what's going on. You won't understand everything, but at least you'll have some sense of where to look when you get stuck. 2. Read the Core Data Utility tutorial: http://developer.apple.com/mac/library/documentation/cocoa/conceptual/CoreDa... This gives you a basic Obj-C version of a program the uses CoreData entirely through the API. Everything is done in code, even creating the model, so it should get you started on something basic. 3. As it turns out, Matt Gallagher (cocoawithlove.com) recently posted an excellent article on parsing CSV files and importing the data into CoreData: http://cocoawithlove.com/2009/11/writing-parser-using-nsscanner-csv.html I highly recommend you also download and read through his code to see how it works. 4. Use the code from #2 & #3 to write a minimal implementation in MacRuby that imports data into your model. 5. After getting #4 to work, go back and read the section on efficiently importing data in the CoreData programming guide and refactor your import code appropriately. At least this way, if you get stuck on #4 & #5, you'll have a fairly short, self-contained example program that you can put in a gist, post a link, and ask for help on specific parts.
On Dec 16, 2009, at 2:25 PM, Brian Chapados wrote:
On Wed, Dec 16, 2009 at 9:11 AM, steve ross <cwdinfo@gmail.com> wrote:
On Dec 16, 2009, at 1:07 AM, John Shea wrote:
The second part, filling with data (presumably you will only need to do this once, because then the data can be saved with the app). There are many ways to add data.
The easiest I reckon, is to add a method to the AppDelegate - called applicationDidFinishLaunching(notification) (delegated from the application singleton) and in that method you can do something like: new_student = NSEntityDescription.insertNewObjectForEntityForName ("Student", inManagedObjectContext:self.managedObjectContext). Then set the attributes for that obj, eg student.name = "Bill".
Let me be more specific about *why* this is important to me. My app goes out to a Web Service for data, so I have to fill some of it in programmatically, then it refreshes only occasionally. I decided this would be best in the controller, so it could be triggered by the user. To emulate that, I wanted to prepopulate the managedObject collection, and that I did in awakeFromNib. Warning: Make sure to call super! So what it boiled down to what this method in the controller:
def new_image(image = {}) object = NSEntityDescription.insertNewObjectForEntityForName ("Image", inManagedObjectContext:managedObjectContext) object.setValue image[:fileid], forKey: 'fileid' object.setValue image[:title], forKey: 'title' puts "#{object} #{object.fileid} : #{object.title}" end
I used the setters explicitly when I was confused about why the bound tableview was blank. I'm beginning to get this a bit more under control, but the IB/CoreData/Cocoa Bindings is even magical to a Ruby person :)
See? I told you it was a dumb question.
Thanks,
Steve _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
If MacRuby is your first exposure to mac programming and all of the associated tools and techniques, starting out by jumping into an IB-based project that uses CoreData & Bindings is going to be really confusing.
I'd break up the tasks into pieces small enough that you can actually understand what's going on. You shouldn't feel like things are happening "magically". If that is the case, then try to take a step back and figure out how the magic trick works.
For example, if you want to tackle CoreData first, then start with just CoreData. Build a command-line program that creates a CoreData stack by reading in your compiled .xcdatamodel (or create the model in code!), add some data, and save it. Once you've got that working, then make it download data from your web service and save it.
Here is the approach I would take:
1. If you haven't already, read through the Core Data Programming guide: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDa...
At the very least, browse through this to get a feel for what's going on. You won't understand everything, but at least you'll have some sense of where to look when you get stuck.
2. Read the Core Data Utility tutorial: http://developer.apple.com/mac/library/documentation/cocoa/conceptual/CoreDa...
This gives you a basic Obj-C version of a program the uses CoreData entirely through the API. Everything is done in code, even creating the model, so it should get you started on something basic.
3. As it turns out, Matt Gallagher (cocoawithlove.com) recently posted an excellent article on parsing CSV files and importing the data into CoreData: http://cocoawithlove.com/2009/11/writing-parser-using-nsscanner-csv.html
I highly recommend you also download and read through his code to see how it works.
4. Use the code from #2 & #3 to write a minimal implementation in MacRuby that imports data into your model.
5. After getting #4 to work, go back and read the section on efficiently importing data in the CoreData programming guide and refactor your import code appropriately.
At least this way, if you get stuck on #4 & #5, you'll have a fairly short, self-contained example program that you can put in a gist, post a link, and ask for help on specific parts. _________________________________
And 6. Once you believe you understand how everything works, submit a sample code to us! :-) Laurent
Great answers from all the other folks. Directly at the end of this mail I have my copied my version of the core data utility tutorial - but without NSPredicates. Created when I was trying to test binding and core data (turned out to be a different issue), that might help when you translate the real thing. Note that at the time was using setValue rather than .value= . regarding:
Let me be more specific about *why* this is important to me. My app goes out to a Web Service for data, so I have to fill some of it in programmatically, then it refreshes only occasionally. I decided this would be best in the controller, so it could be triggered by the user. To emulate that, I wanted to prepopulate the managedObject collection, and that I did in awakeFromNib. Warning: Make sure to call super! So what it boiled down to what this method in the controller:
def new_image(image = {}) object = NSEntityDescription.insertNewObjectForEntityForName("Image", inManagedObjectContext:managedObjectContext) object.setValue image[:fileid], forKey: 'fileid' object.setValue image[:title], forKey: 'title' puts "#{object} #{object.fileid} : #{object.title}" end
I used the setters explicitly when I was confused about why the bound tableview was blank. I'm beginning to get this a bit more under control, but the IB/CoreData/Cocoa Bindings is even magical to a Ruby person :)
I guess using setvalueforkey might be useful if you are running through the hash keys - and are not really sure what key values are coming down (otherwise object.title = image[:title] is nicer). I also guess by now you are using an in memory store - not xml, since you are not storing anything locally. As you can see from the code below if there is a key missing in your download I guess you could also just insert it as a new attribute into the entity - you could even auto add columns to the table view or custom view decorated by a nsscrollview. I went down a similar route once and found there was so much meta that i could not test, nor debug easily nor concentrate on the business problem at hand. As the others suggested - simpler is better - although you might like to still use the NSInMemoryStoreType. In which case you may need to prepareContent yourself manually since there are a view model/view time based dependancies that are normally handled for you with the other persistent store types. Scott Stevenson's Core data tutorials are worth doing too. Hope that helps. John framework "Cocoa" ### binding and observing setup class Observa def initialize(obj) p "added observer" obj.addObserver(self, forKeyPath:"work", options:NSKeyValueObservingOptionNew|NSKeyValueObservingOptionOld, context:nil) obj.addObserver(self, forKeyPath:"energy", options:NSKeyValueObservingOptionNew|NSKeyValueObservingOptionOld, context:nil) end def observeValueForKeyPath(keyPath, ofObject:object, change:change, context:context) val = object.valueForKey(keyPath) p "keypath: #{keyPath} val:#{val} class:#{val.class}" end end class Copier attr_accessor :energy, :work end ##core data setup mom = NSManagedObjectModel.alloc.init myEntity = NSEntityDescription.alloc.init myEntity.setName("NumberTest") myEntity.setManagedObjectClassName("NumberTest") mom.setEntities([myEntity]) energy = NSAttributeDescription.alloc.init energy.setName("energy") energy.setAttributeType(NSFloatAttributeType) energy.setOptional(false) energy.setDefaultValue(123.45) work = NSAttributeDescription.alloc.init work.setName("work") work.setAttributeType(NSDecimalAttributeType) work.setOptional(false) work.setDefaultValue(123.45) output = NSAttributeDescription.alloc.init output.setName("output") output.setAttributeType(NSFloatAttributeType) output.setOptional(false) output.setDefaultValue(123.45) tariff = NSAttributeDescription.alloc.init tariff.setName("tariff") tariff.setAttributeType(NSDecimalAttributeType) tariff.setOptional(false) tariff.setDefaultValue(300.34) immutable_array = NSArray.arrayWithArray([energy, work, output, tariff]) myEntity.setProperties(immutable_array) moc = NSManagedObjectContext.alloc.init coordinator = NSPersistentStoreCoordinator.alloc.initWithManagedObjectModel(mom) moc.setPersistentStoreCoordinator(coordinator) error = Pointer.new(:object) url = NSURL.fileURLWithPath("~/CDFloatTest.cdft") newStore = coordinator.addPersistentStoreWithType(NSXMLStoreType,configuration:nil,URL:url,options:nil, error:error) floater = NSManagedObject.alloc.initWithEntity(myEntity, insertIntoManagedObjectContext:moc) ##end core data setup ####start accessor, kvc and binding tests p "standard accessor" p floater.energy p floater.work p "keys" p "#{floater.energy.class} #{floater.valueForKey("energy").class}" p "#{floater.work.class} #{floater.valueForKey("work").class}" p "set" floater.energy = 456.67 p floater.energy p "#{floater.energy.class} #{floater.valueForKey("energy").class}" floater.work = 456.67 p floater.work #changes to NSDecimalNumber p "#{floater.work.class} #{floater.valueForKey("work").class}" avalue = Copier.new options = {NSAllowsEditingMultipleValuesSelectionBindingOption => true} avalue.bind("energy", toObject:floater, withKeyPath:"energy", options:options) avalue.bind("work", toObject:floater, withKeyPath:"work", options:options) obie = Observa.new(floater) 2.times do floater.setValue(rand(10) * 1.234, forKey:"work") sleep 1 p "avalue work #{avalue.work}. #{avalue.work.class}" end p "--" 2.times do floater.setValue(rand(10) * 1.234, forKey:"energy") sleep 1 p "avalue energy #{avalue.energy}. #{avalue.energy.class}" end On Dec 17, 2009, at 12:40 AM, Laurent Sansonetti wrote:
On Dec 16, 2009, at 2:25 PM, Brian Chapados wrote:
On Wed, Dec 16, 2009 at 9:11 AM, steve ross <cwdinfo@gmail.com> wrote:
On Dec 16, 2009, at 1:07 AM, John Shea wrote:
The second part, filling with data (presumably you will only need to do this once, because then the data can be saved with the app). There are many ways to add data.
The easiest I reckon, is to add a method to the AppDelegate - called applicationDidFinishLaunching(notification) (delegated from the application singleton) and in that method you can do something like: new_student = NSEntityDescription.insertNewObjectForEntityForName("Student", inManagedObjectContext:self.managedObjectContext). Then set the attributes for that obj, eg student.name = "Bill".
Let me be more specific about *why* this is important to me. My app goes out to a Web Service for data, so I have to fill some of it in programmatically, then it refreshes only occasionally. I decided this would be best in the controller, so it could be triggered by the user. To emulate that, I wanted to prepopulate the managedObject collection, and that I did in awakeFromNib. Warning: Make sure to call super! So what it boiled down to what this method in the controller:
def new_image(image = {}) object = NSEntityDescription.insertNewObjectForEntityForName("Image", inManagedObjectContext:managedObjectContext) object.setValue image[:fileid], forKey: 'fileid' object.setValue image[:title], forKey: 'title' puts "#{object} #{object.fileid} : #{object.title}" end
I used the setters explicitly when I was confused about why the bound tableview was blank. I'm beginning to get this a bit more under control, but the IB/CoreData/Cocoa Bindings is even magical to a Ruby person :)
See? I told you it was a dumb question.
Thanks,
Steve _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
If MacRuby is your first exposure to mac programming and all of the associated tools and techniques, starting out by jumping into an IB-based project that uses CoreData & Bindings is going to be really confusing.
I'd break up the tasks into pieces small enough that you can actually understand what's going on. You shouldn't feel like things are happening "magically". If that is the case, then try to take a step back and figure out how the magic trick works.
For example, if you want to tackle CoreData first, then start with just CoreData. Build a command-line program that creates a CoreData stack by reading in your compiled .xcdatamodel (or create the model in code!), add some data, and save it. Once you've got that working, then make it download data from your web service and save it.
Here is the approach I would take:
1. If you haven't already, read through the Core Data Programming guide: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDa...
At the very least, browse through this to get a feel for what's going on. You won't understand everything, but at least you'll have some sense of where to look when you get stuck.
2. Read the Core Data Utility tutorial: http://developer.apple.com/mac/library/documentation/cocoa/conceptual/CoreDa...
This gives you a basic Obj-C version of a program the uses CoreData entirely through the API. Everything is done in code, even creating the model, so it should get you started on something basic.
3. As it turns out, Matt Gallagher (cocoawithlove.com) recently posted an excellent article on parsing CSV files and importing the data into CoreData: http://cocoawithlove.com/2009/11/writing-parser-using-nsscanner-csv.html
I highly recommend you also download and read through his code to see how it works.
4. Use the code from #2 & #3 to write a minimal implementation in MacRuby that imports data into your model.
5. After getting #4 to work, go back and read the section on efficiently importing data in the CoreData programming guide and refactor your import code appropriately.
At least this way, if you get stuck on #4 & #5, you'll have a fairly short, self-contained example program that you can put in a gist, post a link, and ask for help on specific parts. _________________________________
And 6. Once you believe you understand how everything works, submit a sample code to us! :-)
Laurent _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (6)
-
Brian Chapados
-
Ernest N. Prabhakar, Ph.D.
-
John Shea
-
Laurent Sansonetti
-
s.ross
-
steve ross