らどくら通信 |
|
Web開発ツールその他について、あるいは無関係でも、たうら＋うらのの興味がある話題、
あるいは興味がない話題(ないのか！！)、
開発現場の生の声、カスタマーの不倫事件等(ありません)などなどを載せていきます。
あと、文書の更新履歴もこちらです。 |
● 2006/12/31 (sun)
なんでや！なんでなんや！と両方のXML(SpringのapplicationContext.xmlとJSFのfaces-config.xml)
のタグの並び順やなんかを変えてみましたがうまくいきません。
JSFをSun RI 1.1を使っているためかしらん？と思い、Sun RI 1.2をダウンロードしてみましたが、
バージョン1.2のバイナリ配布はなんとJRE 5.0でないと動かせないみたいです。
つまりそろそろJRE 1.4 + Tomcat 5.0の環境を卒業して、
JRE 5.0 + Tomcat 5.5の環境をこの冬休み中に作らざるをえないしか。
とりあえずこの問題は、「Beanは極力Spring側で定義する」という超解決策で回避できるので、
勉強するぶんにはもう少し勉強しようと思います。
● 2006/12/30 (sat)
ということで、頑張れば実システムに適用もできそうですが、
バックエンドが強い代わりにプレゼンテーションに弱い気がします。
そこで巷でよくやられているらしい、JSF(Java Server Faces)との統合ということになるのでしょう。
次はそれをやってみます。
● 2006/12/23 (sat)
Jython(Python)は、クラスのインスタンス変数やメソッドにアクセスする際に、
必ずself.とつけないといけません。つまりJavaでいうthis.に当たるキーワードが省略できません。
一方ローカル変数は宣言せずに何でもいきなり代入できます。
Groovyは逆です。this.はJavaと同様省略可能です。
しかし、ローカル変数を使う前に一々defで宣言しないと代入できません。
慣れればどってことないのだと思いますが、
両者を少しずつ使い始めると面食らうことしきりです。
● 2006/12/22 (fri)
両者は何が違うかというと、iTextがJava APIで印字内容を1つずつ書いていく代わりに、
JasperReportsはそれらの設定をXML文書に定義しておき、
それを読み出して出力を生成するという感じです。
というかiTextを少し使うと誰しもそういう方向で拡張したくなるのは山々、
自分でそういう物を作り始める前に、
キチンとしたオープンソースのソフトウェアが既に公開されていると知ったことは、
大変よかったことです。
● 2006/12/17 (sun)
・記述が少なく、早く作れる
・クラスのコンパイルが不要(Eclipse等を起動する必要がない)
・Webアプリケーションも再起動の必要がない
という利点があります。使う言語処理系はBSF(Bean Scripting Framework)
でサポートされているものなら何でもいいのですが、
スクリプトで書いた物を本格運用する際には通常Javaで書き直すと思うので、
文法がJavaに似た言語、例えばJython(Python)、Rhino(JavaScript)、そして勿論Groovyなどを使うのがいいでしょう。
また、Form BeanやレコードBean(いわゆるValue Object)等はスクリプト言語では書けないみたいでこれは残念。
またScriptActionという専用のActionクラスを使うので、
Actionを既に何らかの自前のフレームワークとして拡張している場合、
その中に組み込むと他の画面との動作の整合性がとれない可能性も高いといえます。
● 2006/12/16 (sat)
CASE式を使って、縦横2次元の集計表が簡単に作れるので、
このSQL結果をそのまま画面に表示すると簡単にそのようなWebシステムが作れます。
以下の例は車の種類ごとに総数、完成済、製作中の台数を表示する、というのを想定したものです：
SELECT CAR_TYPE, COUNT(*),
SUM(CASE WHEN STATUS='KANSEI' THEN 1 ELSE 0 END),
SUM(CASE WHEN STATUS='KANSEI' THEN 0 ELSE 1 END)
FROM CAR_SEISAKU
GROUP BY CAR_TYPE;
おーコレは簡単。列ごとに3回SQLを発行する手間も、
ホスト言語(呼び出し側)で行数を1行ずつ数える必要もありません。
● 2006/12/10 (sun)
● 2006/11/04 (sat)
原因は、要件定義をユーザと詰めていて、
やはり一度決めた帳票様式をずっと使うのではなく、
最初に作ったものを要求に応じてType2、Type3と派生させて、
様々な場合に対応できるように何種類かテンプレートを用意したいという話があり、
それならばExcelでテンプレートフォームを作っておいて、
アプリケーションでそれに値を埋め込んでいく、つまりExcelで出力するのが一番早道ということになりました。
また、iTextを使っていて思ったのですが、
何十種類も必要な帳票様式ごとに、
数値の右寄せ、カンマ区切り等の各印字フィールドの書式設定を、
GUIではなく全てJavaプログラム上で書いていくのは、やはり精神的にキツイです。
そんなわけで、JavaのサーバーアプリケーションからExcelを出力するというと、
過去何度か話が出て立ち消えになったJakarta POIの出番ということになりましょう。
それで今回問題となったのが、従来POIではセルに「100」などの値がじかに入っている場合にそれを取り出すのはとても簡単なのですが、
「=C13+C14」のような参照式(Formula)が入っている場合、
その式(C13+C14という文字列)ではなくて、計算した結果の値を取得することができない、という点です。
気になってWebで検索したところ、メーリングリスト等で
「だからPOIは駄目なんだ。jexcelapiの方が機能、パフォーマンス、メモリ効率全てにおいてお勧めだヨ(意訳)」
等のやりとりを見ていて、そうそうjexcelapiという同様のオープンソースのライブラリがあることも最近知りましたが、
それはそれでリスキーじゃあるまいか？ということでさらに調べてようやっと分かりました。
現在Jakarta POIの3.0-alpha1というのが完全なαリリースですが出ていて、
その中にさらに「poi-3.0-alpha1-scratchpad.jar」という超実験的APIのライブラリが入っており、
これを使うと式の参照が可能だということを！！
試した結果、最初は出まくるんです。NullPointerExceptionが！！
やっぱ駄目やん！！とソースも入手して調べたところ、何とか簡単な式ならばその結果の値を取得できることが確認できました。
ドキュメントを簡単に斜め読みしただけですが、
Excelでは式は内部的に逆ポーランド記法で格納されていて、
多分POI内部でそれらを計算して結果を出しているのだと思います。
● 2006/10/14 (sat)
● 2006/09/23 (sat)
現在職場のシステム開発では、
枠線や印字フィールドなどの帳票設計がGUIでできるベンダー製品を使っています。
これは、1キーレコード1帳票の固定様式での大量出票
(いわゆる伝票と呼ばれる種類の業務帳票)
の場合は大変生産性がよく重宝していますが、
よくある「社内用部門別売上一覧表」のようなあまりに単純な帳票の場合は、
帳票サーバとの連係の仕組なども必要な分、
逆に開発効率に不満がありました。
印刷データだけ渡せばローカルで出来合いの枠線を引いた中に印字フィールドを埋め込んでいけば、
PDF文書が出力される、というAPIを提供するライブラリはないかしらん？
ということで、今回の目的にiTextはぴったりでした。
ただし心配なのは、複雑な枠線、細かいフォントや位置指定を要求される帳票だと、
処理を共通化・再利用できず、
APIでミリミリ書いていかないといけないので、GUIの製品より、
逆に生産性が落ちそうなところです。
印字位置や枠線に対するこだわりがどこまで微細に必要な帳票であるかによって、
どちらを使うかを要件の早い段階で決めることがポイントになりそうです。
● 2006/08/15 (tue)
● 2006/08/11 (fri)
● 2006/08/05 (sat)
Linux PCの電源をなかなか入れなくなってしまったので、
同じファイルをコミットせずに数回続けて編集してしまうことが増え、
履歴管理の役を果たさなくなってきたためです。(-_-)
開発ツールの利用法を家で勉強するという目的には、
共有利用を想定したリモートのサーバを立てる方がずっといいと思いますが、
本来の役を果たさないのでは仕方ありません。
当面頻繁に更新するファイルは「ひとりSubversion」、
あまり更新しないファイルはLinux PC上に(CVSの代わりに)Subversionのサーバを作り、
コマンドラインでの操作はこちらで勉強しようと思います。
● 2006/08/04 (fri)
が、検索エンジンでWebを探しても、
Form Bean Definitionsにワイルドカードが使えるかどうかを書いているページは見つからなかったので、
何でも調査隊は実際に試してみました。
結果。使えません(号泣)。
新しい画面を追加すると、Form Beanの定義だけは必ず書き足さないといけません。
これは残念無念。
● 2006/08/02 (wed)
● 2006/07/18 (tue)
● 2006/07/15 (sat)
● 2006/07/08 (sat)
● 2006/06/15 (thu)
● 2006/05/25 (thu)
今までよく似たActionクラスで、呼び出すSQL文だけが違うようなものは、
問合せのIDをset-propertyで渡すことで共通化を図ることができます。
また1.2から1.3への移行もさほど難しくなく、ある程度決まった手順で移行作業ができるようです。
今度それをメモして上げてみようと思います。
● 2006/05/21 (sun)
バージョン1.3では1.2とほとんど互換性を保っていろいろ拡張が行われており、
中でもSpringなどのDIコンテナに影響を受けたと思われる便利機能が2つ追加されています。
便利機能の1つめは、struts-config.xmlのActionマッピングで、
set-propertyタグを使ってActionクラスに外部から(DIで)プロパティを設定することができるようになった点で、
従来のparameter属性を使う方法から大きくActionクラスの再利用化、疎結合化が推進されます。
2番目はstruts-config.xmlの記述が長くなるという従来の欠点を軽減するもので、
他のActionマッピングなどの定義を流用して、一部を書き足す、
つまりOO言語でいう継承みたいなことができるextends属性です。
これらは今まさに私が丁度ほしかった機能どもで、
Java Server Facesが定着するまで当面DIコンテナ要らずで
Struts 1.3一本で生き抜けることができるかもしれません。
● 2006/05/06 (sat)
それで、StrutsとSpringの連係ということでstruts.apache.orgをいろいろ探しているうちにやっと気がついたのですが、
JSFとSpringの連係ということならShale Frameworkがまさにそれをやっています。
従って、JSF+Springを自分でやるのと別に、Shale Frameworkの勉強もぜひやってみようと思います。
いろいろ手を出すと大変ですが…
● 2006/05/05 (fri)
実際は、簡単な検索画面を作っただけですが…
それで現在は、Spring MVCを一式完全に利用しているわけではなく、
ViewはJSF、Beanを探したりDBアクセスをしたりする部分をSpring、という使い方にしています。
Strutsに比べてJSFやSpringを使うと、
疎結合化、部品化、再利用化というよく言及されるメリットを確かに享受できます。
しかし、この使い方だとJavaコードの他に、JSFのBean定義(faces-config.xml)
とSpringのBean定義の3つを整合をとって管理していかなければいけません。
また何でもPOJOということは、どのクラスにどの機能を持たせ、
相互のBeanの依存性をどのように定義するかが自由に決められる反面、最適解を探すのが難しいです。
最適解があるのなら、それをもう一段フレームワーク化しないといけない感じです。
とりあえず現在は、
「画面から直接メソッドを呼ばれたりするViewに直結したManaged Bean(JSFで管理)」
→ 「検索入力項目などを持つBean(JSFで管理)」
→ 「DB接続情報などを持ちDBアクセスを行うBean、いわゆるDAO(Springで管理)」
という依存関係にしています。
このあたり、仕事でいろいろ教えてもらっている開発者の方に今期相談してみようと思います…
● 2006/04/25 (tue)
● 2006/04/22 (sat)
Strutsの勉強を始めた時を思い出してしまう同じ展開ではありますが、
SpringはStrutsよりもずっと入っていきやすいと感じました。
そのわけは、Springの一部みたいなお手製ライブラリを半分作っていたからで、
つまりデータベースの接続情報や実行するSQLをXML文書に書いておき、
これをBeanのリストに読み込んで、JDBC経由でSQLを発行し、結果集合をレコードBeanのリストにして返す。
という一連の処理は、Springでもほとんど同じ、より強まった仕組が提供されているので、
お手製ライブラリをSpringでAPI単位で置き換えていくということで導入ができそうです。
しかもそれをWebアプリケーションに適用する際のやり方も、
ContextLoaderListenerという、サーブレットリスナーの実装クラスでアプリ起動時にXML文書を読んで、
ServletContextに覚えさせておくというのも同じなので分かりやすくて良いです。
逆にJ2EEにおけるトランザクション管理などは全然理解していないので、
Springを手本にこれから勉強をしようと思います。
また、現在はStrutsと一緒に使うためのtipsという話題が多いようですが、
StrutsとSpringではMVCのCの部分で競合している面もあります。
今からStrutsとSpringの統合を図るくらいなら、JSFとSpringの組み合わせを考えた方がいいのかな？
という気がします。
● 2006/04/16 (sun)
● 2006/04/13 (thu)
共通化可能な汎用関数のライブラリを作っているのですが、
BBB.jsを使うためにAAA.jsが必要、ということはよくあります。
しかし、BBB.jsの冒頭に「AAA.jsをインクルードする」という指令を書く方法が分からず、
現在は必要そうな関数の.jsファイルはとりあえずJSPのヘッダ部に全部書いておく、
という方法でやっていますが…現在うまい解決法はないか調べているところです。
● 2006/04/12 (wed)
(1) テーブル状に表示したとき、各行の左端にチェックボックスをつける方法が分からないので、
レコードを削除するアプリケーションが作れない。
(2) CachedRowSetに対して一度手動でカーソルを回さないと行数が分からないので、
「＊行のデータが見つかりました」という表示ができない。
(じゃあやればいいだろうという話なんですが、そんな汚いのは嫌だ〜！！)
ということで、当面はStruts時代によくやったのと同じ、
結果集合をBeanのListに保持する方法です。
各行をBeanにマップするのはJakarta DbUtilsを使ってもできますし、
私はお手製のライブラリを作っており、これを当面使うことになりそうです。
CachedRowSet#acceptChanges()で一発更新の夢が〜〜〜まだ先は長いです。
● 2006/03/26 (sun)
● 2006/03/25 (sat)
Webを検索すると幾つかサンプルが載っているので、真似て作るだけの話ですが、
一応動作を確認できました。
が…
JSFはバリデーションエラーになった際のエラーメッセージをどうやって生成するか、
という仕様がStrutsより自由度が高く、その分面倒なように思います。
● 2006/03/24 (fri)
● 2006/03/18 (sat)
● 2006/03/12 (sun)
Derbyでは、データベースのホームディレクトリ
(=JDBCのURLでデータベースのパスを相対パスで指定されたとき、起点となるディレクトリ)
を指定するのに、derby.system.homeシステムプロパティで指定する必要があります。
Webアプリケーションが1つならいいのですが、2つ以上ある場合、
異なるWebアプリケーションに異なるホームディレクトリ、ということができるのかが謎です。
そんな変なことをしなければ良いということなんでしょうけど…
しかし、サンプルアプリケーションとして可搬性を保つには当然、
データベースのディレクトリはWebアプリケーションのディレクトリの中に入れる形になるので、
アプリケーションごとにデータベースのホームは変えざるをえません。
これが解決できないと、DerbyではNetworkServerは自分で起動すること、
という方式にしないといけないかなあと考えています。
● 2006/02/25 (sat)
それで初めて知ったのですが、EL式内ではrequestやsession等は暗黙の変数として定義されていないんですね。
(requestScopeやsessionScope、pageContextは定義されている)
そのため、requestオブジェクトをEL式内で参照しようとしたら、
requestではなくて、pageContext.requestと書かないといけません。
● 2006/02/22 (wed)
● 2006/02/19 (sun)
● 2006/02/11 (sun)
● 2006/02/10 (sat)
hsqldbの方は一通り、起動・停止とJDBCでの接続方法を確認できました。
Webで検索して、
ServletContextListenerを使ってWebアプリケーションの起動・停止に連動して
hsqldbサーバープロセスの起動・停止を行うサンプルを載せておられる方がいたので、
参考に早速やってみるとうまくいきました。
Derbyはやっと、Embedded(スタンドアロン)モードでのコマンドラインツール「ij」
の使い方を覚えたところです。先は長い！ぜえぜえ。
● 2006/02/04 (sun)
● 2006/01/21 (sat)
● 2006/01/18 (wed)
そこで各紹介ページを読んで見た所…
・Commons EL…JSP 2.0で定義されている式言語(EL)のインタープリタ実装。
・Commons Jexl…Velocity開発の過程で得られたノウハウをもとに、
JSTLやJSPの式言語(EL)を拡張した式言語。
・Commons Jelly…VelocityやCocoonに影響を受けたXMLベースのスクリプト処理エンジン。
(VelocityやCocoonが専らHTMLを生成するためのテンプレートエンジンなのに対し、
Jellyは普通のプログラミング言語のように普通の処理がいろいろできるらしい)
動的な値の出力にJexlを利用している。
ということですが、Commons ELのドキュメントにはサンプルが全くありません。
ソース配布をダウンロードしてみましたが、ソースの中にも使い方サンプルはありません。
むむ、これは本当にJakarta TaglibsのJSTLの実装であるstandard taglibのソースを見れ、
ということなのかと思ってみましたが、理解できません。(号泣)
ということで、ELは諦め、次にJexlに行きますが、
こちらもJakarta Commonsのインデックスページ
の紹介を見ると、ELを拡張したのがJexlだと読めるのですが、
今度はJexlのホームページに行くと、
「JexlはJSP 2.0仕様と完全に互換性があるわけではない」
と書かれていて、なんだか全然分かりません。
しかしJexlの方は紹介ページにもドキュメントにもサンプルが豊富で、使いやすそうです。
というところまで見たところで、
開発の事情でフィルタを使わなくてもよくなりそうなので、中断ということにしました。
● 2006/01/15 (sun)
私が使おうとしたのは、「Lead Time」の意味でltと名づけたプロパティです。
素直にleadTimeと名づけることにします。(シクシク)
● 2006/01/03 (tue)
undefined symbol: sqlite3SelectDelete
ここに報告されている通りの現象で、
これはもう少し待つしかないですね。とりあえず、今日確認したところまでを改訂して載せてみました。
● 2006/01/02 (mon)
年末年始にちょっと取り組んでいるねたは、
Oracleの配列データ型(VARRAY)やユーザ定義型(RECORD)の値を引数にとるストアドプロシージャを、
JDBCでJavaから呼べるか？
というものです。いや、呼べるのはハッキリしているのですけど、
やり方を自分で試したいということで。
そこで「Oracle8i Javaプログラミング」という本と、
Webで公開されている例を元に作ってみると、うまく行きました！
その顛末を私も載せてみました。
Designed and Written by (C) 2002-2007 URANO398.