On 1/5/06, David Heinemeier H. wrote:
The lure of components is directly proportional with the pain of development.
I’m not trying to be abrasive in any way but I’m curious if this
attitude is related to the number of rails apps David maintains. No I
don’t know how many login systems David maintains. I can understand
avoiding components if a person only has one application to maintain.
Maybe a lot of us are still missing something?
Peter
Configuring an existing login system takes longer than creating a new
one (since you’ll have to look everything up), and what if your existing
login system turns out to be not configurable enough?
I think engines solve most of these problems:
http://rails-engines.org/
You can override everything in Ruby-code.
But I still think that things like calendar-components could be handy
sometimes.
Jules
While I think the statement is a platitude, I can give you a good
indication of my problem with massively componentized architectures:
That’s a lot of components, and all of them are very different in
their usability, documentation levels, and how they’re integrated.
Throw in that some use 1.4 java, some use 1.5 (or is that 3 or 2 or 5
I can never figure it out), and many of them require conflicting
versions of various other jars. A classic example is Log4J. One
project will use Log4J 1.2.8 another uses 1.2.13 and somehow also
uses the latest feature, so you get screwed when they both try to
load the classes and the class loader (that someone decided to
rewrite 20 times for extra confusion) blows up in your face. Even
worse if you used older JBoss that used the same log4j classes, but
just moved them to a different package so you got weird class loader
conflicts (and rewrote the class loader 20 times for extra confusion).
That’s just my opinion as to why components haven’t work as well as
advertised in practice. I think the windows world has a much better
component strategy simply because of the standards they enforce, but
even there you have similar problems.
I would actually say, it’s not so much the components, but the way
most componentized architectures don’t enforce an integration
standard. You can have tons of components as long as there’s a
standard about how they’re documented, written, used, and
distributed. But none of that solves the problem of interlocking
dependencies. Nobody’s got a solution to that I believe.
Zed A. Shaw
Jules wrote:
Configuring an existing login system takes longer than creating a new
one (since you’ll have to look everything up), and what if your existing
login system turns out to be not configurable enough?I think engines solve most of these problems:
http://rails-engines.org/You can override everything in Ruby-code.
But I still think that things like calendar-components could be handy
sometimes.Jules
While I understand DHH’s position on this, I think there is a fair
amount of ‘pain of development’ involved in putting together a good
login system. The stakes are also pretty high if you screw it up.
There are only a few things that lend themselves well to
‘components/engines’. I think a login system is one of them.
One of the things I really like about the ‘engines’ is that it is pretty
easy to customize/extend them once you have them running. In my mind
they are sort of like scaffolds on steroids. As a developer, you would
do well to review/replace them according to your needs, but they do give
you the framework to get up and running quickly.
_Kevin
Am 15.01.2006 um 20:23 schrieb Zed S.:
I would actually say, it’s not so much the components, but the way
most componentized architectures don’t enforce an integration
standard. You can have tons of components as long as there’s a
standard about how they’re documented, written, used, and
distributed. But none of that solves the problem of interlocking
dependencies. Nobody’s got a solution to that I believe.
I can only agree here: The problem with component dependencies is one
you cannot solve without having control over all components.
However, rewriting everything from scratch, having a component in
source code and applying updates and security patches on top of your
code (as is the case with the Generator approach) all have their own
drawbacks.
IMO this is one of the principles of complex systems: Every
sufficiently interestingly complex system bears the seed of havoc and
problems.
Regards
Manuel H.
Whether or not it’s possible (or desirable) to create a ‘general’ set
of high-level components which will happily integrate in a way that
satifies an acceptable proportion of developers, I think at the very
least it’s always going to be useful to have tools which enable
developers to create subsystems which they, personally or within their
team, can reuse in later projects. In this case, the problem of
ensuring interoperability lies squarely at the foot of the
developer(s) themselves, which is almost certainly where it should be.
Even when made public, the responsibility for integrating those
solutions with their own application again lies with the application
developer. This is surely an inversion of responsibility compared to
heavily-component-based frameworks.
Zed S. wrote:
I would actually say, it’s not so much the components, but the way most
componentized architectures don’t enforce an integration standard. You
can have tons of components as long as there’s a standard about how
they’re documented, written, used, and distributed.
I went to the London Web Frameworks night, back in November, and was
very impressed by the way that Catalyst (Perl) [1] provides a framework
that allows different options for architectural components (renderers,
authenticators, persistence etc.) to be plugged together.
I hope someone will do the same in Ruby.
regards
Justin
I’m not trying to be abrasive in any way but I’m curious if this
attitude is related to the number of rails apps David maintains. No I
don’t know how many login systems David maintains. I can understand
avoiding components if a person only has one application to maintain.
Maybe a lot of us are still missing something?
37signals has four applications in production and two in development.
They all have different login systems. Some more similar than others,
but all sufficiently different for components to work well (meaning
less effort and higher cohesion than starting from scratch every
time).
David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework
James A. wrote:
the deep, deep waters of CPAN. One of the advantages of Rails over
works.
I think it’s a bit more remarkable than that. The parts for a PC conform
to interfaces which are understood across an industry, whereas my
impression is that Catalyst allows integration of components that were
defined in the absence of agreed interfaces.
So far as the choice is concerned, if all you have is Catalyst and CPAN,
then you are right, but that combination provides an opportunity for
other people to provide the ‘distro’. I don’t know if that’s happening
with Catalyst, but AppFuse is an example in the Java world. (And the
need to choose is a big difference between the Java world and the .NET
world.)
That said, i know nothing of the Perl library, and if you knew the
dark incantations necessary to summon your carefully-chosen demons
from the CPAN realm, then I can imagine there’s a certain pleasure in
that.
I imagine so - I’m not a Perl hacker myself. I would like a web
application framework with the expressiveness of Rails and a lot more
pluggability of components. I am only using Rails for prototyping at the
moment - most of what my customers need is a little way off the Rails
‘golden path’. I’m looking forward to when JRuby both performs well and
has all the functionality required by Rails.
It also might be worth noting that the components we were talking
about in this particular thread where application-level, rather than
framework level…
Well, there’s a lot of stuff that DHH considers to be application-level
that I am used to seeing architectural support for, so I don’t think
that there is a hard distinction there. The application/architecture
boundary is pretty context-dependent (where context includes people and
organisation structure, as well as business requirements - it’s a
well-known observation that architectures reflect the structure of the
organisations that produced them).
Catalyst has pluggable support for authentication and authorisation,
which is stuff that DHH regards as inappropriate for the core of Rails.
I’d like Rails to take the same approach as Catalyst - define the
plug-in points, and let other people provide the options to plug in.
Thanks for an interesting reply - I’ve had to think quite a lot while
responding, and have thrown away as much text as I ended up with.
Justin
P.S. Have you watched the Snakes and Rubies videos? It’s well worth it.
On 1/18/06, Justin F. [email protected] wrote:
I went to the London Web Frameworks night, back in November, and was
very impressed by the way that Catalyst (Perl) [1] provides a framework
that allows different options for architectural components (renderers,
authenticators, persistence etc.) to be plugged together.
Actually, my impression of Catalyst from that very same presentation
was “… where on earth do I start?!” It seemed like you could chop
and change so many parts of the framework that it was difficult to
know what was even a sensible combination without steeping yourself in
the deep, deep waters of CPAN. One of the advantages of Rails over
that approach, IMHO, is that it provides everything you need. If you
want a different ORM layer or renderer, such things are certainly
possible, but you don’t have to assemble it all like a kit if you
don’t want.
Using Catalyst struck me as being a microcosm parallel to building
your own Linux distro. Eeek! Perhaps a better analogy would be
building your own PC vs. buyng a Mac. I used to build my own PCs, but
now I wouldn’t have a clue which GFX card (read: view renderer) or ATA
standard (read: ORM layer) is any good anymore; my Powerbook just
works.
That said, i know nothing of the Perl library, and if you knew the
dark incantations necessary to summon your carefully-chosen demons
from the CPAN realm, then I can imagine there’s a certain pleasure in
that.
It also might be worth noting that the components we were talking
about in this particular thread where application-level, rather than
framework level…
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs