google maps

Showing 1-7 of 7 messages
google maps Bruce Wayne 7/25/11 4:29 AM
I have some cards that contain location information: City, State, Zip,
Country, Address. I need to include a Google map for each card
Is there a  document that gives instruction on how to integrate google
maps into the cards/wagn ?


Re: google maps rafael perez 9/5/11 11:39 PM
Hi I am new around here...
I have been trying to integrate gmaps4rails into wagn (https://
gmaps4rails is coded for rails 3, but works in 2.x.x with some

I have been stuck in including the javascript generated by gmaps4rails
in a card's view.
The javascript is generated, but never rendered, everything else works
Is there something I have to do to allow custom javascript to be

Thanks in advance
Re: google maps Rafael Perez 9/5/11 11:44 PM
Sorry...I reported this message as spam by mistake...
Re: wagn-dev + Re: google maps Ethan McCutchen 9/6/11 8:02 AM
If you are putting the javascript in a "Basic" card, try putting it into an "HTML" card instead.  Basic cards strip out certain content for security and consistency reasons, but HTML cards are mostly unaltered.  (Wagn does render links and inclusions in HTML cards)

- ethan

You received this message because you are subscribed to the Google Groups "Wagn Developers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Ethan McCutchen
One of the Wagneers,

Wagn. How pioneers roll.

s: ethan.mccutchen
t: @intogreater

Re: wagn-dev + Re: google maps Ethan McCutchen 9/13/11 12:37 PM
Hi Rafael,

Very interesting use case.  Lots of different things to respond to.
  1. You have probably already noticed that wagn is set up to use geocoding and store the results in a +*geocode card.  It's not a mature feature, and we've deliberately avoided publishing documentation for it because we don't want to support forward compatibility, but if you're curious, have a look at features/google_maps.feature to see it explained in cucumber speak.
  2. You said: "define_view renders its contents inside a <div>".  I know why you're saying that, but that's not exactly correct.  The issue is that some views are included inside other views.  In your case, "editor" is included inside the "edit" view (which also adds submit buttons).  In other cases, "naked" (which will soon be renamed to "core") is included inside content, titled, and open, all of which add different wrappers.  Therefore if you define the "naked" view for a specific set and then include the card in naked view, no <div> (or anything else) will be added at all.  I know this is poorly documented; explaining this will be central to promoting our pack API; you're on the bleeding edge now :)
  3. Just want to acknowledge the request for further code commenting.  This is a significant Wagn 2.0 goal.
  4. To get stuff in <head>, you will need to edit the *layout settings.  By default, wagn uses the "Default Layout" card, which has something like this: <head>{{*head}}</head>.  The *head card pulls in the default javascript and css among other things, so things will start looking and acting bizarrely if it's not there.
  5. Even though your map is dynamically updating cards, I don't know if the editor view is what you want.  Isn't the idea that the maps is essentially always in edit mode?  In that case, I would probably just define the naked view.
  6. FYI, in future releases we're going to be making greater and greater commitments to jQuery.  It's worth looking into ways to use that to make the server calls needed for this.
  7. The current javascript model roughly follows the rails pattern of using custom controller methods for each server call and customizing the responses there. The coming model will emphasize a very limited set of restful server calls and shift responsibility for custom handling of the results to the javascript.  That may or may not affect how you approach the problem at this stage, but I thought it might be helpful context.
  8. Most of the value of separate subcards is in visibility to wagn's query language.  The more you break things up, the easier it is to query.  It will also simplify automatic edits and generally requires less custom coding.  Any of those may be of use to you at some point in the process... 
Not sure all of that adds up to a cogent response.  But I hope it helps keep you moving forward!

- ethan

On Mon, Sep 12, 2011 at 10:24 AM, Rafael Perez <> wrote:
Gotta admit I have been enjoying wadding through your code :)

What I want, and need to do, is to display a google map in a card, the
user should be able to drop markers, find places, and generate
More or less, something like this: (click around to
see the functionality)
But, every change to the map will be saved so that the card reproduces
the map every time is it loaded (I would use autosave for that).
Basically, user puts a marker, it goes to ActiveRecord, user makes a
route, goes into ActiveRecord, etc.
Later on, the map cards should be findable by wagn search
(geolocation, marker names, places involved, etc)

So far, I have been trying to just get one map working in a new card
by overriding the editor. but I need some dynamically generated
javascript there to visualize it.
Javascript doesnt work when inside a <div>(define_view renders its
contents inside a <div> )...I am pretty sure if I put that javascript
in <head> or <body> it will work, but so far I haven't realized how to
put it there...

I am not sure if I need separate subcards, the model for the map can
contain all the information needed by itself, but hey, I am willing to
try...just point me in the right direction (some comments in the code
would be welcome :)

Anyway, I really want to integrate google maps to the idea of cards...


