Community
Participate
Working Groups
The input service is kind of weird with respect to its relationship with the current document. Some issues: - we currently configure it with "shouldManageDocumentTitle" to control whether it updates the document title on input update. This is so that we don't always bash the doc title if, for example, the editor was on the same page as the nav... - however we also hook hash change and update the input value when hash changes. This assumes that the input is always related to the document URL - currently the editorContainer hooks a document unload handler to prompt for navigating away when the doc is dirty. Should the input service be hooking this instead? So we have a mish-mash of assumptions about who "owns" the document. Either we should have the input service be configurable for this, and hook hashes and onloads all the time, or else it should hook neither. For example, maybe the editorContainer should monitor hash changes and drive the input service rather than vice versa.
This relates to dirty management as well. We have a saveable service that has to callback to find out if something is dirty. It seems like the doc should know if it's dirty and then call to the saveable if a prompt if needed. I think this would put it more on par with the eclipse desktop saveable service as well
Along with all the service registry changes, I removed the verify callback for input and the isDirty callback for saveables. Saveable is now just a service for saving and it does no dirty prompting. We may find that we have to revisit this when we try to host editorContainer in eclipse desktop. There is still the mismatch whereby all the hash change management is done in the input service. I think that has to be flipped so that it's monitored by the page. I'll look into this next (i wanted to get all the service changes related to the new service registry in first).
I've done enough for M5, including fixing the dependent bug without having to go further here. Another thing I've noticed is that the explorer tree and table pages (glue code) are hooking hash change so that the user can navigate the tree. Note we don't use the input service at all to say who is the "owner" of the navigator page. That is something else to work out. I think that the editor and navigator should be consistent in their use of the input service and who handles the hash. As a side note, while fixing bug 334193, I noticed that loadResourceList is called quite a few times when we click a link in the navigator. (There is commented out code in loadResourceList to show old path and new path). The code that bails if the path is the same is working, so we don't have multiple fetches, but I'd like to understand where these calls are coming from, as it may be a symptom of the other inconsistencies.
In bug 335631 I had to add a hash change on the coding page to restore the dirty prompt that the input service used to give. Here's another example of inconsistency.
Here's what I think we need to do on this issue. - Input service and selection service are dumb. They are just there to hook listeners on and have consumer getters and producer setters. They have no clue how/who decides when something is "selected" or how something becomes an "input." So there should be no hash change hooking in the input service - Both selection and input provide API for producers and consumer components who traffic in URI's and don't know/care which service is providing the info. myService.setURI(someURI) myService.addListener('uriChanged', function(uri) {...}) - Visual components can provide or consume URI's from the designated services - So imagine a visual component like navigator. Conceptually the navigator's "input" is some file path URI and its "output" is the selection or selections. But it doesn't know this, it will just be given the objects for which it is a URI consumer and for which it is a URI provider. - The glue is the one who knows which component is playing which role, and wires up accordingly. - The glue is the one who knows, for example, that hash change controls nav input on the nav page, and editor input on the editor page. It hooks hash change and then updates the correct service. The component gets the listener notification from the anonymous service. Likewise, the glue could tell the outliner that it is providing a URI for some service (the input service), thus wiring up the outliner and editor. Only the glue knows the hash may change and will handle that part of it. - We should probably get rid of "shouldManageDocumentTitle." Since the glue is the one that knows whether input should update the browser tab title, there's no reason for it to pass this info to the input service. We can always have utility methods for things that most pages might want to do rather than have the service do it because it's there. Example: editor Scenario 1: on the current coding page, the glue passes the input service as the URI provider. The glue hooks hash change and updates the input service as needed. Editor listens to URI provider (input) for changes. Scenario 2: nav and editor on same page. Glue passes the input service as the URI provider for the navigator, and the selection service as a URI consumer for the navigator. Glue passes the selection service as the URI provider for the editor. Glue hooks hash change and updates input service as needed. Now the navigator will respond to hash changes and the editor will respond to nav selections. cc'ing Boris. Does that sound about right to you?
Actually, having reread my own description, this means there's no need to define a separate "selection service" and "input service." There is just a "uri service" and the glue can wire up the producer/consumer relationships for the different instances as needed. This "uri service" will have listeners for those who care about multiple URI's (typical selection service consumers) and those who only care about a single URI (typical input service consumers). Likewise producer API can allow setting single or multiples.
(In reply to comment #6) > Actually, having reread my own description, this means there's no need to > define a separate "selection service" and "input service." There is just a > "uri service" and the glue can wire up the producer/consumer relationships for > the different instances as needed. This "uri service" will have listeners for > those who care about multiple URI's (typical selection service consumers) and > those who only care about a single URI (typical input service consumers). > Likewise producer API can allow setting single or multiples. This strategy of chaining up URI providers and consumers suggests that we shouldn't be using the service registry to look up "the uri provider" since there could be more than one at play within a page. We need to be passing the components their uri provider and uri consumer. And I think we should call this thing a url, or "LocationProvider" because we are talking about real URL's vs. just named resources.
Fixed. - I decided it was limiting to call this "LocationProvider" or really anything to do with URL and URI. Because the notion of wiring up inputs and outputs is pretty generic. The only thing that makes this URL related is that in most of our cases today, the input to many pages is obtained from the hash. So I've gone back to "Selection." The idea being, you can provide or consume single or multiple selections, and pages can wire up the selection outputs from one page to the inputs from another. - Anyone who provides or consumes a selection must get their selection service passed in on the constructor, rather than use the registry. This way, we could potentially have multiple providers and consumers on one page. I changed the existing providers (navigators) and consumers (command service) to take the selection in the constructor. - It is now the responsibility of glue code to do things like monitor hash change events, update the page title, etc. This turned into quite a few more changes than I'd anticipated, including changes to unit test page, git clone, user profile, etc. In most of these cases, the pages were using input for the hash change code, and it actually made things cleaner to simply hook hash change directly. I've removed input.js and all references to it. Gosia, could you double check your pages to make sure I haven't broken anything? Libing, I didn't find any references to the input service from your compare pages, so I don't think this change affects you, but cc'ing you just in case.
