仕事無いのかよ

無いわなぁ

>>348
＞カタログ表示してクリックで拡大とか（工数合わないだろｊｋ）
それは一応、モーダルなChildWindowで商品詳細情報を表示させる予定です。
サードパーティーのコンポーネント（葡萄街とか）なんて恥ずかしくて使えませんｗ
それでもショッピングサイト側の対応だけなら工数は数日で済む話なんですが、
DBの登録やメンテをする方の販売業務管理アプリ側が面倒になるんだよな。

あとは通常のvarbinaryに収まらない8000バイト超の拡大画像をどうするかだな。
varbinary(MAX)で格納するか、SQL Server2008からのFileStreamデータ型に
するか、マンドクサくて悩むぜ。

楽しそうなことしてんな

別に組んだ管理プログラムでWCFサービスを通して商品個別にサムネイル画像をSQL上の
商品マスタのvarbinary列に登録したり表示する事が可能になった。
しかし、Silverlightのショッピングサイトで ListBox > ListBox.ItemTemplate > DataTemplate > Image の
Sourceにサムネイル画像のPNG/JPGのバイナリデータが直接バインドできねぇ・・・ orz
ファイルシステム上のサムネイル画像ファイルのURIか、生バイナリをStream化したものならSourceへ
簡単にバインド可能なんだけどな。EDMデータのプロパティから直接はムリポ？！　オワタ

ええい、もう寝る。

　 ＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／
￣￣￣￣￣￣￣

>>353
> サードパーティーのコンポーネント（葡萄街とか）なんて恥ずかしくて使えませんｗ
グレープシティーのコンポーネントってよろしくないの？

うまく使えないから恥ずかしいんじゃないかな

自作厨か

>>356-357
実務では使うことも考えるけど、今は個人トレーニングでデザインパターンの
引き出しを整理しているから使いたくないだけだよ。
構築しているショッピングサイトもSilverlightノウハウのための試験的なもの。

なぜ恥ずかしいんだ？

>それは一応、モーダルなChildWindowで商品詳細情報を表示させる予定です。
>サードパーティーのコンポーネント（葡萄街とか）なんて恥ずかしくて使えませんｗ
>それでもショッピングサイト側の対応だけなら工数は数日で済む話なんですが、
>DBの登録やメンテをする方の販売業務管理アプリ側が面倒になるんだよな。
と業務に関して書いているのに

>今は個人トレーニングでデザインパターンの
>引き出しを整理しているから使いたくないだけだよ。
>構築しているショッピングサイトもSilverlightノウハウのための試験的なもの。
と個人トレーニング云々とか、前後内容が全く一貫性ないんだが。

>>360
本当のところは、今の俺に年度経費や予算が使えない事が恥ずかしいんだよ。orz

>>361
実際に動く模擬システムはコンペで必要だと思ってトレーニングを兼ねて構築している。

P.S.
サムネイル表示の件は結局、SilverlightクライアントがWCFサービスから取得したedm形式の
商品マスタ（IList<T>コレクション）を foreachでブン回しながらMemoryStreamを作成して、
Viewへのバインド専用の商品一覧Classデータに変換して対応した。パフォーマンスも悪くなかった。

MVVMフレームワークの話題が全く上がらないけど
フレームワーク使って開発してる人って少数派なのかね？

MVVMってフレームワークそのものじゃなくてフレームワークのアーキテクチャだと思うんだが

ただのパターンだよ

逆にMVVM使って組まない人間の方が少ないと思う。

そうかぁ？MVVM結構面倒だと思うんだが

MVVM使わない人はイベント直結でゴリゴリかいてるん？
DIコンテナとか使ってない？

やっぱりMVVMフレームワーク自体かなりマイナーなんだな。
一応、MVVMフレームワーク一覧へのリンク
http://www.japf.fr/2009/11/discover-compare-existing-mvvm-frameworks/

だからそれってMVVM使ってるフレームワークでしょ？

>>368
結合度が MVVM の想定してるのより粗いとかじゃね？
Command 使わなくてイベントハンドラに Model 操作するコードビハインド入れちゃったりとか。

SilverlightならMVVMなんかいらないようなちょっとしたアプリの方が多いんじゃないか

マイナーというかWPF限定だもの
言い方違うだけでMVCと同じ概念だからこの辺を使った事ある人は好んで使ってると思うよ

MVVM提唱者もなんでもかんでもMVVMにすんなって言ってたしな。

