RoR with Reia
Hello, would be possible to run RoR with Reia ( http://en.wikipedia.org/wiki/Reia_(programming_language) )?
Hello, would be possible to run RoR with Reia ( http://en.wikipedia.org/wiki/Reia_(programming_language) )?
I have a rails engine that works quite well. We use it internally for creating all our web apps to conform to the same UI look and feel, widgets, etc... Problem is that we want to deploy it as a gem for versioning. Is there a way to create the a gem out of a rails engine?
I tried, and was able to create a gem, but there were errors. Would be great if someone could point me to some documentation on this subject. I have searched and can't find anything. Seen a coupld engines like Clearance that do run as a gem but they are not too complex, they don't have any asset files, and I think that is the problem I was running into.
I vendered my gem to vendor/gems and it was complaining about finding the asset files I believe.
Thanks
_______________________________________________ Engine-Developers mailing list Engine-Developers@... http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
Hey everyone, I've been out of the loop for a minute regarding engines, but I'm looking to update Substruct to Engines 2.3/Rails 2.3 if possible. My last investigation stopped when running into the migrations issue. I'm wondering if there is a recommended way to handle engine migrations / legacy migrations (001_my_migration.rb) with 2.3. The official site mentions some "things being in the works" but I didn't really see anything past that. Any advice or a link to a blog post would be cool. Thanks much. -------------------- http://subimage.com http://twitter.com/subimage
So if I understand things right, my Engine plug-in can have a helper in it. And my app can provide a helper by the same name, and the two helpers will be merged together, any conflicting method names my app's helper with the same name will take precedence. Is there a reason this wouldn't work for an ApplicationHelper in application_helper.rb ? My engine provides an ApplicationHelper. That works fine as long as the app using it has no ApplicationHelper. But if the containing app does have an ApplicationHelper, they are NOT merged together, but instead only the containing app's ApplicationHelper is used, everything in the Engine's ApplicationHelper is lost and unavailable. Can anyone shed some light on this? Jonathan
James, on your presentation at railsconf (http://rails-engines.org/news/2009/05/18/engines-at-railsconf/) you suggest (for now) making your own generator to handle the migrations issue. Can you elaborate on that method?
_______________________________________________ Engine-Developers mailing list Engine-Developers@... http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
Hi,
I have a rails app (redmine) running within a sub-uri via the following
directive in environment.rb:
ActionController::AbstractRequest.relative_url_root = "/redmine"
Unfortunately, URLs generated for plugin assets by Engines do not honor
this directive. I don't know Rails, but it seems like an easy fix if you
know how to get at the request object from within Engines. I was
thinking of something along these lines:
===================================================================
--- vendor/plugins/engines/lib/engines/rails_extensions/asset_helpers.rb
(revision 2796)
+++ vendor/plugins/engines/lib/engines/rails_extensions/asset_helpers.rb
(working copy)
@@ -109,5 +109,5 @@
# Returns the publicly-addressable relative URI for the given asset,
type and plugin
def self.plugin_asset_path(plugin_name, type, asset)
raise "No plugin called '#{plugin_name}' - please use the full name
of a loaded plugin." if Engines.plugins[plugin_name].nil?
-
"/#{Engines.plugins[plugin_name].public_asset_directory}/#{type}/#{asset}"
+
"#{@controller.request.relative_url_root}/#{Engines.plugins[plugin_name].public_asset_directory}/#{type}/#{asset}"
end
Can someone point me in the right direction?
Thanks,
John
One of the handy things missing from Rails, that the engines plugin tries to provide but which isn't really core to its functionality, is a way of inspecting the set of loaded plugins while the application is running. This is achieved via the Engines.plugins method (which is again aliased as Rails.plugins, for backwards compatibility). We use this mostly when dealing with public assets from within plugins, but it's also useful for generating RDoc for plugins. In fact, the only thing the custom engines plugin loader does is to add plugins to this set, so if Rails itself implemented it, we could simplify the plugin greatly. Maybe even get rid of the 'boot' line, which needs to be added to the top of environment.rb! Here's my ticket, hidden under the guise of being about the plugin documentation task: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2526-generated-plugin-rdoc-should-include-all-code-within-plugin-load_paths Feedback appreciated, James
Hi all, I've just made the appropriate changes to bring the engines plugin into compatibility with Rails 2.3, and the engine features it implements. You can find these changes in the 'edge' branch of the git repository, which I'm currently working on now. The most notable change within your engine plugins is that I've removed the custom routes handling from the engines plugin, in favour of the implementation supplied by Rails itself. This means that your routes should now be in config/routes.rb, rather than the plugin root, and that map.from_plugin is no longer implemented. The main reason for removing this is that I'm not very comfortable patching Rails to change existing behaviour like this; it was simpler when Rails didn't provide any plugin routing, but I'm keen not to result in two kinds of engine plugins - ones that require the engines plugin itself, and others that work with Rails out-of-the-box. If the community feels that controlling the positioning of the routes is necessary, we should be pursuing this as part of the Rails core implementation, i.e. with tickets and patches and +1s. I've also properly removed support for 'code_paths' in the plugin - there are simpler and more obvious ways to support this. I am keen to smoothly transition as much of the key functionality as possible from the engines plugin into Rails itself. What remains, IMHO, is the following: * a Rails.plugins map of loaded plugins * Migrations support * Public asset support The major feature missing here is the 'code-mixing', which is basically a short cut for requiring a controller/helper from the plugin before reopening the class again in the application. There's already been some discussion on the Rails lighthouse instance about migrations, but without any suitable resolution. I'd be grateful to hear any ideas or thoughts you might have, either specifically about these features, or about this process in general. Thanks again for your support, James
_______________________________________________ Engine-Developers mailing list Engine-Developers@... http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
Hello,
_______________________________________________ Engine-Developers mailing list Engine-Developers@... http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
Hi all, What's the best way to always reload the assets (javascript + css) when in the development environment? I'm developing a plugin for Redmine that relies heavily on javascript for interactivity and would like to avoid having to restart the server everytime I modify the js. Regards, Mark
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
RSS Feed2 | |
|---|---|
1 | |
2 | |
6 | |
1 | |
4 | |
22 | |
3 | |
3 | |
12 | |
3 | |
1 | |
2 | |
30 | |
25 | |
8 | |
53 | |
8 | |
2 | |
4 | |
4 | |
2 | |
5 | |
4 | |
3 | |
9 | |
31 | |
19 | |
14 | |
4 | |
12 | |
9 | |
29 | |
2 | |
14 | |
4 | |
46 | |
72 | |
48 | |
54 |