Thank you for your explanations, José.
But don't you think that engines should be created by default by the
"rails plugin new" command as I expect them to be more commonly used
than railties or plugins?
This is similar to Rails Metal. You can get a lighter controller using
lower-level classe
> The point I'm trying to make is that there is no need for exposing so
much details to extension developers.
There is. Engine has a longer initialization process, more objects
involved, etc. Why would you submit your app to a longer initialization
process when there is no need to?
Railties
The point I'm trying to make is that there is no need for exposing so
much details to extension developers.
I'd prefer Rails 4 to only provide a single generator for an engine that
would fit all other cases covered by plugins and railties.
You don't have generators for Metal or other lightwei
http://api.rubyonrails.org/classes/Rails/Railtie.html
"if you need to interact with the Rails framework during or after
boot, then Railtie is needed"
It shows examples of how to use a Railtie too.
There is no real difference between a non-rails gem and a basic
plugin. It's just pure ruby that gets
If I recall correctly it was possible to have some global generators in
your user's home dir once.
Was this feature removed? If so, why?
Also, I can provide default options for "rails new" in ~/.railsrc and
that is pretty useful. Is there some similar feature for "rails plugin new"?
--
You r
Em 05-06-2012 15:40, Luiz Felipe Garcia Pereira escreveu:
The same rails guides like you pasted before shows a simple example of
"just a plugin" when it just extends the core class String.
I asked exactly what is the difference between this and a regular Ruby
non-Rails gem.
As for the diffe
The same rails guides like you pasted before shows a simple example of
"just a plugin" when it just extends the core class String.
As for the differences between Railties and Engines, I'll quote the
docs (http://guides.rubyonrails.org/engines.html):
"A Rails::Engine is nothing more than a Railtie
Em 05-06-2012 15:05, Luiz Felipe Garcia Pereira escreveu:
One word: Modularity
If it's a simple plugin, it doesn't need to be a Railtie and inserted
in rails
Could you please explain the differences about this and a regular Ruby gem?
If it's something that extends rails/AR it can be a Railti
One word: Modularity
If it's a simple plugin, it doesn't need to be a Railtie and inserted in
rails
If it's something that extends rails/AR it can be a Railtie and take
advantage of that.
If it's an engine then it makes sense to add the Engine and have the extra
tools Rails::Engine provides.
It's
I'm not that lazy for avoiding to type "--full -T -O" every time I
create a new gem.
By the way I don't get why 's.add_development_dependency "sqlite3"' is
added to gemspec when -O is specified.
The problem here is that it seems inconsistent to me for a plugin not to
be an Engine. I don't ev
I'll review it.
Thank you.
Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca
On Tue, Jun 5, 2012 at 1:55 PM, Steve Jorgensen wrote:
> Hi all,
>
> I've had a pull request up for a while that I'd like to get
> incorporated. Anything I can do to facilitate an
Hi all,
I've had a pull request up for a while that I'd like to get
incorporated. Anything I can do to facilitate an expeditious
acceptance or informative rejection?
This adds auto-reconnection for PostgreSQL if a connection is
externally broken. Also includes build fixes and fixing fragile tests
It's a "rails plugin new" not "rails engine new".
It doesn't create a default Engine because not all plugins are engines.
If it's an engine and not just a plugin/railtie you would normally want the
"--full" option.
If not, just create it. It's only 4 lines of code.
On Tue, Jun 5, 2012 at 1:25 PM
But my engines usually don't have any routes and even those who have are
not mountable ones.
I'm just asking for an engine to be created even for non-mountable
engines. I mean, as the default behavior of "rails plugin new plugin-name".
The "--full" will add integration tests which I also don'
Yes. Just do "rails new plugin some_example --mountable".
You should also take a look at --full. ;)
On Jun 5, 2012, at 2:55 PM, Rodrigo Rosenfeld Rosas wrote:
> What version are you talking about? That doesn't happen on latest stable
> 3.2.5 here.
>
> If that is already implemented in master, t
The only thing I really have to add to this conversation is that your routes
are not necessarily mapped one to one to your models. You might have a nested
url that is actually a different association but there's also an association
matching the url - how do you tell it not to use the automatical
On Tue, Jun 5, 2012 at 10:09 AM, Matt Jones wrote:
>
> On Jun 5, 2012, at 8:18 AM, John Mileham wrote:
> >
> > It's easy to dismiss as an obvious mistake, but I've seen it done too
> many times to want to encourage deeply nested routes by automating the URL
> generation. If your controller is fo
On Jun 5, 2012, at 8:18 AM, John Mileham wrote:
>
> It's easy to dismiss as an obvious mistake, but I've seen it done too many
> times to want to encourage deeply nested routes by automating the URL
> generation. If your controller is forced find the user from the project in
> order to perfor
What version are you talking about? That doesn't happen on latest stable
3.2.5 here.
If that is already implemented in master, then great, I hope it to be
backported to 3.2.6 when it gets released...
Thanks,
Rodrigo.
Em 05-06-2012 10:22, Luís Ferreira escreveu:
It creates the lib/some-examp
Em 05-06-2012 10:10, Maurizio Casimirri escreveu:
Il giorno 05/giu/2012, alle ore 13.55, Rodrigo Rosenfeld Rosas ha scritto:
...
Em 05-06-2012 00:17, Maurizio Casimirri escreveu:The problem relies
in the gems in my opinion. They should follow the SRP instead of just
assuming things to get a b
It creates the lib/some-example/engine.rb file which is just as you described
and then requires it in lib/some-example.rb. Shouldn't that be enough?
On Jun 5, 2012, at 2:10 PM, Rodrigo Rosenfeld Rosas wrote:
> I've been creating several engines for Rails lately and I found that having
> an engin
Il giorno 05/giu/2012, alle ore 13.55, Rodrigo Rosenfeld Rosas ha scritto:
> Em 05-06-2012 00:17, Maurizio Casimirri escreveu:
>>
>>>
>>> Sorry, but I have no idea what you're talking about. Could you please give
>>> me an example of one of those AR plugins you're referring to?
>>>
>>
>> Sor
I've been creating several engines for Rails lately and I found that
having an engine class inherited from Rails::Engine is required if you
intend to bundle some Sprockets assets.
So, shouldn't the template for "rails plugin new" change so that "rails
plugin new some-example" would create some
>
> I feel like there definitely would be some security risk but I can't think
> of a real, solid example. Can you lay one out for me?
>
Hi Michael, here's one example. Let's say that you must be the creator of
a project to add issues to it (perhaps contrived in this case, but many
access control
It's been long best practice to not nest more than one deep:
http://weblog.jamisbuck.org/2007/2/5/nesting-resources
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To
Em 05-06-2012 00:17, Maurizio Casimirri escreveu:
Sorry, but I have no idea what you're talking about. Could you please
give me an example of one of those AR plugins you're referring to?
Sorry, you are right i was referring to gems that involve querying the
database through AR, Devise to s
On Tue, Jun 5, 2012 at 4:28 AM, Michael Boutros
wrote:
>
> As for actually implementing this, my train of thought is to use
> ActiveRecord::Reflections to keep checking what a model belongs_to and then
> calling that association.
>
There is no sane way to guess which association to use. "Issue" fr
27 matches
Mail list logo
