more angularjs MADNESS! ;)

51 views
Skip to first unread message

Max

unread,
Mar 27, 2013, 12:56:26 PM3/27/13
to Utah JavaScript
Hi all,

my angular project is moving along - thanks to your help and advice so
far... a new challenge has arisen!

this app is NOT a single page app, and it's built on top of rails.
we're also integrating twitter bootstrap (using angularstrap where we
need to)

I have a bootstrap modal on an html page - the page contains an ng-
repeat with iterates over a custom directive (which my coworker wrote)
and this directive basically renders a number of "widgets" (we are
calling our model widgets - they are little windows on the page that
will contain graphs or whatever down the road. they are resizeable,
moveable etc and persist)...

on each widget is a drop down menu and one of the selections is a
config option which needs to open my modal window AND, let the modal
window (which has an angular controller around it) what the particular
object is so the modal can render etc... I hope this is clear enough
so far... basically this option is configuring the data we're
attaching to the widget and all of it is pulled out of $resource from
our db model...

I have 2 angular controllers on the page. a report controller and a
dataset controller - the report controller handles the widgets, the
dataset controller has the code for the dataset which the widget is
attached to (there's a dataset_id in the widget model)

in the report controller i have an ng-click that calls:
$scope.openDataset = (widget) ->
# set dataset
# save original dataset
$('#editModal').modal('toggle')


(I know, we're accessing the DOM from our angular code, bad mojo...
has been the best option we've found so far and is very limited)

what do i need to do for the #set dataset line above to get that
modal to show the dataset for that widget and allow it to manage the
contents?

am i totally barking up the wrong tree?

Dave Smith

unread,
Mar 27, 2013, 1:34:55 PM3/27/13
to uta...@googlegroups.com
I would recommend using angular-ui's "modal" directive (not angular-strap in this case), and do something like this:

<div modal="selectedDataset">
Edit Data Set: {{selectedDataset.name}}
Put fields here to edit the selected data set
</div>

And then in your controller: Instead of this:

$("#editModal").modal("toggle");

Do this instead:

$scope.selectedDataset = widget;

The modal directive will notice that "selectedDataset" became truthy, and it will show the modal.

Inside your modal HTML, you can access the {{selectedDataset}} object.

--Dave
> --
> Group meets on the 1st Thursday and 3rd Tuesday of each month. See http://utahjs.com/location/ for more info.
> ---
> You received this message because you are subscribed to the Google Groups "Utah JavaScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to utahjs+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/utahjs?hl=en-US.
>
>

Allen Maxwell

unread,
Mar 27, 2013, 1:46:46 PM3/27/13
to uta...@googlegroups.com
Thanks, I'll check it out.

Ive been watching a youtube video about sharing stuff across controllers
using a service and broadcasting with rootScope. That actually looks very
promising (and pretty cool). May give that a shot first since I already
have some code in place to make that fly. I may try to remove my DOM
stuff with your suggestion tooŠ

THANKS!

Max

Dave Smith

unread,
Mar 27, 2013, 1:52:53 PM3/27/13
to uta...@googlegroups.com
One thing to keep in mind with broadcasting is that Angular has two ways for scopes to send messages:

$scope.$emit()
$scope.$broadcast()

$emit() sends the message to parent scopes who are watching with $on().
$broadcast() sends the message to child scopes who are watching with $on().

In short:

$emit == upward
$broadcast == downward

If your scopes are nested (not peers), this works well.

If your scopes are peers, you'll need to $emit() upward to a common parent scope (e.g., $rootScope), and then the common parent scope can $broadcast() downward.

And yes, a service can do this too. In which case, your $scope would *not* use $emit() or $broadcast(). Instead, it would call a function on your service, and the service would simply call $rootScope.$broadcast(). This will send the message to *all* scopes in your app who are watching with $on().

--Dave

Sean Hess

unread,
Mar 27, 2013, 2:42:52 PM3/27/13
to uta...@googlegroups.com, uta...@googlegroups.com

One thing I've found is when you are new to angular, you really look hard for event based data sharing, like what you're saying, but it's usually better to try to share data. 


To share data between controllers I just make a custom service, using angular.service instead of angular.factory, then the service is a singleton shared between everything. 

Just have it return an object with the property you want shared and you can bind to it in both places. If you still need events, go for it, but just know you can get data binding across controllers too. 

Sent from Mailbox for iPhone

Dave Smith

unread,
Mar 27, 2013, 3:31:04 PM3/27/13
to uta...@googlegroups.com
Agreed. In my early Angular days, I kept getting frustrated that there wasn't a common pattern for eventing between controllers. Then I realized that I usually didn't need it. Only in rare cases do I use $broadcast and $emit now.

--Dave

Randall Bennett

unread,
Mar 27, 2013, 3:36:06 PM3/27/13
to uta...@googlegroups.com
And Sean's example is really great because it's testable in the normal angular way, and it's more explicit too.

The only thing I use actual events for is socket:io stuff. I just broadcast it prefixed on the root scope, and everyone else listens for it however they want. Even that probably should be a service.

Sean Hess

unread,
Mar 27, 2013, 3:37:32 PM3/27/13
to uta...@googlegroups.com, uta...@googlegroups.com

It should definitely be a service :) 


Sent from Mailbox for iPhone


Ryan Florence

unread,
Mar 27, 2013, 3:39:36 PM3/27/13
to uta...@googlegroups.com
I think we've all learned from backbone that building an app around pubsub is the pits.

The only reason we had pubsub before was because our views weren't smart enough to be bound to the data, so we used events to keep them up-to-date.

Share data, make sure its bound when displayed, rejoice in any framework.

Dave Smith

unread,
Mar 27, 2013, 3:40:17 PM3/27/13
to uta...@googlegroups.com
On Mar 27, 2013, at 1:39 PM, Ryan Florence wrote:

> The only reason we had pubsub before was because our views weren't smart enough to be bound to the data, so we used events to keep them up-to-date.


Here here!

--Dave

Randall Bennett

unread,
Mar 27, 2013, 3:58:15 PM3/27/13
to uta...@googlegroups.com
I guess I should say this was ported from a backbone app, so I'm not a total slacker. :)

rb


Brandon Martin

unread,
Mar 27, 2013, 3:58:47 PM3/27/13
to uta...@googlegroups.com
This is great information guys! I have just barely started looking at Angular (using backbone now and have played with ember).

Thanks!

--
Brandon Martin
brandon...@gogungho.com
http://www.gogungho.com

Ryan Florence

unread,
Mar 27, 2013, 4:29:47 PM3/27/13
to uta...@googlegroups.com
> I have just barely started looking at Angular (using backbone now and have played with ember).

You have chosen the path of google reader. glwt
Reply all
Reply to author
Forward
0 new messages