iPhone OS3.0にしたらiPod touch 2ndでもBluetooth使えるようになったよ

OSアップグレードして速攻試したら，無事 DR-BT140Qとペアリングできた。これはスバラシイ。
ただ，SBT01WH(asin:B001GIPZZU)と違ってAVRCP未対応なのか，曲送りは出来なかったけど，そんなことはどうでもいいや。
→ ついカッとなってiPod nanoをBluetooth化してしまった。 - marsのメモ

SONY オープン型ワイヤレスヘッドホン Bluetooth対応 マイク付 耳掛け式 ブラック DR-BT140Q/B

タグライブラリの変態っぷりに茶ぁ吹いた（ほめてる）

feedsプラグインを使ってて発見したのだが，まずはこのコントローラのコードを見て欲しい。

def feeds = {
  render(feedType:"rss", feedVersion:"2.0") {
    title = "My test feed"
    link = g.createLink(controller:"blog", absolute: true)
    Blog.list().each() { blog ->
      entry(blog.title) {
        link = g.createLink(controller:"blog", action:"show", id:blog.id, absolute:true)
      }
    }
  }
}

注目は「g.createLink()」。なんぞこれ？と思ってみたが，答えは簡単，GSPのcreateLinkタグだった。
どうやら，GSPのタグライブラリはコントローラからも使えるらしい。そりゃ，どんな裏技だと思いリファレンスひいてみたら，それっぽい記述を発見。

Tags within namespaces can be invoked as methods using the namespace as a prefix to the method call:

out << my.example(name:"foo")

This works from GSP, controllers or tag libraries

6.3.5 Tag Namespaces - Grails Framework Reference Document

要するにタグライブラリはGSPやコントローラ内でメソッドとしても利用できるそうだ。JSPのtaglibがFunctionsも兼用しているって感じなんだろう。だから，下記の２つは同じ意味になる。
＃標準タグの場合，GSP中ではネームスペース 'g' は省略できるみたい。

