867458 - Created RemotedVariablesView

Status: RESOLVED DUPLICATE of bug 828680

(DevTools :: General, defect, P3)

Description

[Brandon Benvie [:benvie]]

The VariablesView has been designed to work with with grips from the debugger protocol, but there's still a lot of plumbing needed to actually put a remote object into a VariablesView. Right now this plumbing exists as part of JSTerm. This concern should be separated out into a subclass of VariablesView that makes it as easy to work with a local object (i.e. `variablesView.rawObject = obj`) but with remote objects.

This is needed in order to remote the Scratchpad, and generally makes sense as something separate from JSTerm, as we intend to use the VariablesView in multiple places.

Comment 1

[Brandon Benvie [:benvie]]

It might be that this belongs in the VariablesView itself and not a subclass. I think the expectation is that every consumer of the VariablesView may want to work with remote values. This is the reason for the bug in the first place.

Comment 2

[Victor Porof [:vporof][:vp]]

I have no opinions whether the logic should be included inside VariablesView.jsm or someplace else, however, from some initial discussions with Mihai, we though that having a VariablesViewController *thing* would be a better idea than slamming everything inside VariablesView, to clearly separate view logic from protocol handling logic.

However, I do feel strongly about one thing: the implementation should be smart enough to accommodate for both the existing webconsole *and* debugger uses, so we don't end up with 3 completely different consumers with different APIs that talk to the same view. In this case, a RemoteVariablesView might make more sense since we'll be dealing with potentially duct tape code that has nothing to do with the VariablesView itself, so there goes my vote :)

Comment 3

[Mihai Sucan [:msucan]]

A RemoteVariablesView built on top of VariablesView makes sense to me. RVV would then be used by the web console, scratchpad and by the debugger.

Brandon: I also bumped into the issue you point out here. From discussions with Victor we came up with the following: bug 828680.

Comment 4

[Brandon Benvie [:benvie]]

(In reply to Victor Porof [:vp] from comment #2)
> However, I do feel strongly about one thing: the implementation should be
> smart enough to accommodate for both the existing webconsole *and* debugger
> uses, so we don't end up with 3 completely different consumers with
> different APIs that talk to the same view. In this case, a
> RemoteVariablesView might make more sense since we'll be dealing with
> potentially duct tape code that has nothing to do with the VariablesView
> itself, so there goes my vote :)

I agree. The impetus for me making this bug was that I need to add Scratchpad to the list of tools that need a remotable VariablesView. After reviewing how the debugger and webconsole were using the VariablesView, I saw that there was already a lot of overlap.

(In reply to Mihai Sucan [:msucan] from comment #3)
> A RemoteVariablesView built on top of VariablesView makes sense to me. RVV
> would then be used by the web console, scratchpad and by the debugger.
> 
> Brandon: I also bumped into the issue you point out here. From discussions
> with Victor we came up with the following: bug 828680.

Thanks, I'm going to mark this a duplicate of that bug. I missed that in my search since I wasn't looking for a controller.