> Already dipping its toes in the production environment, the team as
> now defined 217 employees in the app.  The oddity is that I'm getting
> precisely 101 options in an employee select (generated by a belongs-to
> association).  In the html, there's one <option value=""> for "None"
> followed by <option value=... for the first 100 employees, in alpha
> order as required by my set_default_order tag.

> Now, it looks like the SQL being generated to populate the drop-down
> is the culprit, as my console window shows:

> SELECT * FROM 'employees' LIMIT 100

> Where's this 100 coming from -- hobo? rails?  More important, how do I
> work around it?

> <def tag="select-one" attrs="include-none, blank-message, options,
> sort"><%
>   raise HoboError.new("Not allowed to edit #{this_field}") if !
> attributes[:disabled] && !can_edit?

>   blank_message ||= "(No #{this_type.name.to_s.titleize})"

>   options ||= begin
>     conditions = ActiveRecord::Associations::BelongsToAssociation.new
> (this_parent, this_field_reflection).conditions
>     this_field_reflection.klass.all(:conditions => conditions, :limit
> => 100).select {|x| can_view?(x)}
>   end

>   select_options = options.map { |x| [x.to_s, x.id ] }
>   select_options = select_options.sort if sort
>   select_options.insert(0, [blank_message, ""]) if include_none ||
> (this.nil? && include_none != false)
>   attributes = add_classes(attributes, "input", "belongs_to",
> type_and_field)
>   -%>
>   <select name="#{param_name_for_this(true)}" merge-
> attrs="&attributes.except :name">
>     <%= options_for_select(select_options, this ? this.id : "") %>
>   </select>
> </def>

> On May 21, 7:29 pm, Montgomery Kosma <mko...@gmail.com> wrote:

> > Thanks to everyone for all the help, things are moving ahead much more
> > smoothly for me this evening.

> > Already dipping its toes in the production environment, the team as
> > now defined 217 employees in the app.  The oddity is that I'm getting
> > precisely 101 options in an employee select (generated by a belongs-to
> > association).  In the html, there's one <option value=""> for "None"
> > followed by <option value=... for the first 100 employees, in alpha
> > order as required by my set_default_order tag.

> > Now, it looks like the SQL being generated to populate the drop-down
> > is the culprit, as my console window shows:

> > SELECT * FROM 'employees' LIMIT 100

> > Where's this 100 coming from -- hobo? rails?  More important, how do I
> > work around it?

> Trying to work around the LIMIT 100 issue by using <name-one>, likely
> a better practice in this situation anyway.  However, I'm getting this
> routing error as soon as I start typing in the autocomplete field:

