JavaScript でURLエンコードする方法を何度も何度も調べてる気がするので、いい加減メモる。 groundwalker.com さんが、詳しく比較してくださっている。 エンコードする関数には、 escape(), encodeURI(), encodeURIComponent() の3種類、それぞれ対応するデコード関数 unescape(), decodeURI(), decodeURIComponent() が用意されている。 次の文字列は、http://www.aaa.jp/?text=あ ああ を escape()した結果。(JavaScriptがONじゃないと見えません)
URL設計の前段階として、とても大切なのがリソース設計です。そのWebアプリ・Webサービスで何を提供するのかが決まる部分だからです。しかし、なかなかリソースという概念が定着していないようなので、Railsで採用されているパターン*1を例に挙げて紹介してみたいと思います。 今までのシリーズ記事と重なるところもありますが、まとめということで…。 リソースとは 簡単に言うと、「URLで示されるもの」です。URLというのが“Uniform Resource Locator”の略ですからね。 http://d.hatena.ne.jp/tkawa/20110819/p1 http://d.hatena.ne.jp/tkawa/20110819 最初のものは、前回書いたブログ記事『RailsでのURL設計を考えてみる(4) スラッシュと「持っている」関係』というリソースです。 その次は、『tkawa
この間のLL PlanetsでIPv6 Hackathonとやらに参加してきた。Ruby組は僕と @sugamasao と @takano32 の3人でチーム組んだ。 RailsはIPv6でも大丈夫っぽい 大丈夫っぽいっていうのは軽くさわった程度なので断言できるほどでもないため。IPv6でRailsを立ち上げたかったら上記のように--bを指定すれば大丈夫です。 rails server --b="::" -p 3000 Unicornの場合もオプションで大丈夫。 unicorn_rails -l '[::]:3000' あとはApacheは対応してるし一応なんとかなるのではないか。Nginxとかthinは調べてないのでわからないです。あとMySQLはIPv6に対応していないらしいけど、データベースはWebサーバから見えれば大丈夫だし何とかなるでしょう。きっと。 github.comやrub
「Ruby on Rails 3 アプリケーションプログラミング」のルーティングの項をパラパラとめくっていたら、scopeを使ってtwitterっぽくトップレベル(?)にユーザ名を持ってくるようなルーティングができることを知ったのでメモ。 概要 例えばroutes.rbには次のように記述したとする。 scope ':uid' do resources :todos end このとき次のようなURLでアクセスすると、USERNAMEの部分をparams[:uid]で受け取ることができる。 http://scope-routing-sample.dev/USERNAME/todos サンプルアプリを作ってみた 早速サンプルのTODOアプリを作ってgithubに上げてみた:scope-routing-sample 次の手順で動く、はず(bundler, rvm, pow, powderが導入済み
第12回おわりに:RESTがつくる明るい未来 山本陽平,羽生章洋,和田卓人 2008-01-28
» REST 入門 目次 kwatch さんから以下のようなコメントをもらいました。 POSTとPUTの説明が逆では?たしかPUTが新規作成であり、POSTは送ったリソースの処理を指定したURIに任せるということだったと思いますが。 コメント欄では返答が書ききれなかったので、補足として新しいポストを追加します。 RFC2616 では PUT の動作が二つ規定されています。 指定した URI がすでに存在している場合 PUT はその URI のリソースを修正(更新)する 指定した URI が存在しない場合 PUT はその URI のリソースを新規作成する PUT を規定している 9.6 節には POST と PUT の違いとして以下の記述があります。 The fundamental difference between the POST and PUT requests is reflect
久々にCatalystをインストールして、ロジックを書くときのアトリビュートでArgs(0)というのが増えていることに気づきました。 このArgs()で自分が今分かっている事を下記にまとめます。 Args()を設定したメソッド名プラス設定した数値の引数の数のURLにアクセスした場合、ディスパッチ制御ができる メソッド名以下を$c->arguments->[0]とかで取得できる まだこれぐらいしかわかってません。 perldocに書かれていますが、sub bar :Localをfooクラスに書いた場合に、/foo/bar/のURLでアクセスできますが、場合によっては、/foo/bar/はダメで/foo/bar/hoge/とかは許可した場合などにArgs(1)とかを使うといいみたいです。 なんだか、Regexアトリビュートとかでも似たようなものはできそう(??)ですが、Args()のほうが手軽
Catalyst::DispatchType::Chainedを使うとスッキリしたURLで組める。 似たような事はRegexやLocalRegexでも出来るけどこっちの方が重複するようなコードが軽減できる。 Chained属性に指定したPrivate Names(コントローラーのメソッド名)を使って処理をつなげる事ができる。 例えば以下のURLを処理するとき、処理はこうなる。 http://example.com/users/1/books/2 /users/1は共通してユーザの検索 その後に続くbooks/2はそのユーザのIDが2の本を表示 基本 では早速、以下の様なURL群を設計 /add /* /*/edit /*/entries/* /*/entries/*/delete CatalystのControllerの実装はこんな風になる。 # [CAPTURE] / sub root_
http://d.hatena.ne.jp/r7kamura/20110505/1304577667がすごいなと思って、routes.rbの書き方の例についてコメントしたのですが、自分で書いておいて後で「unfavorite」はちょっとまずいかなと思ったので、favorite(いわゆるお気に入り、スター)はどういうふうに設計すればいいのか考えてみました。 構造はよくある感じの、 tweet has_many favorites user has_many favorites 任意のツイートに任意のユーザーがお気に入りをつけられるというもの。別にツイートじゃなくても何でもOKです。 ブログのコメントにはこのように書きました。 (1) resources :tweets do member do post 'favorite' post 'unfavorite' end end ルーティングは
Location時にフラグメント識別子を付けられるのか? d:id:maru_cc:20080207:1202385497 こちらがRFC的にどうなっているのか調べてみた。 確信は持てないがおそらく、RFC的にNGということでいいのかな? まず、#XXXと書くのの正式名称がわからなかったので調査。 http://www.7key.jp/rfc/2396/rfc2396_4.html#li28 4.1. Fragment Identifier URI参照が識別されたリソースの取得動作を行う際、URIを"#"で区切ることによってフラグメント識別子を任意で付けることができる。フラグメント識別子は、リソースの取得動作が成功した後にユーザエージェントが解釈する付加的な参照情報である。このため、フラグメント識別子はURIではないが、 URIと共に用いられることが少なくない。 フラグメント識別子と言うら
URI.encodeだっけCGI.escapeだっけ、そういえばuってaliasなかったけとなったので ソース見てみました。 結論 こちらで議論されているように、CGI.escapeとERB::Util.uでは挙動が異なります。 ruby -r cgi -r erb -e 'puts CGI.escape("a b"), ERB::Util.u("a b")' $ ruby -r cgi -r erb -e 'puts CGI.escape("a b"), ERB::Util.u("a b")' a+b a%20b 基本は、ERB::Util.uでいいのかな。(Railsのviewで使うならuでok) CGI.escapeの方が早いらしいのでこの差を意識しない場合のみCGI.escapeでしょうか。 ソース抜粋 URI.encode 使っちゃダメです。 obsoleteでした。 #1.9.
URL Design [ad#ad-2] 下記は各ポイントを意訳したものです。 はじめに URLを設計する理由 トップレベルのセクションは重要 URL構造を増強する方法 クエリの文字列 URLにはASCIIを URLは検索エンジンのためにではない URLは合意 全てがURLを持っているべき リンクはリンクらしく 再利用できないURL 素晴らしいURLの例 おわりに はじめに あなたは、URLの構造を設計するのに時間をかけるべきです。この記事を読んだ後で、あなたに一つだけ覚えておいてほしいことは、URLの構造を設計するのに時間をかける、ということです。 URLデザインは簡単ではなく、正しい解決方法があると言うことはできません。しかしそれは、他のデザインと同じです。良いURLデザインがあり、良くないURLデザインがあり、そしてその中間もあります。 しかし、それは素晴らしいURLデザインを作るこ
このブログはlifehackerを含むgawkerメディア系サイトの#!URLへの移行を批判している。 http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs/ 以下、isolaniとテングの見解をごっちゃ混ぜに紹介する。 lifehacker他のgawkerメディアサイトが数日前に長時間におよびアクセス不能になった。(厳密に言うとページ内のコンテンツアクセス不能になった) #!URLベースのサイトはJavaScriptにエラーがあるとコンテンツが一切ロードせずのっぺらぼう状態になってしまうようだ。 #!について 「#!」は何で呼ぶの? shebangと綴られる。 Hash=# Bang=!の略 発音すると「シバン」といったところか。(ちなみにUnixの#!とは無関係) 以下「#URL」は: サイト内のロケーション情
私、メシマズ嫁スレを笑えないくらい料理音痴なので、マルチビタミンの利用を決めました。筋トレという点は、思っていた以上に助かりました。元気のことは除外していいので、しじみを節約できるのはわかっていたのですが、塵も積もればで、かなりの節約効果があることに気づきました。肝臓の半端が出ないところも良いですね。ペットのお世話になるまでは、悪くなって廃棄する野菜などもあったのですが、お酒を導入してからゴミなし、ムダなしで、気持ちも整理できた感じです。オルチニンで提案されなければ自分では作らなかったであろうメニューも多いです。肝臓の献立はバランスが良いのもあって、食べごたえがあります。サプリメントに頼るなんてどうだろうと思いましたが、導入して正解でした。 料金が安いため、今年になってからMVNOの改善に切り替えているのですが、薬との相性がいまいち悪いです。肝機能は簡単ですが、オルニチンに慣れるのは難しい
December 28, 2010 URL Design You should take time to design your URL structure. If there’s one thing I hope you remember after reading this article it’s to take time to design your URL structure. Don’t leave it up to your framework. Don’t leave it up to chance. Think about it and craft an experience. URL Design is a complex subject. I can’t say there are any “right” solutions — it’s much like the
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く