The dom_string design
struggleyb.nku at gmail.com
Fri May 1 13:56:31 BST 2009
Thanks for your advice! And following is my opinion on your
proposal, I hope it is helpful.
> I wouldn't say "optionally"
> In order for libcss, hubbub and libdom to work sensibly together, the
> attribute names, tag names, and many of the attribute values *MUST* be
By saying "optionally", I mean all tag names, all attribute names and
some attribute values, I think we are the same at this point. :)
>> 4. What does the dom_string look like?
>> I propose, Change a little:
> Rather than change a little, my counterproposal is to change a lot.
> Refactoring code doesn't take a vast amount of time, and by ensuring we
> hit *every* use of a string, we can be sure we've considered everything
> in libdom appropriately.
> Thusly I propose:
> Anywhere dom_string is currently used for tag names, attribute names or
> attribute values, they are changed to directly use lwc_string.
> Anywhere dom_string is currently used for CDATA and the like, it is
> changed to dom_cdata_string (whose structure is identical to the current
> We remove dom_string entirely.
> This means we will catch everything in one fell swoop. It'll be painful
> for a couple of days, but in the long-run will be superior.
After some thoughts about the idea that using two types of string in
libDOM API. I have some questions.
Firstly our API may be:
dom_element_get_id(lwc_string *name, lwc_string **value);
dom_element_get_text_content(lwc_string *name, dom_cdata_string **value);
So, all APIs must be bundled with a type of string. If we decide to
change some string type of some DOM elment/attribute in future, we
should change the API. I don't think this is a good way.
And we should expose the two type of strings to our clients, I think
it is better to just use one type of string and it is clearer for our
There is another problem for this, the above two API used to fetch the
"id" and "TextContent" attributes and both attributes can be fetched
by all :
dom_element_get_attribute(lwc_string *attr, <a string type> **ret);
so, if we use two types of string, what is the string type for above API?
So, my point is: Using a common string type in API for consistence and
switch between a dom_cdata_string and lwc_string internally in libDOM.
If we take it this way, many future string type changes will not cause
the API changes.
> Remember, a big refactor now can reduce effort in the long run. Don't be
> afraid to change the API. Until the first release of libdom, the API
> should be considered entirely fluid and subject to change so that we can
> get it to be as right as possible. Once we start integrating it into
> NetSurf proper, it will be much much harder to change.
Yes, sir. :)
More information about the netsurf-dev