Re: More CChildFrame questions


On Thu, 21 Jun 2007 17:05:02 +0100, "GT" <ContactGT_remove_@xxxxxxxxxxx> wrote:

"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)?
****
A database is not in a DLL. A database is in some file which the DLL accesses. But you
are CLEARLY computing values based on this computation, and you wish to store that
computed data, and THAT is what belongs in the document. Clearly, you think you should
store it somewhere so you don't have to recompute it, and you have confused data
representation, data presentation, and cached computation. You want to cache the
computation, and the only way you seem to think that can be done is by attaching it to the
view. But why? Why not attach it to the document? That's what the document is for.

The data representation is in the database. The data presentation is in the view. And
the cached computation is in the document.
*****

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.
*****
But caching is an interesting issue, because what you really need to do is create a new
object, the data cache, and you attach that object to something that has a lifetime that
exceeds the view. So the lifetime of the document exceeds the view, and therefore the
correct OO presentation is to create an object that does the maths, an object that caches
the results of those computations, and an object (in this case, something derived from
CView) that displays the results of those computations. By confusing the object that does
the computation, the object that holds the cached result, and the object that does the
presentation, you have created a situation in which you feel the only way to preserve the
cached computation is to preserve the object that displays it. So you haven't done a
correct breakdown into OO modules.
*****

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:
*****
Note that by "data", I am referring to the cached information. The data on which those
computations are made can be in the database, and the database is of course an extension
of the document. This is another common error in thinking about document/view. I once
had a client who kept trying to remove the "document" because "all our data lives in a
remote device", and as soon as I explained that the document was the LOGICAL repository of
information, not necessarily the PHYSICAL repository, it became clear that the
communication with the remote device belonged in the document, and all the views were
quite simply presentation representations of the document's data.

That's what you have here: you have confused data with computation with display and lumped
them incorrectly, violating logical OO boundaries.

So there is a comptuation object. The data is brought in, presented to the computation
object, which produces results, and these results are presented to the display object to
show to the user. You can then introduce the notion that you actually talk to the cache;
if the cache has a current set of values computed, it returns those; if it needs to, it
computes new ones.
*****
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.
*****
This is a presentation mechanism.
*****
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
*****
This is a presentation mechanism
****
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?
*****
These are presentation mechanisms. Note that you have the "views" doing iterations on the
data. You have said that "encapsulation" seems to have something to do with these views.
But logically, the data belongs to the document, so if there are any computations to do,
the document should have responsibility. I do this by having ways for the document to
retrieve data from the view (the CFormView already violates OO boundaries because it
forces you to keep the data not in the document, where it belongs, but in the view) and do
the computations. There is not "another" document class involved; all views work with
data which is held in the document. Note that the document doesn't need to know HOW the
data is computed, or even the internal structure of the data objects it is involved in
holding; its role is to provide a data repository. How the views act on that data
requires an abstraction, and by mixing the data with the view you've already introduced
problems with OO purity, so adding a new class to represent the data actually cleans up
the design.
****

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.
*****
No, the computations required by the charts take several seconds to work out. So you are
confusing computation of results and displays of results. It works like this:
There is a computation that produces data for the chart. This is a
display-free computation class that takes some form of input and computes
some form of result

There is a display class (CView-derived) that takes the results of the
computation class and makes them look pretty on the screen

Note that as soon as you make this breakdown, it becomes clear that the data held by the
computation object is completely disjoint from the display mechanism, and therefore does
not need to be part of the object that does the display. So where to put it? Well, the
document holds data that represents the information you care about, and the information
you care about is the result of those time-consuming computations, so the place to store
it is in the document. Note that not a single line of your maths needs to be in the
document, and in fact should not be. All the document holds is a computational object,
because the role of the document is to hold data. It needs to know nothing about what is
in that object, how it gets there, or what it means.
*****

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.
****
No, you are STILL confusing computation with display. Since you have a need to SAVE the
computations beyond the lifetime of the display, then you must decouple the computation
from the display. Why does the information for how to compute the chart have to be part
of the CView which is the chart? No, the DATA is one thing, the PRESENTATION is another.
This is not to say that the two don't have an important relationship, but you've confused
the two.

So there is a means of computing the data you want to show, and a means of displaying the
data you want to show. You've already said they have to be different, so make them so. It
is cleaner OO. (Remember the actual model we want is MVC, Model-View-Controller. MFC is
actually bad at this, because it doesn't clearly separate the view and the controller, so
given that we are already working with a broken model, extending it to cleanly separate
the data from the view seems to make perfect sense).
******

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!
*****
So compute the data, store it in the document, and let the view use it. Since you have
already stated you need the lifetime of the data to exceed the lifetime of the view, you
have essentially already stated your requirement explicitly, and the document is the best
possible implementation of a data repository to hold precomputed presentation data.
*****

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!
*****
No, you are not. You have violated a key design issue here: you have coupled computation
of the data to display with the presentation of the data. Don't throw around acronyms
unless you really understand them (UML has another name, "Voodoo design", because people
believe that if they use UML they have done good design). And clearly it is not OO
because you have melded two different concepts into a single object, then claimed you need
to have two different objects, then complain that when it is pointed out that you really
DO need two different objects, that you have followed good practice by making a single
object out of them. And throw around TLAs (Two Letter Acronyms and Three Letter Acronyms)
as if this justfies a bad design. No, the design is wrong, because you have confused
chart computation with chart display. They are different problems, and you have clearly
stated that they are different problems, so the correct solution is to not violate
abstraction boundaries of MFC because you can't create correct abstraction boundaries in
your own 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!
*****
Because you have to violate fundamental design principles of MFC to make it happen. The
correct solution is to assume the MFC design, and work WITH it, not AGAINST it. If you
are so concerned with OO purity, why do you seem to insist that (a) your clearly
confuse-data-with-presentation approach is good and (b) MFC's
separate-data-from-presentation approach is bad? The first clearly violates abstraction
boundaries, and the second has very well-defined boundaries you wish to violate.

A view instance is coupled to the display, and no, you CAN'T "put in anywhere you'd like",
not without violating the basic design of MFC. Because you made a fundamental design
error of confusing data with presentation, why should MFC support something it was
carefully designed to do, which is to separate data from presentation?

Docking panes are just a way of managing a view, and you want to confuse view management
with data management, so OF COURSE you are having problems. Once you realize this is the
wrong approach, and a proper decomposition of your problem into computation objects,
retained-data objects, and display objects is the right way, you will cease having
problems.
joe
*****

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Charting Question
    ... I want to change the displayed lines on the chart. ... "Duane Hookom" wrote: ... as the SQL property of a saved query. ... the data you want to display ...
    (microsoft.public.access.reports)
  • Re: Gantt Chart
    ... a chart on standard workweeks, Monday through Friday, and to label ... Now all this is displayed on one sheet but then actually calculated ... For instance, on my main sheet, I display the ... Thanks again go to Jon Peltier who has almost ...
    (microsoft.public.excel.charting)
  • Re: PictureBox Scale Confusion
    ... extrapolate the actual data merely by examining the drawn line. ... point that he clicked on the displayed chart. ... data are drawn only into the "display" copy of the chart. ... colour value with that specific data element in your main data. ...
    (microsoft.public.vb.general.discussion)
  • Re: PictureBox Scale Confusion
    ... Whatever you do you need to maintain the actual data that each plotted line or other drawn chart element represents because the lines themselves are only an approximation of the data due to the "whole pixel" limitation of anything you draw on the screen and you cannot therefore accurately extrapolate the actual data merely by examining the drawn line. ... Any background stuff and any foreground grids that might overlay the actual chart data are drawn only into the "display" copy of the chart. ... For each element of your drawing you select a unique colour value for the background) and you associate that specific colour value with that specific data element in your main data. ...
    (microsoft.public.vb.general.discussion)
  • Re: The Designers Cut
    ... I would not consider someone who bought a chart and made up ... what we are really talking about is the stitcher purchasing a license ... to use the design and yet there is no clear license agreement. ...
    (rec.crafts.textiles.needlework)