Re: Best approach to make session based applications
Re: Best approach to make session based applications
- Subject: Re: Best approach to make session based applications
- From: Greg Guerin <email@hidden>
- Date: Sun, 10 May 2009 19:34:19 -0700
Marcus wrote:
This is something I've been thinking about for a while without
making much progress. Let's say that you have an application where
you would have one or many "documents" but where the documents
itself are not tied to a specific file. Examples of such
applications could be terminal emulators or FTP clients.
My first idea was to use a standard single window application and
have each "session" controlled by an instance of a controller
object. That however would give a lot of manual tasks, things like
setting the location of new windows stacked relative to the
previous window etc. That's things that I would more of less get
for free by using NSDocument and NSDocumentController, but they
seem to be more tied to the concept of working with files.
I have done some testing with both methods but I can't decide which
one is the most appropriate to use. How would you approach making
that kind of application?
It depends.
A typical "document" is a chunk of state, typically editable and
persistent. Given that, an app that edits pictures is using
"documents", but a terminal emulator isn't. At best, the terminal
emulator's "document" is a set of collected settings (colors, type
styling, etc.)
On the other hand, a connection to a big SQL database may be backed
by a huge persistent state (i.e. the database), but present a less
stateful representation to the user, e.g. the possibly ephemeral
results from various formulated queries. In that case, the user's
perception of "document" might be the queries, not the backing store
or a given result set.
So it largely depends on what kind of editable and/or persistable
state you have, and how that relates to the user's perception of it.
Since you haven't described any of that except in general terms, it's
difficult to provide any suggestions that aren't equally general, IMO.
-- GG
_______________________________________________
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