More complete View Model support

[noahlh]

I'd like to iterate on the functionality added in #215 and build out a proper standalone View Model. Gonna think out loud here for a bit and would love some feedback/thoughts...(And I'm happy to start building this and submit a PR after some spec discussion)

It would:

• Inherit from something like Granite::ViewModel (instead of Granite::Base)
• Contain only methods for querying, and none for insert/update, i.e. all, first, find, find_by, find_each, and find_in_batches
• Include the query macro to allow for fully customizing the SELECT or full sql query

Optional idea taking things one step further:

• Would it make sense to try and build some functionality that automatically maps DB results to the ViewModel object's properties without requiring each field to be defined? (I haven't thought this through fully yet so don't know the pros/cons/unintended consequences of this).

For example, given a table posts:

id	author	title	body
0	noah	hello world!	lorem ipsum...

One could create a super simple ViewModel as such:

class PostView < Granite::ViewModel
  query <<-SQL
    SELECT * FROM posts
  SQL
end

post = PostView.first

And be able to automatically access post.id, post.author, post.title, and post.body. And/or perhaps offer a tuple-like syntax post[:id], post[:author], etc.

A utility class method such as PostView.fields would return a named tuple of the fields & their types. Or maybe more/less data?

What do you think?

[robacarp]

Would it make sense to try and build some functionality that automatically maps DB results to the ViewModel object's properties without requiring each field to be defined?

It might, but that seems like a feature that is beyond the initial run. I like the idea of a ViewModel in Granite a lot. Maybe automatic field detection, or perhaps some clever DSLy field generation with the query macro can be done as a second round feature?

[noahlh]

Maybe automatic field detection, or perhaps some clever DSLy field generation with the query macro can be done as a second round feature?

Totally agreed. I'll get the initial implementation up & running, and we can add additional fun bits afterwards.

Any other base features I'm missing for Round 1 beyond the basic View Model and its associated methods/macros?

[noahlh]

Gonna jump into this starting this weekend - sorry for delay!