I have a very simple Rails application that performs regular CRUD operations on an object (Path), this all fits nicely in the REST philosophy of Rails. Now however, I need to add a "Duplicate" feature (i.e. create new path from existing path). I have added it as an (RESTfull) action in my path_controller, so far so good (maybe not completely in line with the REST philosophy but I am not a purist).
Now I want to extend the functionality so that the users can choose to either create a completely new path from an existing one or copy the existing path to another, already existing path (duplicating its children). This means I am going to need a few extra Views:
one that allows them to pick Option 1 (Create New Object) or Option 2 (Duplicate to existing Object).
If they choose Option 2, I need another View that lets them then pick the path they want to copy to.
Each of these views needs a corresponding action, and it is here that I am struggling as to where this all fits in REST.
This is a fairly simple example but as my UIs get more complex, I always run into this issue: How do I make my actions I need for my UI fit in REST controllers?
Just add a new collection route to your resource:
resources :paths do
collection do
get :duplicate
end
end
and add a duplicate method to your paths controller and views for it...
now you can access and address specifi routes for your users choice.
Related
I have strange question. I want in my helper to have array of paths that are available for specific resource.For example, if we have a model Comment I want to have an array which will have the following elements: [new_comment_path, comments_path] etc. Is this possible to do?
Edit:
I build left side menu in rails. It will work like tree menu. I don't want to use external plugins. Only thing that i must do is to have a all paths for my models.
You can do
Rails.application.routes.routes.map{|x| x.name}.reject{|x| x.blank?}
Which will get all named routes. I'm not sure if there is a way of just getting routes for one resource though
I am using Ruby on Rails 3.2.2 and I would like to "handle" / "generate" the proper front-end content so to follow a "common" way of managing menu items mostly based on the current user "equality". That is, I would like to display different menu items based on
the current browsed page;
the current user that is accessing that page (the page could be related to a user that is not the current user).
Where (for example, in controller, view or model files) and how (for example, stating checks related to the current user in controller, view or model files) I should "state" / "put" those "conditional statements"?
At this time I think (mostly for matters relating to the current browsed page) I could handle this matter directly in controllers by using helper methods...
I tend to put this into the View files with simple or static cases coded into the View file and more complex cases which would require more than just one line of coding into the helpers.
But in order not to bloat the view file, I suggest to use partials to offload blocks of code from the view file.
One of the reasons why I use the views is that I will do certain user based formatting anyways, e.g. if I list all the orders, then the normal user will see certain columns displayed, whereas if the admin logs in, he will see a couple of additional columns. This is typically done with something like
<%if #curreny_user_type == 'admin'%><td> ...... </td><%end%>
Thus before I now start splitting up some of the user based logic into the controller and others into the views, I'ld rather have them always at the same place.
I seek some guidedence here ... ( I'm not sure if this is the best title )
At the moment I prepend a "server name" to the url like this:
server10.example.com
This works fine, except that I need to handle all the subdomains on the IIS and I'm not sure google are happy about jumping around from sub to sub to sub, when it seems the links to the other servers.
I'm kind a hoping for a nice way to archive this wioth asp.net mvc.
Most pages are related to a "server" ... there are however a few info pages, contact, home that dont really need a valid "server" name ... but could just be "na" for not available, but the name need to be maintained, if there is already a selected server, when a user are keeps browsing the site. This needs to be as transparent as possible when I need to create the links to the diffenrent pages.
I could extend the Html Action() extensien to automatically add the selected "server" from the previusly request to the page.
In the format:
/{serverParameter}/{controller}/{action}/{parameterInfo}
And if no server is selected, just add "na" as the {server} placeholder.
I'm not sure if more information is needed, but please let me know if ...
I tired of extracting the selected server from the domain part and the other way also seems better, I just can't think of a good way to structure this ...
Updated
90% of all the pages are about a server that the user select at some point. Could be server10, server9, server20 ... just a name. I want to maintain that information across all pages, after the users has selected it or else I just want it to be f.ex: "empty".
I mostly looking for an easy way of doing this or an alternative ... atm I'm prepending the serverParamter to the url so it ends up being: "serverParameter.example.com".
I want to end up with something like
http://example.com/{server}/{controller}/{action}
instread of
http://{server}.example.com/{controller}/{action}
If I understand your question correctly, you just wish to group different collections of content together above the controller/action level. If that's the case, have you considered using ASP.NET MVC areas?
Just right-click on your project, and choose Add -> Area.... Give it a name (what you're calling "server"), and then you can add content, your own controllers, actions, etc. Under this area. You will automatically be able to access it via /AreaName/Controller/Action/etc.
I went with the already impemented routing in ASP.NET MVC.
{server}/{controller}/{action}
When creating the links it takes the set value for {server} and places the value when generating URL's, so I only need to supply controller and action in the #Html.Action helper method ... this could not have been more easy.
I'm not sure why I did not think about this. One just gotta love routing.
I'm working on a CMS/Webshop engine with a MVC 3 front-end. I want to be able to define url "aliases" for dynamic content/products runtime, and I want to be able to route this URLs to MVC controller actions.
For example I want to be able to define
~/Products/Motherboards/{manufacturer}/{uniqueName}
~/HugeSavings/{uniqueName}
~/Products/{uniqueName} etc.
to map to the same Display(string uniqueName) controller action in ProductsController. These url patterns are dynamic, even the rules for their order or composition is NOT DEFINED at design time, the pattern's rule or pattern's content can change in runtime without restarting the application, they are stored in SQL, but needs to be cached. Each pattern has a target which may be a typical MVC url like
Products/Display/{uniqueName}
or a direct link like
`http://somestuff.com/stuff.aspx?name={uniqueName}.
Every solution I've found used
RegisteredRoutes.Clear();
RebuildRoutes();
which is horrible, because of this for adding one new pattern for one product (or product category) I have to query the database for thousands of products and their corresponding patterns.
So, can I change routes without clearing or restarting the app? Can I "inject" some logic to routing WITHOUT having to recode the whole "look up the controller and action and parse the parameters" thing.
Yes, you can add routes later. Just don't RegisteredRoutes.Clear(); them first.
If you're still intereseted, I just answered a very similar question regarding fully dynamic routing in MVC.
Multilingual URLs with ASP.NET MVC
I am in the process of building a super simple CMS to handle smaller "static" page type projects (e.g. - small sites for friends). I have different "page types" that I would like to add. I built something similar in Coldfusion previously. Looked something like this:
table content_type:
content_type_code varchar(10)
content_type_name
table content:
content_id
content_type_code varchar(10)
content_name
content_desc
content_url
I would create a content type called "blog" or "photo" and each time a content was added, it'd get assigned the content_type_code. Then in /blog/ I'd query for all content that had a content_type_code of "blog".
Now that I'm using Ruby/RoR I am trying to think about things differently. I was thinking a better way might be to use nested pages with awesome_nested_set (https://github.com/collectiveidea/awesome_nested_set). But I'm not sure if that's the best solution.
Then I could create a page called "blog" and add to that many pages. So essentially the top level would take place of the "content_type" from my previous example.
Can someone steer me in the right direction on what the best method would be? I'm a newb looking for a kick in the right direction.
EDIT
I should add that the only real thing that I would change between the different "types" of content would be the layout and where they are displayed ("photo" content at /photos/, "blog" content at /blog/).
I try to recap:
You want to build a CMS
Your CMS manages a single web site
A web site is made of content
There are differenti type of contents, and I am assuming every type of content has its own behaviour
Contents are organized in a tree
Here is the plan I suggest you:
Create the Content resource; use the scaffold to have something already working, adding few field (title and body in example)
Add validations to your new model
Write a couple of unit tests against your validation (quite useless, just to see how it works)
Install awesome_nested_set and manage to make it working with your model
Work on the UI to make it quite easy to create new content, move content around, edit a single content
Now its time to implement the content types; STI is the Rails way, but I have to warn you it can be really hard. I suggest you to reiterate 1, 2, 3, 5 to create new models for Photo and BlogPost
Once you will be there, you will have hundreds of ideas to implement. Have fun :)
Instead of using content_type I would rather let the user choose a model on a selection page, like "photo" or "blog" and load an editing page based on that selection. So the user wants a new 'blog'-entry they get redirected to blog/new or 'photo' for photo/new. It's the easiest way to go in terms of usability and your controlling backend and you don't have redundant data (for example an empty photo url which is not necessary in a blog-type) in your database.