desired features in Active Resource

10 views
Skip to first unread message

Nick Urban

unread,
May 19, 2011, 11:42:47 AM5/19/11
to Active Resource
Hey all, this is a bit of a repost from the main list, but since I
haven't received any responses yet, we'll start here.

I'd like to suggest we make a list of features which AR should have
and doesn't and then we can figure out what sort of changes will
support those features and not duplicate each other's efforts.

The problems which I have had to deal with in my own code are:
- converting to/from camel case
- resource paths with no extension
- being able to specify which attributes are sent instead of sending
them all
- easily toggleable request logging
- warnings for requests that look like they are probably errors (e.g.
missing path params)

Items I'd like but haven't built yet:
- Hooks!
- Expand the power of the "schema" (possibly fold in the feature that
lets you send / ignore certain attributes)
I understand Markus is working on associations. Reactive Resource
also
adds associations.

Post your added features and wishlists!

Nick

Gaston Ramos

unread,
May 21, 2011, 11:33:09 PM5/21/11
to Active Resource
Some time ago I sent a pull request adding some basic associations to
ARes, but
the rails core never merged it, may be coul we use my pull request?

https://github.com/rails/rails/pull/70

Thanks

markusschwed

unread,
May 23, 2011, 2:50:14 AM5/23/11
to Active Resource
Hi Gastron,

I think the people here should check these two ways of solving the
association - problem and how it's coded and
decide then, which one should be used.

I think Matthias Folz and my solution is a lot better structured, but
this could be just my opinion.
We used to go a similar way to AR (associations through reflection
classes and builder for these) because this makes it more easier to
add more recent features (which is our plan to do), because everything
has it's own place without doing all in one code-file.

Please do not take this as an attack, because it's absolutely not
meant like one.

So what do you think about it?

Greetz
Markus

Nick Urban

unread,
May 24, 2011, 12:32:13 AM5/24/11
to active-...@googlegroups.com
Hey Markus,

Would you post the link to your pull request so we can actively compare?

Thanks,

Nick

Gaston Ramos

unread,
May 24, 2011, 8:39:38 AM5/24/11
to active-...@googlegroups.com
El Sun, 22 de May de 2011, a las 11:50:14PM -0700, markusschwed dijo:

> Hi Gastron,
>
> I think the people here should check these two ways of solving the
> association - problem and how it's coded and
> decide then, which one should be used.
>
> I think Matthias Folz and my solution is a lot better structured, but
> this could be just my opinion.
> We used to go a similar way to AR (associations through reflection
> classes and builder for these) because this makes it more easier to
> add more recent features (which is our plan to do), because everything
> has it's own place without doing all in one code-file.
I haven't seen your code yet, I'm going to compare today.


>
> Please do not take this as an attack, because it's absolutely not
> meant like one.

No problem.

--
"Programs must be written for people to read, and only incidentally for machines
to execute."

(Abelson & Sussman, SICP, preface to the first edition)


+-------------------------------------+
Gastón Ramos
http://gastonramos.com.ar/
GNU/Linux Counter user #450312

Reply all
Reply to author
Forward
0 new messages