First "big" feature: ProMotion tables + core data

[skandragon]

... and I have no idea how to implement it, but it would be wonderfully nice if one could have an easy way to tie in core data into a ProMotion TableScreen.

[jamonholmgren]

Do you have an idea on API, at least? That would help! :)

[squidpunch]

I had a similar thought. I'll try and compile my thoughts here and see how it matches up, and maybe even try and take a stab at it if I have some spare time to work on it.

And gives me a reason to dig a bit deeper in understanding ProMotion Jamon :)

Sent from my iPhone

On Dec 2, 2014, at 6:40 PM, Jamon Holmgren notifications@github.com wrote:

Do you have an idea on API, at least? That would help! :)

— Reply to this email directly or view it on GitHub.

[skandragon]

It's... tricky. Table views are quite tightly connected to the core data model, and while that is really useful at times, it also hurts in this case.

Add to that the various layers on top of core data (core data query for instance, which I use) and suddenly the API space is quite large indeed. Some of those hide the actual context or fetch result context, which also makes this harder.

Unfortunately though, as I am using core data (with a sync phase to a web service for sharing across multiple OSs) I'm sort of stuck doing table the hard way. I'll look at how I do them, and see if I can refactor in some useful way at least. Perhaps I can come up with a limited number of calls into my data store layer, and then an adapter can be made for CQD, raw core data, etc.

[jamonholmgren]

@squidpunch Nice!

@skandragon Often we'll build features for the 80% who just need something straightforward and let the edge cases be edge cases.

[squidpunch]

I won't step on @skandragon's toes but I'll still play around. Looking forward to seeing what you come up with.

Sent from my iPhone

On Dec 2, 2014, at 8:22 PM, Jamon Holmgren notifications@github.com wrote:

@squidpunch Nice!

@skandragon Often we'll build features for the 80% who just need something straightforward and let the edge cases be edge cases.

— Reply to this email directly or view it on GitHub.

[skandragon]

Feel free to step on my toes. Please. It'll keep the dogs from doing it, with their sharp little nails! :)

Seriously, I am trying to get a core data app out, and since I can choose to mix and match where to use ProMotion, for now I'm good. I'll just love removing boilerplate code when I can, which I hope will be this year still, by one of our hands! Or perhaps both. Open source motto should be, "if you start it, others will come."

[willrax]

Here are my initial thoughts. Using a fetch controller the api could look this:

class MyTable < PM::DataTable
  def data_query
    Items.all
  end

  def table_data
   {
     title: :name,
     subtitle: :whatever
   }
  end
end

We could then use the data has to build the cell and execute the methods on each item to get the result. Using CDQ of course :smile:

[squidpunch]

yeah I was thinking something like that, and maybe even creating a bit of convention (which may be totally off base since I have used CDQ pretty lightly and very little ProMotion thus far).

Convention something like:

• We define a table screen, which has a method similar to stylesheet - that has the CDQ model class as the parameter
• A generator that creates the table screen, cdq model, and a custom view cell that would be wired up in the table view.
• Hopefully generic enough that if the consumer wished to override the query they could do so, similar to what @willrax mentioned above.

like I said I probably havent worked with both products enough to even know that this is feasible, and beneficial. But thats came to mind when thinking about marrying a table view and CDQ model.

[skandragon]

I'd skip the generator for the first pass, and document how to do it manually for the first pass. Generators are wonderful for well cooked APIs, but I fear we may be rolling it often enough that it may need to change.

Also, don't forget hooks for knowing when a row is added, etc. I use this, for example, to enable the "edit" button only when there are things in the list, and when the last item is deleted, remove it.

[skandragon]

And don't forget searching!

[squidpunch]

heh, yeah there is plenty to chip away at @skandragon !

[skandragon]

I'll help test and iterate over implementations.

[jamonholmgren]

Idea:

class MyTable < PM::DataTable
  title "My Table"
  searchable placeholder: "Search items"

  cell model: Item, query: :my_query, template: {
    title: :name,
    subtitle: :whatever,
    cell_class: MyCustomClass,
  }

  # Optional custom query...defaults to `<cell_class>.all`
  def my_query
    Item.all
  end

end

[kemiller]

A thought on specifying the query: use a named scope. I.e.:

class Item < CDQManagedObject
   scope :only_some_things, where(:column).eq(value)
end

class MyTable < PM::DataTable
  title "My Table"
  searchable placeholder: "Search items"

  cell model: Item, scope: :only_some_things, template: {
    title: :name,
    subtitle: :whatever,
    cell_class: MyCustomClass,
  }
end

You can use :all in there too. If you provide a lambda option too (which builds on the scope you set) you get a lot of flexibility pretty cleanly. Not sure how'd do scopes with arguments.

[jamonholmgren]

Ooh, I like that.

[squidpunch]

I am working on this, getting closer to a first pass that might even be reviewable by others hopefully soon - will update when there is a PR out, definitely looking towards feedback to making it better after you see the 'mostly working perhaps a bit of a hacky way version' :smile:

[twerth]

This is done right?

[squidpunch]

From my point of view, I thought so. Was waiting to hear from @skandragon or others if they actually were using it and see how it was going - there is an example of it in the sample app though.

[skandragon]

Sorry, I've managed to get swamped and not have a chance recently to come back to the app I was working on.