[patch]: html.cc cleanup: DilloHtml::currentForm()
This patch adds a DilloHtml::currentForm() method and uses it to refactor wherever possible. This reduces the number of instances of the "foo->size() - 1" idiom in html.cc from 23 to 13! Regards, Jeremy Henty
Here's the next patch: it turns DilloHtmlForm into a class with a constructor and destructor to manage the data members. It depends on the previous patch. Note that this changes DilloHtml slightly to manage DilloHtmlForm pointers instead of DilloHtmlForm structs. This improves consistency as DilloHtml already manages DilloLinkImage and DilloUrl objects by pointers. Next I plan to refactor common code into DilloHtmlForm members just as I did with DilloHtml, then address DilloHtmlInput, DilloHtmlSelect and DilloHtmlOption in the same way. I expect this to be straightforward. Then we will be ready to consider moving the form handling code to a separate file and replacing the DilloHtmlInput case statements with virtual methods. This will probably be trickier and need some more planning. (I already tried once to move out the form handling code and gave up because it is so entangled. Hopefully the above cleanups will make it feasible.) Please comment on the patch and the plan, especially if you have an interest in how html.cc should be cleaned up. Regards, Jeremy Henty
I just remembered that inputs don't have to be in forms according to the spec, so maybe it won't be as easy to move so much to form.cc (unless form.cc is given an html-ui-widgety general sort of name...)
corvid wrote:
I just remembered that inputs don't have to be in forms according to the spec,
Ouch, yes. I guess this is because JavaScript can read inputs whether or not they are inside a form?
... so maybe it won't be as easy to move so much to form.cc (unless form.cc is given an html-ui-widgety general sort of name...)
I think the real obstacle is circular data structures and dependencies. DilloHtml objects have pointers to DilloHtmlForm objects, which have pointers to ::form::Form objects which in turn depend on DilloHtml objects. So the code can't be split up as it stands. My tentative solution is to factor things through APIs that treat pointers as black boxes. For example, "delete form_ptr;", which requires the DilloHtmlForm class definition, could be wrapped inside a function "Html_form_delete (DilloHtmlForm *form_ptr);", which only requires the declaration "class DilloHtmlForm;". I'm sure it can be done but it may be too messy to be worth doing. At the moment I am doing cleanups that I think are clearly worth doing anyway and hoping that they will also help us to split up html.cc in a useful way. Regards, Jeremy Henty
corvid wrote:
I just remembered that inputs don't have to be in forms according to the spec,
Ouch, yes. I guess this is because JavaScript can read inputs whether or not they are inside a form?
Yes, although I ran into it when I was looking up information about inputs. The pages liked to show examples of them, but dillo would give me bug meter messages instead.
A revised version of the previous patch that applies cleanly against the latest CVS. No other changes. Jeremy Henty
On Mon, May 26, 2008 at 09:07:46PM +0100, Jeremy Henty wrote:
A revised version of the previous patch that applies cleanly against the latest CVS. No other changes.
Committed. -- Cheers Jorge.-
On Mon, May 26, 2008 at 04:24:37PM +0100, Jeremy Henty wrote:
This patch adds a DilloHtml::currentForm() method and uses it to refactor wherever possible. This reduces the number of instances of the "foo->size() - 1" idiom in html.cc from 23 to 13!
Committed as: inline DilloHtmlForm *getCurrentForm (); -- Cheers Jorge.-
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
onepoint＠starurchin.org