Hi All,
> http://pastie.org/230474
I've used m_r, r_c and others, and while promising at start, I had to
remove them because most of the time the defaults weren't the defaults
as I want them to be and they became too obtrusive. The problem, as
hampton already indicated, is that they try to d
On Jul 10, 6:34 am, "Rick DeNatale" <[EMAIL PROTECTED]> wrote:
> In any event, I'm glad to see this come up. Not having looked at the
> actually code in the patch, this looks like it might help address my current
> pet peeve about rails validations which is that the walkbacks you get when a
> v
On Jul 10, 12:40 am, "Michael Koziarski" <[EMAIL PROTECTED]>
wrote:
> > It has come to my attention the above wall of text is a little
> > intimidating and is holding back adoption ;)
>
> Quite ;)
>
> > So I present to you a summary, in ADD-friendly, fixed-with 68-char
> > column formatted (to a
> My point with all of this is to massively strip down the functionality
> that is available in the plugins and just have an extremely simple
> interface for the most basic, basic resource facilities in a
> controller.
Sounds like a great plan. So what's basic?
(I'm the resources_controller guy,
+1 and I look forward seeing the solution.
On Jul 11, 1:53 am, Chris Eppstein <[EMAIL PROTECTED]> wrote:
> On Jul 10, 7:53 am, James Golick <[EMAIL PROTECTED]> wrote:
>
> > ...or maybe Hampton, Ian, and I should come up with a base plugin /
> > API that we base all of our plugins on?
>
> This is
+1
Ruy Asan (rubyruy) wrote:
>
> It has come to my attention the above wall of text is a little
> intimidating and is holding back adoption ;)
>
> So I present to you a summary, in ADD-friendly, fixed-with 68-char
> column formatted (to appease google's crazy ML reader) point form:
>
> - I re-
On Jul 10, 7:53 am, James Golick <[EMAIL PROTECTED]> wrote:
> ...or maybe Hampton, Ian, and I should come up with a base plugin /
> API that we base all of our plugins on?
This is full of win. +1
--~--~-~--~~~---~--~~
You received this message because you are subsc
> ...or maybe Hampton, Ian, and I should come up with a base plugin /
> API that we base all of our plugins on?
You guys are bound to have a bunch in common, basic core stuff. Of
that set of features there's probably some stuff that still won't be
fit for inclusion in the core, but odds are ther
On N, 2008-07-10 at 16:17 +0200, Rasmus Nielsen wrote:
> As I could not get a definite answer at lighthouse
> (http://rails.lighthouseapp.com/projects/8994/tickets/432-mysql-adapter-with-mediumt-support),
>
> whether my assumption about rails' incorrect handling of mysql integer
> data types w
I'm not necessarily disagreeing.
However, without some hooks for overrides, and polymorphism, plugins
that do RESTful abstraction layers, like the ones mentioned in this
thread, will still be forced to write quite a bit of custom,
duplicated code in order to handle those cases. It would be nice t
> I like Hampton's proposal - I think it covers a lot of cases, while
> remaining relatively neutral in terms of what it expects.
I wholeheartedly concur.
> The only things I'm not clear on is how it would cover polymorphism,
> or cases where the association has a non-standard name. Sure, you
>
As I could not get a definite answer at lighthouse
(http://rails.lighthouseapp.com/projects/8994/tickets/432-mysql-adapter-with-mediumt-support),
whether my assumption about rails' incorrect handling of mysql integer
data types was right or not, I now turn to this mailing list.
About a month
There's also my plugin resource_controller - a little naming collision
there, but nonetheless...
All three of these plugins have a decent amount of traction, and
something to offer. I do think that it makes sense for the three of us
to sit down, and brainstorm over what we can do to add this to r
On Thu, Jul 10, 2008 at 3:40 AM, Michael Koziarski <[EMAIL PROTECTED]>
wrote:
Without attributing Ruy Asan who wrote:
>
> > It has come to my attention the above wall of text is a little
> > intimidating and is holding back adoption ;)
>
> Quite ;)
>
> > So I present to you a summary, in ADD-frien
> My point with all of this is to massively strip down the functionality
> that is available in the plugins and just have an extremely simple
> interface for the most basic, basic resource facilities in a
> controller. Then, build from there if the need arises.
Sounds great to me :)
--
Cheers
Opened ticket #591
http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/591-installing-plugin-from-git-branches
On Jul 8, 3:59 pm, Les Hill <[EMAIL PROTECTED]> wrote:
> This patch was inspired by multiple RSpec tag installs (RSpec edge
> works with the existing script/plugin).
>
>
My point with all of this is to massively strip down the functionality
that is available in the plugins and just have an extremely simple
interface for the most basic, basic resource facilities in a
controller. Then, build from there if the need arises.
-hampton.
On Jul 10, 8:02 am, "Michael Koz
> Also, see my blog post on how Rails routing could help the cause
> without having to pick (yet) a particular implementation::
>
> http://cho.hapgoods.com/wordpress/?p=151
>
> "Full Circle REST" is where it's at.
Definitely, and I think we've discussed this previously on #rails-contrib?
I'm not
Have a look at Resources Controller (RC) plugin, which is a pretty
mature and functional set of functionality for getting the relevant
resources for a controller. RC is strong -I gave up my own solution
to adopt RC (and contribute a bit). Ian White, the author, has really
kept it going.
http://
> It has come to my attention the above wall of text is a little
> intimidating and is holding back adoption ;)
Quite ;)
> So I present to you a summary, in ADD-friendly, fixed-with 68-char
> column formatted (to appease google's crazy ML reader) point form:
>
> - I re-wrote ActiveModel::Validat
20 matches
Mail list logo
