>> Pivot promotes separation of data and presentation via the MVC
>> pattern. However, you can't separate logic from presentation, or your
>> UI wouldn't do anything. :-)
>
> Well, I have seen everything, from a giant class building the GUI, getting
> and updating the data and handling the events, to more or less decoupled code.
> By "separating code and GUI", I was thinking decoupling business code (get
> from database, put in objects, transform it, put in database or other
> repository) and UI code (if user selects this radio-button, activate this
> list; when all mandatory fields are filled, activate the OK button).
> The frontier isn't always well defined (what are "mandatory fields"?) but one
> of the base, good ideas is to have most of the code to work without "real"
> GUI at all: ie. in a unit test, one can replace it with mock objects and get
> the code to work. (I have yet to test this idea...)
>
> This is a bit theoretical, mostly good ideas I saw, not applying particularly
> to Pivot or some other GUI framework. And unless the framework lacks
> flexibility, implementing this is more a question of discipline ("you can add
> code to GUI definition, but don't do that, except in well defined cases")
> than of framework.
That makes sense. Keeping subsystems decoupled so that their implementations
can vary independently is almost always a good idea.
