HelsinkiTeam @rghelsinki2014-blog - Tumblr Blog

Week 14, Day Last day of our RGSoC

Today is the last day of our RGSoC, excited but also a little bit sad. It was so nice experience to LEARN BY DOING at RGSoC.

Last day, i continue to implement the initiaitve with modal dialog approach, as before i failed to make the cancel and submit button work. So based on previous experiperience on implementing alert on removing support, i impelemt edit initiaitve. At the beginning, i also have problem on cancela and update button, as they both save the changed content. Then i google but haven't found solution. Then i went to ember js irc channel to ask, locks gave me hint on using rollback menthod. Then i google again and tried some times. Finally it work.

Below is code

app/templates/edit.js

.edit h5 Initiative title {{input value=title}} h5 Initiative description {{input value=description}}

.update button click="update" Update

.cancel button click="cancel" Cancel

app/controllers/edit.js

import Ember from 'ember';

var EditController = Ember.ObjectController.extend({

actions: { cancel: function() { this.get('model').rollback(); return this.send('closeEdit'); },

update: function() { return this.send('closeEdit'); } }

});

export default EditController;

app/routes/intiative.js

openEdit: function(edit, model) { this.controllerFor(edit).set('model', model); return this.render(edit, { into: 'initiative', outlet: 'edit' }); },

closeEdit: function() { return this.disconnectOutlet({ outlet: 'edit', parentView: 'initiative' }); },

templates/initiative.emblem

.edit_button a click="openEdit 'edit' model" Edit Initiative h5 =outlet edit

This is what i did, now wait for Oliver's feedback. The other thing is Cathy and i will take particicpate in Helsinki challengand also some workshops at Helsinki.

***

As for me, Cathy, I have two outstanding PRs to finish up. One is from some time ago regarding posting a new initiative to an existing issue. I had used controllers to store the an issueExists flag for the existing issue, which got passed to the template of the new initiative form. Then I could know whether or not the issue already exists and could display only the part of the form that relates to the initiative, otherwise, both issue and initiative parts of the form are displayed. I read that controllers can be used to store information about the current state of the app, so this approach seemed reasonable to me. However, Oliver thinks this is not intuitive and he suggested keeping everything related to the issue (including making a new initiative for an issue) under the Issues resource, this way no parameters have to be stored on controllers for use in other routes. I spent several hours trying to get this to work, but ultimately got stuck when transitioning to the new initiative route nested under issue. I could not get the model hook for the initiative model (undefined), and after some reading it I discovered that child routes don't inherit params from their parent resources. So, since initiative was not nested under initiatives (that would make two initiatives resources in two different places, which confuses the app), I reasoned that this approach is not viable.

That said, perhaps I am overlooking something about accessing the model hooks, so now I am waiting to hear Oliver's feedback. Suspense!!

The next PR involves some styling for the delete suggestion button. Oliver wants the delete link to be "discoverable"--that is, it only appears when the user hovers over the suggestion title. I will look at that now.

As Qian said, we are just so happy to have participated in RGSoC and can't believe it's already over. The program has given us so much knowledge and we are planning to move forward with more apps. I also will have a small Rails project to do for a real client, starting tomorrow, which makes me nervous but also quite excited!!

<3 <3 <3

Week 14, Day 1

Hard to believe this is the second-last day of RGSoC!! :( We are both sad, but we are so happy to have had the chance to be in this program. We have learned tons of stuff and have coded increasingly difficult features. Well done us! :)

Today I worked on the few remaining issues of the delete-suggestion feature. I reworked a line in one of the acceptance tests so that the submit button is specifically referenced by its type, not its position on the page (which is currently last, but this may change in the future). I also formatted the delete button syntax in initiative.emblem from handlebars into emblem. This is how to do it in handlebars:

<button {{action "delete" suggestion.id}} class="destroy">Delete</button>

and this is the Emblem version:

button click="delete suggestion.id" Delete

Not sure if I need to specify a class.

I am still waiting for word on the hover styling I made on Friday, in which the Delete button is greyed out until hovered over, and then it turns blue. I am also waiting for feedback on my PR from 11 days ago to make a new initiative for an existing issue.

Week 13, Day 5: Refine code on alert feature

