Plugin routes override application routes Rails ticket
Jason Ronallo
We've had the discussion here about changing "catalog" to "view" or
something else. The reason why this is such an issue and not easily
configurable is because of how Rails loads routes when a plugin
defines routes. In current Rails, plugin routes override application
routes.
There has been a Rails Lighthouse ticket submitted for this issue.
Because this is an issue that I think ought to be fixed in Rails,
here's how you can +1 this ticket and provide more information on why
this ought to be fixed in Rails.
If you do not have a Rails Lighthouse profile here's where you can
sign up for one. It ought to redirect you to the ticket when you've
filled out the required fields.
https://rails.lighthouseapp.com/users/new?to=%2Fprojects%2F8994%2Ftickets%2F2592-plugin-routes-override-application-routes
If you already have a rails lighthouse profile, here's the ticket:
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2592-plugin-routes-override-application-routes#ticket-2592-6
Hopefully this gets fixed in Rails so we don't have to monkey patch to
get route overriding working. If you're interested in the monkey patch
which ought to work, look at the comments on the ticket which link
here:
http://giantrobots.thoughtbot.com/2009/4/23/tips-for-writing-your-own-rails-engine
Jason
Bess Sadler
) and it seems like we could do a lot to get this committed to the
core if we review the code ourselves. We need at least three people to
apply the patch and actually review the code... do the rails tests
still pass, did they write tests covering the code in the patch, and
then write something about it. Once three people have done this we can
mark the patch as "verified" and one of the core committers will look
at it.
Given that this would really help us out for both the blacklight and
the hydra projects, is there anyone out there who feels up to tackling
this?
Bess
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Blacklight Development" group.
> To post to this group, send email to blacklight-...@googlegroups.com
> To unsubscribe from this group, send email to blacklight-develo...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
Jonathan Rochkind
sure your app routes take precedence over engines routes?
http://robots.thoughtbot.com/post/159805560/tips-for-writing-your-own-rails-engine
Bess Sadler wrote:
> So I was just reading the rails contributer guidelines
Erik Hatcher
the Blacklight _application_ (searchworks at Stanford, VIRGO BETA at
UVa) is the place this gets defined, in a plain ol' simple Rails
way... as a Controller.
I'm confused as to why there has to be so much complexity and
workarounds/fixes and configuration for this.
Very interested, yet currently sidelined, lurker,
Erik
Jonathan Rochkind
Blacklight plugin, because to get your controllers working right, it
includes some functionality that most people are going to share, and
shouldn't have to re-invent.
So, I agree that the application should define this, but: a) it needs to
be done in routes, not just in naming conventions of the controller, and
b) _some_ default needs to be in the Blacklight plugin. (I'm unconcerned
with what this default is, because I think it's more important to make
it easily over-rideable in the Application via routes).
However, some bug or lack of feature in Engines makes it hard to
over-ride routes from a plugin in an Application. Which is where the
need for a workaround comes from. However, it looks like a pretty easy
workaround to let Application routes over-ride plugin routes. These
guys seem to have found the recipe (in the "routes precedence" section
of this page)
http://robots.thoughtbot.com/post/159805560/tips-for-writing-your-own-rails-engine
So, to me, it makes sense to add their workaround into things (might be
neccesary for every individual app to add this workaround, might not be
possible to do it in the plugin), and then simply figure out the easiest
way to re-define routes in the application to use whatever words you
want in in the path for each controller.
Just my point of view!
Jonathan
Erik Hatcher
On Sep 17, 2009, at 10:56 AM, Jonathan Rochkind wrote:
> As I understand it, it makes sense to define controllers in the
> Blacklight plugin, because to get your controllers working right, it
> includes some functionality that most people are going to share, and
> shouldn't have to re-invent.
This is true in a "meta" sense. What Blacklight should define in the
plugin are actions that can be wired into controllers. How many
controllers does an app like searchworks or virgo beta need (that use
Solr, that is)? One or two, right? Those actions could be defined
in the plugin, and brought into an application defined controller
easily and configurably.
For example (and I know it isn't as elegant or exemplar as one would
like), here's the Flare controller:
<http://svn.apache.org/repos/asf/lucene/solr/trunk/client/ruby/flare/vendor/plugins/flare/app/controllers/browse_controller.rb
>
Yes, that controller is in the plugin, but what I'm proposing is that
it actually be pulled up to the application itself. The "flare" macro
there comes from the plugin as I'm proposing it should with
Blacklight. Many actions come along for that ride, and parameters
could be passed to it.
Putting less application-level stuff in Blacklight, yet making it
capable of being powerfully wired into an application is the goal I'm
aiming for.
> So, I agree that the application should define this, but: a) it
> needs to
> be done in routes, not just in naming conventions of the controller,
> and
I disagree that it needs to be defined in routes, per se. But even
so, a clever Blacklight plugin level macro seems like it could wire
into routes, but specified at the application level. Not routes
defined actually in the plugin.
> b) _some_ default needs to be in the Blacklight plugin. (I'm
> unconcerned
> with what this default is, because I think it's more important to make
> it easily over-rideable in the Application via routes).
Nah... just a demo application that has a controller that says:
class ViewController < ApplicationController
blacklight
end
I don't see a need for the plugin itself to _be_ the application. But
a demo application, I'm all for no question.
> Just my point of view!
Likewise ;)
Erik
Jonathan Rochkind
an adopting person get a 'default' blacklight with as little work as
possible, but a controller with one line in it (maybe "include
BlacklightController" would do the job just as well but more simply than
a "blacklight" method) isn't so bad. Perhaps combined with a generator
to make those controllers for you for people who do want an easy-start
default configuration.
One trick would be that the controller code that is included from the
plugin can't count on default Rails conventions for finding it's views
anymore, since the controller name is unknown at view-creation-time, so
each controller would have to explicitly call a render statement to get
it's intended default view.
Personally, I think what's going on now, assuming
app-level-route-overriding can be made to work, is perfectly fine too.
But I agree that Erik's approach is also perfectly fine, if someone has
time to do the work to make it so.
Jonathan
Erik Hatcher
On Sep 17, 2009, at 2:41 PM, Jonathan Rochkind wrote:
> I think it's important to let
> an adopting person get a 'default' blacklight with as little work as
> possible,
key already up and running and can index any MARC, etc and show a cool
usable UI right out of the box. +1
Let's move on....
> but a controller with one line in it (maybe "include
> BlacklightController" would do the job just as well but more simply
> than
> a "blacklight" method) isn't so bad. Perhaps combined with a generator
> to make those controllers for you for people who do want an easy-start
> default configuration.
"include" (which I'd argue is just semantics.. whatever makes the
right Ruby mojo happen to bring methods into that controller instance,
whatever wand you want to wave). No objections.
A generator... now we're back to that one... first, I don't think it
is anything urgent to have. Institutions need to tune a few things...
MARC mappings, schema.xml (unless ya go crazy with dynamic fields,
which is fine), solrconfig.xml (nothing needed in the basic case, but
I recommend kind of a controller to request handler connection, or at
least consideration), and template tweaks to personalize.
I've long since thought that a Ruby object model that generated
schema.xml would be cool. Use the model of the underlying data source
in fact... (marc4j/ruby-marc + JRuby, yeah baby). And have some macro
that adds whatever is needed to map to Solr (see solr-ruby Mapper
possibilities).
But since all the above, mostly minor, tweaks to these config spots
aren't really that hard to do by hand, and it's not really that error
prone either, it's hard to justify the effort to go full on generation.
But, for a simple thing, having a "script/generate controller browse"
and manually typing "blacklight" in it seems like not asking too much
for end "users" (developers, let's be honest)
Erik
Jonathan Rochkind
to do ("script/generate controller browse" ; then add "blacklight" under
that ; repeat for three of four more controllers). (I agree "include"
vs. a method doesn't make any difference, whatever is less code and
easier to maintain) ; Or you've got a generator that just does that,
and it probably doesn't take any more lines of code to write such a
simple generator than it does to write the documentation explaining what
to do by hand.
No big deal either way. I like generators for the simple reason that
they can result in instructions like "rails MyApp; ./script/plugin
install blacklight ; rake blacklight:default_app ; configure your
databases.yml and run migrate ===> Bingo, you have a working default
app." Rather than have to have an svn controlled demo app,
necessarily. I kinda like that idea. (Doesn't mean non-neophyte
developers HAVE to use the generator, of course).
But no big deal, I don't think we're really arguing about anything?
Note that I like generators only when all their doing is generating
references to actual code that lives in Blacklight. I don't like
generators that put lots of logic in your app, cause then you've broken
the 'link' and made upgrading hard. So I in fact like generators only
when they're so simple that Erik would argue they are unneccesary -- if
they were actually complicated, I'd be thinking that the logic should be
moved to the plugin instead of needing to be generated in the app in the
first place!
Jessie Keck
Erik Hatcher
On Sep 17, 2009, at 4:05 PM, Jessie Keck wrote:
> Is what's being proposed here the following:
> I want to JUST change my url from 'catalog' to 'something'.
JUST changing a URL, though, in the bigger sense is significant. It's
your applications "control" over how the world interacts with it.
This URL is the heart of the system.
But yeah, this is all about "just" changing the URL. Or rather,
making it flexible to have controllers with different types of Solr
parameter mappings easily (and all actions from that controller that
come into existence are based on that controller-specific config). In
the early days of Blacklight there was a desire to have a Music
Library interface along with the main general public interface. This
would translate to two controllers, a BrowseController (I prefer
"browse" to view or catalog, personally) and a MusicController. The
music controller would have something (off the top of my head) like:
blacklight :facets => [:instrument, :period, :key, ... whatever]
or...
blacklight :request_handler => :music
or with a smart default no parameter would be needed, but each
controller would be based off the controller names request handler
mapping... /solr/browse?q=.... /solr/music?q=....
Too much magic yet?! ;)
> I will need to create a controller (generated or manual) called
> 'something' and include the plugins CatalogController at the top?
Basically, yeah.
> If so, that seems like overkill to me. Maybe I'm not understanding
> this correctly.
A single controller with one line of code is overkill? Versus doing
app-level routes to plugin-level actions? Pull the plugin _into_ the
app, I'm proposing. With meta Ruby magic like it's good for.
before_filter-like stuff.
> Also, I would like to put in a shameless plug for my previous
> suggestion of how to allow the app to override the plugins routes
> until Rails fixes the bug. (Email to list w/ Subject = "Changing
> the plugins default route 'catalog" sent on 9/11/09). I haven't
> heard anything for or against this posted on the list.
I just don't see why the plugin needs publicly accessible routes at
all. Let an app-level controller or two weave them in.
I do a lot of pondering how I idealize these things. You folks are in
the trenches building these apps. My thoughts are meant as food for
contemplation, and maybe some of it will be useful to take away and
incorporate.
One of these days I'll incorporate all my ramblings into Flare. I've
laid things out enough in prose that I could have probably as easily
just coded it up.
Shuttin' up now ;)
Erik
Bess Sadler
Also, I would like to put in a shameless plug for my previous suggestion of how to allow the app to override the plugins routes until Rails fixes the bug. (Email to list w/ Subject = "Changing the plugins default route 'catalog" sent on 9/11/09). I haven't heard anything for or against this posted on the list.-Jessie
Jason Ronallo
I'd prefer to be able to override the whole route in my own
application, but your configuration option meets my most immediate
need. I'm happy if we go with your solution at least for now.
Jason
Jonathan Rochkind
then you will have to create a controller called 'something' and one way
or another reference the plugin if you want.
So, yeah, then if you want to change your url, you just change the
'something'.
I don't think Erik's approach is unreasonable, but I don't think it's
necessary.
Jessie, went back and looked at your suggestion. This works and is easy
to work with. But what do you think about the recipe I found on google
for just plain making app routes correctly over-ride Engines plugin
routes? Then you wouldn't need that extra level of config, you could
just plain use Rails routes, so anyone that knew Rails routes could do
it as normal.
Jonathan
Jessie Keck
I have actually seen this article before in my own research on this
issue. I have 2 issues with this.
1) I'm assuming that this will be addressed in Rails at some point
(hopefully soon). This seems like it will require more clean up once
this fix is implemented. This could also cause potential problems for
users that are currently modifying the routes somehow, although I'm
not sure how many are.
2) Even the article author says that it's ugly stuff. Not sure if
that's much to base a decision on or not but it's something I notice.
While I can't say that I necessarily oppose this method, I just like
the ease of a configuration option. Also, I've heard that the Hydra
folks are interested in a configurable routing mechanism. And not
like we're trying to be vuFind, but this is how vuFind generates its
URLs and seems to be something that the users like.
I'm not trying to find a permanent solution by any means, and if I
were, I think the solution you propose would probably be the best.
However; this is not meant to be permanent. This is meant to be a as
simple of a solution as possible and be as easy to clean up and to
point people how to modify their own apps routes.rb file once Rails
has gotten this fix in.
I like this method, just don't know if it's the simplest.
Thats all for now,
-Jessie
Richard Green
Just to confirm Jessie's suspicion "I've heard that the Hydra folks are
interested in a configurable routing mechanism." Yes, we definitely
are!
Richard