> Processing ApplicationController#index (for 127.0.0.1 at 2009-05-22
> 01:10:16) [GET]
>   Parameters: {"query"=>"gr"}
> ActionController::RoutingError (No route matches "/thiss/
> complete_employee_name" with {:method=>:get}):

> Here's my source - checked against older postings here plus the
> Controllers section of the manual and the Agility tutorial - unable to
> find any material differences from what should work.  Only things I
> don't understand right off is the "thiss" in the route and the
> collection=find_instance line (but seems unlikely that relates to the
> routing error).

> class CollectionController < ApplicationController
>   hobo_model_controller
>   auto_actions :all
>   autocomplete :employee_name do
>     collection = find_instance
>     hobo_completions :name, Employee
>   end
> end

> and

> <extend tag="form" for="Collection">
>   <old-form merge>
>     <field-list: fields="employee, project, name, full_path">
>       <employee-view:>
>         <name-one complete-target="&@collection"
> completer="employee_name" />
>       </employee-view:>
>     </field-list:>
>   </old-form>
> </extend>

> On May 22, 12:11 am, Montgomery Kosma <mko...@gmail.com> wrote:
>> found it!  appears to be hardwired, non-parametric constraint built
>> into vendor/plugins/hobo/hobo/taglibs/rapid_forms.dryml.  Any
>> suggestions how to fix this?  Based on browsing a ton of source
>> looking for this, seems like limit probably ought to be set equal to
>> the count of records... or at very least turned into an option.

>> <def tag="select-one" attrs="include-none, blank-message, options,
>> sort"><%
>>   raise HoboError.new("Not allowed to edit #{this_field}") if !
>> attributes[:disabled] && !can_edit?

>>   blank_message ||= "(No #{this_type.name.to_s.titleize})"

>>   options ||= begin
>>     conditions = ActiveRecord::Associations::BelongsToAssociation.new
>> (this_parent, this_field_reflection).conditions
>>     this_field_reflection.klass.all(:conditions => conditions, :limit
>> => 100).select {|x| can_view?(x)}
>>   end

>>   select_options = options.map { |x| [x.to_s, x.id ] }
>>   select_options = select_options.sort if sort
>>   select_options.insert(0, [blank_message, ""]) if include_none ||
>> (this.nil? && include_none != false)
>>   attributes = add_classes(attributes, "input", "belongs_to",
>> type_and_field)
>>   -%>
>>   <select name="#{param_name_for_this(true)}" merge-
>> attrs="&attributes.except :name">
>>     <%= options_for_select(select_options, this ? this.id : "") %>
>>   </select>
>> </def>

>> On May 21, 7:29 pm, Montgomery Kosma <mko...@gmail.com> wrote:

>> > Thanks to everyone for all the help, things are moving ahead much more
>> > smoothly for me this evening.

>> > Already dipping its toes in the production environment, the team as
>> > now defined 217 employees in the app.  The oddity is that I'm getting
>> > precisely 101 options in an employee select (generated by a belongs-to
>> > association).  In the html, there's one <option value=""> for "None"
>> > followed by <option value=... for the first 100 employees, in alpha
>> > order as required by my set_default_order tag.

>> > Now, it looks like the SQL being generated to populate the drop-down
>> > is the culprit, as my console window shows:

>> > SELECT * FROM 'employees' LIMIT 100

>> > Where's this 100 coming from -- hobo? rails?  More important, how do I
>> > work around it?

> So it was just a safety net. I'm not really sure there's a good reason
> to parameterize it is there? When would you use that? (e.g. if we
> raise the limit). Then again hard wired constants are lame of course
> so maybe we should do it anyway : )

> Tom

> Hard-wired (and undocumented!) constraints are kind of lame, yes.  I
> see 4 possibilites:

> 1. increase hard-wired limit - easy, but issue may arise again
> 2. set LIMIT equal to COUNT - but that's probably the same as no limit
> 3. add and document a parameter - pretty much solves it, and pretty
> easy
> 4. nicest solution, add a "more options..." item after the first 100
> which refreshes the drop-down and pulls in the next 100 items.  Sounds
> hard.

> On May 22, 11:53 am, Tom Locke <t...@tomlocke.com> wrote:
>> The reason for the limit 100 was to stop hobo generating impossibly
>> massive queries sometimes with the auto generated app and existing
>> databases. Select menus with hundreds of thousands of rows in them,
>> crashing your whole machine, stuff like that. The idea was to limit  
>> it
>> to a number that was way higher than what you would practically need.
>> I was thinking that anything above about 50 you should be using a
>> different UI. Then again I'm now thinking that people do use select
>> menus for choosing countries, and I think there are about 200 of  
>> those
>> if you include them all, so maybe 100 was too low.

>> So it was just a safety net. I'm not really sure there's a good  
>> reason
>> to parameterize it is there? When would you use that? (e.g. if we
>> raise the limit). Then again hard wired constants are lame of course
>> so maybe we should do it anyway : )

>> Tom

> cheers,
> Bryan

> On 5/21/09, Montgomery Kosma <mko...@gmail.com> wrote:

> > Trying to work around the LIMIT 100 issue by using <name-one>, likely
> > a better practice in this situation anyway.  However, I'm getting this
> > routing error as soon as I start typing in the autocomplete field:

> > Processing ApplicationController#index (for 127.0.0.1 at 2009-05-22
> > 01:10:16) [GET]
> >   Parameters: {"query"=>"gr"}
> > ActionController::RoutingError (No route matches "/thiss/
> > complete_employee_name" with {:method=>:get}):

> > Here's my source - checked against older postings here plus the
> > Controllers section of the manual and the Agility tutorial - unable to
> > find any material differences from what should work.  Only things I
> > don't understand right off is the "thiss" in the route and the
> > collection=find_instance line (but seems unlikely that relates to the
> > routing error).

> > class CollectionController < ApplicationController
> >   hobo_model_controller
> >   auto_actions :all
> >   autocomplete :employee_name do
> >     collection = find_instance
> >     hobo_completions :name, Employee
> >   end
> > end

> > and

> > <extend tag="form" for="Collection">
> >   <old-form merge>
> >     <field-list: fields="employee, project, name, full_path">
> >       <employee-view:>
> >         <name-one complete-target="&@collection"
> > completer="employee_name" />
> >       </employee-view:>
> >     </field-list:>
> >   </old-form>
> > </extend>

> > On May 22, 12:11 am, Montgomery Kosma <mko...@gmail.com> wrote:
> >> found it!  appears to be hardwired, non-parametric constraint built
> >> into vendor/plugins/hobo/hobo/taglibs/rapid_forms.dryml.  Any
> >> suggestions how to fix this?  Based on browsing a ton of source
> >> looking for this, seems like limit probably ought to be set equal to
> >> the count of records... or at very least turned into an option.

> >> <def tag="select-one" attrs="include-none, blank-message, options,
> >> sort"><%
> >>   raise HoboError.new("Not allowed to edit #{this_field}") if !
> >> attributes[:disabled] && !can_edit?

> >>   blank_message ||= "(No #{this_type.name.to_s.titleize})"

> >>   options ||= begin
> >>     conditions = ActiveRecord::Associations::BelongsToAssociation.new
> >> (this_parent, this_field_reflection).conditions
> >>     this_field_reflection.klass.all(:conditions => conditions, :limit
> >> => 100).select {|x| can_view?(x)}
> >>   end

> >>   select_options = options.map { |x| [x.to_s, x.id ] }
> >>   select_options = select_options.sort if sort
> >>   select_options.insert(0, [blank_message, ""]) if include_none ||
> >> (this.nil? && include_none != false)
> >>   attributes = add_classes(attributes, "input", "belongs_to",
> >> type_and_field)
> >>   -%>
> >>   <select name="#{param_name_for_this(true)}" merge-
> >> attrs="&attributes.except :name">
> >>     <%= options_for_select(select_options, this ? this.id : "") %>
> >>   </select>
> >> </def>

> >> On May 21, 7:29 pm, Montgomery Kosma <mko...@gmail.com> wrote:

> >> > Thanks to everyone for all the help, things are moving ahead much more
> >> > smoothly for me this evening.

> >> > Already dipping its toes in the production environment, the team as
> >> > now defined 217 employees in the app.  The oddity is that I'm getting
> >> > precisely 101 options in an employee select (generated by a belongs-to
> >> > association).  In the html, there's one <option value=""> for "None"
> >> > followed by <option value=... for the first 100 employees, in alpha
> >> > order as required by my set_default_order tag.

> >> > Now, it looks like the SQL being generated to populate the drop-down
> >> > is the culprit, as my console window shows:

> >> > SELECT * FROM 'employees' LIMIT 100

> >> > Where's this 100 coming from -- hobo? rails?  More important, how do I
> >> > work around it?

> T

> On 22 May 2009, at 19:32, Montgomery Kosma wrote:

> > Hard-wired (and undocumented!) constraints are kind of lame, yes.  I
> > see 4 possibilites:

> > 1. increase hard-wired limit - easy, but issue may arise again
> > 2. set LIMIT equal to COUNT - but that's probably the same as no limit
> > 3. add and document a parameter - pretty much solves it, and pretty
> > easy
> > 4. nicest solution, add a "more options..." item after the first 100
> > which refreshes the drop-down and pulls in the next 100 items.  Sounds
> > hard.

> > On May 22, 11:53 am, Tom Locke <t...@tomlocke.com> wrote:
> >> The reason for the limit 100 was to stop hobo generating impossibly
> >> massive queries sometimes with the auto generated app and existing
> >> databases. Select menus with hundreds of thousands of rows in them,
> >> crashing your whole machine, stuff like that. The idea was to limit  
> >> it
> >> to a number that was way higher than what you would practically need.
> >> I was thinking that anything above about 50 you should be using a
> >> different UI. Then again I'm now thinking that people do use select
> >> menus for choosing countries, and I think there are about 200 of  
> >> those
> >> if you include them all, so maybe 100 was too low.

> >> So it was just a safety net. I'm not really sure there's a good  
> >> reason
> >> to parameterize it is there? When would you use that? (e.g. if we
> >> raise the limit). Then again hard wired constants are lame of course
> >> so maybe we should do it anyway : )

> >> Tom

> Further testing shows that the Employee autocomplete code works
> perfectly on an Edit Collection -- the routing error occurs only when
> you type in the field on a New Collection page:

> Processing ApplicationController#index (for 127.0.0.1 at 2009-05-22
> 16:06:47) [GET]
>   Parameters: {"query"=>"ab"}

> ActionController::RoutingError (No route matches "/thiss/
> complete_employee_name" with {:method=>:get}):

> Rendering rescues/layout (not_found)

> On May 22, 11:18 am, Bryan Larsen <bryan.lar...@gmail.com> wrote:

> > Are you defining @collection anywhere?  It's not a magic variable, it
> > has to be defined in your controller.  In the agility tutorial,
> > @project is defined in the show method.  The route for the completer
> > is reflected from complete-target and completer.

> > cheers,
> > Bryan

> > On 5/21/09, Montgomery Kosma <mko...@gmail.com> wrote:

> > > Trying to work around the LIMIT 100 issue by using <name-one>, likely
> > > a better practice in this situation anyway.  However, I'm getting this
> > > routing error as soon as I start typing in the autocomplete field:

> > > Processing ApplicationController#index (for 127.0.0.1 at 2009-05-22
> > > 01:10:16) [GET]
> > >   Parameters: {"query"=>"gr"}
> > > ActionController::RoutingError (No route matches "/thiss/
> > > complete_employee_name" with {:method=>:get}):

> > > Here's my source - checked against older postings here plus the
> > > Controllers section of the manual and the Agility tutorial - unable to
> > > find any material differences from what should work.  Only things I
> > > don't understand right off is the "thiss" in the route and the
> > > collection=find_instance line (but seems unlikely that relates to the
> > > routing error).

> > > class CollectionController < ApplicationController
> > >   hobo_model_controller
> > >   auto_actions :all
> > >   autocomplete :employee_name do
> > >     collection = find_instance
> > >     hobo_completions :name, Employee
> > >   end
> > > end

> > > and

> > > <extend tag="form" for="Collection">
> > >   <old-form merge>
> > >     <field-list: fields="employee, project, name, full_path">
> > >       <employee-view:>
> > >         <name-one complete-target="&@collection"
> > > completer="employee_name" />
> > >       </employee-view:>
> > >     </field-list:>
> > >   </old-form>
> > > </extend>

> > > On May 22, 12:11 am, Montgomery Kosma <mko...@gmail.com> wrote:
> > >> found it!  appears to be hardwired, non-parametric constraint built
> > >> into vendor/plugins/hobo/hobo/taglibs/rapid_forms.dryml.  Any
> > >> suggestions how to fix this?  Based on browsing a ton of source
> > >> looking for this, seems like limit probably ought to be set equal to
> > >> the count of records... or at very least turned into an option.

> > >> <def tag="select-one" attrs="include-none, blank-message, options,
> > >> sort"><%
> > >>   raise HoboError.new("Not allowed to edit #{this_field}") if !
> > >> attributes[:disabled] && !can_edit?

> > >>   blank_message ||= "(No #{this_type.name.to_s.titleize})"

> > >>   options ||= begin
> > >>     conditions = ActiveRecord::Associations::BelongsToAssociation.new
> > >> (this_parent, this_field_reflection).conditions
> > >>     this_field_reflection.klass.all(:conditions => conditions, :limit
> > >> => 100).select {|x| can_view?(x)}
> > >>   end

> > >>   select_options = options.map { |x| [x.to_s, x.id ] }
> > >>   select_options = select_options.sort if sort
> > >>   select_options.insert(0, [blank_message, ""]) if include_none ||
> > >> (this.nil? && include_none != false)
> > >>   attributes = add_classes(attributes, "input", "belongs_to",
> > >> type_and_field)
> > >>   -%>
> > >>   <select name="#{param_name_for_this(true)}" merge-
> > >> attrs="&attributes.except :name">
> > >>     <%= options_for_select(select_options, this ? this.id : "") %>
> > >>   </select>
> > >> </def>

> > >> On May 21, 7:29 pm, Montgomery Kosma <mko...@gmail.com> wrote:

> > >> > Thanks to everyone for all the help, things are moving ahead much more
> > >> > smoothly for me this evening.

> > >> > Already dipping its toes in the production environment, the team as
> > >> > now defined 217 employees in the app.  The oddity is that I'm getting
> > >> > precisely 101 options in an employee select (generated by a belongs-to
> > >> > association).  In the html, there's one <option value=""> for "None"
> > >> > followed by <option value=... for the first 100 employees, in alpha
> > >> > order as required by my set_default_order tag.

> > >> > Now, it looks like the SQL being generated to populate the drop-down
> > >> > is the culprit, as my console window shows:

> > >> > SELECT * FROM 'employees' LIMIT 100

> > >> > Where's this 100 coming from -- hobo? rails?  More important, how do I
> > >> > work around it?

> Further testing shows that the Employee autocomplete code works
> perfectly on an Edit Collection -- the routing error occurs only when
> you type in the field on a New Collection page:

> Processing ApplicationController#index (for 127.0.0.1 at 2009-05-22
> 16:06:47) [GET]
>   Parameters: {"query"=>"ab"}

