<select-one-or-new-dialog> inside a <hjq-input-many>

[Mike]

Hi everyone,

I am trying to create a good way to handle a many-to-many relationship that has a type field associated in the relationship table. 

Person <-> Role (with type field) <-> Company

I am working on the Person form, using a <hjq-input-many> on the role as the object (accessible = true) on role.  Basically:

<extend tag="form" for="Person">

<old-form merge> 

<field-list:> 

<roles-view:>

<hjq-input-many>

<item:>

<field-list fields="role_type,company">

<company-view:>

<select-one-or-new-dialog/>

</company-view:>

</field-list>

</item:>

</hjq-input-many>

</roles-view:>

</field-list:> 

</old-form> 

</extend>

This looks great!  And, seems to work just fine with instances where the role "row" already exists (i.e. update).  Put if you click the "+" and add a new role, then the dialog pops up and is not editable.

I think this is because I am getting too far from the intended use (deeper in the model), and more specifically because it is expecting the role row to exist...you can kind of see this if you look at the HTML that is created:

<button class="hjq-dialog-open-button" onclick="hjq.dialog_opener.click(this, jQuery('#hjq-dialog--company')); return false;">

    New 

</button>

for a new row versus this for an update instance

<button class="hjq-dialog-open-button" onclick="hjq.dialog_opener.click(this, jQuery('#hjq-dialog-role-73-company')); return false;">

    New 

</button>

Anyone done anything like this?  Any better ways to edit a many-to-many with a type field in the relationship table?  Any way to fix the above?

Thanks!!

Mike

[Mike Karp]

It appears you cannot run a select-one-or-new-dialog for a phantom row like input-many creates...

I am thinking about having the "+" sign on the hjq-input-many actually commit the new row, so then I can run the dialog on it.  Just not sure how to do that yet.

Any idea on how to make the "+"/"-"s commit and delete in realtime, so then I can use the dialog on it?

----
Mike Karp
(m) 650.793.0695
(e) mdk...@gmail.com

--
You received this message because you are subscribed to the Google Groups "Hobo Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/hobousers/-/oxuOEjtZDmEJ.
To post to this group, send email to hobo...@googlegroups.com.
To unsubscribe from this group, send email to hobousers+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hobousers?hl=en.

[Bryan Larsen]

On Fri, Sep 14, 2012 at 2:47 PM, Mike Karp <mdk...@gmail.com> wrote:
> It appears you cannot run a select-one-or-new-dialog for a phantom row like
> input-many creates...
>
> I am thinking about having the "+" sign on the hjq-input-many actually
> commit the new row, so then I can run the dialog on it. Just not sure how
> to do that yet.
>
> Any idea on how to make the "+"/"-"s commit and delete in realtime, so then
> I can use the dialog on it?

That would be a lot of work. You'd essentially have to rewrite the
input-many tag, which is definitely the heaviest tag in Hobo.

One hack that i used in a new app was to use after-submit with an
additional submit button that sent the browser to the new page.

Try something like this:

<before-field-list:>
<after-submit uri="&persons_path"/>
</before-field-list:>
...
<company-view:>
<select-one/>
<submit label="Save Person and Create New Company"
onclick="$('input[name=after_submit]').val('#{new_company_path}');
return true;"/>
</company-view:>

And then have the new company form after-submit back.

This won't work as well for you as it did for me because I was using a
select-many, and the item being created was an owned item, so it got
added to the list automatically on creation.

Bryan

[Mike Karp]

Thanks Bryan - let me give that a go.

I also had one other idea...see if this makes any sense to you.

1. Make both the relationship table (i.e. roles) and the final entity (i.e. companies) as accessible => true
2. Use a <select-many> on "roles" for existing companies (and modify the select-many to have the role_type dropdown....will need to edit the javascript so that the dropdown doesn't get picked up as the action to create new rows
3. Use a <input-many> on "companies" for new companies....will have to modify input-many to not show existing rows, only be there for new ones...

Do you think that's feasible?  Are those two modifications possible?  I was having issues doing #2 above...although I saw that post in 2009 of someone doing it by changing the class name of the object that triggers the select-many new rows....

Thanks!

Mike

----
Mike Karp
(m) 650.793.0695
(e) mdk...@gmail.com

--
You received this message because you are subscribed to the Google Groups "Hobo Users" group.

[Bryan Larsen]

Your solution is frustratingly close. The problem is that both the
input-many and the select-many both think they're "definitive". In
other words, they both think they comprise the entire list, and will
try and delete items that aren't on their list.

I just thought of a solution, though: virtual attributes.

Create two methods on your person models:

def new_companies_with_role
[]
end

def new_companies_with_roles=(list)
list.each do |fields|
role_fields, company_fields = fields.partition_hash(:role)
company = Company.create!(company_fields)
roles.create!(:role => fields[:role], :company => company)
done
[]
end

And create a class

class CompanyWithRole
include ActiveModel::Validations
attr_accessor :name, :role

def initialize
# initialize with appropriate type
@name = "", @role=""
end
end

So then you can create two input-manys: one on roles, and one on our
virtual attribute new_companies_with_roles.

Then you can do something like this:

<field-list fields="..., roles, companies_with_roles">
<companies-with-roles-view:>
<input-many template="&CompanyWithRole.new" fields="name, role"/>
</companies-with-roles-view:>
</field-list>

Then the hard step: fixup Hobo so that this actually works. It
should, but there are a few places where Hobo assumes that we've got
an ActiveRecord::Base rather than an ActiveModel.

For instance, I hacked the permissions helper can_edit? by adding

return true unless object.respond_to?(:editable_by?)

Obviously we'd be better off creating an ActiveModel style permissions
mix in, but that will do for now.

The next thing that errors is the translations helper. I haven't
fixed that up yet, it's getting late. I don't know if that's the
last error, but I wouldn't expect many more.

If you want to go down this approach and get stuck, don't hesitate to
email. Replacing our ActiveRecord dependency with an ActiveModel
dependency is something we want to do eventually anyways.

cheers,
Bryan

[Mike Karp]

Thanks for the thought and detail Bryan!  I'm going to give this more thought....

Cheers,

Mike


----
Mike Karp
(m) 650.793.0695
(e) mdk...@gmail.com