Re: Venting on .NET

In article news:<lrcvf.49392$7h7.4948@xxxxxxxxxxxxxxxxxxxxxxxxxx>, David Ching
wrote:
> As I understand it, the the graphical Forms editor in the IDE is more
> powerful than the dialog editor in VC++. The Forms editor spits out
> C# code; the Dialog editor spits out a .rc file. So for ease of layout,
> the tool makes the difference, not so much how it represents the UI
> (either code or data it makes no difference).

Yes, that's more-or-less how I understand it too.

The problem here is that the Forms editor spits out a mass of C++ code, and in
that mass of code there is no convenient separation between parts that handle
the form display (view), the internal representation of the data (model), and
any manipulations on the data (controller). It's probably easier or the
tool-writers to write the tool that way, but it makes the resulting code less
modular and impedes reuse and encapsulation. That may be OK if the code is only
ever going to be changed using the tools (using C++ as a fancy DDL, I suppose)
but is far less that ideal if anyone is ever likely to want to edit the code by
hand.

I have a suspicion that the API was designed hand-in-hand with the tools, and
that the failure of the API to provide good separation between model, view, and
controller is largely because the tools didn't require it ... which is kinda
cheap and shoddy.

> For localization, .NET has an answer with Cultures. ...

Yes, I've read about (but not used) Cultures. They seem to be a reasonable
approach for internationalization, but are limited to that. That is the most
common reason for wanting to change resources and keep essentially the same
codebase, so I suppose they do address the most important issue.

> A general comment regarding code vs. resource templates - code provides much
> greater flexibility in specifying the data.

That's certainly true is we're talking about resource templates in the Win32
SDK as we know and love them <smile> ... but it doesn't have to be so. A
resource template from a different resource description language could allow,
for example, control sizes and positions to be expressed as fractions of the
size of the parent window. Indeed, it would be a lot easier to program
resizable dialogs in Win32/MFC if the SDK did allow that.

> I'm not sure the IDE supports the developer editing the generated code to
> change it as above, but if not, then it could in future versions. But my
> point is all things are possible in code, whereas data must be hard-coded.

There are always going to be subtleties of layout that (if you use them) will
require you to tweak things with code -- no resource description language is
ever going to be perfectly flexible -- but for most cases a resource script
will be adequate. As you say, though, the ease of use (for the programmer)
comes down to the support given by GUI design tools, and with good tool support
the programmer should not need to care whether the design is stored in code or
data. Either way, though, if you want to tweak the design beyond what the tool
supports you will have to write code to do it, and either way I think that code
is going to be simpler to write if the generated code-or-data observes a good
separation between the view and the model+controller.

Cheers,
Daniel.



.

Loading