なんでもMVVMにするなはUIを使用しない共有ライブラリ等の話でしょ…。

葡萄は恥ずかしいだろ

葡萄の特に無くても困らないカスタムコントロールって、素人以外に買って使う人は
居ないんじゃないかな。プロは自分から進んで使わないだろう。
これが無きゃ何もできないってことは、機能や仕様の仕立て、そしてデザインや
プログラミングも十分に出来ない証になっちゃうから。

そんな基準で選んでる時点でプロでも何でもねえよ

だって、.NETのコントロールそのまんまじゃん。あれで数十万円とはボッタ栗ｗ
デモやサンプルを見てみたけど、中国人学生がSilverlight3のβ版時代に頑張って作った
ようなものばかりだし、どれもSilverlight4では標準になって不要になりそうなものばかり。
Silverlight 2 の頃にbasicHttpBinding以外をサポートとか、クライアントサイド印刷をサポート
ってなら存在価値も分るけどね。

一応、MVVMフレームワーク一覧へのリンク（ｷﾘｯ

>>370
MVVMパターンに則ったフレームワークを
MVVMフレームワークと言って何か語弊でもあるのか？

>>380
一般的ではない俺俺用語

今時やらなくていいことはやらないのが有能さの証だと思うけどな。
「これぐらいなら作れるから作る」なんてのは自作厨ですよね(^o^)

>>378
帳票印刷機能と普通の印刷機能の違いがわからないってことは素人か？

>>382
知らなかった。それ使うとノンコーディングで業務アプリができちゃうのか。

>>384
ああ、あなたアホなんですね。成程。

アッサラームのボッタクリ商人思い出した

自作厨って、おいｗｗｗ
Visual C++ で C/C++言語 + MFC だった頃じゃあるまいし、「作る」って程でもないだろ。
XAMLとC#かVBのコードを、例外に気を付けながら順序良く「記述」するだけじゃん。

葡萄の商品を、商店などの個人事業主や営業所がエンドユーザーコンピューティングで
自前向けのシステムを組むために使うってんなら話は別だ。
むしろ賢く積極的に使ってほしいケースだと思うよ。

ただし、システムインテグレータとして他社にシステムを組んでいる身で葡萄の商品を
持ち上げるなら、情報弱者かつ英文弱者で法務弱者だろう。
安易に使うと権利関係が複雑化して、不具合サポートや保守規定を邪魔するだけ。

はい、情弱認定でましたー

グリッドやらチャートやらの基本的な部品を買うより造った方が安いとか
底辺レートで仕事してる奴以外は常識的にありえんし

だから、使い方理解するのが面倒だから作ったほうがはえーって人なんでしょ。

> Visual C++ で C/C++言語 + MFC だった頃じゃあるまいし、「作る」って程でもないだろ。
> XAMLとC#かVBのコードを、例外に気を付けながら順序良く「記述」するだけじゃん。
動けばOKレベルならともかく、きちんと開発すれば、チャート部品ひとつとっても
何十人日という工数が掛かる。それはC++だろうがC#だろうがXAMLだろうが同じこと。
Silverlightに標準で付くグリッドやチャートは、市販コンポーネントほど気の利いた
仕様じゃないから代用にはならない。
本当に仕事でプログラム書いた事あんのか？

ところでSL3は動的生成したビットマップをPNGやJPEGで
保存することってできる？

>例外に気を付けながら順序良く
ここらへんからして素人臭い

せっくす

>>391
いや、普通のSIerなら、カスタムコントロールのストックくらい、ソフトウェア資産として
保有しているものじゃないかと思って。。。
俺も昔、C/C++時代にDLLとインポートライブラリとヘッダを汎用ソフトウェア部品として
ライブラリ登録して、毎度毎度、1から作り直すなんてことはしていなかったけどな。

>>393
えっ

最近SLで案件こなすようになったけど
これ効率よく稼げていいね！
SLのプラグインのインストール絞る人には
何言ってんの？ブラウザでアプリ使いたいんでしょ？
とすごめばOK

テスト

>395
売ってる物をわざわざ作り直す行為そのものが無駄だって言われてんだろ。
市販コンポーネントで要件を満たせないなら作るだろうけど、そういう話じゃなさそうだし。
「コントロールを社内で作ってライブラリ化します」なんて作業にどれだけ付加価値がある？

>>398
多分素人か駆け出しだからそっとしておいてやれ。

大事なお年玉使ってコンポーネント買うくらいなら、自分で作ったほうがいいだろ。