> ActionController::RoutingError (No route matches "/thiss/
> complete_employee_name" with {:method=>:get}):

> Rendering rescues/layout (not_found)

> On May 22, 11:18 am, Bryan Larsen <bryan.lar...@gmail.com> wrote:

> > Are you defining @collection anywhere?  It's not a magic variable, it
> > has to be defined in your controller.  In the agility tutorial,
> > @project is defined in the show method.  The route for the completer
> > is reflected from complete-target and completer.

> > cheers,
> > Bryan

> > On 5/21/09, Montgomery Kosma <mko...@gmail.com> wrote:

> > > Trying to work around the LIMIT 100 issue by using <name-one>, likely
> > > a better practice in this situation anyway.  However, I'm getting this
> > > routing error as soon as I start typing in the autocomplete field:

> > > Processing ApplicationController#index (for 127.0.0.1 at 2009-05-22
> > > 01:10:16) [GET]
> > >   Parameters: {"query"=>"gr"}
> > > ActionController::RoutingError (No route matches "/thiss/
> > > complete_employee_name" with {:method=>:get}):

> > > Here's my source - checked against older postings here plus the
> > > Controllers section of the manual and the Agility tutorial - unable to
> > > find any material differences from what should work.  Only things I
> > > don't understand right off is the "thiss" in the route and the
> > > collection=find_instance line (but seems unlikely that relates to the
> > > routing error).

> > > class CollectionController < ApplicationController
> > >   hobo_model_controller
> > >   auto_actions :all
> > >   autocomplete :employee_name do
> > >     collection = find_instance
> > >     hobo_completions :name, Employee
> > >   end
> > > end

> > > and

> > > <extend tag="form" for="Collection">
> > >   <old-form merge>
> > >     <field-list: fields="employee, project, name, full_path">
> > >       <employee-view:>
> > >         <name-one complete-target="&@collection"
> > > completer="employee_name" />
> > >       </employee-view:>
> > >     </field-list:>
> > >   </old-form>
> > > </extend>

> > > On May 22, 12:11 am, Montgomery Kosma <mko...@gmail.com> wrote:
> > >> found it!  appears to be hardwired, non-parametric constraint built
> > >> into vendor/plugins/hobo/hobo/taglibs/rapid_forms.dryml.  Any
> > >> suggestions how to fix this?  Based on browsing a ton of source
> > >> looking

> Thanks to everyone for all the help, things are moving ahead much more
> smoothly for me this evening.

> Already dipping its toes in the production environment, the team as
> now defined 217 employees in the app.  The oddity is that I'm getting
> precisely 101 options in an employee select (generated by a belongs-to
> association).  In the html, there's one <option value=""> for "None"
> followed by <option value=... for the first 100 employees, in alpha
> order as required by my set_default_order tag.

> Now, it looks like the SQL being generated to populate the drop-down
> is the culprit, as my console window shows:

> SELECT * FROM 'employees' LIMIT 100

> Where's this 100 coming from -- hobo? rails?  More important, how do I
> work around it?

> three years on, and i am encountering the same issue when using
> auto-complete on a new document:

> *ActionController::RoutingError (No route matches
> "/thiss/complete_user_name")*

> any resolution? ~daVe

> On Thursday, May 21, 2009 4:29:19 PM UTC-7, Montgomery Kosma wrote:

>> Thanks to everyone for all the help, things are moving ahead much more
>> smoothly for me this evening.

>> Already dipping its toes in the production environment, the team as
>> now defined 217 employees in the app.  The oddity is that I'm getting
>> precisely 101 options in an employee select (generated by a belongs-to
>> association).  In the html, there's one <option value=""> for "None"
>> followed by <option value=... for the first 100 employees, in alpha
>> order as required by my set_default_order tag.

>> Now, it looks like the SQL being generated to populate the drop-down
>> is the culprit, as my console window shows:

>> SELECT * FROM 'employees' LIMIT 100

>> Where's this 100 coming from -- hobo? rails?  More important, how do I
>> work around it?

> ActionController::RoutingError (No route matches
> "/thiss/complete_user_name")

> any resolution? ~daVe

> On Thursday, May 21, 2009 4:29:19 PM UTC-7, Montgomery Kosma wrote:

>> Thanks to everyone for all the help, things are moving ahead much more
>> smoothly for me this evening.

>> Already dipping its toes in the production environment, the team as
>> now defined 217 employees in the app.  The oddity is that I'm getting
>> precisely 101 options in an employee select (generated by a belongs-to
>> association).  In the html, there's one <option value=""> for "None"
>> followed by <option value=... for the first 100 employees, in alpha
>> order as required by my set_default_order tag.

>> Now, it looks like the SQL being generated to populate the drop-down
>> is the culprit, as my console window shows:

>> SELECT * FROM 'employees' LIMIT 100

>> Where's this 100 coming from -- hobo? rails?  More important, how do I
>> work around it?

> --
> 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/-/3BzO9GWAlNcJ.
> To post to this group, send email to hobousers@googlegroups.com.
> To unsubscribe from this group, send email to
> hobousers+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hobousers?hl=en.

> Your problem is with name-one.  It appears that you need to explicitly
> specify the complete-target attribute.   If you provide more context I
> can probably help you further.

> Bryan

> On Thu, Jun 7, 2012 at 1:09 PM, d@Ve <kungfuk...@gmail.com> wrote:
> > three years on, and i am encountering the same issue when using
> > auto-complete on a new document:

> > ActionController::RoutingError (No route matches
> > "/thiss/complete_user_name")

> > any resolution? ~daVe

> > On Thursday, May 21, 2009 4:29:19 PM UTC-7, Montgomery Kosma wrote:

> >> Thanks to everyone for all the help, things are moving ahead much more
> >> smoothly for me this evening.

> >> Already dipping its toes in the production environment, the team as
> >> now defined 217 employees in the app.  The oddity is that I'm getting
> >> precisely 101 options in an employee select (generated by a belongs-to
> >> association).  In the html, there's one <option value=""> for "None"
> >> followed by <option value=... for the first 100 employees, in alpha
> >> order as required by my set_default_order tag.

> >> Now, it looks like the SQL being generated to populate the drop-down
> >> is the culprit, as my console window shows:

> >> SELECT * FROM 'employees' LIMIT 100

> >> Where's this 100 coming from -- hobo? rails?  More important, how do I
> >> work around it?

> > --
> > 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/-/3BzO9GWAlNcJ.
> > To post to this group, send email to hobousers@googlegroups.com.
> > To unsubscribe from this group, send email to
> > hobousers+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/hobousers?hl=en.

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

> <edit-page>
>   <form:>
>     <field-list: fields="hours_spent, minutes_spent, assignee, assignor">
> ...
>       <assignee-view:>
>         <name-one complete-target="&@assignment" completer="user_name"/>
>       </assignee-view:>
> ...
>     </field-list:>
>   </form:>
> </edit-page>

> <new-page>
>   <form:>
>     <field-list: fields="assignor, assignee, assigned_type, assigned,
> hours_spent, minutes_spent">
> ...
>       <assignee-view:>
>         <name-one complete-target="&@assignment" completer="user_name"/>
>       </assignee-view:>
> ...
>     </field-list:>
>   </form:>
> </new-page>

> class AssignmentsController < ApplicationController
>   hobo_model_controller
>   auto_actions :all

>   autocomplete :user_name do
>     hobo_completions :name_with_email_address, User, :query_scope =>
> [:first_name_contains, :last_name_contains]
>   end
> ...
> end

> class Assignment < ActiveRecord::Base
>   hobo_model # Don't put anything above this

>   fields do
>     hours_spent       :integer, :default => 0#, :options =>
> [0,1,2,3,4,5,6,7,8,9]
>     minutes_spent     :integer, :default => 0
>     timestamps
>   end

>   # remove from live-search results
>   set_search_columns nil

>   # fields set automatically based on context
>   never_show :assigned #
> http://www.mail-archive.com/hobousers@googlegroups.com/msg09518.html

>   def name
>     assigned.name
>   end

>   def type
>     assigned_type
>   end

>   # default sort
>   default_scope :order => 'updated_at desc'

>   # --- Associations --- #
>   belongs_to :assignor, :class_name => "User", :creator => true
>   belongs_to :assignee, :class_name => "User"
>   belongs_to :assigned, :polymorphic => true
> ...
> end

> class User < ActiveRecord::Base

>   hobo_user_model # Don't put anything above this

>   fields do
>     # name          :string, :required #, :login => true
>     first_name    :string, :required
>     last_name     :string, :required
>     email_address :email_address, :unique, :login => true, :case_sensitive
> => false
>     administrator :boolean, :default => false
>     timestamps
>   end
> ...
>   def name
>     first_name.to_s + ' ' + last_name.to_s
>   end

>   # necessary for autocomplete where user has similar or same name as
> another
>   # and thus uniqueness of user determined by email address
>   def name_with_email_address
>     first_name.to_s + ' ' + last_name.to_s  + ' (' + email_address.to_s +
> ')'
>   end

>   # allow autocomplete to find by name when name is a generated field (see
> above)
>   def self.find_by_name(name)
>     names = name.split(' ')
>     (0..(names.length-2)).inject(nil) do |result, n|
>       result ||= self.find_by_first_name_and_last_name(names[0..n].join('
> '), names[1..(n+1)].join(' '))
>     end
>   end
> ...
>   # default sort EVERYWHERE!
>   default_scope :order => 'last_name, first_name'

>   # --- Associations --- #
>   has_many :assignments
> ...
> end

> perusing this group, i continue to see this same issue pop up, so any
> insight is much appreciated! ~daVe

> On Thu, Jun 7, 2012 at 11:37 AM, Bryan Larsen <br...@larsen.st> wrote:

>> Montgomery's email was about a problem with select-one.   The "limit"
>> attribute has existed on select-one for quite some time now to fix his
>> problem.

>> Your problem is with name-one.  It appears that you need to explicitly
>> specify the complete-target attribute.   If you provide more context I
>> can probably help you further.

>> Bryan

>> On Thu, Jun 7, 2012 at 1:09 PM, d@Ve <kungfuk...@gmail.com> wrote:
>> > three years on, and i am encountering the same issue when using
>> > auto-complete on a new document:

>> > ActionController::RoutingError (No route matches
>> > "/thiss/complete_user_name")

>> > any resolution? ~daVe

>> > On Thursday, May 21, 2009 4:29:19 PM UTC-7, Montgomery Kosma wrote:

>> >> Thanks to everyone for all the help, things are moving ahead much more
>> >> smoothly for me this evening.

>> >> Already dipping its toes in the production environment, the team as
>> >> now defined 217 employees in the app.  The oddity is that I'm getting
>> >> precisely 101 options in an employee select (generated by a belongs-to
>> >> association).  In the html, there's one <option value=""> for "None"
>> >> followed by <option value=... for the first 100 employees, in alpha
>> >> order as required by my set_default_order tag.

>> >> Now, it looks like the SQL being generated to populate the drop-down
>> >> is the culprit, as my console window shows:

>> >> SELECT * FROM 'employees' LIMIT 100

>> >> Where's this 100 coming from -- hobo? rails?  More important, how do I
>> >> work around it?

>> > --
>> > 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/-/3BzO9GWAlNcJ.
>> > To post to this group, send email to hobousers@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > hobousers+unsubscribe@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/hobousers?hl=en.

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

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

> btw, we are on hobo 1.3, anticipating the 1.4 release. we've started
> investigating 1.4 but have run into quite a few upgrade path issues: will
> this be one of them, or will our legacy <name-one> calls remain operational
> as-is?

> On Thursday, June 7, 2012 1:40:38 PM UTC-7, Bryan Larsen wrote:

>> Have you tried using complete-target="&Assignment"?   on the new page,
>> @assignment doesn't have an id.

>> Are you using Hobo 1.3 or Hobo 1.4?   The javascript for name-one is
>> completely different in 1.4.

>> cheers,
>> Bryan

> --
> 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/-/QMOr51Qhw6YJ.

> To post to this group, send email to hobousers@googlegroups.com.
> To unsubscribe from this group, send email to
> hobousers+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hobousers?hl=en.