[Webkit-unassigned] [Bug 30772] [Qt] Review the API of QWebElementCollection

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30772





--- Comment #3 from Kenneth Rohde Christiansen <kenneth at webkit.org>  2009-10-26 12:12:05 PDT ---

> I do not have anything against first(), I wanted to avoid last(). :)
> If we find the QWebElements on the fly when they are needed, first() is ok, but
> last() is not.

This is because last actually returns an element? so you mean that you need to
load everything. Well, isnt that the same if you use end() and then get the
element for that? If so, it could be noted in the documentation that is might
be slow, and a similar comment could be added to the info about that class:

"The collection supports lazy loading, thus any access to an element, will
force loading all elements before it."

> The justification I have heard for QWebElement::findFirst() is that findAll()
> is slow. So my idea was to get the element one by one and avoid the problem
> altogether.

Yes, I agree that lazy loading is cool :-) Have you though about unloading as
well?


> With QWebElement::findFirst(), I expect something different from
> QWebElement::nextSibling(). I would expect to be able to write something like
> this:
> 
>     QWebElement element = root.findFirst("p");
>     while (!element.isNull()) {
>       // do something
>       element = element.nextSibling("p"); 
>       // or element = element.nextSibling(); ?
>     }

nextSibling should give the real next sibling as the QWebElement represents a
tree of the DOM. Thus, I do not like the element.nextSibling("p") API. It is
confusing. I guess such functionality should only be added to the collection
itself.

> 
> But maybe I am biased because I have used jQuery.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.