On 29/01/2011 14:25, Greg Brown wrote:
I agree fully with the concept of separating code and GUI
I've said this before but I'll repeat it now: there is a difference
between "separating data and presentation" and "separating logic and
presentation". In HTML, the former is quite relevant since the
presentation medium is a document. Combining formatting and semantic
information in the same document can render your code unmanageable.
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.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