I basically used modal dialog to finish this feature, i need to make the alert modal into be global. So it can be used as many times as it needed. I stucked on calling the removeSupport action inside of the doItModal action. The other thing is passing customized message to modal. Not it's sloved as below:

1. calling removeSupport action from doItModal

Send the doItModal action to the removeSupport in the /routes/initiative.js actions function

doItModal: function() { return this.send('removeSupport'); },

removeSupport: function() { var initiative = this.get('controller.model'); initiative.set('isSupported', false); this.transitionTo('initiative'); },

2. Passing message to modal

2.1 Setting message in in the openModal action (/routes/initiative.js action)

openModal: function(alert, model) { this.controllerFor(alert).set('model', model); this.controllerFor(alert).set('message', 'Are you sure to remove? You cannot make suggestions after removing support!'); return this.render(alert, { into: 'initiative', outlet: 'alert' }); },

2.2 Then put message in the alert.emblem template

.alert h6 #{message}

Especially thanks Oliver and Cathy's hint on the message passing issue :)

Week 13, Day 4: Edit initiative

To implement the edit initiative feature, i firstly defined action in the initiative route file

toggleEditing: function() { this.toggleProperty('isEditing'); },

Then in the initiative template file , i have below code

.title if isEditing h5 Initiative title {{input value=title}} h5 Issue title {{input value=issue.title}} else h2 = title h5 <button {{action "toggleEditing"}}> Edit</button> p.issue_title Issue: #{issue.title}

.choice if isEditing button click="cancel" Cancel button click="submit" Submit

Now when click the edit button, in-place editor with previous initiative title and issue title will show, in addition, a submit button and cancel button also appear. I first try define the submit and cancel action, however had some problem on updating the chanegs and stays the same content. I also think about using modal dialog btu haven't tried. Seems hard to find examples. For the submit button, i now can save the newly upated initiative title but cannot transition back to the initatives/id page. It still has the in place editor and buttons. Hope tomorrow will solve it

Week 13, Day 3: replacing the for loop with the find method

For loops can be avoided by using the built-in find methods in Ember. Here is how I implemented it:

var suggestion_array = this.controller.content._data.suggestions; //get the ids of each Class in suggestion_array var id_array = this.controller.content._data.suggestions.getEach('id');

//find the element in id_array that matches suggestion_id var find_suggestion = id_array.find(function(item, index, self) { if (item == suggestion_id) { return true; } });

//use index of find_suggestion in id_array to get the right //suggestion in suggestion_array var suggestion = suggestion_array[id_array.indexOf(find_suggestion)];

This does not look any cleaner than the for loop to me, but maybe even this can be optimized even further.

Week 13, Day 2: resolved the duplication issue and action handling for deleteSuggestion

Whew! today was a busy day and starkly contrasted from yesterday in which nothing whatsoever worked. Today, everything blissfully worked, yay!

The problem with the suggestion duplication in Ember Data was resolved by simply following the advice of @locks in the original PR (#33) made by Oliver. It was a bit simpler than Oliver's code and appears to do the trick:

SuggestionsNewRoute:

actions: { submit: function() { var _this = this; var suggestion = this.get('controller.model'), initiative = this.modelFor('initiative'); suggestion.save().then(function(model) { initiative.get('suggestions').pushObject(model) _this.transitionTo('initiative.index'); }); } }

Th next issue to tackle was the deleteSuggestion action, which was defined in the controller but should actually be in the route. After trying every route file we had, I discovered that the IniativeRoute is the only file which would handle the action.

I had to perform some fun js object gymnastics to determine which suggestion out of the array of suggestions the user has selected to delete. The first thing was to pass the suggestion id from the template, when the delete button is clicked:

initiative.emblem:

ul.suggestions each suggestion in suggestions li.suggestion = suggestion.details <button {{action "deleteSuggestion" suggestion.id}} class="destroy">Delete</button> else p.nosuggestion No suggestions. Be the first to write one!

The suggestion.id gets passed into the IniativeRoute where a for loop compares it with each of the suggestion ids in the array:

deleteSuggestion: function (suggestion_id) {

var suggestion_array =this.currentModel._data.suggestions; var initiative = this.currentModel;

for (var i = 0; i < suggestion_array.length; i++) {

if (suggestion_array[i].id === suggestion_id) { var suggestion = suggestion_array[i]; } }

initiative.get('suggestions').removeObject(suggestion); suggestion.deleteRecord(); suggestion.save();

}

My first javascript for loop! :)

