home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.next.programmer
- Path: sparky!uunet!ukma!wupost!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!ssircar@canon.com
- From: ssircar@canon.com (Subrata Sircar)
- Subject: Re: Splitting apps into UI and core server?
- Message-ID: <9211161959.AA12141@alychne-nc.canon.com>
- Sender: daemon@magnus.acs.ohio-state.edu
- Reply-To: ssircar@canon.com
- Organization: The Ohio State University
- Date: Mon, 16 Nov 1992 20:01:43 GMT
- Lines: 27
-
-
- I thought the point of the CoreServer was NOT to pass all messages through it,
- but to use it to buffer the UI from the implementation. To that end, I was
- thinking of something along the lines of:
-
- - every object has a UI delegate
- - all the [genericField setIntValue:] and [gField intValue] calls would be
- replaces by [UIDelegate setGenericFieldIntValue:] and [UIDelegate
- getGenericFieldIntValue] type calls.
- - alert panels are generated by [UIDelegate runAlertPanel::::]
-
- Incidentally, this does mean a lot of cross-talking, but not necessarily more
- objects; one UI delegate could serve multiple objects. The cross-talking means
- that I'm effectively doubling the number of messages needed to change UI (or
- adding one) and that might be a concern.
-
- That takes care of 90% of my interaction with UI. Disabling buttons and so
- forth can be done in a similar fashion. In fact, for most of this, you could
- probably use compiler macros rather than a second object (although that won't
- give you the true decoupling necessary for vending your object between several
- interfaces).
-
- ---
- Subrata Sircar|ssircar@canon.com (NextMail ok)|Prophet & SPAMIT Charter Member
- Canon Information Systems and I do not share the same views on everything.
- "I'm just mad that I missed the sexual revolution." - me
- "Yes, but you dress much better as a result." - Mike
-