Hi all, MenuEngine is a small Rails engine that can generate templated drop-down DHTML menus commonly used for web site navigation. Supports creation of menus from a YAML file, from code and from pre-configured HTML. Optionally integrates with UserEngine for authorization. http://www.muermann.org/ruby/menu_engine Project page: http://rubyforge.org/projects/menuengine This is my first attempt to release a Rails plugin, so please let me know if I got the distribution wrong and you have installation problems. Cheers, Max
Posted at http://agilewebdevelopment.com/plugins/menuengine :) -- Benjamin Curtis http://www.bencurtis.com/ http://www.tesly.com/ -- Collaborative test case management http://www.agilewebdevelopment.com/ -- Resources for the Rails community On Jul 27, 2006, at 5:50 PM, Max Muermann wrote:> Hi all, > > MenuEngine is a small Rails engine that can generate templated > drop-down DHTML menus commonly used for web site navigation. Supports > creation of menus from a YAML file, from code and from pre-configured > HTML. Optionally integrates with UserEngine for authorization. > > http://www.muermann.org/ruby/menu_engine > > Project page: > http://rubyforge.org/projects/menuengine > > This is my first attempt to release a Rails plugin, so please let me > know if I got the distribution wrong and you have installation > problems. > > Cheers, > Max > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060728/bd321609/attachment.html
Hi there, your engine seems really nice, but I can''t get it to work.
I followed the little tutorial at the link you gave but the call <%=
menu :menu => "my_menu" %> outputs an empty
<script></script>.
Here is the code I used (I am trying to do some kind of bug tracking
tool. And yes the controller and action are valid)
application_helper.rb
-----------------------------
module ApplicationHelper
include MenuHelper
def my_menu
item_0 = MenuItem.new( :text=>"Menu Item 0",
:controller=>"bug" )
item_1 = MenuItem.new( :text=>"Menu Item 1",
:controller=>"bug",
:action=>"show" )
item_2 = MenuItem.new( :text=>"Menu Item 2",
:controller=>"bug",
:action=>"show" )
item_0.items << item_1 << item_2
item_3 = MenuItem.new( :text=>"Menu Item 3",
:controller=>"bug" )
return [item_0, item_3]
end
end
environment.rb
-------------------------------
module UserEngine
config :access_control, false
end
Engines.start :menu # or :menu_engine
And my basic layout:
application.rhtml
-----------------------------
<html>
<head>
<%= javascript_include_tag :defaults %>
<%= engine_stylesheet "menu_engine" %>
<%= engine_javascript "menu_engine" %>
</head>
<body>
<div id="top_menu">
<%= menu :menu => "my_menu" %>
</div>
All this outputs only
...
<div id="top_menu">
<script></script>
</div>
...
What in the world am I doing wrong???
Thank you for your time,
Jd
P.S. Yes I did install the menu_engine engine.
Max Muermann wrote:> Hi all,
>
> MenuEngine is a small Rails engine that can generate templated
> drop-down DHTML menus commonly used for web site navigation. Supports
> creation of menus from a YAML file, from code and from pre-configured
> HTML. Optionally integrates with UserEngine for authorization.
>
> http://www.muermann.org/ruby/menu_engine
>
> Project page:
> http://rubyforge.org/projects/menuengine
>
> This is my first attempt to release a Rails plugin, so please let me
> know if I got the distribution wrong and you have installation
> problems.
>
> Cheers,
> Max
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
On Friday 28 July 2006 02:50, Max Muermann wrote:> This is my first attempt to release a Rails plugin, so please let me > know if I got the distribution wrong and you have installation > problems.Max, I''m wondering whether there''s a reason to make "it" an engine instead of a plain plugin. You can make available JavaScript and stylesheets files from a plugin, too. Install (deinstall) them from the install.rb (uninstall.rb) hook files. See also ActionView::AssetTagHelper#register_javascript_include_default. Michael -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/
If I may rant on the engines vs. plugins bit for just a bit. I have been working on a couple of engine/plugin implementations...frankly the documentation for plugins, how they should be built, and implemented is not very complete, unless you are a ruby hack, which again frankly speaking alot of us aren''t. The engine routine is easy as heck. The documentation is simple enough. Yeah it is a bit of an overkill, but will someone please finish some consise documentation for plugins that don''t center around class mixins for activerecord?????? Just my two cents... Dave On 7/27/06, Michael Schuerig <michael@schuerig.de> wrote:> On Friday 28 July 2006 02:50, Max Muermann wrote: > > This is my first attempt to release a Rails plugin, so please let me > > know if I got the distribution wrong and you have installation > > problems. > > Max, I''m wondering whether there''s a reason to make "it" an engine > instead of a plain plugin. You can make available JavaScript and > stylesheets files from a plugin, too. Install (deinstall) them from the > install.rb (uninstall.rb) hook files. See also > ActionView::AssetTagHelper#register_javascript_include_default. > > Michael > > -- > Michael Schuerig > mailto:michael@schuerig.de > http://www.schuerig.de/michael/ > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- ~~~~~~~~~~~~~~~~~~~ David Andrew Thompson http://pecatores.blogspot.com http://dathompson.blogspot.com
> I have been working on a couple of engine/plugin > implementations...frankly the documentation for plugins, how they > should be built, and implemented is not very complete, unless you are > a ruby hack, which again frankly speaking alot of us aren''t. > > The engine routine is easy as heck. The documentation is simple > enough. Yeah it is a bit of an overkill, but will someone please > finish some consise documentation for plugins that don''t center around > class mixins for activerecord??????That''s precisely why it is an engine - it was a lot easier to find the information. I''ll have a stab at making it a plugin instead anyway, just out of interest. I am not too sure about the idea that engines are considerably more "heavyweight" than plugins, but am happy to be educated otherwise. Cheers, Max
On Friday 28 July 2006 08:11, David Andrew Thompson wrote:> If I may rant on the engines vs. plugins bit for just a bit. > > I have been working on a couple of engine/plugin > implementations...frankly the documentation for plugins, how they > should be built, and implemented is not very complete, unless you are > a ruby hack, which again frankly speaking alot of us aren''t. > > The engine routine is easy as heck. The documentation is simple > enough. Yeah it is a bit of an overkill, but will someone please > finish some consise documentation for plugins that don''t center > around class mixins for activerecord??????Having implemented a couple of plugins you''re probably perfectly qualified to write those docs. In my opinion, the information linked from http://wiki.rubyonrails.com/rails/pages/HowTosPlugins is okay to get started writing plugins. It is just a bit scattered. In and of itself, packaging functionality in a plugin is fairly easy. What can be considerably less easy is implementing the desired functionality. Changing something deep in the bowels of Rails is bound to be non-trivial. All that said, I haven''t myself figured out how to publish a plugin so that it can be installed using script/plugin install. But I''ve only yesterday touched on plugin writing for the first time. Regarding plugins vs. engines I think that where possible functionality ought to be packaged as a plain plugin. As a rule of thumb I suggest to use the mechanism that results in a simpler component. So, if in a plugin you''d have to recreate the functionality already provided by the engine mechanism, then make it an engine instead. If in an engine most of the engine-specific functionality goes unused, better make it a plugin. Michael -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/
On 7/28/06, Michael Schuerig <michael@schuerig.de> wrote:> If in an engine most > of the engine-specific functionality goes unused, better make it a > plugin.This doesn''t quite make sense, unfortunately. By this logic, if you''re not using most of the features of Rails, you should be coding up your own application from CGI basics. If you''re not making use of most of the features of Ruby, then you *really* ought to be dropping down to C... ... Obviously that''s ridiculous. Rails (and Ruby) exist to make things easier. The engines plugin exists to add some useful features to the existing plugin mechanism, until such point (which may never come) that they can be integrated into Rails itself. If using even one of the tiny aspects that engines provides makes your life easier, then you''re welcome to do just that.> As a rule of thumb I suggest to > use the mechanism that results in a simpler component. So, if in a > plugin you''d have to recreate the functionality already provided by the > engine mechanism, then make it an engine instead. If in an engine most > of the engine-specific functionality goes unused, better make it a > plugin.Alas, this doesn''t make sense either. A simple component would take advantage of existing functionality rather than reimplementing it. How much functionality you use really isn''t relevant to your rule of thumb. - james p.s. Plugin development documentation is only weeks away - there''ll be more information here soon: http://www.informit.com/shortcuts -- * J * ~
On Friday 28 July 2006 10:00, James Adam wrote:> On 7/28/06, Michael Schuerig <michael@schuerig.de> wrote: > > If in an engine most > > of the engine-specific functionality goes unused, better make it a > > plugin. > > This doesn''t quite make sense, unfortunately. By this logic, if > you''re not using most of the features of Rails, you should be coding > up your own application from CGI basics. If you''re not making use of > most of the features of Ruby, then you *really* ought to be dropping > down to C...Suit yourself. Have a look at the distribution of the average plugin compared to the average engine. A plugin with tests can consist of about five files. An engine apparently comes with a bit more baggage. If you only want to plunk some functionality into your app, you''ve got no reason to care about this. But if you want to have a quick look at the code and to see how things work, less *unnecessary* clutter is better. Now, if the intended functionality relies on its own models, controllers, and views -- well, then an engine is probably the better choice. For some simple helper, AR addition, or something of that kind, presumably a plain plugin is the better choice.> > As a rule of thumb I suggest to > > use the mechanism that results in a simpler component. So, if in a > > plugin you''d have to recreate the functionality already provided by > > the engine mechanism, then make it an engine instead. If in an > > engine most of the engine-specific functionality goes unused, > > better make it a plugin. > > Alas, this doesn''t make sense either. A simple component would take > advantage of existing functionality rather than reimplementing it. > How much functionality you use really isn''t relevant to your rule of > thumb.James, next time you think that someone is talking utter nonsense, please check that your understanding of what was said is the intended one. There''s a principle of charity involved in making communication work. Michael -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/
Max Muermann wrote:> Hi all, > > MenuEngine is a small Rails engine that can generate templated > drop-down DHTML menus commonly used for web site navigation. Supports > creation of menus from a YAML file, from code and from pre-configured > HTML. Optionally integrates with UserEngine for authorization. >Wow, this is really cool and useful. Thanks! -- Posted via http://www.ruby-forum.com/.
On 7/28/06, Michael Schuerig <michael@schuerig.de> wrote:> Suit yourself. Have a look at the distribution of the average plugin > compared to the average engine. A plugin with tests can consist of > about five files. An engine apparently comes with a bit more baggage. > If you only want to plunk some functionality into your app, you''ve got > no reason to care about this. But if you want to have a quick look at > the code and to see how things work, less *unnecessary* clutter is > better.Using the plugin/engine that this thread was originally about as an example, the developer could happily drop half of the ''clutter'': * db/ is empty * test/ is unused (though it really ought to include tests, hint hint! :) * tasks/ is empty * lib/menu_engine/ is empty * app/controllers/ is empty * app/views/ is empty ... Max might even choose to drop the entire app folder - if he doesn''t care about the code mixing stuff, the helper and model could happily sit in lib. This would leave... 6 files (including the README) in two directories - lib, and public. Pretty clean. Not everything that uses the engines plugin need be huge, heavyweight, bulky, or bloated. Just because an ''engine'' can carry more baggage, doesn''t mean it has to. -- * J * ~
Simplest way to create a plugin... script/generate plugin my_first_plugin All that is manditory is... lib/my_first_plugin.rb Which gets autoloaded when the server starts. -NSHB On 7/28/06, James Adam <james.adam@gmail.com> wrote:> > On 7/28/06, Michael Schuerig <michael@schuerig.de> wrote: > > Suit yourself. Have a look at the distribution of the average plugin > > compared to the average engine. A plugin with tests can consist of > > about five files. An engine apparently comes with a bit more baggage. > > If you only want to plunk some functionality into your app, you''ve got > > no reason to care about this. But if you want to have a quick look at > > the code and to see how things work, less *unnecessary* clutter is > > better. > > Using the plugin/engine that this thread was originally about as an > example, the developer could happily drop half of the ''clutter'': > > * db/ is empty > * test/ is unused (though it really ought to include tests, hint hint! :) > * tasks/ is empty > * lib/menu_engine/ is empty > * app/controllers/ is empty > * app/views/ is empty > > ... Max might even choose to drop the entire app folder - if he > doesn''t care about the code mixing stuff, the helper and model could > happily sit in lib. This would leave... 6 files (including the README) > in two directories - lib, and public. Pretty clean. > > Not everything that uses the engines plugin need be huge, heavyweight, > bulky, or bloated. Just because an ''engine'' can carry more baggage, > doesn''t mean it has to. > > -- > * J * > ~ > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Kind regards, Nathaniel Brown President & CEO Inimit Innovations Inc. - http://inimit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060728/86b32406/attachment.html
I''ve written a couple of plugins before, as well as some engines. If I want to change some AR functionality, I have used simple plugins. If I have something that relies on a bunch of assets such as javascript and css files, I would chose an engine, simply because this is taken care of automatically.> > ... Max might even choose to drop the entire app folder - if he > doesn''t care about the code mixing stuff, the helper and model could > happily sit in lib. This would leave... 6 files (including the README) > in two directories - lib, and public. Pretty clean. >Above suggestion would negate that advantage that in my opinion the engine layout has over plugins. One of the reasons I like the engine concept better is that the directory structure mirrors that of a rails application. If I pick up an engine from somewhere, I *know* where stuff is, if I need to change it (which I frequently do). With a plugin, I have to read through (sometimes a lot of) the code first to work out what goes where. Yes I know, I could mirror the sam structure in a plugin as well, but then I have to write all the file copying and mixin stuff myself - which really really sounds like repeating myself (or somebody else). Dropping swome of the empty folders is probably a good idea - point taken on the tests, I am normally quite rigorous in rwiting unit tests for my application. Just because something has a few extra folders does not make it "heavyweight..." Max