2009-07-30
2009-07-29
2009-07-26
Google Map APIの直前の検索結果を変える
Google Map APIで縮尺を変えたり、地図を写真に切り替えたりといろいろなコントローラーが付けられるわけですが、その中で場所を移動する矢印の真ん中に「直前の検索結果に戻る」というのがあります。
これの直前の検索結果とは、
savePosition
を使って保存した場所になります。
以下のような感じでクリックするとマーカーを立ててその位置を記憶させることができます。
これによって、マーカーを立てた後に地図をドラッグしてマーカーが見えなくなってもマーカーの位置に戻れます。
本当は、現在たっているマーカーの直前に立てたマーカーに戻るようにするために
マーカーを記述する前にsavePositionを発行してみたのですが、なんかドラッグすると変な位置が記録されているような感じだったのでやめてみました。
これの直前の検索結果とは、
savePosition
を使って保存した場所になります。
以下のような感じでクリックするとマーカーを立ててその位置を記憶させることができます。
これによって、マーカーを立てた後に地図をドラッグしてマーカーが見えなくなってもマーカーの位置に戻れます。
<script type="text/javascript"
src="http://www.google.com/jsapi?key={{gkey}}"></script>
<script type="text/javascript">
google.load("maps", "2.x",{"other_params":"sensor=false"});
var map = null;
function initialize() {
map = new google.maps.Map2(document.getElementById("map"));
map.setUIToDefault();
GEvent.addListener(map, "click", getAddress);
var point;
point = new GLatLng(35.6585873, 139.7454247)
map.setCenter(point, 14);
}
function getAddress(overlay, point) {
if (point != null) {
map.clearOverlays();
map.setCenter(point);
var marker = new GMarker(point);
map.addOverlay(marker);
map.savePosition();
}
}
google.setOnLoadCallback(initialize);
</script>
<body onunload="GUnload()">
<div id="map" style="width: 600px; height: 480px"></div>
</body>
本当は、現在たっているマーカーの直前に立てたマーカーに戻るようにするために
map.savePosition();
map.setCenter(point);
var marker = new GMarker(point);
map.addOverlay(marker);
マーカーを記述する前にsavePositionを発行してみたのですが、なんかドラッグすると変な位置が記録されているような感じだったのでやめてみました。
2009-07-22
jQueryでcookieを
jQueryを使うといろいろステキなわけですが、cookieの取り扱いもステキです。
利用方法は、
http://blog.4galaxy.net/28.html
を見ていただければ完璧です。
ちなみにGoogle App EngineでDjangoを使うときに便利なapp engine patchを利用しているとjQuery関連が一つにまとめられているのでcookieマネージャであるjquery.cookie.jsも同じ場所においておくことにします。
場所は、
プロジェクトルート/common/jquery/media
において
プロジェクトルート/common/jquery/settings.py
を以下のようにjquery.cookie.jsを追加します。
これでcookieが簡単に使えちゃいます。
以下のような感じです。
利用方法は、
http://blog.4galaxy.net/28.html
を見ていただければ完璧です。
ちなみにGoogle App EngineでDjangoを使うときに便利なapp engine patchを利用しているとjQuery関連が一つにまとめられているのでcookieマネージャであるjquery.cookie.jsも同じ場所においておくことにします。
場所は、
プロジェクトルート/common/jquery/media
において
プロジェクトルート/common/jquery/settings.py
を以下のようにjquery.cookie.jsを追加します。
from ragendja.settings_post import settings
settings.add_app_media('combined-%(LANGUAGE_CODE)s.js',
'jquery/jquery.js',
'jquery/jquery.fixes.js',
'jquery/jquery.ajax-queue.js',
'jquery/jquery.bgiframe.js',
'jquery/jquery.livequery.js',
'jquery/jquery.form.js',
#追加しました
'jquery/jquery.cookie.js',
)
これでcookieが簡単に使えちゃいます。
以下のような感じです。
#セット
$.cookie('attr','val',{ expires: 30 });
#ゲット
test = $.cookie('attr');
2009-07-21
google app engine pathではjQueryが組み込まれている
Google App EngineでDjangoを使うためにpatchを利用しているわけですが、settings.pyの中の
INSTALLED_APPSにjqeuryとか書いてあったのです。
これを書いておけばmediautilsでまとめあげたjavaスクリプトを読み込んでおけばjqueryも使えてしまうということなのでした。
具体的に利用できるものとしては、
プロジェクトルート/common/jquery/settings.py
に書いてありますが、以下のものが利用できるようです。
jquery.js
jquery.fixes.js
jquery.ajax-queue.js
jquery.bgiframe.js
jquery.livequery.js
jquery.form.js
jQueryも使おうかと思ったので、このjqueryのエントリも残しておくことにしました。
INSTALLED_APPSにjqeuryとか書いてあったのです。
INSTALLED_APPS = (
# Add jquery support (app is in "common" folder). This automatically
# adds jquery to your COMBINE_MEDIA['combined-%(LANGUAGE_CODE)s.js']
# Note: the order of your INSTALLED_APPS specifies the order in which
# your app-specific media files get combined, so jquery should normally
# come first.
'jquery',
・・・
)
これを書いておけばmediautilsでまとめあげたjavaスクリプトを読み込んでおけばjqueryも使えてしまうということなのでした。
具体的に利用できるものとしては、
プロジェクトルート/common/jquery/settings.py
に書いてありますが、以下のものが利用できるようです。
jquery.js
jquery.fixes.js
jquery.ajax-queue.js
jquery.bgiframe.js
jquery.livequery.js
jquery.form.js
jQueryも使おうかと思ったので、このjqueryのエントリも残しておくことにしました。
2009-07-20
google app engine patchのmediautils
google app engine patchにはmediautilsなるものが利用できるようです。
内容的には、
http://code.google.com/p/app-engine-patch/wiki/MediaGenerator
を見るのが一番なのですが、用は自分の作ったアプリケーションで利用するjavaスクリプトやCSSを一つのファイルにまとめて圧縮してくれるというもののようです。
mediautilsは最初の設定から利用できるようになっています。
関係するsettings.pyの内容は以下の部分のようです。
実際にはちょっと自分で買えている部分はあります。
テンプレートでは、
と指定して利用するようです。
追加するファイルは、プロジェクトのsettings.pyにすべて書いておいてよいのですが、各アプリケーションで個別に追加することもできるようです。
追加するjsファイルをアプリケーションのディレクトリの下にmediaというディレクトリを作って、さらにアプリケーションのディレクトリにsettings.pyを作って以下のような感じに書けばよいみたいです。
いまいち便利さがよくわかっていないのですが、サンプルでも使っているしpatchをいろいろ使うには利用した方がよさそうな気もするので、とりあえずmediautilsは使っていってみようかと思います。
内容的には、
http://code.google.com/p/app-engine-patch/wiki/MediaGenerator
を見るのが一番なのですが、用は自分の作ったアプリケーションで利用するjavaスクリプトやCSSを一つのファイルにまとめて圧縮してくれるというもののようです。
mediautilsは最初の設定から利用できるようになっています。
関係するsettings.pyの内容は以下の部分のようです。
実際にはちょっと自分で買えている部分はあります。
LANGUAGE_CODE = 'ja'
LANGUAGES = (
('ja', 'Japanese'),
('en', 'English'),
)
#ここに書かれているファイルにまとめられるようです。
#ここに纏め上げるjavaスクリプトやcssを書くようです。
COMBINE_MEDIA = {
'combined-%(LANGUAGE_CODE)s.js': (
'.site_data.js',
),
'combined-%(LANGUAGE_DIR)s.css': (
'global/look.css',
),
}
MEDIA_VERSION = 1
INSTALLED_APPS = (
# ...
'mediautils',
# ...
)
テンプレートでは、
<link rel="stylesheet" type="text/css" href="{{ MEDIA_URL }}combined-{% if LANGUAGE_BIDI %}rtl{% else %}ltr{% endif %}.css" />
<script type="text/javascript" src="{{ MEDIA_URL }}combined-{{ LANGUAGE_CODE }}.js"></script>
と指定して利用するようです。
追加するファイルは、プロジェクトのsettings.pyにすべて書いておいてよいのですが、各アプリケーションで個別に追加することもできるようです。
追加するjsファイルをアプリケーションのディレクトリの下にmediaというディレクトリを作って、さらにアプリケーションのディレクトリにsettings.pyを作って以下のような感じに書けばよいみたいです。
from ragendja.settings_post import settings
settings.add_app_media('combined-%(LANGUAGE_CODE)s.js',
'myapp/code.js',
)
いまいち便利さがよくわかっていないのですが、サンプルでも使っているしpatchをいろいろ使うには利用した方がよさそうな気もするので、とりあえずmediautilsは使っていってみようかと思います。
Google App Engine patchを利用している時にテンプレートでMEDIA_URLが取得できなかった
google app engine patchを利用して遊んでいます。
画像をおいて参照しようと思ったのです。
デフォルトの設定そのままな感じでは
/media
の下に画像をおいて
テンプレートで
<img src="{{ MEDIA_URL }}global/logo.png" alt="" />
と書いておけば利用できるようにサンプルを見るとできそうなので自分の作ったアプリでも試してみたのですが、最初は{{ MEDIA_URL }}を解決してくれませんでした。
そしてサンプルではちゃんと解決してくれるわけです。
これは、views.pyで
from django.shortcuts import render_to_response
としていたのがいけなくて
from ragendja.template import render_to_response
としないといけなかったようです。
そしてこの変更をしたら
render_to_responseを使い方も変更が必要でした。
requestを渡してあげる必要があるようです。
以下のような感じです。
画像をおいて参照しようと思ったのです。
デフォルトの設定そのままな感じでは
/media
の下に画像をおいて
テンプレートで
<img src="{{ MEDIA_URL }}global/logo.png" alt="" />
と書いておけば利用できるようにサンプルを見るとできそうなので自分の作ったアプリでも試してみたのですが、最初は{{ MEDIA_URL }}を解決してくれませんでした。
そしてサンプルではちゃんと解決してくれるわけです。
これは、views.pyで
from django.shortcuts import render_to_response
としていたのがいけなくて
from ragendja.template import render_to_response
としないといけなかったようです。
そしてこの変更をしたら
render_to_responseを使い方も変更が必要でした。
requestを渡してあげる必要があるようです。
以下のような感じです。
def index(request):
payload = dict()
payload['test'] = 'testtest'
#変更前のコード
# return render_to_response('test_index.html', payload)
#変更後のコード
return render_to_response(request,'test_index.html',payload)
2009-07-11
2009-07-08
2009-07-07
Djangoのテストケース
Djangoでテストをするときは、
python manage.py test
とすることでいい感じでテストケースを探してくれてテストをしてくれるわけなのです。
とりあえず共通的な処理をするものをプロジェクトの下に
lib
というディレクトリを作って、この中に共通処理をする関数を入れた
common.py
というのを作って、そのテストを行う
tests.py
を以下のような感じで作ってみました。
そして
settings.py
の
INSTALLED_APPS
に
lib
を追加してみたのですが、テストケースを発見してくれませんでした。
Djnagoの説明を見ると自動で発見するテストケースは
models.pyに記載したDoctestか
そのディレクトリにあるtests.py
と書いてありましたので、
libの下に
models.py
と空のファイルを作ることで発見してくれるようになりました。
共通処理をするものをこういう形で書くのが本当によいのかどうか、ちょっとわからないのですがこんな感じで進めてみます。
ちなみにどのテストケースが実行されているかを確認するには
python manage.py test --verbosity=2
とすると確認できます。
python manage.py test
とすることでいい感じでテストケースを探してくれてテストをしてくれるわけなのです。
とりあえず共通的な処理をするものをプロジェクトの下に
lib
というディレクトリを作って、この中に共通処理をする関数を入れた
common.py
というのを作って、そのテストを行う
tests.py
を以下のような感じで作ってみました。
from django.test import TestCase
from lib.common import func
class GmapHelperTestCase(TestCase):
def setUp(self):
pass
def test_func(self):
self.assertEquals('aaa', 'bbb')
そして
settings.py
の
INSTALLED_APPS
に
lib
を追加してみたのですが、テストケースを発見してくれませんでした。
Djnagoの説明を見ると自動で発見するテストケースは
models.pyに記載したDoctestか
そのディレクトリにあるtests.py
と書いてありましたので、
libの下に
models.py
と空のファイルを作ることで発見してくれるようになりました。
共通処理をするものをこういう形で書くのが本当によいのかどうか、ちょっとわからないのですがこんな感じで進めてみます。
ちなみにどのテストケースが実行されているかを確認するには
python manage.py test --verbosity=2
とすると確認できます。
2009-07-06
Google App EngineでDjangoは、helperからpatchにしてみた
http://kingyo-bachi.blogspot.com/2009/06/google-app-enginedjango.html
でGoogle App EngineでDjangoを利用するには、Google App Engine Helperが便利と書いてみましたが、
manage.py test
を実行するとGoogle App Engine Helperのテストエラーが出てしまいました。
私の環境がwindowsであることが原因な気がしつつ、そしてどっかいい感じにパスを通せばなんとかなるような気がしたりしつつ調べていたら
Google App Engine patch
という方がいい感じな気配なので切り替えました。
Google App Engine patchでは、Djangoの機能をGoogle App Engine上で使えるものが多くなっています。
Google App Engine patchは
http://code.google.com/p/app-engine-patch
から取得できます。
こちらからダウンロードしたものを解凍すれば、そのままサンプルになっています。
Google App Engine patchには、Djangoの1.0系のzipファイルも含まれているので自分でDjangoのzipファイルを準備する必要はありません。
もちろん
manage.py test
でエラーはでません。
ですが、windowsの環境でsettings.pyで
USE_I18N = True
となっていると
manage.py runserver
としたときに、gettextのワーニングがいろいろ出ます。
これを解消するには、
http://docs.djangoproject.com/en/dev/topics/i18n/#gettext-on-windows
から
gettext-runtime-0.17-1.zip
gettext-tools-0.17.zip
を取得して、それぞれを解凍して出来たディレクトリの中身を
C:\Program Files\gettext-utils
に入れます。
そして環境変数PATHに
C:\Program Files\gettext-utils\bin
を通すことでワーニングは解消されます。
単に設定を
USE_I18N = False
にするのでも差し支えはないとは思います。
これでDjangoのadmin画面とかが使えちゃえます。
かなり便利です。
デフォルトだと独自にadminアカウントを作って、そのアカウントでログインするようになっていますが、Google App Engineを使っているならば、そこいら辺はGoogleアカウントにお任せしたいところです。
その手段は、
http://code.google.com/p/app-engine-patch/wiki/GoogleAccounts
に書いてありました。
私は、以下のような感じにしてみました。
app.yamlに
として、
settings.pyのmiddlewareの部分を
'django.contrib.auth.middleware.AuthenticationMiddleware'
をコメントアウトして
'ragendja.auth.middleware.GoogleAuthenticationMiddleware'
を有効にします。
そして
AUTH_USER_MODULE = 'ragendja.auth.google_models'
AUTH_ADMIN_MODULE = 'ragendja.auth.google_admin'
も有効にします。
これで/adminにアクセスすればgoogleアカウントのログイン画面が表示されて、admin権限があるユーザのみが利用できるようになります。
そして自分が作ったアプリケーションのmodelをadminで利用するには以下のような感じです。
ここではアプリケーション名をahahaでmodels.pyにOhohoというクラスを作ったとします。
もちろんsettings.pyには記述済みというコトで。
Ohohoをadmin画面で管理できるようにするには、
ahahaディレクトリに以下のようなadmin.pyを作成します。
これだけです。
でGoogle App EngineでDjangoを利用するには、Google App Engine Helperが便利と書いてみましたが、
manage.py test
を実行するとGoogle App Engine Helperのテストエラーが出てしまいました。
私の環境がwindowsであることが原因な気がしつつ、そしてどっかいい感じにパスを通せばなんとかなるような気がしたりしつつ調べていたら
Google App Engine patch
という方がいい感じな気配なので切り替えました。
Google App Engine patchでは、Djangoの機能をGoogle App Engine上で使えるものが多くなっています。
Google App Engine patchは
http://code.google.com/p/app-engine-patch
から取得できます。
こちらからダウンロードしたものを解凍すれば、そのままサンプルになっています。
Google App Engine patchには、Djangoの1.0系のzipファイルも含まれているので自分でDjangoのzipファイルを準備する必要はありません。
もちろん
manage.py test
でエラーはでません。
ですが、windowsの環境でsettings.pyで
USE_I18N = True
となっていると
manage.py runserver
としたときに、gettextのワーニングがいろいろ出ます。
これを解消するには、
http://docs.djangoproject.com/en/dev/topics/i18n/#gettext-on-windows
から
gettext-runtime-0.17-1.zip
gettext-tools-0.17.zip
を取得して、それぞれを解凍して出来たディレクトリの中身を
C:\Program Files\gettext-utils
に入れます。
そして環境変数PATHに
C:\Program Files\gettext-utils\bin
を通すことでワーニングは解消されます。
単に設定を
USE_I18N = False
にするのでも差し支えはないとは思います。
これでDjangoのadmin画面とかが使えちゃえます。
かなり便利です。
デフォルトだと独自にadminアカウントを作って、そのアカウントでログインするようになっていますが、Google App Engineを使っているならば、そこいら辺はGoogleアカウントにお任せしたいところです。
その手段は、
http://code.google.com/p/app-engine-patch/wiki/GoogleAccounts
に書いてありました。
私は、以下のような感じにしてみました。
app.yamlに
- url: /admin/.*
script: common/appenginepatch/main.py
login: admin
として、
settings.pyのmiddlewareの部分を
'django.contrib.auth.middleware.AuthenticationMiddleware'
をコメントアウトして
'ragendja.auth.middleware.GoogleAuthenticationMiddleware'
を有効にします。
そして
AUTH_USER_MODULE = 'ragendja.auth.google_models'
AUTH_ADMIN_MODULE = 'ragendja.auth.google_admin'
も有効にします。
これで/adminにアクセスすればgoogleアカウントのログイン画面が表示されて、admin権限があるユーザのみが利用できるようになります。
そして自分が作ったアプリケーションのmodelをadminで利用するには以下のような感じです。
ここではアプリケーション名をahahaでmodels.pyにOhohoというクラスを作ったとします。
もちろんsettings.pyには記述済みというコトで。
Ohohoをadmin画面で管理できるようにするには、
ahahaディレクトリに以下のようなadmin.pyを作成します。
from ahaha.models import Ohoho
from django.contrib import admin
admin.site.register(Ohoho)
これだけです。