CRUD

[Vanja Radovanović]

Hi!

Sorry for a (possibly) lame question, but I'm struggling with the idea of client side usage of roar (and roar-rails).

Namely, the desired setup is like this:

* backend with roar serving json for collection and single items

* frontend, a rails app, having an ItemsController and actions to CRUD the items

My problem is I can't find a way to perform the index action (listing items).

I've looked at https://github.com/apotonick/roar/blob/master/lib/roar/representer/feature/http_verbs.rb, https://github.com/apotonick/roar-rails/issues/14 and the rest of the issues for both gems and even https://github.com/apotonick/ruby-on-rest but this eludes me.

So, I guess what I am asking is if there is some kind of example for such basic scenario.

If not, I'd be glad to help writing one, if I could just solve this first :-)

Btw, like the idea behind the whole concept very much, thanks for the gems!

[Vanja Radovanović]

Did some more digging, still without a solution but maybe it helps...

Found http://news.dice.com/2012/03/20/activeresource-roar/ and it helped a bit.

The setup:

* backend sinatra app that delivers json data

* frontend rails app that is trying to consume it

The idea was to try to have a backend that would serve data and be responsible for business logic and persistence, and to have a front end that would show some dashboards but also be used for administering the data (CRUD operations etc.).

On sinatra backend there is a representer:

require 'roar/representer/json'

module MyGem

  module ItemsRepresenter

    include Roar::Representer::JSON

    include Roar::Representer::Feature::Hypermedia

    collection :collect, :extend => ItemRepresenter, :from => :items

  end

end

And in the rendering part of the sinatra service:

get '/items', provides: [:json] do

  items = MyGem::Item.find_by_account("some_account_id")

  items.extend(MyGem::ItemsRepresenter)

  items.to_json

end

When going to http://localhost:9292/items, I get:

{

• items:

  [

  • {

    • id: "1",
    • name: "test"

    },
  • {

    • id: "2",
    • name: "second"

    }

  ]

}

so it seams OK (I left out the links).

On the rails frontend side, I have a client:

require 'roar/representer/feature/client'

class ItemsClient

  include Roar::Representer::Feature::HttpVerbs

  def initialize

    extend MyGem::ItemsRepresenter

    extend Roar::Representer::Feature::Client

  end

end

and in controller, the index action:

def index

  client = TweaksClient.new

  client.transport_engine = Roar::Representer::Transport::Faraday

  client.get("http://localhost:9292/items", 'application/json')

  puts client.inspect

end

from what I can see, the json is acquired by transport engine, but when going into deserializinng from json (line 26 in roar/lib/roar/representer/json.rb) it gives me this error:

