問題タブ [seaside]

継続の概念を理解するのに苦労しています(Seaside with Smalltalkで使用されているように)。ウィキペディアのスニペットには次のように書かれています。

「...ファーストクラスの継続を参照してください。これは、プログラミング言語に任意の時点で実行状態を保存し、プログラムの後の時点でその時点に戻る機能を与えるコンストラクトです...」

これは、割り込みをプログラミングするときにアセンブラ プログラマが行うことを表現する別の方法ではないでしょうか。または、私は完全にポイントを逃しました!

私は最近、Seaside+Squeak で Web アプリケーションを開発していますが、素晴らしい経験であることがわかりました。Seaside は実際に他のどのフレームワークよりも優れており、より高いレベルの抽象化 (他のフレームワークが処理する HTTP 要求/応答サイクルと HTML テンプレートの上) で作業しているように感じます。

そうは言っても、私は Seaside コンポーネントについて少し混乱しています。最近、コンポーネントにオブジェクトのリストを表示する必要がありました (stackoverflow のフロント ページに似ています)。最初は各オブジェクトをコンポーネント (WAComponent のサブクラス) にしましたが、これは非常に無駄であることが判明し、#children を親コンポーネントで動的に設定して機能させる必要がありました。次に、レンダリング オブジェクト (WAComponent のサブクラスではなく、コンポーネントのように renderContentOn: の代わりに renderOn: を使用してレンダリングするオブジェクト) を作成しようとしました。これは機能しましたが、コンポーネントが (#session を使用して) できるように、セッション オブジェクトのグローバル状態にアクセスできなくなりました。次に、現在の Seaside セッション オブジェクトへのアクセスを任意のオブジェクトに与える「WACurrentSession 値」を発見しました。これでレンダリング オブジェクトを作成できるようになりました。加えて、

call/answer または backtracking 状態が必要である以外に、レンダー オブジェクトよりもコンポーネントを使用する理由が他にあるでしょうか?

過去数年間Seasideを使用してきたので、テンプレートシステムは悪いコードの臭いであることがわかりました。html、css、javascriptを生成するためにSeasideキャンバスシステムに似たものを使用する.netのフレームワークはありますか？または、テンプレートで見つけがちな重複を回避する方法。

[編集]NHamlは私が探しているものに近づいていません。重要なのは、（X）HTMLの省略形ではなく、コードをリファクタリングして再利用できるプログラミング言語を使用することです。

Seasideでは、次のようになります:(キャンバスはhtml [およびjavascript]のビルダーです）

このメソッドでは、2つのサブルーチンを呼び出します

1つ目は、選択したフォーム要素の周りにデコレータを呼び出します。

これにより、ほとんどすべての重複を排除できます。

そのため、私はSmalltalkを約6か月間使用しており（SqueakとPharo）、主にデータ分析を行っており、最初のSeasideアプリを起動しようとしています。それで、そこにいるすべてのSmalltalkersへの私の質問は、あなたのお気に入りの永続化ソリューションは何ですか？マグマ、GOODS、GLORPを見てきました。私は長年のPythonハッカーなので、ORMを取得しますが、オブジェクト指向のように見えるため、MagmaまたはGOODSの方が優れたソリューションのようです。

簡単なメモ：アプリを複数のVMにまたがってスケーリングしたいので、データをイメージに保存するだけでは実際には機能しません。

ありがとう！

Navision を使用している人がいるかどうかはわかりません。しかし、私たちは最近それで苦労しており、フィールド名を動的に関数に渡そうとしています。

それ以外の

私は何かをしたい...

ここで、文字列 FieldName = "Transmission"

誰かが私を正しい方向に向けることができますか?

シーサイドは「異端のウェブフレームワーク」として知られています。それを異端にするポイントの1つは、それが多くの共有状態を持っているということです。しかし、それは私の現在の理解では、簡単なスケーリングを妨げるものです。

一方、Ruby on Railsは、可能な限り少ない状態を共有します。現代のsmalltalkvmsに比べて犬が遅い場合でも、かなりうまくスケーリングすることが知られています。flickrはphpを使用しており、非常に大きなインフラストラクチャに拡張されています...

では、Seasideのスケーリングの経験はありますか？

Swazoo と Komanche の一般的なパフォーマンスの違いと、Seaside のパフォーマンスの違いを知りたいです。特に、なぜ、どのような状況で、どちらか一方を優先する必要があるのでしょうか?

GLASSに本当に興味があります。無料版の4GBの制限は私が心配しています。特に次のレベル（7000ドル）の価格を考えると。

1. これは主観的で変動する可能性があることは知っていますが、誰かが私のために4 GBのGLASSで何が得られるかを日常的に説明できますか？たぶんビジネスの例です。4 GBは、私が思っているよりも多くのストレージを取得する可能性があります。そして、それについて心配する必要はありません。

2. 私のアプリでは、一部のメッセージに最大5MBのサイズの添付ファイルがあります。これらの添付ファイルをGemstone内ではなく、オペレーティングシステム上のファイルに直接保存することで、4 GBのGemstoneスペースを節約できますか？はいと思います。

SeasideのjQueryUIにロードする必要があるパッケージはどれですか？

現在、私はこれらをインストール/ロードしています：

• ファロシーサイドワンクリック画像
• jQueryリポジトリをMonticelloブラウザに追加しました（Squeaksource-jQuery）
• ロードされたjQuery-EL.10.mcz

ただし、この例を実行すると、「MessageNotUnderstood：WARenderCanvas>>jQuery」というエラーが発生します。

Pharo と Seaside を使用して小さなプロトタイプ Web アプリを作成しました。次に、このアプリを標準の Linux ビルドにデプロイできることをスーツに示したいと思います。アプリのほとんどが JAVA/Apache ベースであるため、ヘッドレスで実行される CentOS、Ubuntu Server、および Gentoo を組み合わせて使用​​しています。ポート 80 と 443 のみが外部に公開されています。

Seaside/Smalltalk サーバー側アプリをホストするときの経験は?