[Webkit-unassigned] [Bug 28269] Inspector: Improve Cookie DataGrid to Show Hidden Data

[bugzilla-daemon at webkit.org]

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





--- Comment #18 from Pavel Feldman <pfeldman at chromium.org>  2009-08-17 10:26:21 PDT ---
(In reply to comment #17)
> > - I don't see why JSValue JSInspectorBackend::deleteCookie needs to be custom.
> > It can be generated.
> > 
> > - JSValue JSInspectorBackend::cookies can also be implemented in
> > InspectorBackend and only have custom accessors (see
> > InspectorBackend::highlight). Otherwise produces too much duplicated code.
> 
> This sounds like a good idea.  I'm rather new to this and I don't know the
> differences between Custom and Non-Custom bindings.  It seems here that a
> non-Custom is better, and if that is the case then I'm all for it.  Can you
> point me to some reading, or some code to read, that would help me understand
> IDL and how WebKit handles bindings?
> 

You should only use Custom when you need to produce JSC (or V8) specific calls.
This includes methods that receive / return DOMObject values in the IDL. In
case of your methods you only talk to WebCore and wrap the results in a general
way. You should place all code into InspectorBackend, wrap these results into
Script(Object|Array|Value) objects and provide small accessors in the cutom
classes that would convert JSObject (or v8::Object) into the ScriptObject
instances. See InspectorBackend.(un)?wrapObject and how they are being accessed
from the custom bindings for reference.

> > - InspectorController.cookies() should not be called synchronously from the
> > frontend. It is actually not clear how it relates to
> > InjectedScript.getCookies() that is asynchronous. Should latter call into it?
> 
> That is a good point.  Right now, InjectedScript.getCookies() is only there for
> the fallback behavior, by which I mean for platforms that haven't implemented
> CookieJar's getRawCookies().  You make a good point about making it async.
> 
> I can look into renaming the current version as
> InjectedScript.fallbackGetCookies or something similar and make the current
> version async with the clearer name.  The end goal is to have all the platforms
> (or most) implement the new cookies functionality and all of the fallback code
> can then be removed, but in the meantime they can still get some data
> (name/value pairs) via the inspected page's document.cookie string.

Actually, things can be even simpler. Here is how I would do this:
- Introduce non-Custom  InspectorBackend::getCookies that would make all
necessary computations and call InspectorFrontend::setCookies(String,
ScriptObject) that you introduce. Other InspectorFrontend methods for the
reference + InspectorResource on how to create a ScriptObject with your data.
- Implement WebInspector.setCookies that would receive and process the data.
- Make a decision on whether to use real cookies or fallback ones right in the
InspectorBackend::getCookies().
- Introduce non-Custom InspectorBackend::deleteCookie and do all the same
except for it does not need a callback (or does it?).

Anyway, following this pattern you won't need any [Cutom] things at all, you
will not need to touch InjectedScript either. InjectedScript is really for the
operations that are easier to implement in JavaScript. In your case all the
real work is done in C++, so you don't need it.

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