I feel the following should go to plugins as well :
- components ( render_component etc. ) - has_many/habtm callbacks - spacer_templates
Any views ? Not in scope of 2.0 ? I asked a few people and no one really uses these features. It'd be nice to know how many people actually use'em.
Just to point out the logical conclusion of this and your other post:
A plugin that needs has_many callbacks should duplicate that functionality internally.
"It'd be nice to know how many people actually use'em."
I feel the following should go to plugins as well :
- components ( render_component etc. )
I think components are just dead. I've seen an "enhanced" component plugin replacement somewhere as well.
- has_many/habtm callbacks
Are you talking about before_add, after_add, etc?
- spacer_templates
Yeah, I don't find them helpful either.
http://dev.rubyonrails.org/ticket/9608
Are you talking about before_add, after_add, etc?
Yup. I personally find them quite useful. But as we talk, they're very much broken. Have a look at http://dev.rubyonrails.org/ticket/8854 I think they might be better off as plugins.
> - spacer_templates
Yeah, I don't find them helpful either.
Same here. If they're pluginized, it'll be easier to improve them for the rare bunch of people who actually use them.
-1. Stop tearing Rails apart into a salad of intertwined unmaintained dependencies.
I’d also like to avoid too many dependencies, but I’d MORE like to have these three pieces of code permanently obliterated.
But +1 for pluginization just in case somebody actually does want to use components.
::Jack Danger
-1. Stop tearing Rails apart into a salad of intertwined unmaintained dependencies.
The entire reason that things are being moved out into plugins is that they *don't* get sufficient care where they are at present.
If there's something in this list you're interested in maintaining, please feel free to volunteer.
Sorry for being harsh, but I'lll try to explain what I meant. I tried to keep my head down but it just has to be said. Callbacks should stay if you ask me. It's also not something I consider easily pluginizable (this is deep, nasty backend stuff).
Granted, nobody uses components (and they were sort of deadborn anyway), so no problem here. Granted, special DB adapters are a spicy specialty that only their respective maintainers should touch. But I got the problem with the big picture. It just upsets me that more and more totally vital things get extracted without anybody being asked if it's a good cource of action or not. It's just presented as a faite accompli in a changeset. I know the "I don't owe you shit" argument, thanks.
So I could take it for pagination (I had no app of all the ones I have built that didn't make use of it to date). Why did you kill the poor fella? "Did not like the style". I took it for acts_as_list (none of the apps I've made could do without it either). Why did you kill the poor fella? "Did not like the style". I took it for acts_as_nested_set (the half of what I've built got that in heavy rotation too). Why did you kill the poor fella? "Did not like the style".
I am all for "less software" and such, but it's kind of unpleasant to see the very features which warrant my Rails use evaporate. With a poof. And I never, _never_ as of yet made anything using the restful paradigm, neither did I have any need to do so.
Did these components have failing tests before extraction? No they didn't (most). Did they brake all the time? No. Is someone going to do CI with them now that they are gone? _Nobody_.
There are tickets on the trac for nested set and acts as list, and everybody knows what happened to them. There are people that wrote better_nested_set and friends - this has never become trunk, for one reason or another (most of the reasons being political so it seems).
What I ultimately fear (and I consider the fear justified) is that there will be a case of component rot (look at what happens to the plugins which are already extracted,for instance. "This plugin only works with Edge Rails revision 76743"). At the same time nothing is being done to actually loose-couple the components (and make their partial use possible) - you can't run a plugin test on a controller withour running routes. Can you do a template lookup without engaging the whole view subsystem and doing major monkeypatching? No you can't (yes I did file a ticket on that).
I can imagine that the extractions taking place are targeted at simplifying support of Rails as a coherent piece of software. I know that extractions do not bring (or bring only minimal) speed benefits (it's not that big of a deal on the performance front to "extract everything").
And yes, I do use habtm callbacks (seldom) and I do use spacer_templates (often), even if they might be not en-vogue and rest-du-jour. Am I the only one on this list who uses that stuff, I wonder.
The only course of action that I can justify in this case is "extract but keep" - that is, the extracted pieces should be integrated into the testing/CI lifecycle. At least so that you know when they cease to function between rev. 18212121 and 18212122, while many many innocent folks depend on them. So that Rails indeed works like a "composable set of plugins" but stays testable and runnable as a whole (with or without the bells and whistles). As the current course of action goes, it's "get rid of" instead of "pluginize". That's the approach that is worrying.
Hope I did not offend anyone. If I'm alone in these thoughts I will rest my case (I'm not core and I did not win any hackfests, and do not do kung-fu, so my opinion weights in at around 2 grams metric).
Sorry for being harsh, but I'lll try to explain what I meant. I tried to keep my head down but it just has to be said. Callbacks should stay if you ask me. It's also not something I consider easily pluginizable (this is deep, nasty backend stuff).
Or instead, you could have spent some time at
http://dev.rubyonrails.org/ticket/8854 
Will do.
That one gets a +1, particularly because I already resorted to using Camping apps as components works mucho beta(tm) than the built-in variety.