+1 both Derby.js and Ember.js are heading towards a full-stack solution, but integrate well with other best of breed options such as jQuery, Rails, Racer, Node, etc.
You can definitely use for resources other than User. For instance, originally had User resource that included a bunch of additional information regarding the user's profile (address, age, phone #'s, etc.).
I decided that these attributes should be part of a different resource called RenterProfile (it's an app for renters), leaving nothing but the email address and password in the User resource. So I setup the appropriate controller, model, views and DB migration for this renter_profile resource. Once I had everything working (all the renter_profile fields within a single page/form, I then moved on to implementing a wizard for the renter_profile resource.
I followed Ryan's example pretty much verbatim simply swapping in renter_profile in place of user. I let my renter_profiles_controller perform the initial #create action with just a few basic fields (similar to creating the User with only the email and password). Then I created a renter_profile_steps controller (of course including the wicked gem same as Ryan's example). I placed the remaining attributes I wanted for the renter_profile into multiple form view files within the ~/views/renter_profile_steps directory.
The only hiccup I encountered was that get "renter_profile/steps" somehow ended up in my routes.rb file which messed everything up. Not sure how it ended up there (maybe wicked created it, but unlikely) or my coding partner did it without remembering... Regardless, with it removed, the renter_profile_steps_path began working correctly.
+1 both Derby.js and Ember.js are heading towards a full-stack solution, but integrate well with other best of breed options such as jQuery, Rails, Racer, Node, etc.
Nice response!
+1 on a Rails + Ember.js example that includes basic authentication and authorization.
@nelsonkeating - see my response above.
You can definitely use for resources other than User. For instance, originally had User resource that included a bunch of additional information regarding the user's profile (address, age, phone #'s, etc.).
I decided that these attributes should be part of a different resource called RenterProfile (it's an app for renters), leaving nothing but the email address and password in the User resource. So I setup the appropriate controller, model, views and DB migration for this renter_profile resource. Once I had everything working (all the renter_profile fields within a single page/form, I then moved on to implementing a wizard for the renter_profile resource.
I followed Ryan's example pretty much verbatim simply swapping in renter_profile in place of user. I let my renter_profiles_controller perform the initial #create action with just a few basic fields (similar to creating the User with only the email and password). Then I created a renter_profile_steps controller (of course including the wicked gem same as Ryan's example). I placed the remaining attributes I wanted for the renter_profile into multiple form view files within the ~/views/renter_profile_steps directory.
The only hiccup I encountered was that
get "renter_profile/steps"
somehow ended up in my routes.rb file which messed everything up. Not sure how it ended up there (maybe wicked created it, but unlikely) or my coding partner did it without remembering... Regardless, with it removed, the renter_profile_steps_path began working correctly.You can see the actual code at: https://github.com/jvenator/wallet
We'll be taking the repository private in the next week or so as we start getting into more proprietary stuff, but for now feel free to have a look!