Thanks for your helpful reply Ignacio. The specific use case that I have is this:
I have a model called Category, one called Product, one called Vendor. class Category ... has_many :product_categories ... end class ProductCategory ... belongs_to :product belongs_to :category ... end class Product ... belongs_to: vendor has_many :product_categories has_many :categories through: :product_categories, accessible:true ... end class Vendor ... has_many :products ... end The default edit/create form for Vendor includes an in-line creation subform to add a Product to products and that subform *always* has a <select-many> for the categories field but I want it to have a <check-many>. As far as I can tell, the subform for adding to products while editing a Vendor *does not employ any identifiable dryml tag for the Product subform*. Because of that, I cannot customize the choice of the editor tag used for categories in the Product subform. My hope is to change the definition of <select-many> (polymorphically just for Category) so that it actually invokes <check-many>. e.g. <def tag="select-many" for="Category> <check-many options="&Category.all"> </def> I have the same sort of issue with <select-one> (for belongs_to relationships) where I want to replace the standard <select-one> in an auto-generated subform with the tag <name-one-or-new-dialog> using the same polymorphic override technique. BTW: <name-one-or-new-dialog> is my own variation of <select-one-or-new-dialog> which I feel is much safer and more widely applicable (since select-one-or-new-dialog completely falls on its face when the the size of the selection set exceeds 100). As the name implies, it uses <name-one> instead of <select-one>. Once I get it debugged, I'll offer it for inclusion in the hobo repository. - Steve Madere On Fri, Oct 10, 2014 at 2:50 PM, Ignacio Huerta <[email protected]> wrote: > Hi Steve, > > Interesting question! There are several ways to go: > > - You could copy and have your own version of polymorphic select many. > Not very nice, as you said. > > - You could create your own polymorphic tag: > > <def tag="mysupertag" polymorphic> > <select-many merge-attrs/> > </def> > > - We could add "polymorphic" to Hobo's source, in the original > definition of select-many. I don't think it would have any negative effect. > > - Also, if you tell us a bit more about your use case maybe we can think > of an alternative. I refer to "whenever an inline form gets > auto-generated for one of my models that includes a categories > attribute, the input mode would default to check-many instead of the > standard select-many.". I think I understand what you mean but with a > bit more information I could go ahead and try to play around with a test > app. > > Warm regards, > Ignacio > > > El 29/09/14 a las #4, [email protected] escribió: > > > > Hi Guy. > > > > I saw this great example of overriding the input mode of a particular > > model throughout the entire application in another thread here. > > > > It looked like this: > > > > <def tag="input-many" for="Offer"> > > <input-many> > > <name-one:engineer/> > > </input-many> > > </def> > > > > > > In this example, any time an object of type Offer is referenced by an > > <input-many> tag > > (which is the default for direct has_many associations), it will use > > this definition > > instead of the standard one. > > > > It's brilliant because it also overrides in the context of automatically > > generated > > forms in a has_many context (which does not make use of the form tag > > but simply throws in a fields tag). > > > > I'd really like to do the same sort of thing for the <select-many> tag > > like this: > > > > <def tag="select-many" for="Category"> > > <check-many options="&Category.all.to_a.sort {|a,b| a.name <=> > > b. name}"/> > > </def> > > > > If I could do that, then whenever an inline form gets auto-generated for > one > > of my models that includes a categories attribute, the input mode would > > default > > to check-many instead of the standard select-many. > > > > Alas, the library definition of the select-many tag is not polymorphic > > so my specialization of select-many for the Category class is > ineffective. > > > > Is it possible for me to re-define the select-many tag to add > polymorphism? > > (without having to fork the hobo repository or copy and paste the > > entire definition of select-many from the hobo_rapid library to my > > application.dryml file) > > > > - Steve Madere > > > > > > > > > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Hobo Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to [email protected] > > <mailto:[email protected]>. > > To post to this group, send email to [email protected] > > <mailto:[email protected]>. > > Visit this group at http://groups.google.com/group/hobousers. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Hobo Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/hobousers/rOuew1nC7NU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/hobousers. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Hobo Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/hobousers. For more options, visit https://groups.google.com/d/optout.