The other thing that had to be done was delete the suggestion from the suggestions array that is attached to the initiative with the removeObject function.

Week 13, Day 1, Stuck on moving action from controller to route

Last week i used controller to define delete action for implementing "Deleting suggestion" feature. Now i get feedback from Oliver that i need to move the action to route. I am quite confused about which route i should move, the delete button is on the initiative template, but suggestion is from suggestion model. I try move action to initaitive route , suggestions/index route. Somehow doesn't work, always have error "Uncaught Error: Nothing handled the action 'delete'. If you did handle the action, this error can be caused by returning true from an action handler in a controller, causing the action to bubble. "

I don't know how to deal with action in route :((((

Week 12, Day 5: niggling issue was a false alarm!

Turns out that i did not have to actually address the problem with displaying Ember data--Ember data is just for testing, so any logic that is needed to display Ember data should not go in the code. Fair enough! I suspected as much, but then at the last minute decided to handle the case of Ember data. But now I reverted back to the original PR code. However, my solution does not seem intuitive to the project mentor, so waiting to hear back how it can be improved. I don't know enough about Ember, or web app architecture in general, to know when something is not elegant or the wrong way to go about it. So...stay tuned!

In the meantime, I spent the day reading Piotr's (not-yet-finished) book on Ember.js. Illuminating! :)

Week 12, Day 4: resolving a niggling left-over issue from yesterday

Turns out my feature from yesterday could also be made to work for the fixture-x data created on-the-fly by the user--the way the issue title was being saved to the controller had to be done differently for fixture-0 issues than for id=num issues (i.e. issues stored in FIXTURE data in the model.js file):