NoMethodError (undefined method `new' for nil:NilClass):

I've tried to make some variations on the subject, but I guess what confuses me is how exactly is the deserializing performed for a collection of objects.

Any help appreciated.

[Nick Sutterer]

Hi Vanja,

the Client feature still needs some love. From what I see, you're
doing everything right! Now, what could happen is that if the request
is empty, the Client feature will fail to deserialize. Me and Alex are
working on that. Can you verify that the return of

client.get("http://localhost:9292/items", 'application/json')
puts client.inspect

is an empty string?

Also, if you're looking for an example for an index action, check out
my newest post:
http://nicksda.apotomo.de/2012/05/ruby-on-rest-6-pagination-with-roar/

Will let you know as soon as I pushed a new roar version!

Nick

[Nick Sutterer]

Ah, you have to define a :class!

collection :collect, :extend => ItemRepresenter, :from => :items,
:class => Item

otherwise Roar doesn't know how to deserialize the items in the list.

[Vanja Radovanović]

That's it!

Thumbs up :-)

I've just given it the class and I get the desired behavior without an issue, problem solved!

For the above question, client.get("http://localhost:9292/items", 'application/json') really returns the json from the backend api.

I've inspected the output and from the transport_engine.get... and there was no problem there.

Thank you very very much :-)

P.S. The offer to create a sample app still stands, I still have further issues to make rails behave well with acquired objects, but I guess that is not as important.

How about some fruit salad choosing app or something similar? 

(is there a need to create such an example?)

On Monday, May 28, 2012 11:13:33 PM UTC+2, Nick Sutterer wrote:

Ah, you have to define a :class!

    collection :collect, :extend => ItemRepresenter, :from => :items,
:class => Item

otherwise Roar doesn't know how to deserialize the items in the list.

[Nick Sutterer]

On Tue, May 29, 2012 at 2:44 AM, Vanja Radovanović <elv...@gmail.com> wrote:
> That's it!
> Thumbs up :-)
> I've just given it the class and I get the desired behavior without an
> issue, problem solved!
>
> For the above question, client.get("http://localhost:9292/items",
> 'application/json') really returns the json from the backend api.
> I've inspected the output and from the transport_engine.get... and there was
> no problem there.
>
> Thank you very very much :-)
>
> P.S. The offer to create a sample app still stands, I still have further
> issues to make rails behave well with acquired objects, but I guess that is
> not as important.
> How about some fruit salad choosing app or something similar?
> (is there a need to create such an example?)
>

Absolutely, I'd love to see an app here, especially if you have more
issues we could solve in this project. That would be awesome, when do
we start?

We could also use the demo app for screencasts.


Nick :)

[Vanja Radovanović]

:-)

As far as I am concerned, right now is the best since I have a few vacation days left, better use them meaningfully.

That said, I have something I've been building, we could use it as a base.

Maybe a day or so to spruce up a new context we can use, I'll put it then on github.

That salad something seams OK, but if you have a more meaningful suggestion, fire away....

Cool!

[Vanja Radovanović]

https://github.com/elvanja/roar_example

not much, but maybe OK for starters

json api is working nicely, it delivers fruit list at http://localhost:9292/fruit.json

but I can't seam to resolve the client issue: can't convert String into Integer

thought it had to do with representers but think not

transport engine is getting the json data so it has to do with deserializing, but can't figure out what...

also, hope the gem separation is not an issue

i was trying to build nicely separated layers, thought it might be a good exercise too

anyway, browse it when you catch a few minutes and let me know how it feels

if the idea is OK, the plan is to:

* finish the crud for fruits

* introduce some smoothie making mechanism both on the client and at the service

[Vanja Radovanović]

Still no solution, can't figure out the cause...

All I have at the time is the stack trace:

representable (1.1.7) lib/representable/bindings/json_bindings.rb:30:in `[]'
representable (1.1.7) lib/representable/bindings/json_bindings.rb:30:in `read'
representable (1.1.7) lib/representable.rb:105:in `read_fragment_for'
representable (1.1.7) lib/representable.rb:95:in `uncompile_fragment'
representable (1.1.7) lib/representable.rb:52:in `block in update_properties_from'
representable (1.1.7) lib/representable.rb:49:in `each'
representable (1.1.7) lib/representable.rb:49:in `update_properties_from'
representable (1.1.7) lib/representable/json.rb:48:in `from_hash'
representable (1.1.7) lib/representable/json.rb:40:in `from_json'
roar (0.10.2) lib/roar/representer/json.rb:27:in `from_json'
roar (0.10.2) lib/roar/representer/json.rb:36:in `deserialize'
roar (0.10.2) lib/roar/representer/feature/http_verbs.rb:68:in `handle_response'
roar (0.10.2) lib/roar/representer/feature/http_verbs.rb:43:in `get'
app/controllers/fruit_controller.rb:4:in `index'

So, the problem is experienced somewhere in representable gem, but can't figure out how to debug this...

Any idea?

[Nick Sutterer]

So, I checked your work. First of all: THANKS! This is super cool that
you started a thing to work on!!! Great!

We should consider making the client a Sinatra app or a command line
tool or so! Rails is so slow. Also, can we use rails_api for the
service? I reckon tutti frutti (love the name) doesn't use the
FruitsRepresenter as the consumed representation in the mixer doesn't
contain the :fruits key. Will check that later!

Cheers,

Nick

[Vanja Radovanović]

glad you like the name :-)

anyway, regarding tutti_frutti service, it is using rails_api, at least I hope it is!

namely, I created the app using rails_api, for example you can see that it contains only 2 controllers and nothing else

the only problem I had was that it wouldn't work without the "hack" in application_controller,rb, you'll notice it right away (# TODO...)

without it I get undefined method `respond_to' for FruitController:Class when going to http://localhost:9292/fruit.json

as for the FruitsRepresenter, it seams it is used in fruit_controller.rb inside the tutti_frutti service,

because when I change the link :self ... in FruitRepresenter, json from the service renders that new link

so, I would guess that the representers are used after all, just can't figure out why the collection or item name are left out

I've just added the show action to be able to do something like

http://localhost:9292/fruit/1.json 

the idea was to test without collection representer in the mix, alas the result is the same

maybe all the client problems are actually related to these issues

if you have a clue as to how to debug this, I'm open to suggestions!

for the client I don't mind Sinatra, Rails is more straight forward for me but OK :-)

also, at some later stage I thought some client side app (backbone, CLI or even a GUI) would be a nice example, 

especially if we had two client apps consuming the same service...

but, whichever suits you better is fine by me

bye bye for now :-)

