Re: More CChildFrame questions
- From: "GT" <ContactGT_remove_@xxxxxxxxxxx>
- Date: Thu, 21 Jun 2007 17:05:02 +0100
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:kf6l735dalaf80rai7ov0151src6l3t6a9@xxxxxxxxxx
I think the OP is merely confusing data and presentation. Therefore,
persists in the
notion that data == presentation and if you delete the presentation you
must therefore
delete the data. Then he denies the usability of the document because
"all the work is
done in a DLL", not realizing that the DOCUMENT is the place to keep the
DATA!
Without trying to be argumentative...
I have a significant amount of data for my application. This data is stored
in a database, rather than locally in the CDocument. Why do you say that I
should not use a database (in a DLL)?
I do not deny usability of anything, but have I have tried to design my
classes around the OO concept of encapsulation - data and work specific to a
particular class is done in that class.
Even if I moved all the data to the document, the view still needs to show
its 'view' of that data - that is encapsulation. I have several views of
(some of) the data:
1. A list view, which loops round the data and fills in columns. The code to
get this information lives in the list view class.
2. A tree view which loops round the data and shows names and structure. The
code to get this information is int he tree view class
3. I have three 'chart' views which loop round the data and show a chart.
The code to calculate graph chart points is in the chart classes. Are you
saying I should break encapsulation and move the work to do with the charts
into another (document) class?
The only difference between these classes is the amount of time required to
get the data and turn it into the visual representation - the charts take
several seconds to work out points.
In fact, I even question why "the view does the maths" when in fact the
COMPUTATION should
be in the document!
Surely the work to do with showing a chart should be done in the appropriate
chart class, not the document. In the app I have 3 similar charts and the
all have a calculateChartPoints method. If I move this to the document, I
will have 3 methods with the same name, or will have to rename methods and
confuse method calls. You said that the document is supposed to be for the
data, so its job should be to hold data and any simple validation/business
rules to accompany that data. It should not also contain work concerning
visual representations - that surely belongs in the appropriate
visualisation class.
The view is merely a minor and relatively trivial conceptual piece of
the effort, a mere way of presenting data.
But this is exactly what I am trying to do - write a view that presents a
chart! In order to display a chart, some work has to be done to calculate
the points on that chart. This work surely belongs in a method on the chart
class!
It is a fundamental misunderstanding of the
relationship of view and document, mistaking presentation for data.
No, I'm simply following UML and OO methodologies for good coding -
encapsulation and tidy/maintainable code!
Everyone keeps telling me it is difficult and problematic to separate views
from frames, but noone has told me why! I don't see the problem the frame is
the frame and the view is the view. Why can't I take my view instance and
put it in whatever frame I like? I can take a view out of a childframe and
put it into a docking pane, but the reverse doesn't work and this is what I
need help with!
.
- Follow-Ups:
- Re: More CChildFrame questions
- From: Joseph M . Newcomer
- Re: More CChildFrame questions
- References:
- More CChildFrame questions
- From: GT
- Re: More CChildFrame questions
- From: Joseph M . Newcomer
- More CChildFrame questions
- Prev by Date: Re: TRACE with VS6 onVista
- Next by Date: Re: More CChildFrame questions
- Previous by thread: Re: More CChildFrame questions
- Next by thread: Re: More CChildFrame questions
- Index(es):
Relevant Pages
|