I am implementing a dashboard as a relative Rails newbie (more of an infrastructure guy). The dashboard will consist of multiple pages, each page of which will contain multiple charts/tables/etc. For modularity, I want it to be as easy as possible to add new charts or change views of the data.
Say one page has 5 different charts. I could have the controller do 5 separate data lookups, hold all the relevant data in instance variables, and render 5 partials, each of which touch subsets of the data. But it seems more modular to have one "index" controller action whose render has a bunch of divs, and for each div there is another controller action which does the data lookup and has an associated view partial in charge of managing the view of that data within the div.
So if I'm showing the website dashboard page which has two graphs, website/index would use website/graph1 and website/graph2 to look up the data for each and then _graph1.html.erb and _graph2.html.erb would use the controller data to fill out divs "graph1" and "graph2", etc.
Is this the right design, and if so, what's the easiest way to accomplish this? I have an approximation using remote_function with :action => "graph1" to fill out divs, but I'm not 100% happy with it. I suspect I'm missing something easier that Rails will do for me.
Version 1:
Simple method that I've actually used in production: iframes.
Most of the time you don't actually care if the page renders all at once and direct from the server, and indeed it's better for it to load staggered.
If you just drop an iframe src'd to the controller's show action, you have a very simple solution that doesn't require direct cross-controller interactions.
Pro:
dead easy
works with existing show actions etc
might even be faster, depending on savings w/ parallel vs sequential requests and memory load etc
Cons:
you can't always easily save the page together with whatever-it-is
iframes will break out of the host page's javascript namespace, so if they require that, you may need to give them their own minimalist layout; they also won't be able to affect the surrounding page outside their iframe
might be slower, depending on ping time etc
potential n+1 efficiency bug if you have many such modules on a page
Version 2:
Do the same thing using JS calls to replace a div with a partial, à la:
<div id="placeholder">
<%= update_page {|page| page['placeholder'].replace with some partial call here } %>
Same as above, except:
Pro:
doesn't lock it into an iframe, thus shares JS context etc
allows better handling of failure cases
Con:
requires JS and placeholder divs; a bit more complex
Version 3:
Call a whole bunch of partials. It gets complicated to do that once you're talking about things like dashboards where the individual modules have significant amounts of setup logic, however.
There are various ways to get around this by making those things into 'mixins' or the like, but IMO they're kinda kludgy.
ETA: The way to do it via mixins is to create what is essentially a library file that implements your module controllers' setup functions, include that wherever something that calls 'em is used, and call 'em.
However, this has drawbacks:
you have to know what top level controller actions will result in pages that include those modules (which you might not easily, if these are really widgety things that might appear all over, e.g. user preference dependent)
it doesn't really act as a full fledged controller
it still intermixes a lot of logic where your holding thing needs to know about the things it's holding
you can't easily have it be segregated into its own controller, 'cause it needs to be in a library-type file/mixin
It IS possible to call methods in one controller from another controller. However, it's a major pain in the ass, and a major kludge. The only time you should consider doing so is if a) they're both independently necessary controllers in their own rights, and b) it has to function entirely on the back end.
I've had to do this once - primarily because refactoring the reason for it was even MORE of a pain - and I promise you don't want to go there unless you have to.
Summary
The best method IMHO is the first if you have complex enough things that they require significant setup - a simple iframe which displays the module, passing a parameter to tell it to use an ultraminimalist layout (just CSS+JS headers) because it's not being displayed as its own page.
This allows you to keep the things totally independent, function more or less as if they were perfectly normal controllers of their own (other than the layout setting), preserve normal routes, etc.
If you DON'T need significant setup, then just use partials, and pass in whatever they need as a local variable. This will start to get fragile if you run into things like n+1 efficiency bugs, though...
why don't you give Apotomo a try, that's stateful widgets for Rails:
A tutorial how to build a simple dashboard
You could achieve this by using
render_output = render :action => "graph2"
But Me personally would probably wrap the code in either a shared helper or write you own "lib" under the lib directory to reuse the code with a shared template. Remember that unless you change your route.rb file any public method defined is accessible by
/controller/action/:id
Also remember to turn off the layout for the function :layout => nil (or specify at the top of the controller layout "graph", :except => ["graph2"]
Cheers
Christian
I'm not aware of any special Rails tricks for achieving this without using AJAX in the way you've outlined.
The simplest way to get the modularity you seek is to put those portions of controller code into separate methods (e.g. set_up_graph1_data, set_up_graph2_data, etc.), which you simply call from your index action to set up the variables for the view.
You can put these methods into ApplicationController if you want them available to multiple controllers.
As a side note, early on, Rails did used to have a feature called 'components' which would allow you to do exactly what you're asking for here, without having to use AJAX. From your view, you could just render another controller action, inline. However, this feature was removed for performance and design philosophy reasons.
Related
I am building an ember app and it is starting to get large. Is there any way to do lazy loading of the ember files so that it does take 10+ seconds to load when the user first hits the site? For example since I have several logically separate modules as part of the site, I could load the modules as they are accessed. I am using ruby on rails and the ember-rails gem.
If you think about what Ember is actually doing to render that code, you can understand why it is slow. Suppose you're creating 2k view instances, and rendering 2k templates. Templates that for the most part are doing very little. Especially if you don't care about data binding.
For a first stab, let's stop rendering through templates. This code uses itemViewClass to render each item with a custom view instead of the view used internally by each.
// Use with {{each item in items itemViewClass=App.SpanView}}
App.SpanView = Em.View.extend({
render: function(buffer) {
buffer.push("<span>"+this.get('content')+"</span>\n");
}
});
JSBin: http://jsbin.com/enapec/35/edit66
With render over-ridden, we need to interact with the render buffer ourselves.
Even faster would be getting rid of the view entirely. I think there are two ways to do this. You could create a custom view with a render method that loops over all the items, and pushes each element onto the buffer. I think given the previous example you can get that going yourself.
Another simple option is to use a helper. A dumb helper like this is more difficult to wire up for re-rendering when the list changes, but sometimes it is the right solution.
// Use with {{eachInSpan items}}
Em.Handlebars.registerBoundHelper('eachInSpan', function (items) {
return (
new Handlebars.SafeString(
items.map(function (i) {
return '<span>'+i+'</span>';
})
)
);
});
Live JSBin: http://jsbin.com/enapec/34/edit
Lastly, you could do this in jQuery with didInsertElement and the afterRender queue. I don't recommend it though.
Ember.RenderBuffer gathers information regarding the a view and generates the final representation. Ember.RenderBuffer will generate HTML which can be pushed to the DOM.
FYI here is the RenderBuffer API
DEFINED IN
MODULE : Ember-views
I am also new bee but I got this from some resource. Thanks.
On this Keynote on Embercamp London 2016, #wycats and #tomdale talk about the plans for improving Ember with slicing and dicing of the app. They talk about loading only what it's needed for that particular route. This is going to be great. I think that's what you wanted :)
https://www.periscope.tv/w/1mrGmzPBvQqJy#
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.
Just wondering what the shorthand would be in Rails to do this (if any):
I have views/pages/ containing 5 html.erb files and they all use the same default layout.html.erb, with one yield statement in the middle of it (the standard setup).
Now I want one view that incorporates all 5 of those erb files above contiguously, one after the other, in place of the one existing yield statement in that same layout.html.erb.
What minimal changes would I make to the layout.html.erb to accomplish this.
(Rails Newbie - like it more than Django now).
Ah,
I see what you're saying. Try this. Have your file structure such that all the views for said controller are in one folder...
#controllers_views = Dir.glob("your/controllers/views/*.erb")
#controllers_views.each { |cv| puts cv }
Seems like that would work, I'm away from my dev box or I'd test it for you.
Hope that helps.
Good luck!
You could always have a javascript that requests the sequential yields at a time interval as an ajax request. Then just your target element change to reflect the updated information.
Alternatively load all 5 into different divisions, and have them revolve visibility, like a picture gallery. CSS3 could pull this off.
http://speckyboy.com/2010/06/09/10-pure-css3-image-galleries-and-sliders/
This is a new application, and I have an index method on a Search controller. This also serves as the home page for the application, and I'm trying to decide if I am headed down the wrong path from a design pattern perspective.
The method is already 35 lines long. Here is what the method does:
3 lines of setting variables to determine what "level" of hierarchical data is being searched.
Another 10 lines to populate some view variables based on whether a subdomain was in the request or not.
A 10 line section to redirect to one of two pages based on:
1) If the user does not have access, and is signed in, and has not yet requested access, tell them "click here to request access to this brand".
2) If the user does not have access, is signed in, and has already requested access, tell them "so and so is reviewing your request".
Another 10 lines to build the dynamic arel.
I can't get it straight in my head how to separate these concerns, or even if they should be separated. I appreciate any help you can offer!
Summarizing what you've said in something codelike (sorry, don't know ruby; consider it pseudocode):
void index() {
establishHierarchyLevel();
if (requestIncludedSubdomain())
fillSubdomainFields();
else
fillNonsubdomainFields();
if (user.isSignedIn() && !user.hasAccess()) {
if (user.hasRequestedAccess())
letUserIn();
else
adviseUserOfRequestUnderReview();
}
buildDynamicArelWhateverThatIs();
}
14 lines instead of 35 (of course, the bodies of the extracted methods will lengthen the overall code, but you can look at this and know what it's doing). Is it worth doing? That really depends on whether it's clearer to you or subsequent programmers. My guess is it's worth doing, that splitting out little code blocks into their own method will make the code easier to maintain.
That's a lot of variables being set. Maybe this is a good opportunity for a module of some kind? Perhaps your module can make a lot of these decisions for you, as well as acting as a wrapper for a lot of these variables. Sorry I don't have a more specific answer.
Without your code it's somewhat difficult to suggest actual fixes, but it definitely sounds like a really wrong approach and that you're making things much harder than they need to be:
3 lines of setting variables to
determine what "level" of hierarchical
data is being searched
if there is a search form, I would think you would want to pass those straight from the params hash into scopes or Model.where() calls. Setup scopes on your model as appropriate.
Another 10 lines to populate some view variables based on whether a subdomain was in the request or not.
This seems to me like it should be at most 1 line. or that in your view, you should use if statements to change what you'd like your output to be depending on your subdomain.
A 10 line section to redirect to one of two pages based on:
the only thing different in your explanation of the 2 views is "whether the user has requested access" surely this is just a boolean variable? You only need 1 view. Wrap the differences into 2 partials and then in your view and write one if statement to choose between them.
Another 10 lines to build the dynamic arel.
It might be necessary to go into Arel, but I highly highly doubt it. Your actual search call can in most cases (and should aim to be) 1 line, done through the standard ActiveRecord query interface. You want to setup strong scopes in your models that take care of joining to other models/narrowing conditions, etc. through the ActiveRecord Query interface.
Hy,
I was thinking that all my website will have use of cells, using the known plugin cell for rails, so this is my idea:
A table that contains 3 fields: id, view_name and layout. the layout will be a serialized hash.
When a request is made, the layout field is requested and then in the view, default layout, will be unserialized the layout var, that looks like this:
#layout[:sidecol][:gallery] = {... some params for it...};
#layout[:maincol][:comments] = {..params...};
In the <% #ruby code to render the cells in the #layout[:sidecol] %> will be some ruby code that will loop over the #layout[:sidecol] and render all cells in it. the same occurs in the maincol div.
What do you think?
Positive in my opinion:
More modular
controller is used only for post
easy change of structure
easier to implement some kind of traking to see diferences on what layout is better or not.
Negative:
not found yet
EDIT:
1) The request comes, is calculated the view name.
2) Load from the database the layout field that corresponds to the view name. (this will be cached, and will be updated only when changes are made. I intend to use this way, because I will need to test the layout. 33% layout1, 33% layout2 and 33% other layout. So will be used a random number to choose the view layout.)
3) The layout field contains: first subdivision is the name of the div to be created, then in each one will be more components, named cells in this case, that will be instanced in the application controller, because will be repeated for all get requests.
4) In the view will be created the divs and will be rendered in each one the cells defined.
5) The cell will make the request to the db and load the data.
6) The cell will then render the HTML and is ready to go!
So... in discussing MVC, you should understand that the controller layer is probably the most critical of any of the layers for actually accomplishing tasks. The controller layer is intended for actually getting any work done within your framework.
There are ways to abandon monolithic MVC as your primary pattern, for example, building a set of services which communicate with each other, but even there, that's mainly abandoning monoliths, since you can push the MVC pattern down into each component.
With regard to your specific proposal, storing layout data, which seldom changes between requests, in your DB is an unnecessary performance hit. Having to drag the layout from your DB out, unserialize it and run it will require you either to set up a caching framework, or to do crazy DB scaling.
Incidentally Rails3 and Merb (and i think even Rails2) are sufficiently modular in the controller layer, that they don't really care where your layout/templating/view stuff comes from. If you really want, you can just tell them to render a string.