Re: Programmatically Picking Elements
Re: Programmatically Picking Elements
- Subject: Re: Programmatically Picking Elements
- From: Pierce Freeman <email@hidden>
- Date: Sat, 27 Jun 2009 11:17:12 -0700
- Thread-topic: Programmatically Picking Elements
Hey Kyle:
Thanks for your reply... I looks like that took a lot of time to type. ;)
>
> Ah. Please do re-read the documentation, as it will at the very least
> better inform your vocabulary. An "outlet" is a property or instance
> variable that has been tagged with the IBOutlet macro and as such is
> available for wiring in Interface Builder. For example, the
> nextResponder outlet on instance of NSResponder. Objects themselves
> cannot be outlets.
>
> The term you're looking for is "View." Read the View Programming
> Guide, especially the section on the View Hierarchy. Everything
> contained in a window is a view. Views draw themselves in response to
> -drawRect: (sometimes using helper objects like instances of NSCell).
> Views can also contain other views.
>
I suppose that's what I get from constantly switching between web
programming and Cocoa programming. Sometimes it takes a few days to fully
switch mindsets - Which my clients don't seem to be too willing to give me.
>
> First off, only tackle this if you are incredibly comfortable with the
> view hierarchy and Cocoa in general. You're going to need to
> understand a lot about how views work, much more than just playing
> around with IB will tell you.
Unfortunately, I kind of figured this... Most of the complex things aren't
easy. Yes, obviously, as they are considered complex. ;)
>
> Secondly, you're going to need a very sharp delineation between your
> business-side concept of a user interface and the Cocoa concept of a
> user interface. Your business terms, for example, might include
> things such as "List of People" or "Expense Report." Your Cocoa terms
> are things like NSTableView and NSTextFieldCell. Your biggest
> challenge is going to be drawing the line between these two things,
> and sometimes it's very difficult to say what is a business
> requirement and what is an implementation detail. You're only ready
> to make these distinctions when you've had quite a bit of experience
> with the framework.
>
> Third, don't expect to implement a web-based Interface Builder. You
> will set yourself up for failure quite quickly. Resist the temptation
> to offer your users a generic table in which they can create columns,
> bind controls to business objects, etc. There's a tool that does that
> already, and its name is Interface Builder. It sounds like you're
> developing an internal application -- despite the fact that this setup
> allows for greater communication and faster turnaround between the
> developers and the customers, too often developers (myself included)
> have taken a very release-oriented attitude. You don't need to make a
> super-generic tool that your customers can use to implement their
> dream interface. You have the convenience of proximity, which means
> the customer can walk down the hall and say: "We need a window that
> looks like X so we can do Y." Those of us in the consumer software
> market would kill for this kind of customer interactivity. Besides,
> do your customers really want to learn how to make an interface?
> They've got more important things to do!
I feel really bad about typing this next part as it looks like that took a
LOT of time to write. When I said "more going for" I more meant the
following:
A user logs on to a web application. They have some options for filing a
web report. Choices: single line and multiple line. They can choose how
many of these fields they have for various variables that they want to
input. This is then saved in a MYSQL database for later use.
The client side application fetches the data in the MYSQL databases and then
displays it. The problem is that it is a variable number of fields and a
variable number of types.
So, it's technically not a online Interface Builder - I think I'll let the
capable guys at 280 North handle that. It's more a dynamic online tool,
which I think may require a lot of the same tools. But I'll let more
experienced people (you) tell me if I'm totally wrong on that.
>
> In short, don't try to obsolete yourself. You will wind up with
> happier customers if you accept your limitations and they accept
> theirs. Take advantage of your situation: iterate frequently, be
> responsive to customer needs, and don't be afraid to say "no" to crazy
> requirements proposals -- including your own.
That's very good advice, especially with dealing with some of my clients.
One wants some fading elements, noises, complete dynamic... On the web. Just
Wow.
Once again, thanks for all your help.
Sincerely,
Pierce Freeman
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden