Closed eccegordo closed 10 years ago
This looks related: https://github.com/emberjs/data/pull/1114
On Mon, Aug 12, 2013 at 11:48 AM, Gordon Potter notifications@github.comwrote:
I am not sure how much effort this would be take, but it would be nice if EPF could provide a hook into the new data browser in ember-extension.
tildeio/ember-extension#38https://github.com/tildeio/ember-extension/issues/38
Perhaps they could provide public interface for this functionality.
Or perhaps EPF could provide a debug flag that fakes itself as Ember Data enough to work with the extension. Although that feels hacky.
Over even better would be a custom extension for debugging the EPF model state in the browser. It could be really powerful to see what overall state the model graph was in and what would happen before a session flush is triggered. And being able to peer into the shadow backup and client shadow models seems useful. And better understand what is going on in the diff.
— Reply to this email directly or view it on GitHubhttps://github.com/GroupTalent/epf/issues/65 .
Gordon L. Hempton http://codebrief.com 360.460.8098
OK interesting. If I understand this correctly it looks like EPF could piggy back on this DS.DebugAdapter.
Will have to investigate more... design question is how to represent the client shadow and shadow backup within system and UI that ember-extension uses.
It might also be nice to document or toggle the merge strategy within the interface. Basically let user experiment with hypothetical data changes that could possibly emit from the server backend.
Almost like how changing CSS selector or DOM elements within the inspector work.
Could be very powerful tool to explore complex model graphs and how changing thing would effect the app.
The Data tab in the extension was intentionally written in a way to be data library agnostic; it is not specific to Ember Data. Everything goes through Ember.DataAdapter
which is defined in Ember core.
All you need to do is extend Ember.DataAdapter
with EPF specific code and register it as dataAdapter:main
in the application's container using an initializer
hook. Everything is customizable, the table columns, filters, record colors, keywords for searching... etc
You can find Ember.DataAdapter
here. This is what you need to extend and register.
As an example, you can see how Ember Data extends this adapter here.
And here's how ED registers the adapter.
Thanks for the info @teddyzeenny . This is something I would definitely like to support.
@ghempton great! Ping me if you need any help.
@teddyzeenny I tried hacking around with it. Still new to ember. But this is a good excuse for me to learn more by hacking and exploring the source code. @ghempton will likely come up with his own approach. But figured I would attempt something. And submit a PR if I can get it to work.
You can see what I tried here
https://github.com/eccegordo/epf/tree/debugadapter
Wondering if you have any feedback.
Couple questions:
Is it possible to to create our own variant of the Ember.DataAapter? e.g.
Ep.DebugAdapter = Ep.DataAdapter.extend
vs.
Ep.DebugAdapter = Ember.DataAdapter.extend
Second I get a console error
Uncaught TypeError: Cannot call method 'watchModelTypes' of null
Seems like something is up with the observer logic. Any pointers?
Thanks for building a great tool in ember-exstension. It has helped me immensely.
@eccegordo
Is it possible to to create our own variant of the Ember.DataAapter?
I am curious as to why you would want to do that since you can override any method in Ember.DataAdapter
. You shouldn't worry about adding a dependency as the adapter is in Ember core.
IMO you'll want to aim at doing the opposite (minimize number of overridden methods). If you want we can discuss this further.
Second I get a console error
That is in fact very strange. Are you using the extension's latest master
branch?
You'll also want to inject the session
into the adapter here; as I see you are using the this.get('session')
inside the adapter.
(Clarification referring to this comment: It is the store
that is being injected into the adapter not the other way round).
Note that I can't comment on the EPF specific code (as I am unfamiliar with it). You'll want @ghempton's feedback on this.
It's awesome you're willing to spend time to do this, I hope this was helpful, good luck :)
@teddyzeenny Thanks for the feedback. I will play around with this more and try building ember-extension from source and see what I can to.
Initially I was just trying to get some basic console logging to debug what was happening in the debugAdapter but was not getting anything. That led me to believe that Ember.DataAapter was not being loaded or even extended. So then I thought I would try to create my own variant as a test because it looks like a straightforward extension of Ember.Object.
That is why I asked about Ember.DataAdapter. I don't necessarily want to create my own variant, just trying to understand the module loading and dependencies.
Is Ember.DataAdapter available as part of EmberJS? In other words if you load ember.js and then epf.js in your project then code inside epf.js should be able to freely extend Ember.DataAdapter object. Is this correct?
Basically trying to understand the whole package management process a bit better.
Thank you @teddyzeenny this feels like progress. I was confused on distinction between "store" and what to pass into the injector.
@ghempton in my example it looks like the basic plumbing is connected using Ember.DataAapter
but still need to workout the EPF specific logic and what methods to implement and override. Latest tweaks at
@ghempton I made some more tweaks and was able to get the data view to show a bit more. But there are a couple issues.
EPF doesn't have an equivalent all
method or filter in the store.
this.get('store').all(type);
I think the Session class needs a filter to fetch all local records synchronously for this to really shine.
I did try stubbing out the Ep.DebugAdapter. You can see the changes in my recent commit.
There is a basic implementation in now, but could probably still use a lot of work. Going to close this issue, however.
I am not sure how much effort this would be take, but it would be nice if EPF could provide a hook into the new data browser in ember-extension.
https://github.com/tildeio/ember-extension/pull/38
Perhaps they could provide public interface for this functionality.
Or perhaps EPF could provide a debug flag that fakes itself as Ember Data enough to work with the extension. Although that feels hacky.
Over even better would be a custom extension for debugging the EPF model state in the browser. It could be really powerful to see what overall state the model graph was in and what would happen before a session flush is triggered. And being able to peer into the shadow backup and client shadow models seems useful. And better understand what is going on in the diff.