[Webkit-unassigned] [Bug 73215] [Qt][WK2] Split QWebPermissionRequest into QWebSecurityOrigin

[bugzilla-daemon at webkit.org]

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





--- Comment #46 from Adenilson Cavalcanti Silva <savagobr at yahoo.com>  2012-01-29 06:25:38 PST ---
Kenneth

Thanks for the review, I will comment inline.

> 
> could you please wrap these lines in 80-100 chars
> 

Cool, I will do that.

> 
> Seems like info for the header instead
> 

Easy to fix, np.


> Huh? Why is that exposed? What is the url for the origin? it is pretty ambigious.
> 

You suggest to (exclusive):
a) Not have this as a property

or

b) Not have any way to access the QUrl?


> 
> I really dislike the setUrl API (you are making an implementation detail shine through the api, bad).
> 
> Why not have a securityOrigin = QtWebSecurityOrigin::create(scheme, host, port); or make it the ctor.

At time the object will be constructed, I lack the information (port/scheme/etc) to fill in the object, at least in the case of QWebPermissionRequest.

The 'setUrl' was suggested by Simon (but I can change if you wish) and allows to fill in the information after the object is constructed. Maybe you will recall that a previous version of this patch was passing an empty QUrl() object in the constructor (and you suggested to remove it)?

Going with a factory like approach (i.e. a static ::create() method) would imply that the user of this class (e.g. QWebPermissionRequest) is going to always use a pointer to handle it? This adds some complexity in its usage, since it will need to have a shared pointer of some sort to ensure that the pointer will be freed (instead of an object living in the stack) or even worst to explicitly delete it.

The problems that I'm trying to solve are:
a) Allow to fill in the security origin information into the object after the object was constructed

b) Allow the user of this new class to both create/use the object in both the stack and the heap.


Best regards


Adenilson

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