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
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 .
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
<%= javascript_include_tag :defaults %>
<%= engine_stylesheet "menu_engine" %>
<%= engine_javascript "menu_engine" %>
<body>
<div id="top_menu">
<%= menu :menu => "my_menu" %>
</div>
All this outputs only
…
...
What in the world am I doing wrong???
Thank you for your time,
Jd
P.S. Yes I did install the menu_engine engine.
On Friday 28 July 2006 02:50, Max M. 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 S.
mailto:[email protected]
http://www.schuerig.de/michael/
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
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 S. [email protected] wrote:
–
David Andrew T.
http://pecatores.blogspot.com
http://dathompson.blogspot.com
On Friday 28 July 2006 08:11, David Andrew T. wrote:
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 S.
mailto:[email protected]
http://www.schuerig.de/michael/
On Friday 28 July 2006 10:00, James A. wrote:
On 7/28/06, Michael S. [email protected] 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.
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 S.
mailto:[email protected]
http://www.schuerig.de/michael/
On 7/28/06, Michael S. [email protected] 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.
p.s. Plugin development documentation is only weeks away - there’ll be
more information here soon: http://www.informit.com/shortcuts
Max M. 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!
On 7/28/06, Michael S. [email protected] 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.
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 A. [email protected] wrote:
Using the plugin/engine that this thread was originally about as an
doesn’t care about the code mixing stuff, the helper and model could
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
–
Kind regards,
Nathaniel B.
President & CEO
Inimit Innovations Inc. - http://inimit.com
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