Rails en de dingen die je niet moet doen
Afgelopen week kwam Kevin Clark met een artikel over de dingen die je niet in Rails moet doen. Grotendeels gaat het artikel over het gebruiken van oude code, zoals instantie variabelen gebruiken die je niet gedeclareerd hebt en deprecated methoden als find_all en render_partial. Over het algemeen kon ik me prima vinden in de adviezen die Clark geeft. Toch zet ik hier en daar m'n vraagtekens.
Rails Engines
In het artikel maakt Clark een opmerking over Rails Engines, die hem duur is komen te staan.
Yes, I know you’d like to have an authentication system without doing any work. Yes, I know Rails preaches convention over configuration. This is not a place where it applies. This is, as we say back in the hood, “too much software”. It’s also a nasty hack that breaks every new version of Rails because it hooks into internals that aren’t publicly supported. These are akin to scaffolding. You’ll be happier without them.
Al snel kwamen de ontwikkelaars van engines met een reactie op hun blog. Ik ben zelf een grote fan van engines, het geeft je de mogelijkheid om code op te delen. Zo ben ik nu bezig met een content management systeem als engine in Rails. Je kunt de code simpel in verschillende applicaties gebruiken zonder telkens weer de standaard dingen opnieuw te hoeven schrijven.
Uiteraard moet je er wel rekening mee houden dat de code in je engine nooit een one-size-fits-all oplossing is. Maar zolang je kritisch blijft over de toepassing van een engine, zie ik alleen maar voordelen. Een puntje voor de engine ontwikkelaars dus.
Components
Components don’t belong in Rails. Don’t use them. They weren’t an extraction. They weren’t well planned. When you want to use a component it is probably because you misunderstand them or really want a partial. Rethink what you’re doing. The rest of the Rails world has written off components for a reason and they’ll probably be deprecated by 2.0. Resist.
Bij deze opmerking plaats ik een heel groot vraagteken. Ik denk dat ik het doel van components redelijk begrijp en ik ben ook zeker een voorstander van partials (gewoon omdat ze beter geïmplementeerd zijn). Toch zijn components onmisbaar op bepaalde punten.
Een partial is niet meer dan een stukje HTML waar geen logica in zit. Hoe kunnen partials ooit de combinatie van logica en weergave vervangen? Je kunt er niet omheen dat je soms gegevens uit je database moet halen en om dat allemaal in een partial te zetten gaat mij iets te ver.
Dat de implementatie van components nog wat verbetering kan gebruiken kan ik me in vinden, dat ze in Rails 2.0 niet meer terug te vinden zijn geloof ik niet.
Het artikel (en de reacties) van Clark is zeker aan te raden om te lezen als je met Rails bezig bent. Wellicht dat je jezelf kan betrappen op foute code, maar het is ook heel interessant om de verschillende perspectieven van mensen op de onderdelen in Rails te zien.
Volg Scriptorama via RSS!
on 
on 
on 
on 
on 
on
Reageer ook!
Ik vind de 'attitude' van de auteur niet echt gepast. Elke Rails fanaat wil een PHP programmeur bekeren tot Rails, maar met zo'n toon gaat dat niet snel lukken. Hij geeft wel goede argumenten.
Ik ben schuldig aan het scaffolding argument. Foei!
Door Tri Pham
op 09.01.06 @ 2:29 am | Permalink
" Elke Rails fanaat wil een PHP programmeur bekeren tot Rails, maar met zo’n toon gaat dat niet snel lukken. "
Lukt je toch niet :P
Door berry__
op 09.01.06 @ 8:46 am | Permalink
"Elke Rails fanaat wil een PHP programmeur bekeren tot Rails, maar met zo’n toon gaat dat niet snel lukken. Hij geeft wel goede argumenten."
Ik denk eerder dat hij een poging doet om Rails fanaten te bekeren tot nadenken over hun code. Er zweven helaas nog veel slechte voorbeelden op internet rond. Zelf heb ik ook tijden gebruik gemaakt van @flash en @session. Voor mijn gevoel is dat namelijk ook logischer, want hoe kan Rails ooit een variabele flash aanmaken in een method scoop.
Het bekeren van PHP fanaten tot Rails lukt mij meestal in 15 minuten: gewoon de screencast laten zien!
Door Edwin V.
op 09.01.06 @ 10:14 am | Permalink
Heb ik al gezien en ik ben nog niet bekker :D (PHP & PostgreSQL FOR EVER!!)
Door Sebastiaan Stok
op 09.01.06 @ 2:39 pm | Permalink
Ja Sebastiaan, dat dacht ik een half jaar geleden ook. "PHP en MySQL for life", totdat ik toch echt de overstap heb gemaakt. Niet zozeer door de screencasts, maar meer omdat ik een goed framework nodig had en PHP een beetje saai begon te worden.
Door Tri Pham
op 09.01.06 @ 5:25 pm | Permalink
Tsja, ik krijg bij rails toch een beetje hetzelfde idee als bijvoorbeeld Linux: minder mensen zijn er bekend mee dus oh, oh, oh wat is het 1337.
Ik heb rails bekeken en was onder de indruk, maar toch kan ik met niet aan het idee onttrekken dat het allemaal wat lastiger wordt wanneer je iets wilt dat niet in het framework ondersteund wordt. Trouwens: zonder Rails was Ruby helemaal nergens.
Tri: "maar meer omdat ik een goed framework nodig had en PHP een beetje saai begon te worden"
PHP heeft prima frameworks waar je veel mee kunt. Nadeel is gewoon dat er te veel frameworks in PHP zijn. Het lijkt alsof iedereen met een paar jaar ervaring een framework released in de trant van "kijk wat ik kan". Ik denk dat het feit dat PHP wat saai voor je begon te worden een grotere factor is dan dat PHP zogenaamd geen goede frameworks zou hebben.
Door Ruud
op 09.04.06 @ 7:47 am | Permalink
"Tsja, ik krijg bij rails toch een beetje hetzelfde idee als bijvoorbeeld Linux: minder mensen zijn er bekend mee dus oh, oh, oh wat is het 1337."
Dat idee had ik eerst ook ja, samen met de beklemmende gedachte dat je ooit tegen iets aan zou kunnen lopen dat niet mogelijk is. Ik werk nu enkele maanden met Rails en ben zo'n situatie nog nooit tegen gekomen.
Daarnaast is het werken met Rails te vergelijken met werken met een Mac: het werkt allemaal zonder gedoe. Er is heel goed nagedacht over de opzet, het is echt toegespitst op webapplicaties en zal daarvoor altijd werken. Je moet alleen wel durven afstappen van je ideeën over webontwikkeling in PHP, in Rails gaan veel dingen namelijk net iets anders (lees: beter).
Door Edwin V.
op 09.04.06 @ 11:09 am | Permalink
RoR biedt veel mogelijkheden maar komt op mij nog niet over als iets wat ik zelf zou gaan gebruiken naar een klant toe. Dit kan ook héél goed aan mij liggen overigens...
Trouwens, Edwin... Meloen? ;)
Door Dennis Wijnberg
op 09.05.06 @ 11:06 am | Permalink
Dennis,
Ik zie eigenlijk geen redenen om het niet te doen. Het biedt een basis die elke webapplicatie nodig heeft. Door deze basis kan het je veel werk uit handen nemen. De enige reden die ik kon bedenken om niet met Rails te gaan werken voor klanten, was mijn gebrek aan ervaring met Ruby. Maar Ruby is zo'n heerlijke taal dat zelfs dat geen problemen geeft.
Maar als je nog meer overtuiging nodig hebt, wil ik die wel eens komen geven onder het genot van een stukje meloen :-)
Door Edwin V.
op 09.05.06 @ 1:01 pm | Permalink
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>