【ツール】 フレームワーク作成スレ 【ライブラリ】
言語やジャンルは不問、 勉強も兼ねて何か作ってみるスレッドです。
私はJavaでServletのフレームワークを作ります。 Apache ECSに最近のトレンド(AOPなど)を盛り込みます。 他の参加者も並行して何か開発してくれると お互いのモチべが長持ちしますよ!
フレームワークはバズワードだろwww
>>1 どんなのをつくりたいのか、もうちょっと具体的に話そうか。
ECSってフレームワークじゃなくて、どちらかというとテンプレートエンジンの一種なんだが、
それにAOPを組み合わせるとどううれしいのだろう。
ちなみに
http://jakarta.apache.org/ecs/ によると
> As of 2010-09-01, the ECS project is retired. This is an archived site.
とあるんだが大丈夫か。
7 :
デフォルトの名無しさん :2012/01/28(土) 00:38:34.38
寝ろ
このスレッドは天才チンパンジー「アイちゃん」が 言語訓練のために立てたものです。 アイと研究員とのやり取りに利用するスレッドなので、 関係者以外は書きこまないで下さい。 京都大学霊長類研究所
どうして、京都大学霊長類研究所は、アイちゃんの、 スレ乱立を見過ごしてるの? 独自の板立ててそっちで実験するとかできないの? いまどき、主婦だって専用の板ぐらい立てられるぞ。 「関係者以外は書きこまないで下さい。」とか、何 お前らがエラソーに仕切ってんだよ、ハゲ! 糞スレをあちこちにポンポン乱立されちゃ迷惑なんだよ。 ったく、京都大学霊長類研究所は能無しの集まりかよ!
>>6 何から説明したら話が早いでしょうかね。
単純なソースの例でもあればいいかもしれませんね。
>ECSってオワコンプロジェクトなんだが大丈夫か?
ECSやWicketからアイデアを抽出しますが、
内部でライブラリとして使用するというわけではありません。
>ECSはテンプレートエンジンの一種なんだが
ECSはXMLパーサに毛が生えただけのライブラリです。
私はServlet APIをラップしたフレームワークを作ります。
ページの遷移などのAction(Controller)も包括的に管理します。
フレームワークはデプロイ時にクラスパスから Pageクラスを継承したステートレス・クラスを検索して生成(new)され、。 生成されたインスタンスはBinder(ハッシュ+シングルトン)に登録されます。 PageクラスはAction、View、 Action and Viewのうち一つ役割を持ちますが、 振る舞いはModelクラスを継承したクラスに委譲されなければなりません。 ここでのModelクラスはビジネスロジックのModelではなく、 Action Model、 View Model、つまりActionやViewの振る舞いを表します。 @Action(path={"index.html", "/sample.html"}) class SampleAction extends Page { __@Override __public void onGet(Event e){ // callback for http GET method ____Model model = SampleActionModel(); ____model.flow(e); __} } class SampleView extends Page { __public void onRender(Event e){ // @Overrideではない ____Model model = SampleViewModel(); ____model.flow(e); __} }
ここではModelの最も単純な使い方に対する説明に留めます。 Modelは幾つかのprotected methodを順に呼び出します。 途中でエラーフラグを立てるとonError(Event e)をコールして サイクルを中断しますが、正常な場合には最後にonResult(Event e)がコールされます。 SampleActionからSampleViewをレンダリングする例です。 class SampleActionModel extends Model { __protected void onResult(Event e){ ____SampleView view = Binder.getPage(SampleView.class); ____view.onRender(e); __} } class SampleViewModel extends Model { __protected void onResult(Event e){ ____e.doPage(this); // draw HTML (何も出力されない) __} }
ModelとHTML出力に関係がありますが、一端HTML出力に説明の焦点を絞ります。 Apache ECS同様に、JSPやVelocityスタイルではなくDOM形式でHTMLを扱います。 DOMは繰り返し処理など動的な変更に強力で、 JavaScript組み込みコンポーネントが作りやすい、学習性が高い利点があります。 しかしHTMLの大部分は静的であり、動的に生成されるのは商品リストのような わずかな領域です。この動的領域以外の領域をDOMのNodeオブジェクトで 生成するのは冗長なので、プレーンなHTMLファイルをinclude(DOMにマッピング)します。 (Wicketのコンポーネント指向と似ていますが、 Wicketの苦手な面、繰り返し処理などを改善しています)
DOMはめんどくさい。
>>16 Apache ECSの致命的な問題点(時代的制約)はそこにあります。
如何にDOM操作をCOCで省略するのか、本当に必要な箇所に限定するのか、
次回はそれに対するアイデアである以下を説明する予定です。
1. HTMLロード
__ Node root = new Node("hello.html");
2. HTMLのid属性で参照を取得
__ Node child = node.id("base"); // <base id="base" href="C:/project"/>
__ child.attr("href", "
http://localhost/sample/ ");
3. 動的領域Canvas, 繰り返しや表示・非表示、並べ替えの単位Group
__ @Source(html="/WEB-INF/source/html/hoge.html")
__ class SampleModel {
__ __@Source(id="item_list")
__ __Canvas item_list; // @Source id と Field name が等しい場合省略
__
__ __@Source(id="item")
__ __Group item;
__
__ __public void onModel(Event e){
__ ____for(int i=0; i<10; i++ ){
__ ______Node add = item.in(item_list); // Groupのクローンを取得 、子ノードとして追加
__ ______Node update = add.id("item_id", i); // 繰り返しごとの変更、idに[i]追加
__ ______update.addText("ID:"+i); // addText, addAttr, addNode
__ __}
__ }
>>17 ほらな。めんどくさい。
[foreach 〜]
<tr><td>${value}</td></tr>
[/foreach]
こんな感じでいいじゃないか。
HTMLなのだから、プログラム以外も書けるような形にすべき。
> 2. HTMLのid属性で参照を取得
> __ Node child = node.id("base"); // <base id="base" href="C:/project"/>
> __ child.attr("href", "
http://localhost/sample/ ");
prototypeやjQueryを見習ってCSSセレクタでやれ。
$('#base').attr('href', '
http://localhost/sample/ ');
これだけで終わりだ。
>>18-19 >HTMLなのだから、プログラム以外も書けるような形にすべき。
タグライブラリっぽいものからjavaソースの自動生成がいいかなと
考えてたんですけど、先にVelocityとかJSF2調査したほうがいいかな。。。
<foreach>
<tr><td><namespace:value/></td></tr>
</foreach>
>CSSセレクタでやれ。
HTML id を少しでも減らすのに良いですね。
>>15 どうも
画面遷移はぶっちゃけServlet一個だけ作っておいて、
Pageオブジェクトとかに処理を委譲すると簡単。
PageServlet(以下の状態管理を行う)
APage→A.HTML→GET/POST→APage(*1)→BPage→B.HTML
└──←───←─┘(エラー時)
*1で正規表現によるvalidationやエラーメッセージの設定などを行う。
この方式だとAPageクラスに処理を局所化できるので、プログラミングはかなり楽。
ASP.NETのポストバックでも似たような処理をしていると記憶している。
>>21 のアーキティクチャはPerlで使ったんだけど、Javaにも
普通に応用できると思う。
各Pageオブジェクトは、基本的にはMapでパラメタを全部受け取り、
適宜チェックし取捨選択して(*1)次のPageオブジェクトに渡す。
Pageオブジェクトは毎回生成してもいいし、必要ならキャッシュしてもいい。
Perlのときは、出力にテンプレートエンジン(HTML::Template)を使った。
これはJavaのVelocityに相当するもので、Velocityなら、パラメタとして
受け取ったMapをそのまま渡せていいかもしれない。(*2)
*1 ここが少し面倒だが、セキュリティ上しょうがない
良く使う正規表現などをまとめた、Validation専用のライブラリがあると楽。
*2 もちろんXSS対策など、セキュリティに配慮は必要だが。
あとこれは反則かも知れないが、Applicationクラスをセッションに放り込んでおいて、 面倒な処理は全部そっちに丸投げするという方法もある。 各Pageで持っているのが面倒なパラメタや処理は、Applicationクラスに 記述する。たとえばクソ重いバッチ処理の起動や、ユーザの階級に合わせた処理など、 Pageから分離すべきタスクはけっこうある。 それを全部Applicationクラスに任せると、けっこう上手くいくのではないだろうか。 長々と書いたが、フレームワーク的にはAbstractPage、AbstractApplication、 それらに付属する個別の設定ファイル(Properties or INI or XML)、テンプレートエンジン などへの軽快なアクセスを提供することになる。
ごちゃごちゃ説明しなくていいよ。 ようするに既存の○と同じ方式だろ? さっさと実装(再発明)でもしとけ。 話はそれからだ。
>>21 >Servlet一個だけ作っておいて~
それは内部での話しですね。
私の場合、ブラウザ・クライアントがURLにアクセスしたとき、
全てServlet Filter が割り込み、URLハッシュと関連づいた
Pageクラスに委譲してるのでPage = HttpServletなんです。
(これは多くのJava系FWと同じ仕組みです)
>ASP.NETのポストバック
>セッションに放り込んでおいて、 面倒な処理は全部そっちに丸投げするという方法もある。
JavaのWicketステートフル・アーキテクチャと似てますね。
リダイレクトやセッションが増えて回線IO作るのが欠点ですが。
メソッドチェーン導入しろ
>>21 >この方式だとAPageクラスに処理を局所化できるので、
>プログラミングはかなり楽。
ページクラスに全部押し込むとステートレスにする必要があるので
AOP(インジェクション・バイジェクション)でバリデーションとかするのを
諦める必要があります。
class hoge extends Model {
[email protected] (name="money")
[email protected] (name="money")
__int money;
__
__void onRead(Event e){} // Sessionからmoneyにインジェクション
__void onModel(Event e){ if(money < 100) money++; }
__void onWrite(Event e){} // moneyからSessionにアウトジェクション
__void onResult(Event e){} read -> model -> write -> resultの順に実行
}
AOPで幸せになれるとは限らないと思うけど……。
>>AOPで幸せになれるとは限らないと思うけど……。 もちろんそうです。 場合によってはクラス変数増えまくりで 文字数は少なくてもソース行数が増える欠点があります。 まあSeasar, Spring, PlayみてもAOPでスコープ操作したり バリデーションするのが流行りみたいなので持ち出したアイデアです。 利点としては文字列リテラルが消せる場合があることです。 以下をAOPで置き換える例を示します。 Event e; Session session = e.getSession(); int money = (Integer)session.getAttr("money"); ↓ @Read.Session int money
海外ではHAJO(Heavy Annotation Java Object)とかいう蔑称で SpringのAOPを叩いてる人もいるらしいですよ
"Heavy Annotation Java Object"との一致はありません。
>>30 の続き
AOPを使わないApache Wicketでも
文字列リテラルが不便だったりしますね。
Page page;
String id = "html_id";
TextField<String> txt = new TextField<String>(id);
page.add(txt);
Velocityを参照しろ
1.getParameterMapを使ってパラメタを全部取得する。 2.そのMapに対して徹底したValidationと正規化を行う。 3.次にMapを元に処理を行う。 4.最期にそのMapをテンプレートエンジン(Velocity)に渡す。 こういうフレームワークなら欲しいな。 特に3.をServletの実装から完全に切り離したい。
ViewとActionの話が混ざってる
.vmファイルだけみて比較してるから気付いてないんだろうけど、
Velocityにも対応するjavaコード書いたら
>>17 とVelocityの違いって
条件分岐(if, for)を書くところをテンプレートにするか
javaソースにするのかぐらいしかないと思うよ(あとid属性)
データベースから商品リストを吐くサンプルで比較したらいんじゃない?
Velocityを内部に組み込んだフレームワークってあるかしらんが
もしべろ(もしVelocityを内臓したら)との比較やってみました まずはVelocityを使わない場合 <div id="item_list"> __<div id="item"> ____商品名:<span id="item_name"/><br/> ____価格:<span id="item_price"/><br/> __</div> </div> @Source(html="/source/hoge.html") class Hoge extends Module { __@Source __Canvas item_list; __ __@Source __Group item; __ __void onModel(Event e){ ____BusinessLogic logic = new BusinessLogic(); ____List<Item> entityList = logic.getItemListFromRDB(); ____ ____for(Item i : entityList){ ______Node node = item.in(item_list); ______node.id("item_name").addText(i.name); ______node.id("item_price").addText(i.price); ____} __} }
続いてVelocityを内部で利用した場合です。
<div>
__#foreach( $item in $item_list)
____<div>
______商品名:$item.name<br/>
______価格:$item.price<br/>
____</div>
__#end
</div>
class Item {
__public String name;
__public int price;
}
@Source(vm="/source/hoge.vm")
class Hoge extends Module {
[email protected] // アウトジェクション
__List<Item> item_list;
__
__void onModel(Event e){
____BusinessLogic logic = new BusinessLogic();
____item_list = logic.getItemListFromRDB();
__}
}
__________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________
>>35 >1.getParameterMapを使ってパラメタを全部取得する。
Servlet APIは元からパラメータをMapに持っています。
Mapからclass fieldにマッピングするならば、
SpringやSeasarはみんなそれですよ。
>2.そのMapに対して徹底したValidationと正規化を行う。
fieldにマッピングされた値に対してアノテーションで行うのが
現在の主流(SpringやSeasar)です。
>4.最期にそのMapをテンプレートエンジン(Velocity)に渡す。
>こういうフレームワークなら欲しいな。
Spring + Velocityはどうですか。
>>38 続き
Velocityと比べた感想として、Javaソース内でHTML id に関する
文字列リテラルをメソッド内から消したいって印象が残りました。
(メソッド内でなければデプロイ時にID不一致が全て検出できると思うので)
EntityBeanと相性が悪そうですが、改善案を出してみます。
@Source(html="/source/hoge.html")
class Hoge extends Module {
__@Source
__Canvas canvas;
__void onModel(Event e){
____BusinessLogic logic = new BusinessLogic();
____List<Item> item_list = logic.getItemListFromRDB();
____canvas.add(item_list);
__}
}
@Source(html="/source/hoge.html", id="item")
class Item extends Group {
__public String name;
__public int price;
}
>>41 >Mapからclass fieldにマッピングするならば、
それをしたくないんだよ。
Bean書くのめんどくさいじゃん。しかもマッピングに失敗したら漏れなく例外吐くじゃん。
マッピング成功後のValidationも別途書かなきゃいけないじゃん。
悪意を以て値が改変されてたらシステム止まるじゃん。
めんどくさいからMapのままでいいよ。
Mapに対して何かするメソッドを沢山作って
メソッドチェーンで手っ取り早く終わらせたい。
>Spring + Velocityはどうですか。
XML書くのめんどい。
パラメタも設定ファイルも全部MapとPropertiesに入れちゃえばいいじゃん。
なんでいちいちBeanとXML書く必要あるの?
そんなにたくさんオブジェクト作っておいて、やってることはせいぜいが
テンプレートエンジンへの値の再設定じゃん。
>>43 ダックタイピングではない言語でMapに詰め込んだり
rubyみたいなのは無理ですけど、無名クラスでコールバックぐらいなら。
void test(){
__Form form = Servlet API; //Http Form パラメータ
__Map result = new Scope(form){ // 引数にForm, Session, Cookieどれか
____public String name(String value){ // メソッドの名前 = MapのKey
______escape(value); // HTML Escape
______return value;
____}
____public int age(int value){ return value; }
__};
__super.view(result); // Velocity
}
いやまてよ、Formパラメータに限定すればString型と決まってるからできるね。 PHPみたいだけど。 Map form = Servlet API; escape(form, "テキストエリア"); // TextAreaに入力された値をエスケープ
こういう流れ @Source(vm="/source/hoge.vm") void onModel(Event e){ __Map form = Servlet API; __if (validate(form)) { ____BusinessLogic logic = new BusinessLogic(form); ____form = logic.aLogic().bLogic().cLogic(); //メソッドチェーン __} else { ____form.put("validation.error", "入力エラーです"; __} } boolean validate(Map form) { __LzMap map = new LzMap(form); __if (!map.getSortedKeys().equals("[item.name, item.price]")) return false; __if (!LzValidator.isJapanese(form.get("item.name"))) return false; __if (!LzValidator.isInteger(form.get("item.price"))) return false; __retrun true; }
Validationは面倒だから設定ファイルに外出ししたほうがいいと思う validation.values=item.name,item.price validation.item.name=Japanese validation.item.name.error=不正な商品名です。再入力してください。 validation.item.price=Integer validation.item.price.error=不正な価格です。再入力してください。 みたいにしておいて、自動でチェックする機構を作る この部分はセキュリティ上、最も重要なポイントなので、必要なら XMLでもいいと思うよ。
Applicationに対して1個。 Pageに対してそれぞれ1個の設定ファイルがあるといいと思うよ。 とにかくValidation済みのMapが一個あれば、大抵の処理では事足りるんだよ。 あと、HTMLエスケープはテンプレートエンジン側の仕事じゃないかな。 経験上Servlet内でエスケープするとろくなことないよ。
age
誰がブログで書いてたか忘れたけど、 ビュー制御用に新しいテンプレート言語を覚えるなんて馬鹿らしいじゃん
まず始めにテンプレートエンジンとか設定ファイルありきではなくて、 Javaでプログラミングするスタイルを土台に作ったうえで 様々なテンプレートや設定ファイルからスケルトンコードを 出力するツールを作ったらいんじゃないだろか (.java生成でもいいし、鯖へデプロイ時にjavassistで動的生成でもいい) フレームワークの上にさらにフレームワークやライブラリを乗せることを 前提にしたつくりって風呂敷が大きすぎるかもしれんがな
>>51 もしVelocityのことを言語と言っているなら、簡単すぎてあくびがでるレベルだけどね。
それにビューをJavaから分離することでXSS脆弱性を根治できるんだとしたら
十分おつりがくる。
XSS脆弱性は風邪じゃなくてインフルエンザ。
発生したらシステム止めないといけないランクS障害だからね。
>>52 WEBの基本は、処理の「前の」Validationと、処理の「最後の」HTMLエスケープ。
これはいつの時代も変わらない真理なんだが、いつもないがしろにされて
不具合とスパゲティコードを生み出している。
Java単体、いやServlet単体で何ができるか?アノテーションでどこまで自動化できるか?
深刻な不具合(XSS脆弱性、唐突な実行時例外、etc)が起きない仕組みづくりは可能か?
このへんを突き詰めていくのは興味深い問題だと思う。
>WEBの基本は、「前の」Validationと、処理の「最後の」HTMLエスケープ。
>どこまで自動化できるか?
>Validation
例えばログイン処理でカスタムアノテーションを使って
フィールドにマッピング+バリデーションの場合、
半角英数であるか、ぐらいはアノテーションでする。
カスタムアノテーションにはEvent eが渡され、バリデーション処理中に
次のようにマップにエラー情報が渡された場合、onError(Event e)に推移する。
(※HashMapであるErrorsのサイズ > 0 のとき、エラーが発生しているとみなすので
スタックトレースが重い例外を発生させない )
Errors error = e.getError();
error.setError("error name", "error value");
class Hoge extends Model {
[email protected] // onRead(Event e)でリクエストパラメータから値を読み出す
[email protected] // バリデーション
__@Length(min=4, max=8) // バリデーション
__String name;
__protected onRead(Event e){}
__protected onValidate(Event e){}
__protected onModel(Event e){}
__protected onResult(Event e){}
__protected onError(Event e){} // Errorsからエラー情報を取得できる
}
カスタムバリデーターは次のように実装されます。 // バリデーションようのアノテーション @Validator(listener = LengthValidator.class) public @interface Length { __int min() default 0; __int max() default 0; } // アノテーションの実装 public class LengthValidator implements Validator.Listener<Length, String>{ __public void onListener(Length type, Event e, String value){ ____int length = value.length(); ____int min = type.min(); ____int max = type.max(); ____// (エラーが起きたら例外ではなくErrors ers = e.getError()に文字列をつめる) __} }
>処理の「最後の」HTMLエスケープ。 ページ内の動的領域が分かるならば、 動的領域の全てをHTMLエスケープすればいいかもしれません。 私は文字列計算のパフォーマンスのためにHTML IDと一致する Canvas領域を用意していましたが、これをエスケープ対象領域に使うとか。
>>38 は、素のDOMプログラミングよりは簡単だけど、VelocityやPHPと比べたら直感的でないし、めんどくさい。
>>57 Pure HTML vs テンプレートエンジンのトレードオフだな。
作業を分離した場合(大規模)か、しない場合(小規模)かで評価違う。
>>ちなみに38, 42 にあるソース側の構文は改善できる。できないのはHTML内のID。
意外と有用なスレになっているな。
すまんあげてしまったorz
rubyとscala調査したけどViewに関して収穫なし。
>>61 viewというかtemplare engineはTAL (Template Attribute Language)がすき。
zopeちゃん、息してないけど。
SeasarやSpringでVelocityやFreeMakerが使われてる(使える)ので、 POHP(Pure HTML)で工夫する余地を探す事にします。 <SAMP>, <VALUE>などHTML5にあるタグ+規約で ページ側の冗長を削る事を先に行い、 それにあわせてJava側を改革できれば良いかなと。 独自タグ(XMLNS、タグライブラリ)は HTMLオーサリングツールと相性が悪いのでなし。
>>62 タグライブラリ形式ですね。
<lib:Facebook/>みたいにマッシュアップとかコンポーネント化で
一番魅力的なんですが、メインには採用できません。
一部のCMSではHTMLオーサリングツールとの関係で コメント内にタグライブラリを書かせてるみたいです。
>>64 違うよ。HTMLのタグにTALで定義された属性を記述する。
専用のタグはない。
名前空間も定義されてたはずなので、元がxhtmlならvalidなxmlになる。
属性ベースなので、オーサリングツールの邪魔をしない。
テンプレートそのものがサンプルとなる。
最後のテンプレートそのものがサンプルになるとは、TALの属性は、webブラウザでは無視されるので、そのまま表示することができるということです。
>>66 なるほどねー。属性は害なく使えるんだ。
XMLベースなら簡単に追加できるし、いいかも。
がんばage
属性ベースで考えてみたんですが、HTMLからJava生成に便利な反面 HTMLに独自属性が増えると見た目がいまいちだったり。 (もともとHTMLって属性をたくさん使うので) やはりid属性を使ったPure HTMLだけで作る仕組みに留めて、 XMLやテンプレエンジンからの自動生成ツールを上乗せすることにします。
昔、住友がStrutsソースを吐き出す 楽々なんとかっていうXML系フレームワークを売ってたらしいですね。 フレームワークの上にフレームワークってのも悪くないはず。
<SAMP></SAMP>で囲まれた領域はフレームワークが読み込み時に削除する。 静的な見た目確認テスト用のデータを置く為に利用する。 <VAR></VAR>も何か使えないかなとは思うのですが、 <var>node:item(型:変数名)</var> とか候補を挙げつつも今のところは保留。
Node, Canvas, Groupだけ見直したら実装、 あとの問題は上位のレイヤーにまる投げ
実装に関して課題はファイルアップロード。 とりあえず現バージョンではcommons-fileuploadを使うとして、 (依存ライブラリ増やしたくないのだが) テンポラリファイル置き場とかの設定方法考えないといけない。 ファイルアップロード自体を保留しないと進まなくなる予感。
ninja test
もう一回
まだLV15しかないのか
WicketとかClickだとGET, POSTなんてのを隠蔽している。 綺麗にみえるけど、FormはPOSTであると決めうちしてるのだろうか? サーチエンジンに入力して送信するボタンはGETだけど、 そこはBookmarkablePageへの移動判定と、リダイレクトする仕組みで 層を作ってごまかしているはず。 仮想化するために回線IOが増えるのは避けたい。 String id ="html"; Button html = new Button(id) { __@Override __public void onSubmit() { ____setResponsePage(new HomePage(new DiaryVO())); __} };
飽きてきた。Memcachedの偽物でも平行してつくろうかな
80 :
デフォルトの名無しさん :2012/02/09(木) 05:38:00.89
そんなときはノーパンしゃぶしゃぶ行って気分転換するといいよ
外に行くの面倒だから ノーパンでしゃぶしゃぶ食べたよ。
しゃぶしゃぶ金かかるから 娘のパンツ食べてノーパンにしたよ。
>>70 >属性ベースで考えてみたんですが、HTMLからJava生成に便利な反面
>HTMLに独自属性が増えると見た目がいまいちだったり。
>(もともとHTMLって属性をたくさん使うので)
HTML5ならdata属性が使えるし、見た目もそんなに悪くないと思う。
id属性はCSSやJavaScriptでも使うから、テンプレートエンジンで使う属性は
それらと分けたいという要求は少なくない。
それを考慮すると、独自属性は悪い選択肢ではない。
>やはりid属性を使ったPure HTMLだけで作る仕組みに留めて、
>XMLやテンプレエンジンからの自動生成ツールを上乗せすることにします。
すでにMayaaというのがあるけど、それとは違うものを作るってことだよね。
差別化要因は何になる?
>>83 Mayaaは全く競合ではないよ。
>HTML5ならdata属性つかえば完全Pure HTMLで機能盛り込める。
これ知らなかった。でも独自属性の方が名前がすっきりしそう。
>id属性はCSSやJavaScriptでも使うから、テンプレートエンジンで使う属性は
>それらと分けたいという要求は少なくない。
もう一度考えてみる
>>86 html5のdata属性は、data-で始まってれは、どんな名前をつけてもいいってのだから、ほぼ独自属性だな。
jQuery Mobileがdata属性を駆使してたかとおもう。
89 :
デフォルトの名無しさん :2012/02/11(土) 14:35:55.24
うるさいハゲ
90 :
デフォルトの名無しさん :2012/02/11(土) 15:56:55.82
で? ノーパンしゃぶしゃぶは完成したのか?
そうかもしれないし、そうじゃないかもしれない
OK それじゃ歩み寄ろう
>>86 >Mayaaは全く競合ではないよ。
どう違うのか説明してくれないと誰にも伝わらないし、スレも寂れる。
それは説明しなくても分かること 説明しないとわからない奴は馬鹿。 俺は転載
>>93 MayaaはVelocityと同じ。
私の場合はコアにDOM形式のAPIがあって、Ajaxなどでそれを生かすの目的。
ファイルのHTMLを使い、またHTMLファイル内で小細工するのは
DOMの欠点を補うために、DOMライクなAPIの上に乗せられたレイヤーにすぎない。
メモ: セッションの上にリダイレクトスコープ(フラッシュスコープ)とか 会話スコープみたいな機能を盛り込んだり、 ブラウザの戻るボタン対策に、セッションに古いページ情報詰め込んだりする コンポーネントを持つフレームワークもあるみたい。 いっそのことセッションの代替を作ってしまうかとも思ったのですが、 ver1.0ではこの辺も全部棚上げということにします。
>>84 みたいなオープンなタイプの奴とライブラリを共有して発展してみたいな。
ただし俺の基本ライブラリは
>>84 の1000倍以上なので協力関係は無理そうだ。
SourceForge、GoogleCode、自宅サーバー、 どこで晒すにしてもなかなか難しい事よ
>>95 >MayaaはVelocityと同じ。
どういう観点から同じといっている?
MayaaはVelocityとまったく違うと思うんだけど。
>私の場合はコアにDOM形式のAPIがあって、Ajaxなどでそれを生かすの目的。
なんか話がごっちゃになってない?
コアにあるというDOM形式のAPIって、サーバーサイドの話でしょ。
Ajaxは関係ないし。
Mayaaとかいうドマイナーなものもってこられても困るんだけど
>>99 >どういう観点から?
1.MayaaはMVCのViewしか担当しない。(ActionはSAStrutsなど他のものが必要)
2.テンプレートファイル内だけで完結している(.vm .html .mayaa)ので
自由度に多少制約がある。(めったに困る事はないが、抜け道がない)
>コアにあるというDOM形式のAPIって、サーバーサイドの話でしょ。
Action(Controller)だけでなくViewもサーバーサイドです。
リンク先にあるチュートリアルのような、
Java Servletだけで開発する原始的なスタイルから、
ActionとViewを切り離すさいに、ViewをJSPやテンプレートエンジンにするタイプと、
XMLCやApacheECSなどDOM形式で扱うフレームワークに分かれて10年ぐらいたちます。
そして私は両者のハイブリットを目指しているのです。
http://www.javadrive.jp/servlet/ini/index3.html 私の狙いでは、Servlet -> DOM -> HTML(テンプレートエンジン)という
構成によって、Viewに対してレイヤーが2つ使用できることから、
オーソドックスな操作はHTML(テンプレートエンジン)で、
ポートレットなどのモジュール化に関してはDOMを使ったコンポーネントを
使うことです。
やる気がなくなって2週間ぐらい放置してましたが、 たぶん明日からまたがんばります。
103 :
デフォルトの名無しさん :2012/02/13(月) 20:53:03.20
>XMLCやApacheECSなどDOM形式で扱うフレームワーク これってJSPに負けて消え去ったんだっけ?
HTML5は勘弁して欲しいなぁ。 その時点でIE6, 7, 8切り捨てってことでしょ? 企業の標準ブラウザは上記3つでほぼほぼ100%だから採用できない。 2014年になればXPがトドメ刺されるからIE6は消え去るんだけど…
<canvas>とか使わなければいいだけじゃん?
>>104 IE6でHTML5技術は70%使える。
HTML5って最新のブラウザでもhidden属性とか未実装機能満載でしょ まだまだ対応する価値ないよ
hidden属性なら簡単にエミュレートできそうだなw
あんなの飾りです!
>>110 残念ながら進んでない。
何か追加リクエストがあれば実装するんだけど。
業務用のコードばかり書いていると、 ライブラリ用のコードの書き方を忘れそうになる。
JAXBとSTAXの改善希望
XMLはDOMとかSAXとかより、下みたいに潰して作業するのが好きだな {_path=HTML, _child=[BODY: null], _tag=HTML, lang=ja} {_path=HTML.HEAD, _child=[SCRIPT: null], _tag=HEAD} {_path=HTML.HEAD.META, _tag=META, content=text/html; charset=UTF-8, http-equiv=Content-Type} {_path=HTML.HEAD.TITLE, _tag=TITLE, _value=PhpWiki - TestPage} {_path=HTML.HEAD.LINK, _tag=LINK, href=about.html, rel=next} {_path=HTML.HEAD.LINK, _tag=LINK, href=cover.html#minitoc, rel=contents} {_path=HTML.HEAD.LINK, _tag=LINK, href=default.css, rel=STYLESHEET, type=text/css} {_path=HTML.HEAD.SCRIPT, _tag=SCRIPT, src=prototype.js} {_path=HTML.HEAD.SCRIPT, _tag=SCRIPT, src=jquery-14.4min.js, type=text/javascript} {_path=HTML.BODY, _child=[HR: null], _tag=BODY, _value=2012/02/15 {_path=HTML.BODY.H1, _tag=H1, _value=TestPage - Php学習用Wiki} {_path=HTML.BODY.DIV, _child=[A: null], _tag=DIV, _value=} {_path=HTML.BODY.DIV.A, _tag=A, _value=ホーム, href=/cgi-bin/wiki.php} {_path=HTML.BODY.DIV.A, _tag=A, _value=更新履歴, href=/cgi-bin/wiki.php?page=RecentChanges} {_path=HTML.BODY.DIV.A, _tag=A, _value=ページ一覧, href=/cgi-bin/wiki.php?page=IndexPage} {_path=HTML.BODY.DIV.A, _tag=A, _value=このページを編集する, href=/cgi-bin/wiki.php? page=TestPage&edit=true} {_path=HTML.BODY.P, _child=[BR: null], _tag=P, _value=test4}
この方法 List<Map>型 の利点はメモリをあまり食わない点だ。、 また、HTMLのほんの一部のデータだけをピックアップするのに向いている if (line.get("_path")..equals("HTML.BODY.H1")) { } でサーチし、 {_path=HTML.BODY.H1 _tag=H1 _value=TestPage - Php学習用Wiki} のラインからタイトルの「TestPage - Php学習用Wiki」を取り出すのは簡単だ
方向性はOKだからとにかく頑張れ。俺はゴールで待っているよ。
>>118 emo-frameworkも最初試してみたんだが、
ソースに日本語が使用できないのはちょっと難点だったからあきらめた・・・
色々フレームワークは試したけど、最終的にMOAI SDKに行き着いて、
気に入らない部分は自分でフレームワークを作ろうかなと
SilverlightのMVVMって発想的に近いんだな
ライブラリ作成を手伝ってくれる人いないかな? 実用的な高速正規表現エンジンを1から作りたいのです。
どうぞ
何に使うの?
既存ので十分実用的だろ
125 :
121 :2012/02/28(火) 21:37:18.17
>>123 訳あってpure javaの用途で必要性が生じました。
しかしそれをCへ移植すれば正規表現エンジンの用途は無限です。
>>124 試したのはjava.util.regexやapache-oro
ですがかなり遅い。使い物にならないレベルです。
google re2については機能が足りません。
他の言語から移植しようと試みましたが今のところダメです。
速くなる見込みはあるの? オライリーの正規表現に載ってる程度の、実装戦略による長所短所は知ってるの? ちょっとググったら DFA で実装している人が何人かいるみたいだけど、これらより速くなりそうなの? 遅い原因が、単に正規表現のコンパイル結果をキャッシュしないで毎回コンパイルしなおしているのせいだという可能性は?
127 :
121 :2012/02/29(水) 16:58:40.04
>速くなる見込みはあるの? 簡単な例でインデントタブの検索で 既存のものより1000倍以上早くなると妄想しています。 >オライリーの正規表現に載ってる程度の、実装戦略による長所短所は知ってるの 知りません。 DFAの知識に拘っている限り指数オーダーの呪縛から抜け出せないと思っています。
128 :
121 :2012/02/29(水) 17:16:31.07
>遅い原因が、単に正規表現のコンパイル結果をキャッシュしないで毎回コンパイルしなおしているのせいだという可能性は? ミスの多い自分なので、今自分のプログラムを見ましたが無い事を確認しました。
その妄想に根拠はあるのかい?
130 :
121 :2012/02/29(水) 22:13:30.37
脳内根拠ならあります。 1から始めると言いましたが、根拠を掘り起こす作業も含まれます。
132 :
131 :2012/03/01(木) 23:01:02.62
>>131 .*abc.*def.*
>誰も知らない爆速アルゴリズムを思いついた
133 :
121 :2012/03/02(金) 00:05:49.76
>>131 興味深いページをありがとうございます。
かなりの協力を得た感じがします。
線形時間で解くという点で目的は同じみたいです。
ただ自分はもっと幼稚な手法で学術知識は無視します。
>どんな複雑な正規表現を使おうとしているの?
(?<=(?:\A|\n)[ \t]*)\t
インデントの各タブ文字を検索するだけですが激重です。
こんなのは一瞬で求まっていいはずです。
これがスタート地点です。
>誰も知らない爆速アルゴリズムを思いついた
奥の手を持っていますが、今回は使わないと思います。
誰も知らないというが 俺は知ってる。
135 :
121 :2012/03/02(金) 18:08:05.54
本来こんな事はチラウラにでも書くべきだが・・。 脳内根拠だけじゃだめなので、簡単な実験プログラムを作ってみた。 .*単語.*単語.*単語.*単語.*単語.*単語.*単語.*単語.*単語.*単語.* ランダムな2文字の単語が10個並んだもの。これと1万文字とのマッチングをしてみた。 java.util.regexとの比較で 5千〜2万倍早くなった、従って早くなる見込みとしては十分だ。 発想は極めて幼稚で、.*のところで分割すればいいじゃないかというもの。
>>133 まあオライリー読みなよ。
で、ここでやりとりしててもあれだから、Wiki でも用意してよ。それみて興味を持ったら手伝うよ。
念のために確認するけど、テキストを行ごとに分解して、分解した行ごとにマッチさせてはいけない理由があるんだよね?
インデントの例だけに限って言えば、行単位で ^([ \t]+) でマッチして自分で分解するのが妥当だと思うけど。ていうか正規表現検索する必要もないか。
>>136 ありがたいお言葉ありがとうございます。
別のプログラムで忙しく1%の余力でやるつもりなので
気長に見守って頂けたら有り難いです。
>テキストを行ごとに分解して、分解した行ごとにマッチさせてはいけない理由があるんだよね?
既存のライブラリが遅くなるサンプルを作っただけなので、
比較用に作ったという以外に深い理由はありません。
138 :
121 :2012/03/02(金) 19:10:40.67
>インデントの例だけに限って言えば、行単位で ^([ \t]+) でマッチして自分で分解するのが妥当だと思うけど。 行ごとでない正規表現内に改行文字があった場合には ^や$などの行開始記号行末記号を適当に配置して、 行ごとの正規表現に置換するフィルター作るだけでも 実用上は十分な気がしてきたw しかしそれでもなお作らなければならない理由があって、 1、逆方向にリバース検索できること 2、かなり大きいストリームを扱える事 3、強制失敗できること が自分から自分への要求仕様なのです。
141 :
121 :2012/03/04(日) 00:12:36.16
ドモドモ
121応援するぞ無謀でもガンバレ
ドモドモ
144 :
121 :2012/03/06(火) 01:30:17.46
寝てしまってましたがプログラムを書き始めました。 設計はいい加減なままプログラムできちゃうのが一人で開発する場合のいいところです。 でも協力いただけたらなおヤル気が出ます。逆に協力して下さった方のプロジェクトに協力することもできるでしょう。 皆さんも頑張って下さい。
145 :
116 :2012/03/08(木) 01:54:17.12
そこそこにフレームワークが出来上がってきたんだが、 誰かスマホ向け2Dゲーム用フレームワークに興味のある人いないですかね? 協力してくれるような人がいたら嬉しいです(´・ω・)
146 :
121 :2012/03/08(木) 02:07:11.00
Objective-Cの素養は無いので、アンドロイドなら協力してもいいぞ。 こちらが提供できるものGIFアニメーション作成用ツール(作りかけ) スプライトの軌跡をGUIでガンガン作成する事を目的にしていて。 マウスでクリックして点列を与えてやると、滑らかなスプライト曲線にできる。
147 :
121 :2012/03/08(木) 02:09:58.45
訂正:スプライト曲線→スプライン曲線
他の機能はタイムラインごとの速度変化をスプライン曲線を使って作成できる。 予定はモーフィングはできるようにしたい。swfを作成できるようにしたい。 スマホのゲームにも応用したい。でも正規表現以外の他のプロジェクトが忙しい。
LuaとかJavaScriptはあんま好きじゃないな
>>146 暇になって参加したくなった場合はforkしてください。
誰でもforkする事は歓迎です。
ちょっとずつ試しに使用している人はいるみたいだから、
どんどん機能を追加して、簡単にスマホのゲームが作成できるようなフレームワークにします。
151 :
121 :2012/03/17(土) 18:19:27.05
頑張って下さい。ただ他に競合するフレームワークは色々あるでしょう。 社内でクローズドなフレームワークは色々ありそうです。 私もモバイルのウィンドウマネージャのフレームワークを作りましたが公開していません。
152 :
121 :2012/03/17(土) 20:28:11.77
仮に競合があったとしても自分で構築して勉強したことは無駄にはならないと思いますので頑張ってね。
153 :
1 :2012/06/25(月) 23:03:53.09
復帰あげ
俺もニートに戻ったし再開するかな。 でも JunkUtil はある程度作り込んだから、拡張する要素が無いんだよな。
156 :
1 :2012/06/29(金) 20:37:56.07
>>155 SourceForgeってどうですか?
私は前にGoogleCode試したものの、
良く分からなくて投げちゃったんだけどw
>>156 SourceForgeは英語版(本家)と日本語版(日本人向け)があって、日本語版は
日本発のソフトウェアや翻訳プロジェクトが多い。英語書けるなら本家でやれ、って感じ。
当たり前だけどダウンロード数は露出に比例する。
短期間にリリースを繰り返したりしない限り、無名のプロジェクトは埋もれる傾向がある。
ダウンロード数は(想像できると思うが)
万人向けソフト>>>ツール>>>ライブラリ>>>フレームワーク
なので、よほどプレゼンに力入れないと全く使ってもらえないと思う。
ソースコードのバージョン管理は、プロジェクトの規模が小さいうちはむしろ煩雑。
トラブった時には鯖にログインして対処する必要がある。
CVS や Subversion や Git に慣れているのなら、使えばいいと思う。
158 :
1 :
2012/07/02(月) 04:14:23.18 うーん、だめだ。 あれこれ迷走した挙句、 結局Apache Wicketとほとんど同じ考えに至ってしまう。 ちょこっとシンタックスを改善したぐらいじゃしょうもないしな。。。