Rails 5 roadmap?

[Jason Fleetwood-Boldt]

Rails core,

I was wondering if Rails 5 has a discussed (or proposed) roadmap? A growing chorus of developers are seeking ways to separate domain logic from persistence logic at the model level. I was wondering from a bird’s-eye perspective if the framework plans to adopt patterns to make that easier (and more encouraged) to implement in the future?

I tried to do a little googling for Rails 5 docs but I was unable to find solid stuff.

-Jason

----

Jason Fleetwood-Boldt

te...@datatravels.com

http://www.jasonfleetwoodboldt.com/writing

[Rafael Mendonça França]

We don't have any roadmap yet besides the drop of support o Ruby 1.9.

About your specific question I believe it is unlikely we provide something besides what we already provide with Active Model.

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Xavier Noria]

Rails comes with a default structure that serves well a ton of apps, but does not mandate that you use that structure as is, which is a common misconception/starting point in talks, posts, etc.

Those are the defaults, but of course projects can add their service objects, form objects, decorators, and whatever they want. Tailor-made for their needs or their personal preferences, which are legit.

What it is not going to happen in any foreseeable future is that the default structure changes. The only change in that direction has been to add a convention for code organization via modules (concerns).

I'd like to add I've personally done dozens of (gasp) well-written apps using the default layers in the last decade, do not believe every generalization or theoretical argumentation you read out there. Think with your editor.

[Jason Fleetwood-Boldt]

Got it, thanks.

I agree that as a framework there is no architectural mandate, and that the idea that there is one is a (too) common misconception. It is unfortunate that people coming to the framework do not have the perspective to know that (and in turn create a lot of unsustainable code).

The main architectural issue I would take with Rails in its entirety (and pitfall I’ve seen on dozens of badly written apps myself) is the encouragement of over-use of callbacks and, of course, the all-too-common domain logic where it shouldn’t be. I’m sure everyone knows on some level what I’m talking about, and yes, I agree this is not fundamentally Rails’ fault but instead the fault of the developers who use it. 

I wonder if there’s a way we can provide better documentation or training to alternatives design approaches — well within the paradigm of what Rails is currently capable of (as you pointed out).

-Jason

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Xavier Noria]

On Tue, Nov 25, 2014 at 5:37 PM, Jason Fleetwood-Boldt <te...@datatravels.com> wrote:

I agree that as a framework there is no architectural mandate, and that the idea that there is one is a (too) common misconception. It is unfortunate that people coming to the framework do not have the perspective to know that (and in turn create a lot of unsustainable code).

The main architectural issue I would take with Rails in its entirety (and pitfall I’ve seen on dozens of badly written apps myself) is the encouragement of over-use of callbacks and, of course, the all-too-common domain logic where it shouldn’t be. I’m sure everyone knows on some level what I’m talking about, and yes, I agree this is not fundamentally Rails’ fault but instead the fault of the developers who use it. 

I wonder if there’s a way we can provide better documentation or training to alternatives design approaches — well within the paradigm of what Rails is currently capable of (as you pointed out).

I don't know.

For example, some people say business logic in AR models violates SRP! ZOMG! And look at the ancestor chain! Look at user.methods.size, that... must break some principle or another!

Those people would write some kind of documentation.

Other people look at the code and say: it's fine and simple to understand, models encapsulate, some models are not ARs, controllers coordinate. Find a balance. Extract as needed. Do after/before comparisons. Works like a charm for many applications. If it does not work for your particular application, grow a design tailored for it.

In my view, It depends so much on the application and personal design preferences that you cannot generalize. I don't think "if your ARs grow too big insert an entire new layer of POROs and extract everything there" is an advice you can document like that in the Rails documentation, to pick an example. And the Rails documentation shouldn't have a catalogue of patterns that we generally cannot recommend by heart.

[Bráulio Bhavamitra]

If I could suggest something, I would say: DOUBLE PERFORMACE

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

--

