Hi Joe,
# from Joe Claborn
# on Monday 21 April 2008 10:18:
>For various reasons - we are starting on a project to convert a 60,000
> line QTPerl program to wxPerl. My question is how to organize the
> UI so that we can keep a clean separation between the UI and the code
> that manages the database transactions.
The "answer" to this depends on how many pieces you want to tear it into
while you're working on the "port" to wx. For instance, you might want
to get some automated tests written and do some refactoring on the
current GUI to get to the point where you have a clean architecture
while you still have running code. Example: break the db transactions
into a library and write lights-out (i.e. no gui) tests for that, do
the same with your config objects, etc.
How successful that is depends on your app, the interactivity, etc. How
much validation goes in any given dialog? What about progress bars?
Cross-widget calls/updates? Sub-frames, and so on?
Strategies that might help include: passing subrefs and/or method names
as callbacks, make instantiated classes into caller options (rather
than hardcoding the My::Class->new), and passing callbacks that do GUI
things into the backend code (e.g. for progress updates, prompts, etc.)
>I've been looking at wxGlade to aid in the screen layouts. I see that
> it has way to produce perl code with markers indicating the wxGlade
> generated code. In a real project - how does this work out ?
It hurts. We found several cases where the generated code was not valid
under 'use strict', and had problems with developers on different
platforms making changes in glade which generated piles of spurious
diffs in svn. We wrote code to change the generated code -- and that
sort of thing is zero fun to maintain, no matter how simple the fix is.
We also ended up with timing issues in the wxSplash which were in the
middle of the glade code, so the generated code had to be changed to be
a subclass of the workaround code.
I was also very dissappointed trying to make certain changes via glade
because of the way its GUI treats things as a tree. IIRC, one has to
delete all of the children to change the type of a sizer (or something
tedious like that.)
In short: it is handy for drawing your project, but very soon becomes
unmaintainable if you need to make changes.
> Is there a better tool to use?
Not really :-/
After a certain point, dotReader was just getting broken every time we
tried to change things in glade, even with all of the glade
workarounds. I just started making GUI changes in code.
I also tried XRC, but the speed was abysmal (I suspect this has
something to do with loading many MB worth of mime files or something
at startup) and I wasn't too impressed with the API. That is, it seems
to require quite a bit of hand-holding from your code to get the XRC
instantiated, so isn't nearly the sort of separation that I hoped for.
But it is obviously designed with C++ in mind, where the runtime is
much weaker and stricter than Perl -- so having been spoiled by dynamic
languages, the sort of "my GUI is specified by $this" and "my code is
over $there" that I'm wishing for seems to not really exist. I guess
the trouble with XRC is that it was designed to allow C++ to do some
runtime loading or to generate some C++, but it didn't delve far enough
into the runtime feature IMO.
--Eric
--
Peer's Law: The solution to the problem changes the problem.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