In IssueRoute:deactivate: function() { this.controllerFor('issues').set('expandedIssueId', null);

this.controllerFor('issues').set('issueExists', true); //set issue title and description. Stored under _data for issues in FIXTURES, but //stored under _attributes for issues created on-the-fly

var issueId = this.modelFor('issues.issue').id; if(issueId > 0)

{ //issue defined in FIXTURE model.js file and has numeric

id this.controllerFor('issues').set('savedIssueTitle',

this.controller.content._data.title);

this.controllerFor('issues').set('savedIssueDescription',

this.controller.content._data.description); }

else

{ //issue defined on-the-fly file and has id = fixture-x

this.controllerFor('issues').set('savedIssueTitle',

this.controller.content._attributes.title);

this.controllerFor('issues').set('savedIssueDescription',

this.controller.content._attributes.description);

}

...et voilà! savedIssueTitle now can be displayed on the screen regardless of whether the issue is stored in FIXTURES or created on-the-fly.

Week 12, Day 3: going solo

Today I managed to complete the coding of a feature all by myself #MiraclesDoHappen. I was able to piggy-back off Piotr's code from the last feature. The biggest insight I got from his solution was that you can stick variables onto controllers that can then be accessed by other controllers using the needs: statement. In this way, I was able to store the particular issue title and issue description that a user wants to make an initiative for. Then, in the controller for new initiatives, I could call these two paramenters, as well as the issueExists flag. Then in the route for a new initiative, where the submit action is defined, I could differentiate between forms filled out for new issues vs existing issues:

submit: function() {

var issueExists = this.controllerFor('issues').issueExists,

_this = this,

initiative = this.get('controller.model');

if(issueExists) {

var issue = this.modelFor('issues.issue');

initiative.set('issue', issue);

initiative.save().then(function(model) {

_this.transitionTo('initiative', model.get('id')); });

}

and issueExists is also available in the new initiative template, so I could display different parts of the form using this flag, which was indeed very handy.

In doing this feature, I came to finally understand modelFor and controllerFor, and I learned that the issues controller had to be explicitly defined, with the issueExist flag declared as null, otherwise if the user clicked on "Start a new initiative" as the first thing they do in the app, the code will crash because it is looking for an issueExists property on the issues controller which has not been set yet (it eventually does get set when navigating around the issues pages):

var IssuesController = Ember.ObjectController.extend({

//declare 'issueExists' otherwise cannot "Start a new initiative" when first //opening the app

issueExists: ' '

});

When I started working on this feature yesterday, I had no clue how to start. It's just amazing how ideas can come together and result in code that works! I love it.

Week 12, Day 2: smooth day

Yesterday our project mentor asked me to make the alert more generic and today i tried to refine my code to make it. Genereally i just made a second maodal dialog in the initiatives/new template and define associated actions called openModal, clodeModal and doItModal in the routes/initiaitves/new.js file. Now both the intiiaitve.emblem and new.emblem had modal dialog and can be used seperatedly. But still have duplicated code on those actions. Not sure how Olver will comment about that.

Cathy did feature called "Posting an initiative to an exisiting issue", she successfully figure the pre-populated issue title and initiative title and descrition as well as submit button. We are quite happy about this.

Week 12, Day 1: Modal dialog

I start to implement the pop up alert by using modal dialog. Here is the step i did to implement the feature. The main idea is to render modal template into my initiative template which has clickable link "Remove support for this initiative" . The modal template should have alert message such as "are you sure to remove the support?" and "Yes" "Cancel" button which let users to choose. If users choose "Yes", then users remove the support and go back to page that they can decide to make support. If they choose "Cancel", they still stay the previous page which before they click "Remove support for this initiative".

As a result, for the modal template, it has two actions for yes and cancel. The yes action should be associated with the removeSupport action in the initiative route file. The cancel action should close the modal. So we send the yes and cancel action to the initiaitve route action which called removeSupport and closeModal action. In addition, to render the modal template in our initiative template, we need an action called openModal in our initiative route file. So in a world, 2 actions in the modal controller and 3 actions in the initiaitve route file. One modal template file and one initiative template file.

Below is the steps i did for implementing the feature.

Step 1 define the alert controller (app/controllers/alert.js)

import Ember from 'ember';

var AlertController = Ember.ObjectController.extend({

actions: { cancelRemove: function() { return this.send('closeModal'); },

yesRemove: function() { return this.send('removeSupport'); } }

});

export default AlertController;

step2: modal template (app/templates/alert.emblem)

.alert h6 Are you sure to remove? You cannot make suggestions after removing support!

.yes button click="yesRemove" Yes

.cancel button click="cancelRemove" Cancel

step3: initiaitve route which has action open, close modal and execute removeSupport action (app/routes/initiative.js)

import Ember from 'ember';

var InitiativeRoute = Ember.Route.extend({

model: function(params) { return this.store.find('initiative', params.initiative_id); },

actions: { supportIt: function() { var initiative = this.get('controller.model'); initiative.set('isSupported', true) },

removeSupport: function() { var initiative = this.get('controller.model'); initiative.set('isSupported', false); this.transitionTo('initiative'); },

openModal: function(alert, model) { this.controllerFor(alert).set('model', model); return this.render(alert, { into: 'initiative', outlet: 'alert' }); },

closeModal: function() { return this.disconnectOutlet({ outlet: 'alert', parentView: 'initiative' }); } } });

export default InitiativeRoute;

step 4: initiative.emblem

.title h2 = title

.issue_title p Issue: #{issue.title}

.description p = description

.support if isSupported a click="openModal 'alert' model" Remove support for this initiative =outlet alert else a click="supportIt" href="#" Support this initiative

.new_suggestion if isSupported = link-to 'suggestions.new' | Make a suggestion else p Note: To make suggestions for an initiative, you must first support it

h2 List of suggestions

ul.suggestions each suggestion in suggestions li.suggestion = suggestion.details else p.nosuggestion No suggestions. Be the first to write one!

=outlet

Week 11, Day 5: navigate by url

The long-standing issue of how to know what the user has typed in the url has been resolved by our remote miracle-worker Piotr Sarnacki. I had read just about every search result pulled up by Google and I have become intimately close with the Discourse source code in countless attempts to find out how they can open an issue when the user types in the issue id manually in the url (see it in action in this Ember discussion forum page)...I got lots of clues but still could not put the pieces together.

The wild goose chases were definitely worth it, but in the end it's nice to have a working feature. Piotr's solution requires a really good understanding of Ember and it will take me some time to get it all straight. But, here it goes:

The first thing that was needed was an overhaul of the app directory structure. Because we have the special case where both the issues and each individual issue are displayed on the same page (/issues), we needed the issues router to be in /routes and NOT in /routes/issues/index.js. That means the templates move from /templates/issues/index.emblem and issue.emblem to just one template in /templates/issues.emblem.

Piotr says: "In many cases, a list (i.e. model with no params) could be fetched in index (and it's often done so), but your case is kind of special, because you want to render list and do something with the list when user clicks on individual item.”

The other thing was that the toggle action to open and close an issue description is now no longer needed--this will all be taken care of by monitoring an "expandedIssueId" parameter.

Now the routes:

1. route for issues: /routes/issues.js contains the model hook for the array of issues (allowing the each loop to be run in the template):

var IssuesRoute = Ember.Route.extend({ model: function() { return this.store.find('issue'); }

2. route for a single issue: /routes/issues/issue.js contains the model hook for an individual issue:

model: function(params) { return this.store.find('issue', params.issue_id); }

and also the first bit of magic:

setupController: function(controller, model) { this._super(controller, model); this.controllerFor('issues').set('expandedIssueId', model.get('id')); }

The setupController will assign the id of an individual issue (i.e. the one entered in the url) to the variable "expandedIssueId". This variable gets set on the issues (plural) controller (why this controller?). (Confusion alert: we do not actually have an explicit issues controller in the /controllers directory, but it exists by default, so it can be assigned things even if there is no file anywhere).

So now, if the user has typed /issues/1 in the url, model.get('id') = 1 and the value 1 gets set on the issues controller via the expandedIssueId parameter.

3. route for the issues/index page: /routes/issues/index.js We use the route for the issues index page to clear expandedIssueId so that if the user goes from /issues/1 to /issues, issue 1 will close:

var IssuesIndexRoute = Ember.Route.extend({ setupController: function(controller, model) { this.controllerFor('issues').set('expandedIssueId', null); } });

Question: Why is this in /routes/issues/index.js--can it be in /routes/issues.js instead (to save the confusion of adding yet another file)?

Update from Piotr: the expandedIssueId can also be nulled in the IssueRoute instead of having to create IssuesIndexRoute to do it:

deactivate: function() { this.controllerFor('issues').set('expandedIssueId', null); }

Next, the controller.

We want to know which issue to expand. This is a display logic so it goes in the controller, and since it involves a single issue, it goes in the issue (singular) controller /controllers/issues/issue.js:

var IssueController = Ember.ObjectController.extend({

needs: ['issues'],

expandedIssueId: Ember.computed.alias('controllers.issues.expandedIssueId'),

isExpanded: function() { return this.get('id') === this.get('expandedIssueId'); }.property('id', 'expandedIssueId'),

});

There's a lot here to parse out and I'm not clear on all of it yet...

needs: used when one controller needs to access another one (c.f. http://emberjs.com/guides/controllers/dependencies-between-controllers/). In this case, the issue controller needs to know the value of expandedIssueId which is set on the issues controller.

Ember.computed.alias: I'm not sure, but I think this is used because of nested directories (http://www.ember-cli.com/#nested-directories). In any case, expandedIssueId on the issues controller is accessed here.

Update from Piotr: Ember.computed.alias is an alias to the other property. So in this case, the following code could be used instead current code without using an alias:

needs: ['issues'], isExpanded: function() { return this.get('id') === this.get('controllers.issues.expandedIssueId'); }.property('id', 'controllers.issues.expandedIssueId'),

It's just a bit more elegant to create an alias named expandedIssueId and use it instead of the full path controllers.issues.expandedIssueId

the logic: the router for issue has previously set expandedIssueId = 1 (we are still following the case where the user has entered /issues/1 in the url)), so this.get('expandedIssueId') = 1. Now we are in the issue controller for issue 1, so this.get('id') = 1 as well. That means the function "isExpanded" will return true, and we can then use isExpanded in the template to determine which issue to expand.

.property('id', 'expandedIssueId'): I'm not sure what is happening here. I think this is a way to monitor for any changes in the expandedIssueId value.

Update from Piotr: .property('id', 'expandedIssueId') is a common construction in ember.js applications. It changes a function to a property, so it can be used in a template as {{isExpanded}}. Arguments to property function are dependent keys. By default all properties are cached and will be updated only when one of the dependencies changes. So here, when either id or expandedIssueId changes, the isExpandedproperty will be recalculated to get a new value.

Lastly, the template.

/templates/issues.emblem:

h2 List of issues

ul.issues each model itemController="issues/issue" li.issue if isExpanded = link-to "issues" = title p.description #{description} else = link-to "issues.issue" this = title

So, if isExpanded is true, the description for the issue will be shown, and clicking on the issue title itself will transition back to /issues and close the issue description (because of the null defined in /routes/issues/index.js).

If isExpanded is false, only the issue title will be shown, and if clicked will transition to issues.issue which is rendered in the same page because of itemController="issues/issue" in the each loop??? We had originally used renderTemplate in IssueRoute to render the issue template in the issues template, but we removed that, so it seems a big magical here how the issue template is displayed in the issues template while also showing the /issues/id url...

If you have read all the way to the end, you deserve something nice :) Please correct anything that needs fixing, or fill in the holes in my understanding with some of your wisdom :)))

