Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue 96 #195

Merged
merged 8 commits into from Sep 21, 2016
Merged

Issue 96 #195

merged 8 commits into from Sep 21, 2016

Conversation

jphager2
Copy link
Contributor

@jphager2 jphager2 commented Sep 8, 2016

This is a work in progress. (also see the TODOs)

This provides the api for managing forms.

view.form(:user).create(User.new) do |form, user|
  # ... extra manipulation of the form view
end

view.form(:user).update(User.find(1))

View#form is simply a alias for View#scope and #create and #update (for both View and ViewCollection) uses bind to preform the normal data binding, then adds the specific form data, then passes the view to the block passed by the caller.

@bryanp
Copy link
Contributor

bryanp commented Sep 10, 2016

Thanks for taking this on! Couple thoughts here:

  1. The form method should be defined on ViewContext. This will give it access to the request parameters. When you call view from a route, you're really creating a ViewContext instance that contains the view and the request context (see here).

  2. I think we should create a Form object with the value from scope. This would give us a place to define create and update without polluting View with form-specific methods. Since theForm instance would be created from ViewContext, we would create it with the request context, giving it access to params (and anything else it might need).

add ViewContext#form method that passes the scoped ViewCollection and
context to Form.
add Form#create and Form#update methods for manipulating forms.
@jphager2
Copy link
Contributor Author

Thanks for the feedback. Could you take a look at the spec to see if they are okay? Do we need more than these for now?

module Presenter
class Form

attr_reader :form_view, :context
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's rename form_view to view. It's already scoped within the form, so it seems redundant.

@bryanp
Copy link
Contributor

bryanp commented Sep 14, 2016

Ah, I love this. But I think you could write your example like this:

data = { id: 1, name: 'a', images: [{ id: 1, name: 'b' }, { id: 2, name: 'c' }] }
view.form(:album).update(data) |view|
  view.scope(:image).apply(data[:images]) do |fields, image|
    fields.prop(:name).attrs.name = "album[images][#{image[:id]}[name]"
  end
end

@jphager2
Copy link
Contributor Author

jphager2 commented Sep 14, 2016

Ok so just to be on the same page (since in the last iteration, I removed bind_form_action), should the Form action methods take a block in the same way as View#bind? So that if the block has an arity of 1 then it is evaluated with instance_exec in the view's context, otherwise the method yields the view and the current data to the block? Or are we going to do something different for Form?

Because looking at your updated example, it seems that you want the method to simply yield the view to the block.

@bryanp
Copy link
Contributor

bryanp commented Sep 16, 2016

That's a good point. For consistency, we should instance_exec when arity == 1. And that should happen in context of the Form's view, not the Form instance. Make sense?

Blocks passed to Form#create and Form#update with be evaluated in the
Form#view context if the block has an arity of 1. Otherwise, the view
and data are yielded to the block.
@bryanp
Copy link
Contributor

bryanp commented Sep 19, 2016

Looks good to me! @jphager2: anything else you'd like to do or ask before I merge?

@jphager2
Copy link
Contributor Author

I'm happy with it.

@bryanp
Copy link
Contributor

bryanp commented Sep 21, 2016

Thanks :)

@bryanp bryanp merged commit c1da172 into pakyow:master Sep 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants