[Blacklight-development] routing problem
Matt Mitchell
goodieboy at gmail.com
Wed Mar 11 13:37:00 EDT 2009
My gut is telling me that this was never a BL problem, but an :id param
format problem. If the format of the :id param does not match the route
rules, the route helper will not work. I'd seriously consider re-formatting
the id param to use something that doesn't use a .
Matt
On Wed, Mar 11, 2009 at 12:55 PM, Naomi Dushay <ndushay at stanford.edu> wrote:
> Vernon,
> Just for giggles, try this:
>
> 4. copied the vendors/plugins/blacklight/lib/blacklight.rb to my
> app/lib/blacklight.rb
>
>
> don't do this step
>
> 5 - added Blacklight.solr.param_mappers[:select] = :dismax to
> app/lib/blacklight.rb
>
>
> do this in place.
>
> I had trouble with my solr_helper refactoring when I needed to add and read
> add'l info in solr.yml; I couldn't get it to work when I did it in my local
> rails app -- I had to do it in vendor/plugins/blacklight/lib
>
>
> If my "fix" works, then we need to discuss if this can be done differently
> and/or change the documentation accordingly.
>
> - Naomi
>
>
> On Mar 11, 2009, at 9:40 AM, Vernon Chapman wrote:
>
> I am not sure what I am doing wrong so here is what I did
>
> 1 - checkout blacklight from svn using svn co http://....../trunk
> blacklight
> 2 - followed the direction to setup internal solr/jetty server and index
> records
> 3 - test the setup, everything works when I got to http://localhost/ i see
> the new home page with text etc.
>
> Here is where I am getting KILLED
>
> I need to change the solr url , handlers and the controller for my
> application so I
>
> 1 - modified solr.yml from http://127.0.0.1:8983/solr to
> http://127.0.0.1:8983/solr/content (my solr is multicore)
> 2 - copied the home_controller & catalog_controller to my app/controllers
> 3 - modified the catalog_controllers by replacing the :search symbol with
> the name of the handler
> on my solr server in this case :select
> 4 - copied the vendors/plugins/blacklight/lib/blacklight.rb to my
> app/lib/blacklight.rb
> 5 - added Blacklight.solr.param_mappers[:select] = :dismax to
> app/lib/blacklight.rb
> 6 - restart passtenger ( touch rails/tmp/restart.txt)
> 7 - restart apache2 (just to make sure passenger restarted)
>
> The fist time I access http://localhost/ I see the home page with the
> facets from my external
> solr server listed on the left, if I click on one of the facets, I get the
> following :
>
> You have a nil object when you didn't expect it!
> The error occurred while evaluating nil.commit
>
>
> /opt/appz/blacklight/rails/app/controllers/home_controller.rb:15:in `solr_params'
>
>
> /opt/appz/blacklight/rails/app/controllers/home_controller.rb:7:in `index'
>
>
> the line with .commit is the Blacklight.commit line in solr_params, so for
> some reason Blacklight
> is nil.
>
> Any ideas
> On Wed, Mar 11, 2009 at 10:35 AM, Molly Pickral Cadieux <
> mpc3c at virginia.edu> wrote:
>
>> Vern,
>>
>> Just to make sure -- did you restart passenger or mongrel or whatever
>> it is you are using? Changes to helpers seem to need an extra kick.
>>
>> Molly
>>
>> On Tue, Mar 10, 2009 at 2:51 PM, Vernon Chapman <chapman.lists at gmail.com>
>> wrote:
>> > Molly,
>> >
>> > Thanks for your work on this, but unfortunately that didn't fix the
>> > issue. I did an svn update on my checkout of blacklight and restarted
>> > apache and I still get the same error.
>> >
>> > Vern
>> >
>> > Molly Pickral Cadieux wrote:
>> >>
>> >> Hi again,
>> >>
>> >> I went ahead and tried the fix on demo.blacklightopac.org, and it
>> >> works great! So, Vernon, if you could grab the new version of
>> >> catalog_helper.rb from subversion, I'm almost certain that will fix
>> >> the bug you reported yesterday.
>> >>
>> >> Molly
>> >>
>> >> On Tue, Mar 10, 2009 at 9:45 AM, Molly Pickral Cadieux
>> >> <mpc3c at virginia.edu> wrote:
>> >>
>> >>>
>> >>> Hi everyone,
>> >>>
>> >>> I recently committed some changes to the repository that offer the
>> >>> following features:
>> >>>
>> >>> 1. A drop-down list that allows users to specify how may results per
>> >>> page to display (the previous default was 10 per page)
>> >>> 2. "Previous" and "Next" links that allow a user to page through a
>> >>> search result, as opposed to going back to the previous page to select
>> >>> the previous or next item.
>> >>> 3. Several rspec tests for the catalog controller and various models.
>> >>>
>> >>> This all works perfectly on my setup, but when I went to deploy the
>> >>> changes on demo.blacklightopac.org, I ran into a routing issue.
>> >>> Vernon also reported this error yesterday. The error is as follows:
>> >>>
>> >>> ------------
>> >>>
>> >>> catalog_url failed to generate from {:commit=>nil, :action=>"show",
>> >>> :id=>"agrecord.2008-11-27.1267669533", :controller=>"catalog",
>> >>> :counter=>1}, expected: {:action=>"show", :controller=>"catalog"},
>> diff:
>> >>> {:commit=>nil, :id=>"agrecord.2008-11-27.1267669533", :counter=>1}
>> >>>
>> >>> Extracted source (around line #21):
>> >>>
>> >>> 18: <% # main title container for doc partial view -%>
>> >>> 19:
>> >>> 20: <div class="yui-u">
>> >>> 21: <h5><%= counter + 1 + @response.start.to_i %>. <%=
>> >>> link_to_document document, :label=>:title, :extra_params=>{:counter =>
>> >>> counter + 1 + @response.start.to_i } %></h5>
>> >>> 22: </div>
>> >>> 23:
>> >>> 24: </div>
>> >>>
>> >>> -----------
>> >>>
>> >>> Bess had reported a similar problem back in February (I've included
>> >>> the message below). Unfortunately, I have been unable to reproduce
>> >>> the reported problem on my Mac running the same versions of Ruby,
>> >>> Rails, and Passenger. I would like to try Bess's recommended solution
>> >>> if I can get a setup where I can reproduce the problem. In the mean
>> >>> time, I'd love it if Vernon or others who may have seen the problem
>> >>> could try modifying this file:
>> >>>
>> >>> rails/vendor/plugins/blacklight/app/helpers/catalog_helper.rb
>> >>>
>> >>> and change this line:
>> >>>
>> >>> link_to label, catalog_path(doc[:id],
>> >>> params.merge(opts[:extra_params]).merge(:action=>nil, :commit=>nil))
>> >>>
>> >>> to be:
>> >>>
>> >>> link_to label, catalog_path(doc[:id],
>> >>> params.merge(opts[:extra_params]).merge(:action=>"show",
>> >>> :commit=>nil))
>> >>>
>> >>> and see if that fixes it. A restart of passenger will be necessary.
>> >>>
>> >>> If I can't get this worked out soon, I will revert the changes in the
>> >>> repository and work through this again here.
>> >>>
>> >>> In any case, I wanted to let you all know that what is currently in
>> >>> the repository may cause routing issues under certain environments.
>> >>> I'll keep you all posted on progress.
>> >>>
>> >>> Molly
>> >>>
>> >>>
>> >>> ----------
>> >>>
>> >>> From eos8d at virginia.edu Sun Feb 1 17:25:35 2009
>> >>> From: eos8d at virginia.edu (Bess Sadler)
>> >>> Date: Sun, 1 Feb 2009 17:25:35 -0500
>> >>> Subject: [Blacklight-development] demo app bug fix
>> >>> Message-ID: <A6EAD76B-55E8-45A5-AACF-E080B1D2D499 at virginia.edu>
>> >>>
>> >>> Hey, folks.
>> >>>
>> >>> I've spent the last day or so playing pretty intensively with the demo
>> >>> app. I fixed a couple of minor bugs in the installation instructions
>> >>> (here:
>> >>> http://blacklight.rubyforge.org/wiki/wiki.pl?Installing_The_Demo_App)
>> >>> and I've deployed the demo app several times, on several different
>> >>> systems. Strangely, although I could get it running right away with
>> >>> mongrel or webrick, I found that I could not get it running with
>> >>> mod_passenger, which is our preferred method of running rails apps in
>> >>> production. I think I tracked down the bug today, and you can see the
>> >>> demo app running with mod_passenger as a virtual host at
>> >>> http://demo.blacklightopac.org
>> >>>
>> >>> I was getting two errors. One, encountered whenever the index screen
>> >>> was loaded, said:
>> >>>
>> >>> ActionView::TemplateError (catalog_url failed to generate from
>> >>> {:action=>"index", :controller=>"catalog", :id=>"u1"}, expected:
>> >>> {:action=>"show", :controller=>"catalog"}, diff:
>> >>> {:action=>"show", :id=>"u1"}) on line #11 of
>> vendor/plugins/blacklight/
>> >>> app/views/catalog/_index_partials/_default.html.erb:
>> >>> 8:
>> >>> 9: <div class="yui-u">
>> >>> 10: <h5>
>> >>> 11: <%= link_to document.get(:id), catalog_path(document[:id],
>> >>> params) %>
>> >>> 12: </h5>
>> >>> 13: </div>
>> >>> 14: </div>
>> >>>
>> >>>
>> >>> The other was generated whenever the show screen was loaded, and it
>> >>> said:
>> >>>
>> >>> ActionView::TemplateError (catalog_index_url failed to generate from
>> >>> {:action=>"show", :controller=>"catalog", :id=>nil}, expected:
>> >>> {:action=>"index", :controller=>"catalog"}, diff:
>> >>> {:action=>"index", :id=>nil}) on line #8 of vendor/plugins/blacklight/
>> >>> app/views/catalog/show.html.erb:
>> >>> 5: </div>
>> >>> 6:
>> >>> 7: <% @sidebar = capture do %>
>> >>> 8: <p><%= link_to '<< SEARCH',
>> >>> catalog_index_path(params.merge(:id=>nil)) %></p>
>> >>> 9: <% end %>
>> >>>
>> >>> Turns out these were basically the same error. In both cases, we're
>> >>> using the link_to function to create a link to another part of the
>> >>> application, in this case from index to show, and from show to index.
>> >>> Let's talk about the link from index to show as an example.
>> >>>
>> >>> <%= link_to document.get(:id), catalog_path(document[:id], params) %>
>> >>>
>> >>> That says create a link, and the text of the link is the id number of
>> >>> the current document (say, u999), and the target of the link is
>> >>> catalog_path(u999) which will evaluate to /catalog/u999. Incidentally,
>> >>> the rails console was really valuable in helping me understand how
>> >>> these worked, and you can play with it like this:
>> >>>
>> >>> paz:rails eos8d$ ./script/console
>> >>> Loading development environment (Rails 2.2.2)
>> >>> >> app.catalog_path("u999")
>> >>> => "/catalog/u999"
>> >>>
>> >>> Anyway, I found that if I just changed the link_to statement to look
>> >>> like this instead, removing the params object:
>> >>>
>> >>> <%= link_to document.get(:id), catalog_path(document[:id]) %>
>> >>>
>> >>> the error went away. However, this wasn't an acceptable solution,
>> >>> because whenever a user performs a search or selects a facet, that
>> >>> value goes in the params hash, and you want to keep it around when you
>> >>> go from screen to screen, so that the user isn't always having to re-
>> >>> enter their current search. Let's say you're on the index screen, and
>> >>> you've entered a search and selected a facet. At that point your
>> >>> params hash looks like this:
>> >>>
>> >>> {"commit"=>"search", "action"=>"index", "q"=>"poetry",
>> >>> "f"=>{"language_facet"=>["English"]}, "controller"=>"catalog"}
>> >>>
>> >>> When you want to look at a detailed view for a specific item, you're
>> >>> linking to the show action of your same catalog controller, and
>> >>> passing it a specific document id. But you also want to hang onto the
>> >>> fact that you've searched for poetry and limited to
>> >>> language_facet:English, so you also pass the params object in. At
>> >>> which point your link_to really looks like this:
>> >>>
>> >>> <%= link_to document.get(:id),
>> >>> catalog_path
>> >>> (:id
>> >>> =>document[:id], :commit=>"search", :action=>"index", :q=>"poetry" ...
>> >>> etc ... ) %>
>> >>>
>> >>> Do you see the problem? It took me awhile to notice it. I've just
>> >>> called the show action, and then I also pass in a parameter of
>> >>> action=index. It's not obvious, because catalog_path sort of obscures
>> >>> the fact that you're calling the show action. Interestingly, webrick
>> >>> and mongrel don't seem to care. I guess they just assume that even
>> >>> though you've passed two values for action, you must really mean
>> >>> action=show because that's what's defined for catalog_path. The fix is
>> >>> easy, once you know what the problem is:
>> >>>
>> >>> <%= link_to document.get(:id),
>> >>> catalog_path(params.merge(:id=>document[:id],:action=>"show"))%>
>> >>>
>> >>> Now you're passing in a params object that looks like this:
>> >>>
>> >>> {"commit"=>"search", "action"=>"show", "id"=>"2008349843",
>> >>> "f"=>{"language_facet"=>["English"]}, "q"=>"poetry",
>> >>> "controller"=>"catalog"}
>> >>>
>> >>> So, all your user defined parameters, plus the id number of the
>> >>> specific item you want to show, plus action=show, which is what
>> >>> catalog_path expects. Problem solved.
>> >>>
>> >>> Sorry this is so long, but I learned a lot in fixing this bug and I
>> >>> thought it might be helpful for someone else too. But if it just looks
>> >>> like gibberish, ignore it.
>> >>>
>> >>> Cheers,
>> >>> Bess
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> From goodieboy at gmail.com Sun Feb 1 17:59:36 2009
>> >>> From: goodieboy at gmail.com (Matt Mitchell)
>> >>> Date: Sun, 1 Feb 2009 17:59:36 -0500
>> >>> Subject: [Blacklight-development] demo app bug fix
>> >>> In-Reply-To: <A6EAD76B-55E8-45A5-AACF-E080B1D2D499 at virginia.edu>
>> >>> References: <A6EAD76B-55E8-45A5-AACF-E080B1D2D499 at virginia.edu>
>> >>> Message-ID: <
>> c66dcac40902011459y279c7187yd46effb14248da9a at mail.gmail.com>
>> >>>
>> >>> Seriously, that's a kickin' write up Bess. Great bug catch. And the
>> docs
>> >>> look so nice too!
>> >>>
>> >>> For the link_to fix here:
>> >>>
>> >>> <%= link_to document.get(:id),
>> >>> catalog_path(params.merge(:id=>document[:id],:action=>"show"))%>
>> >>>
>> >>> You should be able to do this too:
>> >>>
>> >>> <%= link_to document.get(:id), catalog_path(document[:id],
>> >>> params.merge(:action=>nil)) %>
>> >>>
>> >>> I think this kind of thing will become a url-param-linking pattern in
>> BL
>> >>> and
>> >>> might do well in a view helper. I think there's one in the UVa trunk,
>> >>> called
>> >>> link_to_document or something. We could then have one called
>> >>> link_to_documents or link_back_to_search? The upshot of it being in a
>> >>> helper
>> >>> is that if someone overrides a view partial, they don't have to
>> re-write
>> >>> the
>> >>> param merging stuff. Food for thought...
>> >>>
>> >>> Matt
>> >>>
>> >>>
>> >>
>> >> _______________________________________________
>> >> Blacklight-development mailing list
>> >> Blacklight-development at rubyforge.org
>> >> http://rubyforge.org/mailman/listinfo/blacklight-development
>> >> Blacklightopac Blog http://blacklightopac.org/
>> >>
>> >>
>> >
>> > _______________________________________________
>> > Blacklight-development mailing list
>> > Blacklight-development at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/blacklight-development
>> > Blacklightopac Blog http://blacklightopac.org/
>> >
>> _______________________________________________
>> Blacklight-development mailing list
>> Blacklight-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/blacklight-development
>> Blacklightopac Blog http://blacklightopac.org/
>>
>
> _______________________________________________
> Blacklight-development mailing list
> Blacklight-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/blacklight-development
> Blacklightopac Blog http://blacklightopac.org/
>
>
>
> _______________________________________________
> Blacklight-development mailing list
> Blacklight-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/blacklight-development
> Blacklightopac Blog http://blacklightopac.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/blacklight-development/attachments/20090311/b59b2d0a/attachment-0001.html>
More information about the Blacklight-development
mailing list