また、この分離が1,000のテンプレートエンジンで明示的であっても、出力ではそのような分離はなくなります。 なぜサーバーはユーザーが必要とするビューを生成しているが、サーバーは必要ないのかと疑問に思いましたか？ さらに、これらのxssなど、すべてのユーザーに対して表示されるデータをチェックするという問題があります。 タグを閉じませんでした-サイトを殺しました。
私の意見では、唯一のhtmlタスクはbr、strong、aなどを表示することです。 ブロックレイアウトは、HTMLエージェントがレイアウトを作成しようとする試みであるため、ブロックでレイアウトする必要はありません。 そして、子供が親の境界からはみ出すと、階層型ブロックコンテンツのこの考え全体が粉々に崩れます。 一般的にカプセル化をモックするというアイデアを思いついたのはなぜですか？ コードの観点から見ると、WYSIWYGはなんとなく奇妙です。1つのコードが表示され、どこにでも表示できます。 なぜこの曖昧さが必要なのですか？
そして、-999pxなどの形式の松葉杖なしで複雑なブロック状のuiを作成することはできません。 ところで、なぜレイアウトのネイティブサポートがまだないのですか？ すでに低レベルの言語では、Web上よりもインターフェイスの記述が高速です。 注：各デザイナーは、あらゆるOSで長年使用されてきたコントロールの作成/スタイリング/配置についてscられています。 では、なぜ同じものを作成するために非常に多くのジェスチャーが異なるのでしょうか？ それで何？ ところで、なぜ各サイトに独自のデザインが必要なのでしょうか？ これは強制的なものですか？ 同じコントロールを備えたデスクトップUIが退屈しないのはなぜですか？また、デスクトップ上のさまざまな非標準インターフェイスがどれほどマナーが悪いと見なされているのですか？ ええ、はい、悲しい現実から抽象化できるテンプレートエンジンをさらに20個作成できます。 そして、-99999pxのネイルuiをhtmlにしてデザイナー自身に任せます。
コメントは、QMLをブラウザーに埋め込むことを示唆しています。 これ、私見は非常に興味深いアプローチです。 ちなみに、htmlと同じメソッドを使用してqmlを生成する手間はありません。
要約すると、私にとって論理的なWebは次のようになります。
- ユーザーはaddress％sにアクセスします
- サーバーは1つのスクリプト、バイナリ、またはqmlコードを提供します
- コードは、たとえばパブリックにデプロイされたredisからパブリックコンテンツを独立してアップロードします
- クライアントスクリプトは、このデータに基づいて、UI表現も独自に生成しますが、エスケープなどすべてを行います
- ユーザーがプライベート領域を必要とするとすぐに、通常の方法を使用してsession_id / private_codeが与えられます
- クライアントとサーバーのさらなる通信はmqです。 キーmq = session_id。 Redisは最初にそれを処理します。
このようにredisを使用するプロジェクトはいくつかありますが、これは主流ではありません。 アイデア自体は、データが要求された場所と同じ場所に送信されないという点で（そしてその後も）送信されないという点で快適です。 ユーザー自身が必要なデータを繰り返し要求します。 そして、彼が彼らに望んでいることをします。 この場合、少なくとも彼自身のuiを書かせてください。
その結果、プログラマのタスクはたった1つです。適切なデータを生成するビジネスロジックを作成します。 そしてそれだけです。 それはすべてです。 そして、このデータをどう処理するか、どのように、いつ、なぜ、なぜ-10番目のこと。 テンプレートを編集したり、リクエストの順序を変更したりする必要はありません。 その後、web-appのサーバー部分は、最初はデータを受信するための一連のインターフェースのように見えます。 ユーザーのメインページと彼の個人アカウントがどのデータで構成されるかは気にしません。 ユーザーが望む場合-彼は彼のUIを書くでしょう。
そして、私が本当にしたいもう1つの仮定：データとコードは常に分離されるべきです。 そして、ウェブも例外ではありません。
ロールが分割されている場合：
- サーバーは、直接または間接のUI生成には関与しません
- サーバーがデータ出力に従事している
- サーバー認証
- クライアントは、受信したデータに応じてコンテンツのレンダリングを行っています
- 不正なデータの保護に関するトラブルはすべてクライアントにあります。 そして、クライアントは自分自身がデータを要求したため、何をスクリーニングする必要があるかを知っています。
- サーバーは、それだけを損傷する可能性のあるデータのみをフィルタリングする必要があります。 それ以外はすべてクライアントの仕事です。
だから：
- htmlは、UIを作成するのに適した便利なツールではありません
- データとビューからのキャストの生成は、Occamのカミソリで喉に向かって、採算が取れず強制されません。
- 要求-応答モデルは非同期性を破り、両方の当事者を過度に拘束します
- 一般に、すべてのデータの検証という形でのhtmlの結果はうんざりします。ブラウザは受信するデータを事前に知らないため、データに正しいフィルターを設定できません。 そして彼がこれを知るためには、彼自身が明示的に彼らに尋ねなければなりません
今日のほとんどの興味深いサイトは、単なるページではなく、インターフェースとデータ処理メソッドのホストです。 インターフェースをすぐにデータから分離しないのはなぜですか？ 今日、どのサイトも私にその考えを課していることがわかりました。 そして、私は本当にそれが好きではありません。 写真や新しいcss3ルアーを見るのではなく、情報を得るためにサイトにアクセスします（時々非常に美しいとは言いませんが、美しさが気を散らし、最終的には使いやすさが低下します）。 私が探している検索ボタンがページ上の検索であることに腹を立てます。 同じ目的地のすべてのサイトで、ボタンが異なる場所に配置されていることに腹を立てます。 すべてのデスクトップアプリと同じようにサイトを表示したい。
私はホリバーに燃料を供給したくありません、ただ考えてください：今日の技術にはどれくらいの無理な仮定が含まれているのか。 「なぜ私はここにいるの？」のような質問を何回しましたか。もしあなたがすべてを当然のように受け取らなければ、イデオロギーの再編成がすべてをその場所に置く可能性は十分あります。
個人的には、設計作業の多くがUIに収まると思います。 松葉杖と冗長性の焦点はそこにあります。 これはまず第一に便利でなければならないことです。 そして、ここでは発電機を使用することはできません。発電機自体は問題を解決せず、つまずきを助長するだけです。
私はこの機会に機会に皆を祝福し、創造的な成功を願っています。