JSP 3章 アクション 3.1. アクション 3.2. <jsp:useBean> 3.3. <jsp:setProperty>と<jsp:getProperty> 3.4. <jsp:include>と<jsp:forward> 3.5. <jsp:plugin> 3.6. <jsp:attribute>と<jsp:body> 3.7. <jsp:doBody>と<jsp:invoke> 3.8. <jsp:element> 3.7. <jsp:doBody>と<jsp:invoke> <jsp:doBody>と<jsp:invoke>はタグファイルの中で使用されます。 <jsp:doBody>はタグファイルで設定したカスタムタグのボディ部を出力するアクションタグです。 出力先を変数に設定することが出来ます。 属性名 必須 スクリプト 可能 説明
今まで JSP で struts の bean タグや logic タグで記述していたところを、JSTLを使って書かなくちゃいけなくなった。めんどっちぃ。ということで、対応表。 struts taglibJSTL
最近ではコンピューター、ウェブ、モバイルでゲームを楽しめるようになりました。これらのゲームプログラミングについて学びましょう。 ゲームプログラミングの特徴 ゲームプログラミングは比較的新しいジャンルです。 ゲーム開発に使用される言語は、C#、C++、JavaScript、Swift、Rubyです。ゲームでは通常のアプリケーションと異なり複雑なビジュアルを操作するパフォーマンスと速度が要求されますので、プログラム言語もそれに特化している言語がおすすめです。 ゲームプログラミングは今後も人気の職種です。習得してステップアップを目指しましょう。 Oracle PLのプログラミング言語について学びましょう。 Oracle PLの特徴 SQL、T-SQLと同様にOracle PLもデータベースを処理するための言語です。違いとしてはOracle PLは世界最大のデータベースのひとつであるOracleデ
[速報]JavaOne Tokyo基調講演。JavaへHTML5機能統合、Java EE 7のクラウド機能などを紹介。JavaOne Tokyo 2012 「JavaOne Tokyo 2012」が開幕しました。国内での開催は7年ぶり、サン・マイクロシステムズがオラクルに買収されてからは初めての開催となります。 初日の基調講演は「Java Strategy Keynote」として、Java全体を俯瞰した今後の方向性、ロードマップなどがおもなテーマ。いままで別々に行われていたJava MEとJava SEのリリースを同期させていくこと、Java EE 7でのクラウド対応、JavaにHTML5の機能を統合するProject Avatarの紹介などが行われました。 午前9時から行われた基調講演の内容をダイジェストで紹介します(ちなみに、Oracle OpenWorldとJavaOneは午前9時か
JSR 236: Timer for Application Servers 前回はJava EE環境でスレッドプログラミングを可能にするAPIとしてJSR 237: Work Manager for Application Serversを紹介した。今回はJSR 237と同じく、Java EE環境において非同期並列処理を実現するためのもうひとつのAPI「JSR 236: Timer for Application Servers」を紹介する。 JSR 237がjava.lang.Threadの代替となるAPIであるのに対して、JSR 236が提供するのはjava.util.Timerのようなタスクのスケジューリング機能だ。つまりこのAPIを使うことで、あるタスクが定期的に繰り返し実行されるような処理を実装することができる。 java.util.Timerクラスにおいて、スケジュールされた
J2EEのパターン 山野裕司 <Yamano_Yuji@ogis-ri.co.jp> (株)オージス総研 ∼レイヤアーキテクチャと プレゼンテーションレイヤ∼ 目的 • J2EEアプリケーション開発で用いる パターンの種類の紹介 • レイヤアーキテクチャ、プレゼンテー ションレイヤを設計するためのパターン の紹介 • 設計のコツ 2 目次 • J2EEのパターンとは • レイヤアーキテクチャ • プレゼンテーションレイヤのパターン 3 J2EEのパターンとは 4 J2EEのパターン? • 一般的にJ2EEパターンと呼ばれている のはCore J2EEパターン • しかし、J2EEアプリケーション開発 において、Core J2EEパターン以外の パターンもたくさん使う 5 J2EEのパターンの種類 • 設計パターン POSAパターン、GoFデザインパターン、 PofEAA パターン、Cor
前年、 #JavaEE開発あるある で呟くとJavaEE6の本がいただけるということで、つぶやいていたらなんと当たりました。 ありがとうございます。 Beginning Java EE 6~GlassFish 3で始めるエンタープライズJava (Programmer's SELECTION) 作者: Antonio Goncalves,日本オラクル株式会社,株式会社プロシステムエルオーシー出版社/メーカー: 翔泳社発売日: 2012/03/09メディア: 大型本購入: 5人 クリック: 147回この商品を含むブログ (29件) を見る 現時点では日本語でのJavaEE6全体に関して解説した書籍はなく、JavaEE6を使ってみたいという人がいても英語の資料を読む必要があり、敷居が高いものになっていました。 それがついに解消されるということで、非常に嬉しいです。JavaEE6が広く使われるよ
Java EE6でさらに開発は容易になった? 以前JavaEE標準の進化から最近の業務アプリケーション開発手法の変遷について考える - 達人プログラマーを目指してにてJava EE標準の開発モデルの進化について説明しました。10年前の相当面倒だったJ2EEの開発モデルと比べて、最新のJava EE6では、様々なOSSの良い特徴を取り入れて、簡単にプログラミングできるように大幅に改良されています。また、Glassfish 3.1やJBoss AS7などは起動時間が非常に短縮されており*1、よほど遅いPCでなければわずか数秒で再起動することができます。さらに、Java EEサーバーが重くてテスト不能というイメージはもう過去の話かもしれない - 達人プログラマーを目指してで紹介したように、Java EE6では従来困難であった単体試験の自動化も容易になっています。 個々の技術は優れているのだけれど
十年一昔といいますが、文字通り一昔前の書籍ではJ2EEのEJBコンポーネントはプロセスが分散化されたリモート呼び出しにより処理を行う分散コンポーネントとして説明されています。そして、残念ながら現状Java EE関連の日本語の書籍はこうした古い時代に書かれたものがほとんどとなっています。それゆえ、 開発効率がきわめて悪い 実行性能が悪い*1 仕様がきわめて複雑で理解が大変 といった悪いイメージが定着してしまっているのではないかと思います。しかしながら、最新バージョンのJava EE6では、Spring、Guice、SeamなどのOSSの軽量コンテナのアイデアを取り込むことにより、以前とは比較にならないくらい開発効率が改善されているという事実があります。 ここでは、Hello WorldのEJBの書き方を以前の古いバージョンから順次振り返りながら比較してみることで、EJBのプログラミングモデル
Java(.NET)のO/Rマッピングライブラリ。最近、Ruby用も登場。(RBatis) SQL(引数、戻り値、マッピング設定など)をXMLに定義することが特長。 本家(2010/06/16まで) http://ibatis.apache.org/ 本家(2010/06/16以降) http://www.mybatis.org/ (http://code.google.com/p/mybatis/) サンプルは以下のページ参照。 iBATIS(Java) http://634.ayumu-baby.com/ibatis/ http://www.h7.dion.ne.jp/~a.d.1976/ iBATIS(.NET) http://codezine.jp/a/article.aspx?aid=112 http://codezine.jp/a/article.aspx?aid=113 6年
「DI(Dependency Injection)」および「AOP(Aspect Oriented Programming)」と呼ばれる技術が注目を集めている。これらはオブジェクト指向プログラミングにおけるプログラムの単位であるクラスを,互いに結び付ける新たな技術である。システムへの機能変更ニーズが高くなり,さらに開発期間が短くなっている開発の現場において,開発の効率化や品質向上を実現する新たな手段として期待されている。まずはオブジェクト指向プログラミングにおける課題を明らかにし,DIやAOPがそれらをどう解決できるのかを見よう。 DIでクラスを容易に付け外す オブジェクト指向プログラミングの一つ目の課題として,「変更時にクラスの修正が必要になる」ことがある。そもそも,オブジェクト指向で開発したプログラムは,オブジェクト指向ではないプログラムと比べ,機能の削除や変更が容易であることが特徴だ
DIって本当に必要?たまにそう思うときがあります。DIによって開発は本当に楽になったのか。 DIのメリットでよく語られることとして、インターフェースと実装を分離し、機能の利用者側はインターフェースを通じて機能を利用することで、実装に直接依存しなくなり、後で実装を変更しても影響を受けなくなるということがあります。 実際後から、実装クラスを変更するということはめったにないので、よくあるのは、テストのために実装クラスをモックに変えることです。 でも、別にそれだけならDIContainerなんていりません。たとえば、次のようにServiceクラスに直接依存したClientがあるとします。 class Client { Service service = new Service(); void setService(Service service) { this.service = service;
Javaの世界では、POJOというものが流行している。Plan Old Java Objectの略で、Martin Fowler氏らの造語だ。シンプルで、依存性をなくしたオブジェクトのことをさす。しかし、このPOJOというものをどう捉えるべきか、まだまだはっきりしていないのではないかと感じる。ここでも、僕なりの説明を試みるわけだが、正解といえるかは分からない。ただ、方向性としては間違っていないと思っている。 POJOとは まず、POJOを、もう少し詳しく定義するなら、「自分がするべきことに対して最低限しか知らないオブジェクト」、さらに「実行環境やフレームワークのことは一切知らないオブジェクト」といえるのではないか。たとえば、ビジネスロジックを担当するPOJOであれば、自分のするべきこと、まさにロジックと、そのロジックに必要な他オブジェクトのインターフェース(まさに、interface)し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く