Re: [ANN] NSTableView Assistant
Re: [ANN] NSTableView Assistant
- Subject: Re: [ANN] NSTableView Assistant
- From: Andy Satori <email@hidden>
- Date: Sat, 14 Jun 2003 21:57:55 -0400
I've been working on something similar but from a different different
direction. My project isn't ready for general usage yet, but it's
generating Cocoa Java or Objective C collections, that optionally
support NSCoding and / or NSTableView datasource methods, but unlike
this tools, doesn't even attempt to wire to the NIB, nor does it
attempt to push it's results in and out of Project Builder. It's
lagging a bit because I've been working on it's related Wizard /
Assistant, and that is the 'Object' and the 'Object from Database table
schema' wizards, both of which I personally use alot in my development
efforts. I did these for my old job in Windows, and I found them great
foundations, so now I want it for Cocoa.
My gripe is that I'm having to tie it to a specific DB, in this case
I'm targeting OpenBase for phase I, I might add Oracle, and perhaps
Postgres as a phase II or III. I *really* wish the ODBC drivers for OS
X were more readily available and supported, and a nice Cocoa C wrapper
for the ODBC engine would be huge.
Andy
On Saturday, June 14, 2003, at 08:22 PM, Chris Meyer wrote:
Hi Uli,
Thanks for the great beginning of a tool.
After a quick use I noticed the following items:
- importing from a Nib file may contain multiple tables; it might be
nice to give the user the choice of which table for which to generate
the code.
- some column names might not be valid objective-c names (i.e.
"Date-time"); the user might want to edit the mapping of column names
to method names
- the 'item' have code for NSCoding (old style and keyed, of course)
and NSCopying; the power really starts to show if it does this!
- the table could easily implement (optionally) default methods for
dragging/dropping rows and a variety of other things (double clicking,
etc.)
- an even more radical thought is that this entire thing could be done
with NO generated code; only a library and a generic nibbed-object
that handled the fields (more on this)
Ideally tools like this shouldn't contain any editable code for the
user; yet the user should be able to customize any aspect of things.
This is what always frustrated me using 'wizards' in the Windows
development environments; once code was generated you either had to
modify and forget about using the wizard to 'add a column' or stay
away from certain marked sections of code that the wizard would later
use. Cocoa is nice because for the most part it gets around this
problem to some degree; editing Nibs and adding outlets and other
connections is a painless process. Every bit of code that the user has
to write is absolutely necessary and also generally something that IB
doesn't care about. It would be nice to make this table editor
something similar.
If the 'item' were simply a generic list of fields stored in an array
then all of the niceties (NSCopying, NSCoding, drag&drop, etc.) of
that object could be hidden away in that object and the user would not
have to even have the code for 'item'; an array might not be most
efficient but this would be a detail that would be hidden from the
user so it would be easy to change. The wizard then would be concerned
with connecting user specific actions to the fields of that item,
similar to how IB connects outlets and targets. But the table wizard
could have a whole bunch of default behavior for the common cases so a
user might not have to do any specific coding.
Ideally in the end you end up with a wizard that can generate AND EDIT
your items that fit within a table view. There are a ton of extensions
to this idea such as support for undo, hooking up the items to a
database, handling outline views, etc. Also, I've never used EO
framework so I might just be describing that; I kind of get the
feeling that it is something along those lines already. Anyone with
experience care to comment?
In any case, any chance of putting this up on Source Forge? I might be
interesting in contributing a couple of more ideas to it (of course
Source Forge and .nib files aren't the happiest bedfellows
unfortunately).
It's nice to see something useful come out of the original 'troubling
article' post!
Chris Meyer
LQ Graphics, Inc.
On Saturday, June 14, 2003, at 08:59 AM, Uli Kusterer wrote:
Folks,
that recent thread inspired me to write a little "Assistant" (or in
non-Apple parlance "Wizard") that generates the necessary backend
classes for an NSTableView. If anyone would like to test (or even
use) it, point your browser at:
http://www.zathras.de/programming/cocoa_stuff.php
Right now, the assistant touts the following features:
-> Extracts column identifiers from NIB files
-> Generates ObjC source code for list items, table delegate and
data source (the latter two may be combined into one class if >> desired)
-> Auto-generates code to display custom cell types such as
Pushbuttons, check boxes, combo boxes, NSImages etc.
Source code to the assistant is available under the GPL (submissions
are welcome!), while the generated code is explicitly exempt from the
license (i.e. you can use it for commercial projects).
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.