<g:createLink action="show" id="1"/>
${createLink(action:"show', id:"1")}

試しにコントローラ内で「println g.class.name」とかってやると，こんなのが返ってきた（独自タグを作った場合は，gをそのタグのネームスペースに置き換えると良い）。

org.codehaus.groovy.grails.web.taglib.NamespacedTagDispatcher

だから，コントローラからもユーティリティ的にタグライブラリを利用することができるわけだ。リファレンスに書いてあるくらいだから，当たり前に使って良いんだよね。つか，これ便利すぎるよ，ママン！！:-)

ちょうどJSON形式で複数をHTML片を返したいなって思ったんだが，コントローラのrender(template:〜)じゃ実現できないのに気付いたワケ。だって，これ戻り値無いでしょ。かといって，MarkupBuilderでHTML片作るのもたるくてJSONで返すの諦めてたんだけど，この方法知って，あっという間に解決した。
つまり，こんな風に書けば，複数のテンプレートを束ねることができるのだ。

render([main: g.render(template: "main_tempalte",
                       model: [foo: foo, bar: bar]),
        sub: g.render(template: "sub_template",
                      model: [hoge:hoge])] as JSON)

↑ちょっとわかりづらいけど，renderタグをメソッドとして利用している（g.render(〜んとこ）。むろんテンプレの中にはGSPタグを使ってたって構わない。この超便利さ，わかってくれるかしら？

ちなみにサービスではこの方法は使えないので，このリンク先にあるようにGroovyPagesTemplateEngineを使うらしい。試してないからアレだけど，例えば電子メールのテンプレにGSPを使いたい場合などに使えるようだ。
→ Grails – Rendering a Template from a String | Disgruntled Developers

あと，AcegiSecurityプラグイン使ってんだけど，これもいくつか便利なタグがあるんのね。たとえば，ログインしてる時だけ評価されるような，g:isLoggedInタグとか。

<g:isLoggedIn>
ログインしてると，ここが表示されるス
</g:isLoggedIn>

もちっと器用に「ログインしてて，かつ自分のものだったら評価する」みたいな条件付けも，今回の件で解決した。Acegiにはログインしているユーザ名を出力するg:loggedInUsernameってタグがあるんで，これを使ってこんな感じにするとできた。

<g:isLoggedIn><g:if test="${loggedInUsername() == account.username}">
ログインしててかつ，accountが自分のモノなら，ここが表示される。
</g:if></g:isLoggedIn>

わはは。融通利きすぎて笑える。Grailsって発想が斜め上を行きすぎてて，もうJSP使えないかも知んない。:-P
＃あわせて読みたい。→ うぬはまだEL（式言語）の本当の恐ろしさをしらぬ - しんさんの出張所 はてなブログ編

ps.
どうやらタグライブラリをメソッドとして使った場合，out変数に突っ込んだ内容が戻り値となるようですね。あと当然，タグボディは評価されない。
LogicalタグやIterativeタグがどう評価されるかは試してないけど，無理に試すもんでもないか（必要になったら確認してみる）。

• • • -

2009.06.20 追記：
ついてる時はどこまでもついているのぅ。
→ groovy - Grails link taglib use outside of GSP - Stack Overflow

タグライブラリをメソッドとして評価した場合，タグボディはキーワード無しパラメタかクロージャで渡せば良いんだそうな。なので，

<g:link controller="foo" action="foo">text of the link</g:link>

は，こんな風に書ける。

g.link(controller:"foo", action:"bar", "text of the link")
g.link(controller:"foo", action:"bar") { "text of the link" }

タグライブラリのシグネチャが

def tagname = { attrs, body -> ... }

なので，なるほどと言えばなるほどな答え。

GrailsをサポートするIDEは，こいつを実装してくんなきゃ泣いてやる

NetBeansのGroovy/Grailsサポートは相当デキが良いと思うデス。IntelliJもGORMのER図書いたり相当スゴイことしてくれる。
→ Features - IntelliJ IDEA

でも，GORMのER図が見えたり，コード補完ガンバってる事より何よりも便利だったのが，これ。導入しているプラグインのソースを参照できることだったりする。:-)

「そんなこと？」と言う無かれ，Grails1.1からプラグインの場所が$PROJECT_HOMEから見えない場所に移ってしまったので「アレなんだっけ？」って気楽に参照しづらくなったのだよ。プラグインの使い方は，なんだかんだでコード読むのが一番の近道だしね。

試しにNetBeans 6.7RC2でも確認してみたんだけど，プロジェクトウィンドウとかに使っているプラグインは見えなかったね。せっかく上等なプラグインマネージャ持っているだけに，すごく惜しいとオモタ。

次の理由でGrailsはオススメしない

一通りGrailsを使ってみて，ほぼ確信に近い手応えを感じたので，一応書いとく。まったくもって余計なお世話様なのは百も承知。

Grails使っちゃダメ，ゼッタイ

って，主にJavaでEclipse使った開発に慣れているチーム向けの話ね。:-)
その理由はこんなの。

• Eclipse, NetBeans, IntelliJの中で，Groovy/GrailsサポートはEclipseが一番うんこ
• 動的言語なんで，ちょっとしたtypoにハマる
• リファクタリングするなら覚悟を決めろ
• あと，日本語の情報が超少ない

ホットデプロイだけだったら，Eclipse+Dolteng+Seasarで十分サクサク開発できるので，それだけじゃGrailsを使う利点にはならんよね。あえてGrailsの利点を挙げるとすれば，プラグインかな（最近では，Grailsのウリはこいつだと思ってる）。
仮にEclipseに興味のない（Javaの素養がない）LL使いの人だったら，Groovyの根っ子に流れるJavaの制約に拒絶反応起こすと思う。あれはLLの皮を被ったJavaだかんね。

そう思うとGrailsって誰向きなんだろうって思うワケ。って，あれ？そんな話，前も言ったな。

当然，上記の項目なんぞ屁でもねぇって人たちには当てはまらないのでご安心（？）を。あたし自身「Grailsダメ，ゼッタイ」って人には言うけど，自分は好きよ，Grails。やりたいことすぐ出来るし，なにせIntelliJ使ってるし。:-D

もし，あなたがJava屋で，社内SEとか開発プロジェクトの下回り役で，誰も頼れず，それでも気楽に「こんなのちょちょって作って〜」と頼まれるようだったら，Grailsは超オススメ。ホントにちょちょって作れる。
＃いや，そんなことする前に「ふざけんな，このクサレ○○！！」とぶち切れるのが先だよね。:-P

ps.
マジメな話。IDEのパワーをフル活用できるJavaの生産性ってバカにできないものがあるのよね。IntelliJだってGroovy/GrailsよりJavaでこそ威力を発揮する機能いっぱいあるし。ちょっともったいない感は否めんよな。:-(