Rails - Aug 2007 - rails code reuse: plugins (and engines)

------ reusable code in rails

Like many other companies I''m sure, we have a bunch of rails code for
building social networks. and we''re doing lots of projects that are
very
similar.

i was wondering what rails options have been succesful for other
people for code re-use across projects.

my understanding is that plugins'' approach to anything
with views is to use generators.
you cant actually have view/controller code in the plugin?

the problem with generators is that then you cant re-use any
modifications to the generated code - theyre basically one-way.
but this maybe OK, if a lot of the actual code is still in the plugin.

- concrete example: forum
a good specific thing we need to do: a forums
if we move this into a plugin...

- dependencies on main app / models
first, there are dependencies on the main app''s user model.

- migrations
there arent easy way to share migrations with the main app and an also
evolving plugin.
this could possibly be solved in the plug-in installer having its own
mini-migrations.

- getting added code back into plugin
but, lets say we add a function to the forum. eg we want to show the
"status" of any poster.
eg are they a level1, or level5 person.
this is basically a modify of the view, plus reading some data from
the user model:   user.status
not much controller code.

if we modify the BBS view after the code was generated,
then no code goes back into the plugin for re-use/sharing.
a generator is basically one-way.

- view helpers?
since plugins support -view helpers- we could rewrite the forum views
all as helper methods.
these could then maybe be passed parameters? eg render_forum
(:with_status) would be in the generated view for the app.

- installing partials
another thing some people seem to do is have the installer copy some
partials into the main app.
this is just as set in stone as generators really. eg:
http://svn.nanorails.com/plugins/bookmarkit/install.rb

- can a plugin include a controller?
i guess it could include a library, which is a module that the
controller in the app could require...

- non abstract plugins
basically for abstract functions (like a swf renderer, or AR/ acts_as
extensions) the plugin approach works well.
but not sure how much it will save us on these very view-oriented
items.
it may end up being a lot of work to make the plugin, and then its
basically just a fancy way to cut and paste the code.
how much code will actually be in the plugin, vs. what is generated?


"engines" seem to allow most of what i need, but they dont seem to be
getting much use.
they depend lot of rails internals, and it seems they aren''t the safest
way to go
- every time rails changes, all engines break. if the developer stopped
maintaining engines, i doubt we''d be able to go in and keep things
working...and so be stuck without.
there are very few ppl using engines vs. plugins.
http://www.railslodge.com/plugins/category/6

i think this is a problem for rails. now components are in limbo, there
isnt an obvious way to reuse/subclass view-related functionality.

Any thoughts appreciated.

/dc
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I''ll cover some of your points here, and other ones on the engines
mailing list.

On Aug 5, 10:38 pm, D-- C--
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> my understanding is that plugins'' approach to anything
> with views is to use generators.
> you cant actually have view/controller code in the plugin?
That''s correct, although some of the recent changes in edge rails make
it slightly easier to load views from different paths (http://
interblah.net/2007/2/5/more-plugin-power-goes-into-rails-core).
However, for Rails 1.2.x, the engines plugin provides the small amount
of patching required to load views from plugins.
> - dependencies on main app / models
> first, there are dependencies on the main app''s user model.
Is this a problem? Your shared code simply requires some objects for
working with the user accounts that respond to a set of well-known
methods. Even if your user accounts use different tables in different
applications, this can normally be circumvented by using a common
interface (i.e. a current_account method somewhere) to access it.
Regardless, this isn''t a significant problem until you start sharing
your forums with other developers whose code you cannot control.
> - migrations
> there arent easy way to share migrations with the main app and an also
> evolving plugin.
I presume you''ve seen the migration integration that the engines
plugin provides? This works very well as a solution for evolving the
schema required by shared plugin code.
> - getting added code back into plugin
> a generator is basically one-way.
This is basically the primary motivation for enhancing plugins in the
way that engines does.
> - view helpers?
> since plugins support -view helpers- we could rewrite the forum views
> all as helper methods.
This might be possible, but it''s such a departure from how you
typically develop a Rails application, is it worth pursuing? You will
also encounter problems when you try and delegate production of views
to designers if you choose this route.
> - installing partials
> another thing some people seem to do is have the installer copy some
> partials into the main app.
That''s definitely a possibility, but you''ll run into the same
"generators are one-way" issue as before.
> - can a plugin include a controller?
> i guess it could include a library, which is a module that the
> controller in the app could require...
The easiest type of non-typical code to include in a plugin is a
controller - if this is all you need, there are solutions which exist
for doing this without including the engines plugin (google is your
ally here). However, these still involve playing with some Rails-
internal functionality, only this time it''s in your plugin''s
init.rb
file, rather than being provided by another plugin (engines). YMMV.
> "engines" seem to allow most of what i need, but they dont seem
to be
> getting much use.
Regarding your other concerns about engines being unstable and so
on... this is only really a concern if you like developing against
edge rails, and the same concerns exist on any code that you rely on
but aren''t responsible for.

If you feel like you need some of the functionality that the engines
plugin provides, take a look at it. You''re certainly free to tear out
the methods that you need and discard the rest, if that feels like a
safer approach :)

- James


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---