Vanja

On Tuesday, June 5, 2012 7:16:22 PM UTC+2, Nick Sutterer wrote:

So, I checked your work. First of all: THANKS! This is super cool that
you started a thing to work on!!! Great!

We should consider making the client a Sinatra app or a command line
tool or so! Rails is so slow. Also, can we use rails_api for the
service? I reckon tutti frutti (love the name) doesn't use the
FruitsRepresenter as the consumed representation in the mixer doesn't
contain the :fruits key. Will check that later!

Cheers,

Nick

[Nick Sutterer]

Hey Vanja, can you setup a test environment in tutti_frutti so i can
write some controller API tests. We can then figure out what's wrong.

Thanks!

[Vanja Radovanović]

Sure thing, 

rspec enabled, added a test for a single fruit,

test passes for the currently wrong json response, 

feel free to change as needed!

Let me know if there is anything else I can help with...

[Vanja Radovanović]

Hi,

any news regarding this?

Can I help somehow?

[Nick Sutterer]

Hi Vanja, working in responders in roar-rails to incorporate this into
the fruit mix. Will push in 1 or 2 days, then we can continue working.
Thanks for the test setup!!!

Nick

[Vanja Radovanović]

Great news :-)

And feel free to ping me if something needs to be done...

Thanks again!

On Tuesday, June 12, 2012 10:29:46 AM UTC+2, Nick Sutterer wrote:

Hi Vanja, working in responders in roar-rails to incorporate this into
the fruit mix. Will push in 1 or 2 days, then we can continue working.
Thanks for the test setup!!!

Nick

On Tue, Jun 12, 2012 at 9:20 AM, Vanja Radovanović wrote:
> Hi,
> any news regarding this?
> Can I help somehow?
>
> On Wednesday, June 6, 2012 10:04:48 PM UTC+2, Vanja Radovanović wrote:
>>
>> Sure thing,
>>
>> rspec enabled, added a test for a single fruit,
>> test passes for the currently wrong json response,
>> feel free to change as needed!
>>
>> Let me know if there is anything else I can help with...
>>
>>
>> On Wednesday, June 6, 2012 9:04:23 AM UTC+2, Nick Sutterer wrote:
>>>
>>> Hey Vanja, can you setup a test environment in tutti_frutti so i can
>>> write some controller API tests. We can then figure out what's wrong.
>>>
>>> Thanks!
>>>
>>> On Tue, Jun 5, 2012 at 9:38 PM, Vanja Radovanović  

[Nick Sutterer]

Hey bro, can you please add a controller test for tutti_frutti? I will
then add some stuff new in roar-rails. Cool!

[Vanja Radovanović]

Hello :-)

https://github.com/elvanja/roar_example/blob/master/tutti_frutti/spec/controllers/fruits_controller_spec.rb

Did you have some other kind of tests in mind?

Also, updated the projects to latest roar, roar-rails gems and respective changes in representations.

A few comments/questions:

* single item representation

  - I thought that a single fruit should have "fruit" root element in JSON, much like "artice" in "Creating Representations" section of https://github.com/apotonick/roar

  - http://localhost:9292/fruits/1.json is an example of current state

* listing in client

  - now it works nicely :-)

* single item client

  - can't figure out how to get a single item in client (smoothie_mixer)

  - created the edit action on fruits_controller to illustrate

As always, let me know if I can help!

On Friday, June 22, 2012 9:54:22 AM UTC+2, Nick Sutterer wrote:

Hey bro, can you please add a controller test for tutti_frutti? I will
then add some stuff new in roar-rails. Cool!

[Nick Sutterer]

Cool!

On Fri, Jun 22, 2012 at 5:33 PM, Vanja Radovanović <elv...@gmail.com> wrote:
> Hello :-)
>
> https://github.com/elvanja/roar_example/blob/master/tutti_frutti/spec/controllers/fruits_controller_spec.rb
> Did you have some other kind of tests in mind?
>

Sure, testing the client but I will have to wrap my head around that now.

> Also, updated the projects to latest roar, roar-rails gems and respective
> changes in representations.

I now use #represents in my repo, maybe we should merge:
https://github.com/apotonick/roar_example

> A few comments/questions:
> * single item representation
>   - I thought that a single fruit should have "fruit" root element in JSON,
> much like "artice" in "Creating Representations" section
> of https://github.com/apotonick/roar
>

If you use self.representation_wrap = :fruit you get that but most
people don't like it! It is useless since you know you have a fruit in
your hands ;)

[Nick Sutterer]

