Re: [ANN] NSTableView Assistant
Re: [ANN] NSTableView Assistant
- Subject: Re: [ANN] NSTableView Assistant
- From: Chris Meyer <email@hidden>
- Date: Sat, 14 Jun 2003 17:22:52 -0700
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.