Is there an equivalent to Symfony's Localized Schema in Rails 3 - ruby-on-rails-3

I've been searching for an equivalent to Symfony's built-in Localized Schema which provides a native support for managing internationalized Tables/DB. Here is a link to Symfony's documentation covering their implementation of I18n & L10n, with the relevant part on Localized Schema (appx. a third down the page, such as the paragraph "Text Information in the Database").
I've checked out Globalize2 gem, but not sure as to whether it is fully supported in Rails3.
Also found the gem puret, which seems to have more recent commits/activity.
All in all though, it's very likely I am missing out on other possible options, as still getting my bearings in RoR dev.
Open to any info/suggestions you may have! ;)

Try gem named has_translations. It have been tested in several production sites for a one year already. Supports 1.9 + Rails 3. For any issues fill out form on the github.
https://github.com/dmitry/has_translations
Actually it's more or less the same as puret, but it was built when rails 2.3.5 was a mainstream, so I just supported it for a websites I've did already. I suggest you to choose between puret and has_translations, others is too magic or not maintained anymore. You can find more alternatives in has_translations README file.

Related

report builder like salesforce has for ruby on rails?

Salesforce report builder is pretty awesome - see here http://www.salesforce.com/_app/video/chatter/help/report_builder.jsp.
Lots of my customers want similar functionality built into ruby on rails apps. I cant seem to find any good tool, framework or gem out there to do this sort of thing. Before I start building one myself, I wanted to see if anyone knew of something out there that was similar or could be used for the same purpose.

Automatic website creation using rails

I am looking for a template generator for rails, much like the scaffolding, but complete with preset pages and css, everything already built-in generically.
I am unsure where or how to search for this.
The reason I want something like that and not create one myself, is that I need to create a website really quickly with a certain preset theme
I had the same problem that you had, and could not find a solution. Therefore I built a gem for it.
https://github.com/bighostkim/simple-layout
It only applies to your development mode and it does not use asset to make it simple.
Hope it helps.
Rails Yard may be the solution you are looking for. It is a CMS written in Rails.
Rails CMS WIKI FORUM 2nd option
Rails Admin is great for data management (Create, Retrieve, Update, Delete).

How can I implement write through caching in Rails 3 similar to cache-money?

I recently inherited a Rails 2.3 application that I'm now trying to upgrade to Rails 3. Cache-money is an integral part of the application so I want to make sure we have the same functionality in place when we go to Rails 3. However, my research on the subject has shown that cache-money is not compatible with Rails 3 (due to the use of unsupported AR methods :find_every and :find_from_ids).
I've seen a couple of comments and blogs mention that implementing the type of write through caching with Rails 3 that cache-money provided should be a trivial task. Any ideas on how to approach implementing write through caching with Rails 3?
Last week I launched a new write-through-cache gem for Rails 3, see
https://github.com/orslumen/record-cache.
The reason I built it, is because we were using cache money in a Rails 2.3 project and recently migrated to Rails 3. So chances are, it will also serve you well.
Writing your own write-though caching in Rails 3 does not sound like a trivial task to me. If you do find a trivial way, please be sure to copy me in on that.

Migrating from Dojo 1.1.1 to Dojo 1.3/1.4

We are in mid of a project where we have used an extended Dojo 1.1.1 to meet the customer requirement and add richness.
But there are quite some bugs and performance problems with this version of Dojo and
we are looking ahead to migrate the Dojo version to overcome both the issues, but the migration cycle seems to be quite painful and may not be yield expected result.
The concern we have is with the various extension which we have created with the version of Dojo for components that were provided in 1.1.1 and the impact on them after migration.But, the advantage we see are equally important.
As per Dojo , they have kept some level of compatibility with version 1.1.1 but i have not seen any discussion around this anywhere.
Has any body else previously done
migrated between Dojo version?
Will the components like Grid will
work as expected or will i need to
carry out a refactoring exercise?
Do we have any commercial support
available as the forum seems to
deprecated?
Any help or suggestions are welcome
Dojo has had a policy of freezing and supporting public APIs since 1.0. Migrations prior to 1.0 were extremely painful. Now, it should be much better, provided you use only public APIs. Code written for stable JS APIs in Dojo or Dijit in 1.1 should largely still work. Exceptions are noted in the release notes, which you should explore (good luck finding them... unfortunately the site is a bit of a mess)
If you wrote any custom widgets, you're probably in for some extra work. dojox.grid was not particularly stable at that point, and it has also seen a major rewrite since then (there is an old 'compat' layer you may wish to use)
Regarding for forum, like the note says, you can either use the active dojo-interest mailing list or post questions here at SO. There are some firms which offer commercial support, but that's outside of the scope of Dojo as an open source project. (try googling 'Dojo commercial support' or asking on dojo-interest)
I have done 5 dojo migrations now (from 0.2 -> 1.4) over the last few years. Although the API does not change, you will often have coded in workarounds that no longer work after upgrading. Things I have noticed:
quality in 1.4 is VERY good and worth
upgrading to (even from 1.3)
although
the API does not change, little
things that are not public often
change slightly (diji.Tree
itemNodeMap -> itemNodesMap in 1.4)
build options are usually added each
release but not always publicised -
strage really as they are always
useful improvement
since you are 1.1.1, you should change all your set attribute calls to 'attr' - this could take a while to do.
As for commercial support, you could try Sitepen

Updating sqlite3 API

I want to update/upgrade the standard Leopard install of Sqlite3 to >3.5 to use the new sqlite_xxx_v2 methods from a Cocoa project.
I can't seem to find any information on how to do this. Does anyone have any tips or a site that outlines the update procedure.
Also is 3.5+ supported on the iPhone. I understand it's embedded so shouldn't be an issue...
What you want to do is grab the amalgamation sources from http://sqlite.org/download.html . Then just compile that into / add it to your project. You don't want to replace the system sqlite- that'll have unintended consequences in other applications. Plus, I'm pretty sure the system sqlite isn't a stock sqlite... Apple has probably made their own modifications to it that core data relies on.
You can read up on the amalgamation stuff here: http://sqlite.org/amalgamation.html , but in short: '''The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3 and RTREE extensions'''
I'd also suggest not using the sqlite calls directly, they weren't designed to be used that way (says the author of sqlite). Instead, there are a number of cocoa wrappers out there, including fmdb: http://code.google.com/p/flycode/source/browse/trunk/fmdb/ (which I wrote) :)
-gus
You don't really want to upgrade the system version of SQLite on Mac OS X. The reason is that all Mac OS X software is qualified against the versions of the packages that it includes, as built by Apple's build process. Installing a different version of a package, or even building the same version yourself but doing so slightly differently than Apple does, may result in a system that behaves unexpectedly.
Finally, if you embed a newer version of SQLite — or any Open Source library or framework included with Mac OS X — into your own application, you should be sure to integrate the Darwin changes for it from Apple's public source site. That way you can be sure you'll get as close to the same behavior as possible from the library you've built yourself as the version Apple ships, which is especially important when it comes to functionality like file locking in databases.
I don't believe i've updated my version, but it's currently at 3.4.2, and i'm able to use the new methods with the current version.
And i'm running 10.5.5 with the latest (public) iPhone SDK.
It would likely be easier to just drop the library into your project and link it in from there.