Check my repo, I fixed some stuff, we can now use URL helpers in the
representers.

[Vanja Radovanović]

Hi Nick, just merged in your changes to.

Looking nice, with clients removed from smoothie mixer, and url helpers working for representers :-)

I can't get one thing to work though.

The fruit_edit_path(fruit.to_param) generates edit link with object id instead of just ID.

Tried editing the smoothie_mixer fruit class, even hardcoding #id method, and even using fruit_edit_path(fruit),

but always I get:

URI::InvalidURIError in FruitsController#edit

bad URI(is not URI?): #<Orcharding::Fruit:0x00000002258ad0>

And I can't figure out a way to make this work.

Any idea?

On Thursday, June 28, 2012 9:39:18 AM UTC+2, Nick Sutterer wrote:

Check my repo, I fixed some stuff, we can now use URL helpers in the
representers.

[Nick Sutterer]

Yeah bro, working on it! I will push Sunday. PROST

[Vanja Radovanović]

Looking forward :-)

On Friday, June 29, 2012 8:44:05 PM UTC+2, Nick Sutterer wrote:

Yeah bro, working on it! I will push Sunday. PROST

[Vanja Radovanović]

Hi, 

Saw some new development - merged it into the main repo.

Also, introduced active_attr gem https://github.com/cgriego/active_attr, helps a great deal with impersonating ActiveRecord!

The form to create a new fruit is now working.

Next step: complete the posting of a new fruit.

Any suggestions?

Posting to Fruits seams silly (since this is a base list of fruits, it might make more sense for "making smoothies").

Well, that's it for now...

Thanks man!

On Friday, June 29, 2012 8:44:05 PM UTC+2, Nick Sutterer wrote:

Yeah bro, working on it! I will push Sunday. PROST

[Vanja Radovanović]

Long time no see....

Sorry, I've been too busy to do more work here, but things may be changing :-)

Anyway, I've upgraded the example to latest roar gems.

Had to change orchard folder/namespace to fruit_orchard, it conflicted with a real outside gem.

Also, I've added a small command line client to the mix (basher folder, just a proof of concept currently).

Had some issues with smoothie_mixer edit fruit action.

That thing with needing to require representers as late as possible took its toll :-)

I added some specs to the representers too.

And here comes the question :-)

Requiring collection to explicitly name the class to deserialize is OK, but it would probably be nice if it could be passed in the representer somehow instead of being hard coded.

I marked all the places in all the projects that were affected by this issue with the following:

# TODO see if there is a way to decouple representer from Fruit class

And if you check, there is quite a lot of places to beware of.

Is there a way to make this less brittle?

[Nick Sutterer]

Vanja, good to see you! I will have a look at that now!

[Nick Sutterer]

Hey Vanja, I was checking out the roar_example today and found out we
do not use #consume! anywhere. I thought we once had that somewhere,
can you remember it? It must have been somewhere in the tutti_frutti
service. Are you up for working on this example a bit more?

Cheers

[Vanja Radovanović]

Hi Nick,

You are right, #consume is not used at this point.

It may be the next step since saving changes back to tutti_frutti service is a #TODO item.

The only representation that currently happens is in /app/controllers/fruits_controller.rb:7 in smoothie_mixer, for which #consume is not needed.

Anyway, yes, I am up for some more fun on the project.

What did you have in mind?

[Nick Sutterer]

Can we somehow simplify the data layer, e.g. using mongo or something?

> --
> You received this message because you are subscribed to the Google Groups
> "Roar" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to roar-talk+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Nick Sutterer]

The thing is, I always wanted to play around with mongoid. Also, I
want additional APIs in HAL and Collection+JSON since roar does
support these formats now! Exciting!!!

[Vanja Radovanović]

Well, the main idea behind this "in memory persistence" was to run the app without external database while in development mode.

In production, a separate layer, mongo or something else, would definitely take place.

Not really sure how would this show off roar and related gems?

Or are you just itching to play with mongo so it doesn't really matter?

As for the additional APIs, I kind of imagined as first step that basic web CRUD would be completed.

Then, the next step would be to add clients that could use new APIs in new fashion, e.g.:

* a web client (smoothie mixer) that gives random smoothies (any maybe records which one sound interesting enough to be tasted)

  by exploring API and following HAL links

* maybe an iOS/Android port of smoothie mixer

I guess somewhere in there would the new Roar thingies be used.

In the end, if the stack is ever to see the day of light (on heroku maybe), the production could run on mongo, and development in memory and all the while all the Roar goodies would be utilized.

So I guess, the question is what would you like to do first :-)

