ansaurus

Question

Answer 1

+1 A:

It sounds like you are talking about RESTful ideas (having actions called index, create, new, edit, update, destroy, show).

In MVC you can call an action largely whatever you want (so yes, you can call it uploadcsv if you want). If you want it fit RESTful principles you might want to think about what the action is doing (for example is a data upload essentially a create or an update function) and name it using one of the RESTful action names.

Michael Gattuso 2009-10-12 14:50:52

Michael,I think the ambiguity of the question you pose ("is it essentially a create or an update function") is what is really challenging me. I suppose, I could imagine that the action of "Upload CSV" is updating the hypothetical "This User's Uploaded Data" held in memory and as a result that would be the context of my controller. Food for thought! If you've got any specific examples, they would be great help to me.Thanks again.

thoswarner 2009-10-12 14:56:22

It can be tricky to conceptualize RESTful names (I am certainly no expert). This one, I believe, is familiar in the rails world. A user logs on to a site, they are creating a session. It is common then to use the RESTful /session/create to log a user in, correspondingly /session/destroy is used to log out. This is nothing to do with CRUD. What makes it more confusing still is that you can alias these actions in rails and mvc so that /login and /logout are really just references to /session/create and /session/destroy.

Michael Gattuso 2009-10-12 15:06:42

In the case of create vs update. I (again, no expert) ask myself "Have I got this information / resource already?" If not, it's a create, if so, then it's an update. Using the session/create example: I do have a user but prior to log in they do not have an active session on the application. Therefore I don't have the concept of the user with an active session so it's session/create not session/update.

Michael Gattuso 2009-10-12 15:11:25

Good example - I came across this while learning Rails and made me think "I probably wouldn't have thought of that, but it's obvious when I think about it now!" Milan left some good comments about breaking these ambiguities down to concrete concepts , even if that means you have to explode the steps of what you are doing into more actions than you "need".

thoswarner 2009-10-12 15:14:11

Answer 2

A:

The persistence of the resource is not crucial here. I suppose that what you are doing here is this - creating some kind of resource (although not persistent) out of the csv provided. The thing here is to think about what this csv file represents. What's inside? Is it something that will become a collection of resources in your system, or is it a representation of only one object in your system? If you think about it it has to be something concrete. Can you be more specific about your problem domain?

Milan Novota 2009-10-12 14:58:15

Thanks for your reply! Keeping with the CSV parsing example - So, let's assume I upload a CSV file with a header row of fields then arbitrary data following. Then I want to grab all the headers and present them to the user so they can select their fields before an actual data import occurs (the import schema is ambiguous and can differ depending upon the source data). This is where I need to make the decisions "what should I name my controller?", "what action should I use to handle the initial upload view" and "what action should I use to handle the actually uploading and parsing of the CSV"..

thoswarner 2009-10-12 15:08:10

My question still is - does this csv contain only one particular kind of data (that represents some kind of objects in your application)? Or is it really arbitrary? What I mean is - Are you (at the end) going to populate only one kind of resource out of this file or it can vary?

Milan Novota 2009-10-12 15:18:41

In answer to your question, the data itself doesn't represent a resource in the system (a list of cars, usernames etc), as it can really be anything. BUT the data, however arbitrary, will still fit into a resource to store it, even if the actual data fields don't reflect the original data source directly. Thus, you are correct there!Thus, thinking of it in the terms you have provided me there has answered my question! Thank you!

thoswarner 2009-10-12 15:23:42

Answer 3

A:

I believe I have the same point of view as you.

In my projects I try to be as restful as possible whenever I can. However as you said sometimes a special case just does not 'fit'

After all it is also a question of 'feeling' If you provide a csv import function, I see it as perfectly correct to not create a full REST implementation for CSV.

Let's imagine in your application you have clients. And you wnat to give the option for clients to import data using csv. You can add a route for this action using:

map.resources :clients, :member => { :uploadcsv => :get }

The route is properly declared, Your 'clients' resource is completely restful and you have an additional action properly declared to manage data importation.

The only warning I have is: don't use a route like this one "/data/uploadcsv". From my point of view It lacks clarity. I like to be able to understand what my application is going to do just be looking at the url. And '/data' is too vague for me :)

Aurélien Bottazzini 2009-10-12 18:04:20

ansaurus

tags:

views:

answers:

Non-CRUD Controller Actions

related questions