On Tuesday, March 01, 2011 08:50:19 pm Poulain Benjamin (Nokia-MS-Qt/Oslo)
wrote:
> Hello,
>
> Andreas and I were talking about the recuring problem of QWebElement
> being too simple to handle use cases with text.
>
> We were thinking about what kind of simple change would get us out of
> those problems (text wrapping, selections, text + element as children, etc).
>
>
> Given the following changes, anyone has comments?:
>
> class QWebNode {
> enum Type { Element, Text };
> Type type() const;
> QWebElement parent() const;
> QWebElement document() const;
> QWebNode nextSibling() const;
> QWebNode previousSibling() const;
> QString toPlainText() const;
> }
>
> class QWebElement: public QWebNode {
> }
> So we could play with QWebNode of type Text for text.
>
> (Yep, I think that is BC to change the parent class in this case :))
Yeah, this _may_ be BC. As similar trick was used with QGraphicsObject. It
would be
good to double check it against that case.
However in general I'm not a fan of introducing a Node class. It was a very
concious
decision early on _not_ to repeat the API mistake of DOM to distinguish between
Nodes and Elements,
as it requires constant type-casting.
Perhaps in our case it's not that bad, given that QWebElement is rather
powerful. But I think it's would
also be worth it to explore a cursor / iterator style API on a web element. At
least for a side-by-side comparision.
Simon
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