On Tue, Sep 13, 2011 at 12:53 AM, Ethan McCutchen
<> wrote:
> Oh, you're getting into the modules api.  Awesome!
> But are you sure you need to for this case?  If you're just combining
> javascript with other essentially static content, it might be easier to do
> this with formatting.
> In the example you pasted, it looks like you're overriding the editor.  Is
> part of the idea that you would have an editor with multiple sections?
>  Typically when we do that, we like to store the separate information in
> separate subcards.  Would that work for you?
> - ethan
> On Sat, Sep 10, 2011 at 2:42 AM, rafael perez <> wrote:
>> But what if I want something like this:
>> # wagn/.../packs/types/map_pack.rb
>> Wagn::Renderer
>> define_view ( :editor, :type => 'map') do
>>   Stuff
>>   JavaScript to render
>>   Stuff
>> end

>> On Sep 7, 12:02 am, Ethan McCutchen <> wrote:
>> > If you are putting the javascript in a "Basic" card, try putting it into
>> > an
>> > "HTML" card instead.  Basic cards strip out certain content for security
>> > and
>> > consistency reasons, but HTML cards are mostly unaltered.  (Wagn does
>> > render
>> > links and inclusions in HTML cards)
>> >
>> > - ethan
>> >
>> >
>> >
>> >
>> >
Re: wagn-dev + Re: google maps Rafael Perez 9/19/11 1:21 AM
I got it working, I put everything in the naked view and now it works.
It would be nice if javascript worked in the editor view as well. It
could be great to show a uneditable map in the naked view (markers,
routes, etc), and move to editor view to be able to change things.
Anyway, this is more than enough for now.
Thank you so much!


Re: wagn-dev + Re: google maps Ethan McCutchen 9/21/11 9:38 AM
Hi Rafael,

I'm cc'ing the dev list on my response because I think this gets to an important concept that we haven't really dug into enough as a group: what does "model" mean within Wagn.

When approaching models (in the MVC sense), there is a key difference between how wagn and more "normal" (in the idiomatic sense) rails applications: with Wagn, it's all one model.  This is the low-level corollary of the idea that everything is a card.

We've given lots of attention to the many benefits of this unified approach, both for the present and for the future.  A short list would include supporting extremely DRY (Don't Repeat Yourself) data, a very flexible query language, highly reusable interface components, a clear path towards data distribution, and expansive visualization potential.

But as often the case with breaking the mold, there are also some costs along the way.  In this case, we lose some of the benefits built-in to rails for generating new models, because we generally don't want new models in the rails sense.  We don't want new tables and new structures invisible to WQL.  In fact, the thrust of our current development is about getting rid of rails models, so that ultimately we hope there will be only three: cards, references (an optimizated store of connections between cards), and changes (card history).

That said, we clearly do want to be able to create what we might call submodels: special views and behaviors that apply only to specific sets of cards.

The API for extending wagn in this way is moving forward rapidly, but it is still a work in progress.  By Wagn 2.0, the answer to your question will be very simple: you just create a set module and use it to extend the views and behaviors of that set.  From one set module you will be able to approach all three components of MVC to extend cards in that set:
  1. model - extend and adapt methods on Card objects
  2. view - create and tweak card views, including editors
  3. controller - create and tweak actions triggered by CRUD operations on cards.

We're not all the way there yet.  The action (#3) component isn't available at all yet.  The view (#2) component is there but is currently done through Renderer classes, not through set classes, in the packs directory.  (We're going to unify those -- set modules and packs will essentially be the same thing, except that "packs" will be a wagneer level concept, whereas set module will refer explicitly to the code.)

And, finally, back to your question re models.  The good news is that models are already extended through the set module, as they will be at 2.0.   The bad news is that currently this method only works for extending one kind of set: types.  You can see examples of this in use at /lib/wagn/set/type.  All of the cardtype extensions for the types that come standard with new wagns are done in this way.

Gerry Gleason has been doing some great work on making set inclusion work for all kinds of sets (all, right, type plus right, star, etc), and this functionality will certainly be in place by 1.8, probably sooner.

In the meantime, if you really need to extend the model, the best solution is probably to try to solve your problem by creating a new cardtype and extending it as the other types.  But I would also invite you to look closely at whether you really need new model behaviors or just new views of cards.  If it's the latter, you might be able to do everything you need via packs.

- ethan

On Wed, Sep 21, 2011 at 7:08 AM, Rafael Perez <> wrote:
Hi again,

Well, I got gmaps to show on a card and I need a new model to connect to it.
I tried generating one with the generator and well, didnt work...
also I tried using  Wagn::Model::MapModel and it didnt work...
Is there anything special that has to be done for the models to work?

Ethan McCutchen
One of the Wagneers,

Wagn. How pioneers roll.

s: ethan.mccutchen
t: @intogreater