Thank you!

Week 11, Day4: alert contunue

Don't remember how long i have been stuck on writing test for the pop-up window by using confirm. According to the erro messag below

error not ok 10 PhantomJS 1.9 - Supporting an initiative "after each" hook

---

message: >

global leak detected: confirm

I disable this kind of global leak by addingmocha.setup({ignoreLeaks: true}); in the tests/units/test-helper.js. Now no error message and i start to write test and hoped to find solution. I referred to one similar test with whindow confirm. When the window.confirm return false, code seems to pass. However, when return true, it also expect all things when it is false. After i comment the window.confirm function, i found that it actually didn't test the return value. Writing test code inside of the confirm function also doesn't work. Quite frustrated by writing the test, especially when you successfully implement the feature.

The remaining day, i tend to use modal dialog, which is recommended by Oliver. It starts to work, tomorrow, i need to refine the code. Hope the code and test is smooth this time.

Week 11, Day3: One PR merged and the other to be determined

I fixed the bug on remove support and todally it was finally merged. After i submitted the PR, discuss with Oliver serval times and refine the code again and again. Finally it was merged! Feel somehow relased and happy. But the other PR on fixing bug on making suggestion via manul url needs to be decided. The bug is when user manually type url such as /initiatives/1/suggestions/new. The suggestion box and button appears together with "Support this initiative". Users can directly make suggestion without supporting the initiative.

