ASP.NET SPA - 版の履歴

imported>Administrator: /* history.jsとnav.js */

2012-04-17T22:06:46Z

history.jsとnav.js

← 古い版		2012年4月17日 (火) 22:06時点における版
30行目:		30行目:

	==== [[history.js]]と[[nav.js]] ====		==== [[history.js]]と[[nav.js]] ====
	ここまで見てわかるようにASP.NET SPAは大半がクライアントサイド、つまり[[ウェブブラウザ]]で動くわけだが、間違ってリロードや戻るボタンを押すと悲しいことになるのがクライアントサイド通例。それをクライアントサイドでセッションのようなものを実現し、回避してくれる神ライブラリ層がこれ。あるとないとでは何よりデバッグの捗り具合が桁違い。		ここまで見てわかるようにASP.NET SPAは大半がクライアントサイド、つまり[[ウェブブラウザ]]で動くわけだが、間違ってリロードや戻るボタンを押すと悲しいことになるのがクライアントサイドの通例。それをクライアントサイドでセッションのようなものを実現し、回避してくれる神ライブラリ層がこれ。あるとないとでは何よりデバッグの捗り具合が桁違い。

	ASP.NET SPAであれば純正を使うべきだが、独自SPAであれば[[sammy.js]]を使って似たようなことはできる。		ASP.NET SPAであれば純正を使うべきだが、独自SPAであれば[[sammy.js]]を使って似たようなことはできる。

imported>Administrator: /* history.jsとnav.js */

2012-04-17T15:01:39Z

history.jsとnav.js

← 古い版		2012年4月17日 (火) 15:01時点における版
30行目:		30行目:

	==== [[history.js]]と[[nav.js]] ====		==== [[history.js]]と[[nav.js]] ====
	ここまで見てわかるようにASP.NET SPAは大半がクライアントサイド、つまりウェブブラウザで動くわけだが、間違ってリロードや戻るボタンを押すと悲しいことになるのがクライアントサイド通例。それをクライアントサイドでセッションもどきを実現し、回避してくれる神ライブラリ層がこれ。なによりデバッグが捗る。		ここまで見てわかるようにASP.NET SPAは大半がクライアントサイド、つまり[[ウェブブラウザ]]で動くわけだが、間違ってリロードや戻るボタンを押すと悲しいことになるのがクライアントサイド通例。それをクライアントサイドでセッションのようなものを実現し、回避してくれる神ライブラリ層がこれ。あるとないとでは何よりデバッグの捗り具合が桁違い。

	ASP.NET SPAであれば純正を使うべきだが、独自SPAであれば[[sammy.js]]を使って似たようなことはできる。		ASP.NET SPAであれば純正を使うべきだが、独自SPAであれば[[sammy.js]]を使って似たようなことはできる。

imported>Administrator: /* history.jsとnav.js */

2012-04-17T15:00:33Z

history.jsとnav.js

← 古い版		2012年4月17日 (火) 15:00時点における版
30行目:		30行目:

	==== [[history.js]]と[[nav.js]] ====		==== [[history.js]]と[[nav.js]] ====
	ASP.NET SPAであれば純正を使うべきだが、独自SPAであれば[[sammy.js]]~~を使ってもよい。~~		ここまで見てわかるようにASP.NET SPAは大半がクライアントサイド、つまりウェブブラウザで動くわけだが、間違ってリロードや戻るボタンを押すと悲しいことになるのがクライアントサイド通例。それをクライアントサイドでセッションもどきを実現し、回避してくれる神ライブラリ層がこれ。なによりデバッグが捗る。
	というか[[ASP.NET MVC 3]]上でASP.NET SPAモドキを作っているとsammy.~~jsは捗る。~~
			ASP.NET SPAであれば純正を使うべきだが、独自SPAであれば[[sammy.js]]を使って似たようなことはできる。
			というか[[ASP.NET MVC 3]]上でASP.NET SPAモドキを作っているとsammy.jsでもなんとかなっている。

	== 関連項目 ==		== 関連項目 ==