[Nick Sutterer]

I guess I will checkout the Fruit#create logic now since I need some
application for #consume! :-)

[Vanja Radovanović]

Great, check out /app/controllers/fruits_controller.rb:21 in smoothie_mixer, I kind of stopped about there, ready to post to tutti_frutti's /app/controllers/fruits_controller.rb.

I might be able to take some of the work, if you have an idea on how to approach this we can split up if possible?

P.S. I've been loosing regex battles all day long, sorry I didn't catch up earlier...

[Nick Sutterer]

Yo Vanja, check my repo I made POST to /fruits work. There might be
some more commits soon, but I'll keep you up-to-date. Thanks again for
all your work so far!

[Nick Sutterer]

Vanja- now the problem is that the repository keeps another version
(or just a hash?) or the object than the object itself. #consume!
updates the object which is not propagated to the repo - maybe we
switch to something like mongo? Are you up for that? Check my
roar_examples repo, the tutti_frutti#create method does not exactly
what it's supposed to do!

Nick :-)

[Vanja Radovanović]

Great, I'll give it a look in the next few days.

The way I see it (and I may be using hippie glasses), repo should get the updated object and replace it.

Maybe the repo logic is not complete/correct, I'll try to resolve this.

If it becomes too much of a burden, we'll go with mongo, no problem :)

Keep posted, and just commit the latest changes if you have any left.

I've added you as collaborator to the root project, so we can work on the same code base.

Your changes are already up (should be).

And we can open up a feature branch if need be.

Thanks!

[Vanja Radovanović]

Hi Nick,

I've located and fixed (a bit dirty though) the issue.

A few notes/details/explanations follows.

tutti_frutti/app/controllers/fruits_controller.rb:18
Saving the new fruit requires that update be called on created fruit.

So, the idea is:

* let repository create a new instance, giving it ID and everything else needed

* consume it from posted data (that's your thingy)

* save changes back to repository
I've updated the code to reflect this.

Why data was not seen in response?
As you probably noticed, when new fruit is added, you get an empty row as a result.

The data is also not saved as can be seen @ localhost:9292/fruits.json

The reason was that repository updates only if it finds a matching ID.

Now, the data passed in had "id" instead of :id for hash key.

After a bit of debugging, it seems representable has overridden the to_hash and from_hash on Fruit instance being updated.

Hence, the resulting hash passed to repository for saving had no :id key since I didn't expect fruit implementation of those methods to be lost (http://www.imdb.com/title/tt0335266/).

I fixed those issues in fruit_orchard/lib/fruit_orchard/domain/fruit.rb:14 and fruit_orchard/lib/fruit_orchard/persistence/fruit_repository.rb:30

The whole process

Now the following is taking place:

* tutti_frutti api is calling Fruit.create to get a new instance

* fruit delegates instance data to repository 

* repository creates and returns the data, creating the ID in the process

* tutti_frutti calls consume on fruit instance it to parse the received data

* tutti_frutti updates fruit 

* fruit sends updated data to repository

* repository finds relevant record by ID and updates

A bit of hash conversion in both directions is present but that is the case

How to imporove slightly?

Maybe if in tutti_frutti the call could be:

@fruit = FruitOrcharding::Fruit.create(consume(Fruit))

That way, no updates would be needed, but create flow would get the needed data and return the created record.

How to improve more?

By being good and eating a lot of fruit :-)

OK, my 5 cents for this evening have been spent.

Let me know how you feel about this.

On Wednesday, February 6, 2013 11:13:42 PM UTC+1, Nick Sutterer wrote:

[Nick Sutterer]

I thought a lot about the #consume! semantic and I decided it would be
best to just do the setup process (e.g. filling the object with
incoming data). Everything else, like saving and stuff is up to the
user. That was to save us from having to write adapters for DM, AR,
Sequel etc.

Surely, we can think about additionals ways of making #consume! and
friends more helpful.

[Vanja Radovanović]

Yep, agree.

I've also updated the code a bit, so that saving new fruit takes only one trip.

Also, this repository/active record like implementation is becoming a bit lousy.

Don't know how you feel about using http://datamapper.org/ and rewriting that part from beginning?

[Nick Sutterer]

On Wed, Feb 13, 2013 at 10:13 PM, Vanja Radovanović <elv...@gmail.com> wrote:
> Yep, agree.
> I've also updated the code a bit, so that saving new fruit takes only one
> trip.
>
> Also, this repository/active record like implementation is becoming a bit
> lousy.
> Don't know how you feel about using http://datamapper.org/ and rewriting
> that part from beginning?
>

Sure, go for it! Great!