On Thu, Jun 25, 2009 at 1:20 PM, Pierce Freeman<piercefreema...@comcast.net> wrote: > While there may be a more official name for them (outlets, maybe?), I > consider an "element" to be any element that goes on the screen. For > instance a NSTextField or a NSImageView.
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 am more going for creating a UI on the server and then displaying it on > the client side. Does this still fall under the category of "View > Programming", or something different entirely? 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. 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! 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. Read the docs and play around with Cocoa a bit more before attempting a project of such a scale as the one you've described. Remember the tenet of "Make One To Throw Away," and have fun while doing it. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