I fix the bug with below steps:

1.defining an flag in initiatiave mdoel

2. define related action in routes/initiative.js

clickIt: function() { var initiative = this.get('controller.model'); initiative.set('isClicked', true); this.transitionTo('suggestions.new'); }

3.use click rather than link-to method in the initiative template, also moves the outlet

.new_suggestion if isSupported a click="clickIt" href="/suggestions/new" Make a suggestion if isClicked = outlet else p Note: To make suggestions for an initiative, you must first support it

I also wrote the test for it. However, Oliver didn't think that fix make sense. Let's see how it goes

Week 11, Day 2: Test non-existence of textarea and submit button

In the morining, i refined my code according to Oliver's feedback. I need to test suggestion box and submit button don't exist after user clicking "Remove support for this initiative". It indeed took me for a while to figure out how to test existence of textarea and button. I google a bit and find some similar issues, then i refer to chai document and finally find the solution

test non-existence of suggestion textarea and submit button

expect($("textarea").length).to.equal(0);

expect($(':submit').length).to.equal(0);

Now update my PR and waiting for merge.

Week 11, Day1: Pop up alert test

Last Thursday and Friday, Cathy and i attended the Frozen Rails conference, we had a lot of fun.

Today i continue with the pop-up alert test, after posting question on emberjs irc channel, i get help form kevinansfield, he or she sent me link on similar pop-up test, https://github.com/dockyard/ember-data-route/blob/master/tests/acceptance/data-route-mixin-test.js

Then i modify my code as test.js file here . But it always shows below message no matter i wrote test code inside the then fucntion or outside

not ok 10 PhantomJS 1.9 - Supporting an initiative "after each" hook --- message: > global leak detected: confirm ...

Also read one similar discussion here. But cannot figure out yet.

Trending Blogs

Recently Viewed Blogs

HelsinkiTeam