Re: some thoughts on the active record support (Rubycocoa-devel 899) - RubyCocoa

thanks for the great response, my comments are inline below

On 5/25/07, Eloy Duran <eloy.****@gmail*****> wrote:
>
> Hi Jean-Pierre
>
> On 5/25/07, jeanp****@gmail***** <jeanp****@gmail*****> wrote:
> >
> > i gave the active record'ified maildemo sample and it is really neat. a
> few
> > questions i had along the way:
> >
> > rather than include the migrations in the application, would it be
> possible
> > to package only the resulting schema? it seems like migrations are an
> > affordance to developers and for end users it wouldn't do a whole lot
> (maybe
> > even slower?). in a rails app i think the schema is generated from
> >   % rake db:migrate
>
> Yes this is a good idea that I need to investigate, it's now on my
> TODO list. I primarily did it this way (for now) because it would
> allow you to immediately move on from where you left off in
> development mode.
> So just create a new migration and the existing db will be upgraded if
> necessary.

excellent, i love migrations for development but it might be overkill for
users :)
thanks for the TODO list on the wiki too, it is nice to know what things are
planned and others might poke into

> maybe rubycocoa needs some default rake tasks too :)
> Be careful what you wish for.... :)

i think we could come up with some good ones, aside from migrations we could
have stuff like packaging an application (wrapping standaloneify perhaps),
and what not.

i've written some that dynamically wrap an xcode project's targets and
configurations that might be helpful.

> will support for other active record-supported database be added?
> Except for the dbfile creation in the app support folder it should already
> work.
> I have used it with mysql for instance, however there isn't a simple
> connect
> way yet like with sqlite. So if you would like to connect to mysql for
> instance,
> simply replace the connection code in MyController.rb with something like
> this:
>
> # Connect to the database
> ActiveRecord::Base.establish_connection({
>   :adapter => 'mysql',
>   :host => 'localhost',
>   :username => 'user',
>   :password => 'pass',
>   :database => 'db'
> })
>
> See
> http://railsmanual.org/class/ActiveRecord%3A%3ABase#establish_connection
> for more examples.
>
> We could create a extra connector method which loads the connection in
> the same way as it's done in rails, a yaml file.
> If people have suggestions on this topic please let me know.

excellent, for some reason i didn't think to use the default ActiveRecord
connection methods and thought there was something rubycocoa specific that i
should be using. maybe it needs its own wiki page :)

> i'm a bit confused on EmailProxy#rbValueForKey. could this be addressed at
> a
> > different level? if i tweak the pure objc/bindings MailDemo and
> represent
> > the body as an NSString ivar rather than the dictionary, i am not
> required
> > to convert it to an NSAttributedString. of course not using that bit of
> code
> > i see:
> >   NSInternalInconsistencyException - Cannot create
> > NSAttributedString from object sample text of class NSCFString
> > (OSX::OCException)
> >
> > if a String is bridged to NSString shouldn't that be enough?
>
> In the case of a NSTextField it expects a NSAttributedString, which
> the bridge won't do for us.
> So this is why it's converted in the EmailProxy, it's actually also a
> demo of where you should handle these kind of cases.
>
> However, before anything is written to the db #to_ruby is called on the
> object
> which will try to resolve it and return a string for a NSAttributedString.
> Doing this the opposite way is a bit harder since we would need to know
> the
> type of object that is expected by the object that's bound to this column.
> (the text field in this case)
> I believe resolving which bindings have been established is already a very
> hard task, let alone figuring out what kind of type they expect...
> If I'm wrong in this (which would be better) I obviously would like to
> know.

ahh i see, thank you for adding some commentary on that. an
NSAttributedString isn't even a subclass of NSString (instead NSObject) so i
have no idea why/how the pure objc route gets to avoid this problem :)

and now an odd question - if i wanted to automatically synthesize a proxy
class much like dr nic's magic models does for activerecord model classes
(dynamically generate a UI for a database), where would that be best done?
override the OSX module's const_missing method?

  module OSX
    def self.const_missing(class_id)
      # stuff
    end
  end

how could i alias the original class method?

cheers,
jean-pierre
-------------- next part --------------
An HTML attachment was scrubbed...
Descargar 

RubyCocoa

[Rubycocoa-devel 899] Re: some thoughts on the active record support