Hi!
I think the engines are nice to:
1) share some common logic between several applications on your own;
2) make an example implementation of something available to the world.
Engines, at my opinion, are not good for (and I'm going to give
arguments for this):
3) making an implementation of something that is usable in a wide range
of applications.
Overriding elements within an engine works good for the first case. If
something gets unoverridable, you refactor your engine a bit and stay
happy.
Overriding *CAN* work for the third case *IF* the engine is designed
with that in mind. Doing this is difficult, but even the more important
problem is that this way is not in the spirit of Rails, and is not easy
for users. I've already told why in the first post. (Rails does not
provide ready-made implementations, it generally focuses on providing
building blocks, and the assembly process stays in the hands of
developer. This way the developer knows how his application works.)
The very important thing you must realize is that people tend to take
the 2nd case as if it was the 3rd case. I've seen this happening in
other projects, and now this starts to happen with Rails. Instead of
taking the LoginEngine as an example and rolling their own engine for
their specific tasks (which will probably be common for a set of
applications), they treat it as an unmodifiable black box and search for
a way to customize it. If you look through the engine users mailing list
(and I guess you do :), you already know this is happening.
What's more, people take LoginEngine as an example of a proper engine,
and start distributing their own engines similar to it. But this is not
a correct way! Their code would be much, much more reusable if they
would split it into several building blocks, and make such blocks
available.
Not only splitting up complex logic into building blocks helps
reusability, it also helps to produce somewhat more managable code,
which better adheres to the "one module (class) - one task" rule.
> But distributing black-box components is NOT
> the purpose of the engines plugin, but rather a secondary effect with
> unique benefits and of course, some unique drawbacks.
But this side-effect has very important consequences, which can even
ruine the whole Rails plugins idea. One must be very sure before he
starts to wrap complex logic into an opaque component for
redistribution.
> The LoginEngine itself, however, does have aspects where it's
> implementation doesn't lend itself well to being overridden.
The problem is that you believe one can make a Good Engine that will
solve this problem. What I say is that making public reusable engines in
not practical at all, because such complex logic needs a higher level of
customization than is possible with engines-style overriding and/or
configuration.
> To make this absolutely clear, the point of engines is NOT so I can
> write a bunch of components for you guys to plug together in weird and
> wonderful ways. It's so YOU can develop your applications in a modular
> way and reuse those modules across your applications as YOU determine
> might be appropriate.
Yeah, this is all right, and I fully agree with this. However I'm
worried by all the newly appearing public engines which are nearly
uncustomizable.
> The community sharing is essentially an
> afterthought, but if you're written something that other people find
> useful then that presents a not-inconsiderable secondary bonus.
I think it must be stated somewhere that engines (unlike plugins) are
not meant to provide drop-in functionality from public sources. Doing
this can bring serious scaling (in the sense of requirements changes)
and customization problems to your application.
> If you find yourself having to rewrite a lot of some component,
> chances are you would be better off not using it.
Yeah, that is *exactly* what I've talking about: if the only thing you
like about, say, LoginEngine is the way it handles account deletion, you
cannot use just that one thing from it (and *still* have benefit of
updates of that feature, that is, still get everything one gets when he
moves from code generators to engines).
Engines are good as a way to share complete business logic betwen your
projects. (For example, I have a credit-card processing engine that
works with my specific bank and with my specific sschemas. I'm not going
to make it public because I'm not going to maintain it as a public code
with a stable interface. *And* it is inefficient to do so, even if I
wanted to.)
However, then, a way to share truly reusable building blocks is still
required for Rails. (Another reason engines are not good for this is
that you can have only one copy of an engine, while you could use the
same building blocks to build two different parts of your application.)
> Sorry if this doesn't seem quite on-topic, I just feel it's essential
> not to bring criticisms of the LoginEngine's "lack of modularity"
> against engines in general.
I hope that I've explained my thoughts better, and that I've made clear
that the problem is not specific to {Login,User}Engine, but is much more
general and relates to all public engines.
Yes, one can build a modular engine, but both it's usage and development
(and even usage documentation) would be harder than splitting the
modules and implementing them as separate non-engine plugins.
> Good luck exploring your modular methods idea!
Thank you, I hope I'll come up with a good solution to the "reusable
blocks" problem I've stated.
Still another question: being tired of edge rails and trunk engines
(in)compatibilities, is there a plan to integrate Engines plugin into
the core?
Andrey.
--
Posted via http://www.ruby-forum.com/.
_______________________________________________
engine-developers mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
