I would like to speed up some of my admin-generated modules by hydrating doctrine results with Doctrine::HYDRATE_ARRAY. Is this a good idea? How can I do it?
I don't think that you can do it that easy. All calls in the default admin generator theme use the Doctrine object (i.e. $model->id, and not $model['id']. To use arrays you would probably need to recreate the default theme, as well all calls that retrieve the objects.
Oh, and also the Admin Generator uses the generated forms as it's base for generating the displayed forms.
You would probably be better off optimizing other ways. Make sure you have to correct client side caching headers, optimize the sfViewCacheManager on the server side, use APC, use the doctrine query cache, etc...
This could include some more custom work (for example leveraging the view cache manager), but significantly easier to implement.
I agree with Grad van Horck. Also, make sure your index pages are using the minimum number of queries (easy to see in the development environment's web toolbar). Most of my modules are much more efficient after I create custom table_methods with the proper table joins and also include ONLY the fields I need to have loaded into the object.
Related
I want to search in content and I don't want to get fault result.
assume users search 'br' I don't want to see in output results that have <br> or <P> and other html elements
Simply, you must strip the tags before you search. However, that would mean not being able to query the database directly. Rather, you'd have to pull all the objects first, and then query the collection in memory.
If you're going to be doing a lot of this or have large collections of objects (where pulling all of them for the initial query would be a performance drag), then you should look into a true search solution. I've been working with Elasticsearch, which seems to be just about the best out there in my opinion. It's easy to set up, easy to use, and has third-party .NET integration through the nuget package, NEST.
With a true search solution, you can index your content fields, stripped of HTML, and then run your queries on the index instead of directly on your database. You'll also get powerful advanced features such as faceting, which would be difficult or impossible to do directly with Entity Framework.
Alternatively, if you can't go full board on the search and it's unacceptable to query everything up front (which really it pretty much always is), then your only other option is to create another companion field for each HTML content property, and always save a HTML-stripped copy of the text there. Then, use that field for your search queries.
I have a Grails application that needs internationalization. Grails makes it easy to translate fixed strings using the messages.properties file, but I could not find how to translate model fields.
Is there some way to manage internationalized models, so that models in multiple languages can be entered in some admin area and the correct one will be selected in the view?
I could roll up my own system, but maybe something of this kind already exists and it is more featured and battle-tested than what I would write. This had happened to me in Django: I used a custom system - which I describe below - for internationalization, only to find out that various Django apps already solve this problem.
An example of how to solve this issue
If it is not clear what I am trying to achieve, here I describe the implementation I used on Django.
I had two base abstract models, I18NModel and TranslationModel. The actual models used in the application inherited from the former, while their translations from the latter. In inheriting, they needed to define a foreign key to their untranslated model and to define a field with the associated language.
The original model, in turn, inherited a method translate, that took a language and returned a proxy model. This proxy had a reference both to the original, untranslated model and to a translated model associated to the correct item and language.
Whenever you asked for a field on the proxy, it would try to find if it was defined on the translated model. If it was, it would return that, otherwise it would give as default the field on the untranslated model.
Hooking it with a method to find the current language, I got as a result something that I could use like this in the templates:
<h1>{{ article.translate.title }}</h1>
while allowing editors to insert translations in the admin area.
Looks like i18n-fields plugin does the thing.
I'm using Rails 3 to create a project that will need a model called Sketch. I've already created a model, controller, and migration to handle Sketch - so far it just creates a 'sketch' object with a name for each sketch.
My problem is that I need to be able to attach an html5 canvas to each sketch object when it is created (or remove it when it is destroyed).
Since 'canvas' is not a datatype that will be stored in the database (like 'string', 'integer', or 'datetime'), how do I go about creating custom html components such as this that need to be treated like any other datatype in a Rails app?
I'm assuming that you would need to add the html components to a Model method and use a callback - like after_save - to initiate the component. But I'm not sure at all how to do this.
Not sure if I'm describing this well enough, so here is a very simple mockup:
I have the Raphael Javascript library in mind for the component that will do the sketching - if that helps.
If you can point me to any tutorials on this subject that would be great.
HTML5 canvases are rendered in the browser, not on the server where your ruby code is actually executed. Therefore I think it's safe to say that what you're asking isn't possible (at least in the way the question is phrased).
Instead you'll need to work with HTML, CSS and Javascript in your view to get the canvas working.
Canvas Tutorial / Reference
Hope this helps.
(On a related note, it's also considered a bad practice to mix view-related concepts in with your models.)
What's the best way to implement an interface that looks like this in rails?
Currently I'm using Searchlogic, and it's a tad painful. Problems include:
Making sure certain operations remain orthogonal -- for example, if you select "Short Posts" and then search, your search results should be restricted to short posts.
Making sure the correct link gets the "selected" class. Right now the links are <a>'s, so maintaining this state client-side is tricky. I'm hacking it by having the AJAX response to, say, sorting return a new sort links section with the correct link "selected". Using radio buttons instead of <a> tags would make it easier to maintain state client-side -- maybe I should do that?
I recently solved a similar problem using named_scopes and some ruby metaprogramming that I rolled up into a plugin called find_by_filter.
find_by_filter accepts a hash of scope
names and values, and chains them into
parametised scope calls. If the model has a named_scope that matches the provided name, this is called.If no named_scope is found, an anonymous scope is created.
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.