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/
Related
This is my most confused aspect that I continually have to ask people about. They have given me answers like 'if it works with data it goes in the model'... but to me that is pretty much ALL of it.
Does anyone have a better way to explain this?
Perfect example from my current code:
I have a listing of posts that can be favorited or not favorited. On the front end, i differentiate the different ones by dynamically adding class="favorite" to the HTML depending on if its a favorite or not.
So basically ... <li class="item<%= is_favorite?(current_user.id) %>">
Part of me thinks this should go in the model because its going to be running a statement to find a record that matches :resource_id and :user_id...
but another part of me thinks its going to be in the controller because its directly outputting the word " favorite" which is used in html
My second mini question is, is it the-rails-way to put methods that the controller uses in the same controller? as long as they remain un-routed, etc. Or is that not the right spot?
You're thinking properly.
The right answer is that you should use presenters or decorators.
See this railscast for inspiration.
I would like to be able to set things like the page title and <meta> description from within HAML “pages” served up by my static page controller.
Is there a good way to do this? Ideally, I see it working something like:
Name files like about_us.html.haml.yaml
Use the normal render method
But now there is a hash of metadata available to my controller and layout templates, which set various headers and elements, respectively.
Thoughts?
(Since no one contributed a full answer)
If you want to set up title, description, noindex or similar tags in the head, then github.com/kpumuk/meta-tags is the best way to do it! I've used in a various projects, and think it's best gem ever for manipulating with title, description and other stuff that sits in the head tag.
— Dmitry Polushkin
It seems to work well for me, though it is a touch less powerful than what my question was looking for. Further answers welcome.
I have a small set of css items in a db table that I need to turn into a css file to be included on a page. How can I do this in Rails3?
Is there a way I can call this directly from a stylesheet_link tag? Do I need to go through some ruby to open a file and output it in some directory first? Do I do this in a controller?
The css is actually its own model associated to the item using the css.
I do not know and looking for a solution found little yet, so asking here.
EDIT:
Simple when looked at, I was looking toward a sass or less solution and may still, but this is a simple start
I would create a Controller that retrieves the data from the database that uses a View to render the data to a Cascading Style Sheet.
You could then reference the given URL whenever you need to use the resulting stylesheet.
This is the easiest way that I have found http://blog.hasmanythrough.com/2007/10/18/simpler-than-dirt-restful-dynamic-css
I've got a very old php application (1999) that has been worked on during the last ten years. At this point the app starts to show it's age so i'm in te progress of migrating to a "new" framework, symfony 1.4. But since the app is very large, i cannot do this at once. So i'm planning to wrap the old app into the new symfony app, and convert functionality by functionality.
First step in this transition was making the old app appear in the new symfony app. So, i've created the "frontend" application, added a "legacy" module, made it the default homepage, and i've put everyhting i had in my index.php (all pages went through this index.php) in the indexSuccess.php file for the indexAction. I've added the code in the "view" because there are also functions in it and changing that setup would take me more time than i want to spend on the old app.
Unfortunately i've now got an issue with global variables. Let me give you an example (i would have never made this register function like this, but it is, so please look past that.
$session = new ps_session;
$demo = "this is a demo variable";
$session->register('demo');
In ps_session i have this method
public function register($var) {
global $$var;
$_SESSION [$var] = $$var;
}
So it should put the content of $demo in a session var named "demo". Clever right :) Anyway, var_dumping shows me the that $$var is "null" and $demo is filled if i var_dump before and after calling the function. Exact same code without symfony and it returns the correct content.
What am i missing? The global call is spread out in all area's of this massive app so i really don't want to switch to something else, so i'm hoping for a quick fix :)
Maybe relevant, the all code except the index.php content are in frontend/lib/legacy/ folder, the index is in frontend/modules/legacy/ (if there is some scope issue i'm missing)
I think that since your indexSuccess.php file is included inside a function (more precisely, here : lib/vendor/symfony/lib/view/sfPHPView.class.php:185 ), this can't work, because $demo is no longer in the global scope. I don't see any easy workaround for this...
I think you should create a legacy folder in /web , and use routing to redirect to it if the url corresponds to something not migrated yet.
I went with putting the entire old site under web/legacy and redirecting from the default index action to the legacy folder. Most of the url's were made by mod_rewrite so easily fixed. The other url's went through a function so fixing was ok, and only a few were hardcoded. To make it totally transparant, i only need to redo the homepage to start from, so i don't have a visible /legacy/ in my url. Thanks for the help!
I agree with greg0ire that this is an issue with the way sfPHPView includes indexSuccess.
Could you simply require index.php in the default/index action?
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.