On Sun, May 25, 2008 at 05:13:13PM +0100, Jeremy Henty wrote:
On Sun, May 25, 2008 at 10:31:23AM -0400, Jorge Arellano Cid wrote:
On Sun, May 25, 2008 at 01:12:38PM +0200, Justus Winter wrote:
Furthermore I'd suggest to break down html.cc into several files.
The hard part is a good choice on what to separate. ;)
I suggest splitting out everything that handles forms and form elements. That's a fair amount of code that represents a reasonably self-contained chunk.
The forms code can also be be cleaned up in a few ways.
It looks like you have a good set of ideas to start. Corvid has been working around forms lately so please try to coordinate ideas with him
There's a lot of cut-and-paste code like "foo->get (foo->size () - 1)". Adding getLast() methods to some lout classes and using them wherever possible would remove a lot of clutter.
OK.
html.cc looks like a C file that was subsequently converted to C++ because it makes little use of C++.
html.cc is a C file that was subsequently converted to C++! :-)
If DilloHtmlForm and > DilloHtmlInput were given constructors and destructors and managed with new and delete then lots of allocation/deallocation code would be neatly factored out instead of sitting inline with all the other logic.
OK 2.
The type element of DilloHtmlInput leads to much horrible case code. If DilloHtmlInput were an abstract class and the different Input types were subclasses then all the type-dependent code could go into virtual methods. This would break up the huge case statements that make much of this code hard to follow.
I'll propose patches if people are positive about these suggestions.
BTW:
[corvid wrote:] It's at least definitely worth trying, I think.
Just beware of not converting the "horrible case code" into "horrible virtual method subclassing". :-) FLTK2 does this quite nicely with the virtual handle() method. This is IMHO remarkable because the underlying event handling model is certainly complex, but the abstraction for it attains simplicity at the widget level. -- Cheers Jorge.-