"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
http://cirandas.net/brauliobo
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e destruídas nas fases de extroversão e introversão do fluxo imaginativo cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente, naquele momento, essa pessoa é a única proprietária daquilo que ela imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha por um milharal também imaginado, a pessoa imaginada não é a propriedade desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso a propriedade deste universo é de Brahma, e não dos microcosmos que também foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo, mutável ou imutável, pertence a um indivíduo em particular; tudo é o patrimônio comum de todos."
Restante do texto em http://cirandas.net/brauliobo/blog/a-problematica-de-hoje-em-dia

[Sean Griffin]

I don't want to go into specifics because most of what I'm working on is still high level ideas. I doubt that we'll see a separated persistence and business logic layer land in Rails any time soon (though internally we're actually becoming very close to that). However, we are continuing to break things into smaller pieces which may eventually be made public and can be re-used by other libraries like Virtus or ROM.

One of the biggest places for this is having clearer lines between what happens at the AR class level, vs the DB table level, and how the two communicate. I'm hoping to reduce the number of places that take a class object which inherits from AR::Base as part of their arguments, in favor of objects which represent the concept they need, which again should help reusability without having to inspect hundreds of methods across dozens of modules to figure out what the expected interface actually is.

I don't have anything specific other than rough ideas of where things need to happen to get there, and this is all just ideas that may or may not actually happen. My concern is more on improving maintainability of the internals, hooks for gem makers, and fixing bugs, rather than user facing API. Even if everything does happen, it might not result in anything that you use in your rails apps.

[Kasper Hansen]

The Rails team gladly awaits your benchmarks and Pull Requests to help make that happen, Bráulio ;)

--

Kasper

[Mohamed Wael Khobalatte]

While we are on the subject of potential changes, I asked in a previous thread about what's gonna happen to controller tests (functional tests in previous parlance) and got no response. I am asking for two reasons: 1. It was one of the proposed GSOC projects, so it is to be expected that someone picked it up, and 2. I think it's a mistake to deprecate them (the wording was to unify them with integration tests, but from what I read it seems that they'll essentially be deprecated) and I plan to write more on the subject if what I suspect is true. But perhaps suffice it to say that the renaming to controller tests alone has already eased most of the confusion out there. 

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

--

Mohamed Wael Khobalatte

[Xavier Noria]

BTW, something that is in the radar is replacing accepts_nested_attributes_for with something else, maybe form objects... it is just being explored (and could end up in nothing).

[Bráulio Bhavamitra]

I hope I'll be able to contribute more to rails Kasper, thank you!

[Kunal Shah]

Hello,

I've been giving a lot of thought to building a gem which puts more validation into the controllers and routing and removes it elsewhere. My conclusion was that I didn't need to build a gem, Rails in fact already has everything needed to accomplish this, however - I just need to change the default pattern it provides. I'd like to share my thoughts and receive yours - 

route validations, strong_parameters, and ActiveModel are sharing responsibility but are split across framework.

What if the instead of defining a single set of validation rules with a single class inheriting from AR per table, the default was to define several valid persistable-object states per table with a series of ActiveModel Prototypes.

What if setters, getters and validations were mixed in by virtue of these AM Prototype classes (I think default setters/getters are AR defined atm?). Further, the Prototype would guard persistence, like a state machine, since 'create', 'save', 'update/patch', 'destroy' would not be defined/mixed-into every Prototype, only ones appropriate for the action.

Really, all this already exists - for instance, routing allows you to define regex's to match incoming parameters -- but how many people are using this? (that's a real question, I have no idea). Then we have controller level validation with strong_parameters. Then we have model level validation. Why not move all this into some form of Prototype which defines what keys are open, required, what they can, should, should not look like (type checking), etc?

This approach also has one cool side benefit - nicer introspection which can aid front end generators / frameworks.

I'm posting here cause I haven't thought this through fully and when I try to write out a DSL for this I start going off course -- but to my delight a few have touched upon these things in this thread, if I'm reading your thoughts correctly.

- Kunal

[Oleh Novosad]

DCI is the solution to all architectural problems.

вівторок, 25 листопада 2014 р. 08:57:07 UTC-8 користувач Xavier Noria написав:

[Ecleel]

I'd love to see more use for Rails Engine and make it a default way of developing application.

[pathé Sene]

#go Rails Engines