unsay / vicini

9 stars 1 forks source link

Moving a metric ton around. #4

Closed unsay closed 11 years ago

unsay commented 11 years ago

@jdalt

To get you up to speed, take a look at this pull request.

The key parts: vicini.js is the "app". It loads the modules needed messages.js, profiles.js, etc.

I've mapped AngularJS routes as closely to Rails routes as possible. When binding an AngularJS controller to a template, be sure to have the file extention be .ng for A(ng)ular.

Rails then will render it as a partial. For instance a new message has an Angular route defined:

app/assets/javascripts/messages.js

   .when('/messages/new',
      {
        controller: 'messagesController',
        templateUrl: '/messages/new.ng'
      })

And the HAML view rendered to a Angular template: app/views/messages/new.html.haml

%h1 Send a Message
= simple_form_for :message, url: '', html: { 'data-ng-submit' => 'submit()' } do |f|
  = f.input :subject
  = f.input :body
  = f.button :submit

Feel free to comment on any line and ask questions in this pull request.

jdalt commented 11 years ago

@unsay

Are notes on lines included as comments or is that meta information exclusive to the github interface?

jdalt commented 11 years ago

Do we want to develop more structure now in the app/assests/javascripts/ directory for Angular (by creating directories for modules, controllers, services,...) or should we just refactor that once the files count grows?

unsay commented 11 years ago

@jdalt Comments are all GitHub only. The git repo doesn't concern itself with the noise we create. :)

unsay commented 11 years ago

Regarding organization, it seems the recommended approach is to have directories by feature with modules, controllers, services. I'm still learning and figuring it out. Up for anything at this point. I imagine we'll probably be refactoring this somehow.

unsay commented 11 years ago

I'm reading up on testing in Angular. Would prefer to have those before this is merged to master.

jdalt commented 11 years ago

I get an error when trying to submit to the forms. For the profiles form I get:

No route matches [POST] "/profiles/edit.ng"

1) Should we fix these forms before merging the pull request? 2) Should we setup a javascript testing environment before going much further? I assume this would integrate with Travis CI and then we would know the forms are working with angular and passing all tests.

unsay commented 11 years ago

Have you pulled recently? I fixed that. I missed a route.

I think tests before merging to master are important. So let's not. I would rather have "working software".

jdalt commented 11 years ago

@unsay

I did a git pull on the angular_feature branch and a git fetch origin, and I believe everything is up to date.

On my local test server I'm unable to submit forms with angular--both cause the browser to post and fail to recognize the ng-submit="submit" in messages.html.haml and my copy of profile.html.haml lacks an ng-submit directive.

The browser submission occurs because angular will only prevent the default submit behavior if the action attribute doesn't exist. I was unable to find out how to remove the action in the Simple Form documentation or even the default rails form helpers. This seems like it should be possible but if it isn't we'll be rolling our own forms or form helpers to play nice with angular.

unsay commented 11 years ago

Bah. I think I left something important out. I'll check over lunch. :S Sorry about that.

jdalt commented 11 years ago

I feel like there's a couple complications and cruft things we need to iron out. We have a user and a profile model/object which in my mind don't really have a clear delineation of responsibility. Also, after integrating Persona, we have fields on user which should probably store Persona information rather than a crypted_password and salt which seem like the legitimate responsibility of Persona (we probably need a field for a Persona token). Thoughts?

unsay commented 11 years ago

@jdalt Agreed. I'll clean up in a few.

  1. Get rid of the sorcery turds as I'd like to use Persona.
  2. Rename Profile to Address.
  3. Move address fields from User to Address.

The only thing we get from Persona is the email address. Authentication is completely out of our hands. No salt.

We'll need an additional screen for new user to update their "profile" which is first/last name and and address.

Eventually, I'd like to support multiple addresses (formerly profiles).

jdalt commented 11 years ago

@unsay

Awesome. I agree on all these accounts.

However I'm curious as to how we do authorization (like editing one's address) when persona only gives us an email address.

What piece of shared information (between client and server) guarantees that the email address verified by persona is the same individual calling the api (through an angular xhr or otherwise)?

Obviously we can't rely on client side code for authorization.

unsay commented 11 years ago

@jdalt I'm going to cull out the ideas into separate issues so we can discuss independently and not make this thread longer. Will also create issues for must haves in order to merge this in to master.

Yahyaateyah commented 9 years ago

leave a cammnte