imported>Administrator: /* ASP.NET MVC */

2012-04-17T14:49:39Z

ASP.NET MVC

← 古い版		2012年4月17日 (火) 14:49時点における版
12行目:		12行目:
	=== サーバーサイド ===		=== サーバーサイド ===
	==== [[ASP.NET MVC]] ====		==== [[ASP.NET MVC]] ====
	[[ASP.NET MVC]]~~である必要性を感じないどころか、静的コンテンツだけで何とかなってしまいそうなくらい。~~		[[ASP.NET MVC]]である必要性を感じないどころか、動的コンテンツどころか、静的コンテンツだけで何とかなってしまいそうなくらい。

	==== [[ASP.NET Web API]] ====		==== [[ASP.NET Web API]] ====

imported>Administrator: /* 基本概念 */

2012-04-17T14:48:26Z

基本概念

← 古い版		2012年4月17日 (火) 14:48時点における版
6行目:		6行目:
	[[ファイル:ASP.NET SPA概念図.png]]		[[ファイル:ASP.NET SPA概念図.png]]
	<br style='clear:both'/>		<br style='clear:both'/>
	画像をみてわかるようにハッキリ言ってASP.NET ~~SPAという名前だが、ASP~~.~~NETである必要性はない。~~
	サーバーサイドは[[RESTful]]かつ[[JSON]]でクライアントと通信さえ出来れば何でもよいわけで、[[Ruby]]や[[PHP]]なんかを使ってもSingle Page Applicationは実現できる。SPAの開発者がASP.~~NETの中の人達なのでインテリセンスのコメントの充実度や環境構築の手軽だよ、というだけの話。~~		画像をみてわかるようにハッキリ言ってASP.NET SPAという名前だが、別に[[ASP.NET]]である必要性はない。
			サーバーサイドは[[RESTful]]かつ[[JSON]]でクライアントと通信さえ出来れば何でもよいわけで、[[Ruby]]や[[PHP]]なんかを使ってもSingle Page Applicationは実現できる。SPAの開発者がASP.NETの中の人達なので[[インテリセンス]]のコメントの充実度や環境構築の手軽さ、デバッグの容易さなんかは[[Visual Studio]]が最先端だよ、[[MSDN]]入れよ、というお話。

	=== サーバーサイド ===		=== サーバーサイド ===
	==== [[ASP.NET MVC]] ====		==== [[ASP.NET MVC]] ====
	[[ASP.NET MVC]]である必要性を感じないどころか、静的コンテンツだけで何とかなってしまいそうなくらい。		[[ASP.NET MVC]]である必要性を感じないどころか、静的コンテンツだけで何とかなってしまいそうなくらい。

	==== [[ASP.NET Web API]] ====		==== [[ASP.NET Web API]] ====
	これ重要。		これ重要。

imported>Administrator: /* 基本概念 */

2012-04-17T14:45:49Z

基本概念

← 古い版		2012年4月17日 (火) 14:45時点における版
5行目:		5行目:
	== 基本概念 ==		== 基本概念 ==
	[[ファイル:ASP.NET SPA概念図.png]]		[[ファイル:ASP.NET SPA概念図.png]]
			<br style='clear:both'/>
	画像をみてわかるようにハッキリ言ってASP.NET SPAという名前だが、ASP.NETである必要性はない。		画像をみてわかるようにハッキリ言ってASP.NET SPAという名前だが、ASP.NETである必要性はない。
	サーバーサイドは[[RESTful]]かつ[[JSON]]でクライアントと通信さえ出来れば何でもよいわけで、[[Ruby]]や[[PHP]]なんかを使ってもSingle Page Applicationは実現できる。SPAの開発者がASP.NETの中の人達なのでインテリセンスのコメントの充実度や環境構築の手軽だよ、というだけの話。		サーバーサイドは[[RESTful]]かつ[[JSON]]でクライアントと通信さえ出来れば何でもよいわけで、[[Ruby]]や[[PHP]]なんかを使ってもSingle Page Applicationは実現できる。SPAの開発者がASP.NETの中の人達なのでインテリセンスのコメントの充実度や環境構築の手軽だよ、というだけの話。

