本質・可能性に迫ります。持っているパワーの一端をお伝えできればと考えています。して、また、システム開発の基盤として、非常に有望な選択肢であると考えています。方々や個人で活動する方々の参考になりましたら幸いです。コンテンツを取り扱うものとして、これまでの「node」に代わり、「Entity」という概念・実装が導入されました。「Entity化するDrupal」というエントリーでも、主として一般的な観点から、既に取り上げています。踏まえて、サイトオリジナルの「Entity」を導入することに関して、そのメリット・デメリットを考察したいと思います。して格段の進化を遂げているように感じる。おける最も大きな変更点ではないか、と考えている。開発を行うためには、まず、この「node」について深く理解することが必須であった。開発を行うためには、まず、この「Entity」について深く理解することが必須であるのかと問われれば、どうであろうか。答えは必ずしも「YES」というわけではないだろう。site(通常のサイト)」であれば、これまで同様「node」を用いて「node」をベースにして様々なコンテンツタイプを作成・利用すればよいのである。「node」は、これまでどおり、非常に優秀で柔軟性のあるコンテンツタイプである。それでは、「Entity」は無用の長物なのかと問われれば、どうであろうか。その答えは完全に「NO」である。大規模なサイト・より高度なサイト・より複雑なサイトを構築・運用しようとする場合には、この「Entity」を利用することにより、さまざまなメリットを得ることができると考えられるのである。site(先進的なサイト)」の開発・運用に、より対応できるようにするという意図があるように感じられる。site」をそのターゲットとするように進化していくものと思われる。前段において「Entity」について解説を試みた後(Section.2〜7)、サイトオリジナルの「Entity」を導入することに関して、そのメリット・デメリットを考察することとする(Section.8〜16)。※当コラムは、「スライドショー」になっています。クリックにより、ページ遷移無しで、瞬間的に「次のセクション」に切り替わります。クリックにより「最後のセクション」に切り替わります。おいては、コンテンツを取り扱う概念・実装は「node」のみであった。その特徴は、次のように整理することができるだろう。type)を作ることができる。type)を作ることができる。様々な機能を実現するためのプログラム処理を提供する複雑なものを開発・設置することが可能である。おけるコンテンツに関する概念構造を整理すると、次ページの図のようになる。「オブジェクト指向プログラミング」における「クラス」と「インスタンス」の関係性に似ていることに気付かれるかもしれない。ページ」がある、ということになる。「オブジェクト指向プログラミング」における「インターフェース」のように機能しているとも言える。おいては、コンテンツに関する概念構造を整理すると、次ページの図のようになる。「オブジェクト指向プログラミング」に喩えて理解することができる。比較すると、以下のようになる。おける「Entity」がどのようなものであるかが明確になってきたものと思われる。個別のサイトにおいてサイトオリジナルの「Entity」を利用するメリット・デメリットについて考えていきたい。コミュニティにおいても、まだ手探りの状態にあるようである。一般的には、次のような場合に「Entity」を利用することが適していると言われている。独自の権限処理・ワークフローを組み込む(プログラミングする)ということなる。用意するデータベースではなく、独自のデータベースを使用することになるため、レガシーなデータベースをそのまま使用することが可能になる場合もある(ただし条件がある)。処理を軽くする(サーバの負荷を軽減する)ことが可能となる。movie」が必要であるような場合、「node」では実現することができないが、オリジナル「Entity」を利用することにより、それを実現することが可能となる。大規模サイトにおいてオリジナルの「Entity」を導入することのメリット・デメリットについて考察してみたい。Controller)」に基づいて考えてみる。3つの部分に分割して設計・実装する技法である。主として、開発者(テーマ制作者を含む)による実装が担うということになる。type」というバンドルタイプを考えてみる。ついてはサイト開発者が独自に開発を行う必要がある。type」を想定通りに出力・機能させるために、次のような開発作業が必要になる。関して、上記(A)〜(E)のような作業が必要となる。ここでの問題点は、サーバーサイドのプログラミングコードが、(A)(B)(C)に分散して設置されることになる点である。対してマイナスに影響することになる。ようなメジャーなバージョンアップに対応する場合(upgrade)にも、テーマにおいては個別的な対応になりがちであるために、非常に多くの労力が必要になるという点でも問題になりやすい。サイトの更新に関する困難度がアップし、結果としてサイトの柔軟性が失われ、サイトが硬直化し、ユーザーから見た時のサイトの鮮度が落ちることに繋がりかねないという危険性を孕んでいる、ということである。type」というバンドルタイプを、サイト独自の「Entity」を用いて構築する場合を考えてみる。ついても、サイト開発者が独自に開発を行う必要がある。前ページの(A)〜(E)に関しては、その全てを、独自に開発する「Entity」モジュール内に一括して設置することができる。いうメリットを獲得することができるわけである。これらのメリット・デメリットをどのように勘案するかということになる。運用段階において、如何にユーザーの方のニーズに対応するように更新していくかが大切であるとの認識が共有化されつつあり、この点においては、独自の「Entity」の導入はメリットをもたらすと言えるであろう。サイトの更新が容易化・迅速化し、結果としてサイトのユーザー対応への柔軟性がアップし、ユーザーから見た時のサイトの鮮度を高く保つことが可能になる、ということである。現実的には、(D)(E)については、テーマにおいて設置することになる場合が多いかもしれないが、それでも、サーバーサイドのプログラミング部分については一括管理することができる。Section.13次に「リクエスト処理面」について考える。「node」は、非常に豊富な機能を有しているが、それは裏を返せば、そのために、様々なプログラミング処理やデータベースアクセスが発生している、ということである。おいて言及したことの繰り返しになってしまうが、e-コマースにおける「商品(products)」のように、非常に頻繁なアクセスが生じる場合で、なおかつ、「node」の処理に付随する他の様々な付加的な機能が不要な場合には、オリジナル「Entity」を利用することにより、データベースアクセスを単純化して、かつ、必要な処理のみを実装することにより、リクエストに対する処理を軽くする(サーバの負荷を軽減する)ことが可能となる。この点も、オリジナルの「Entity」を導入することの大きなメリットであると言える。Section.143番目に「データ保守面」について考える。モジュールが用意・管理するデータベースに保存されることになる。新規にフィールドを追加している場合には、そのフィールドのデータに関しては、そのフィールド用モジュールが用意・管理するデータベースに保存されることになる。いう処理系との「結合性」が高くなるということを意味している。アプリケーションフレームワークであり、開発も非常に活発に進展しているようである。用いるという選択に関する不安材料は少ないと言える。強力なライバルが登場するかもしれないことを、誰も否定することはできない。可能な限りその可搬性を確保しておいた方が良いということである。重要なデータに関しては、オリジナルの「Entity」を用いて取り扱うという選択肢は大いに考慮すべきであると考えられる。用意・管理するデータベース(=テーブル)ではなく、その「Entity」モジュールが用意・管理するデータベース(=テーブル)に保存するのである。切り離して利用可能となるのである。この観点からは、オリジナル「Entity」を導入する場合には、できる限り、フィールドモジュールによる追加フィールドの利用は最小限に留めた方が良いという開発方針が導かれることにも留意しておきたい。Section.154番目に、「コンテンツ作成面」について考える。考えて開発されたオリジナル「Entity」であれば、サイト管理者やコンテンツ制作者のコンテンツの作成・更新作業を効率化することができるということである。おいても、オリジナルの「Entity」により独自のワークフローを導入することができるということで言及したが、特に、コンテンツ制作者・新規コンテンツの制作数が多い場合や更新頻度が高い場合には、その効果が累積することにより、大幅な効率アップが期待できるため、大きなメリットとなると考えられる。Section.16以上、4つの側面から、オリジナル「Entity」導入に関するメリット・デメリットを考察してきた。結論としてまとめると、オリジナル「Entity」導入に関しては、次のように考えることができる。関係性を「疎」の状態にして、重要データの可搬性を確保することができる(4)独自のワークフローを導入する、それによりコンテンツ作成・更新作業を効率化することができるというメリットを得ることができる。以上を勘案した上で、メリットが大きいということであれば、オリジナル「Entity」を導入するメリットが小さいということであれば、これまで通り「node」を使うという判断になるであろう。これは、オリジナル「Entity」導入に関する、一般的な利用方法に限定した判断フレームワークである。今後より有用・有益な活用方法が発掘・提案される可能性もある。先進的なサイト管理者の方は、その辺りへの目配りをしておくと良いかもしれない。最後までお読みいただき、ありがとうございました。読者の皆様にとりまして、多少なりともお役に立つものとなりましたら幸いです。対策を組み込んでいるという、もう一つの、大幅な改善点を有しています(一般的にはこちらのインパクトの方が大きいかもしれません)。インジェクション対策となる、わけです。正式リリース」に追記しています。Byこのページにつきまして、お問い合わせ・ご相談・ご意見等をお待ちしております。コンタクトすることができますので、お気軽にご連絡いただけましたら幸いです。印が付いているのは、必須項目です。単独の有料電子新聞としては、WSJ(非公式推計で90万人)を抜いて、世界最大規模ということになりそう。契約数の増加には、米国外での読者増加も貢献とのこと。レスポンス」の3つを等しく重視すべき、とのこと。よる「ものの見方とモノクロ写真」に関する哲学的考察も面白い。現象学する氏の今後の写真にも期待。工業用レンズ(産業財)のノウハウを消費財用に活用したとの事。引退技術者の活用など、老舗ブランドにおける技術承継の事例としても興味深いです。ModuleTransNetCreation(トランス・ネット・クリエイション)。