GUI and non-GUI data

H

Hal Fulton

I'm refactoring some ugly code and looking for some general
high-level advice.

I'm always rather at a loss when it comes to separating the GUI-related
data from the non-GUI data.

For example, a Note might have certain attributes. But a NoteWidget, which
would know about a Note, would have different (GUIish) attributes.

But I'm a little uncomfortable with this separation, and I always end up
with a certain tangling anyway.

How do you handle this sort of issue?


Hal
 
A

Austin Ziegler

I'm refactoring some ugly code and looking for some general
high-level advice.

I'm always rather at a loss when it comes to separating the GUI-related
data from the non-GUI data.

For example, a Note might have certain attributes. But a NoteWidget, which
would know about a Note, would have different (GUIish) attributes.

But I'm a little uncomfortable with this separation, and I always end up
with a certain tangling anyway.

How do you handle this sort of issue?

It varies. I think we're using a variety of things in Ruwiki (not gui,
per se, but still). The backends are handled through delegates. The
tokens are handled through inheritance. Both are right for the choices
made.

I think I did a decent job of allowing for alternative FEs to
RTidy/CD, although I don't think much of the rest of the code in the
app at this point (my first "big" Ruby program).

If a single NoteWidget can represent one of any number of Notes, then
delegation is probably the right choice. If the GUI will create a
NoteWidget for each Note, then inheritance is the right choice ...
IMO. Someone else will probably have a different opinion.

-austin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top