2012年4月17日 (火) 14:44にimported>Administratorによる

2012-04-17T14:44:41Z

← 古い版		2012年4月17日 (火) 14:44時点における版
2行目:		2行目:

	[[ASP.NET MVC]]も若干使われているが、土台となるHTMLを送り出すだけで、あとは[[jQuery]]と[[Knockout]]を中心とした[[JavaScript]]でゴリゴリと見た目を加工するのが正攻法な使い方らしい。		[[ASP.NET MVC]]も若干使われているが、土台となるHTMLを送り出すだけで、あとは[[jQuery]]と[[Knockout]]を中心とした[[JavaScript]]でゴリゴリと見た目を加工するのが正攻法な使い方らしい。

			== 基本概念 ==
			[[ファイル:ASP.NET SPA概念図.png]]
			画像をみてわかるようにハッキリ言ってASP.NET SPAという名前だが、ASP.NETである必要性はない。
			サーバーサイドは[[RESTful]]かつ[[JSON]]でクライアントと通信さえ出来れば何でもよいわけで、[[Ruby]]や[[PHP]]なんかを使ってもSingle Page Applicationは実現できる。SPAの開発者がASP.NETの中の人達なのでインテリセンスのコメントの充実度や環境構築の手軽だよ、というだけの話。

			=== サーバーサイド ===
			==== [[ASP.NET MVC]] ====
			[[ASP.NET MVC]]である必要性を感じないどころか、静的コンテンツだけで何とかなってしまいそうなくらい。
			==== [[ASP.NET Web API]] ====
			これ重要。

			=== クライアントサイド ===
			==== [[jQuery]] ====
			[[DOM]]による[[HTML]]の加工と、[[AJAX]]による通信の根幹を担うもっとも重要な部分。

			==== [[upshot.js]] ====
			[[MVVM]]、つまりウェブなのにリアルタイムで事あるごとにサーバーと通信しまくる鬼仕様という関係で、ASP.NET SPAでは[[jQuery]]と[[knockout.js]]の間に[[JavaScript]]で書かれたクライアントサイドのデータキャッシュ機構が搭載されている。

			ASP.NET SPAモドキの独自SPAであれば、キャッシュなどという軟弱なシステムは導入せず、サーバーの増強で乗り切るのが漢。ただし電気の無駄として時代背景に反する諸刃の剣。

			==== [[knockout.js]] ====
			ASP.NET SPAの中でも特に重要な[[MVVM]]を担う部分。

			==== [[history.js]]と[[nav.js]] ====
			ASP.NET SPAであれば純正を使うべきだが、独自SPAであれば[[sammy.js]]を使ってもよい。
			というか[[ASP.NET MVC 3]]上でASP.NET SPAモドキを作っているとsammy.jsは捗る。

	== 関連項目 ==		== 関連項目 ==

imported>Administrator: ページの作成：「'''ASP.NET SPA'''とは、ASP.NET Web APIとJavaScriptにより、ウェブアプリケーションの見た目（ビュー）の処理の大部分はクライ...」

2012-04-09T09:11:42Z

ページの作成：「'''ASP.NET SPA'''とは、ASP.NET Web APIとJavaScriptにより、ウェブアプリケーションの見た目（ビュー）の処理の大部分はクライ...」

新規ページ

'''ASP.NET SPA'''とは、[[ASP.NET Web API]]と[[JavaScript]]により、ウェブアプリケーションの見た目（ビュー）の処理の大部分はクライアントサイド中心でやってしまおうというフレームワークである。SPAは'''S'''ingle '''P'''age '''A'''pplicationの略らしい。

[[ASP.NET MVC]]も若干使われているが、土台となるHTMLを送り出すだけで、あとは[[jQuery]]と[[Knockout]]を中心とした[[JavaScript]]でゴリゴリと見た目を加工するのが正攻法な使い方らしい。

== 関連項目 ==
== 参考文献 ==
<references/>
== 外部リンク ==

{{stub}}