Umi.CMS開発者問題ツリー、遅い成長オプション

プログラマにとって残念なことに、Umi.CMSでプロジェクトを開発した後、次の2つの問題が発生する可能性があります。



1)コンテンツの記入を担当する人にプロジェクトデバイスを説明する方法。

2)保証期間中にプロジェクトの問題を迅速に解決する方法。



Umi.CMSは、実際の問題の解決から十分に抽象化されたモジュールのセットを提供します。 実際、システムで使用可能なモジュールはありません

デフォルトでテンプレートに組み込まれている機能は非常に限られているため、顧客のタスクをすぐに解決することはできません。 特定の問題に対する既成のソリューションの代わりに

必要なソリューションを柔軟に準備できるツールのセットが提供されます。



そのような柔軟性には反対側があり、個々のプログラマーのトレーニングおよび思考特性のレベルに大きく依存します。

タスクはさまざまな方法で解決できます。また、この方法は非常に重要であるため、使用するすべての人に実際の問題が発生します。



コンテンツを埋める人は、それがプロのコピーライターであろうと顧客の未知のパフォーマーであろうと、彼のタスクだけを解決したいのであり、代わりに彼は

特定のプロジェクト実装の機能に適応するには長い時間がかかります。 非標準的なアプローチを必要とするプログラマーまたは複雑なプロジェクトの不十分な資格、

Umi.CMS管理パネルでは、さまざまなデータタイプの多数のパラメーターを持つ相互接続されたページの拡張ツリーが成長するという事実につながります。



そのようなツリーで迷子になるのは非常に簡単で、コピーライター向けに準備されたドキュメントでさえ、事故に対して保険をかけることはできません。 重大なエラーが発生した場合でもツリーを最適化するという問題が発生します

サイトを復元する可能性はまだありました。 そして、テンプレートとマクロのコードに干渉することなく、管理パネルによってのみ望ましいです。



ページツリーの衝撃的な成長は、次の理由により発生します。



1)システムに登録されている多数のテンプレート。 たとえば、「Structure」モジュールの設定では、メインページ、ニュース、投票、フォーラムなど、あらゆる場面でテンプレートが登録されます。

明確な目的を持つテンプレートに加えて、「当社の特別キャンペーン」または「レポートフォームNo. 22」という形式の専用テンプレートを登録できます。

新しいページを作成するとき、コピーライターは大きなリストからテンプレートを選択せざるを得ません。それはそれ自体不快であり、テンプレートの目的が明確でない場合、特定の困難を引き起こす可能性があります。



原則として、多くのテンプレートがUmi TPLテンプレートエンジンを使用して登録されますが、一部のプロジェクトでは、XSLTテンプレートエンジンを使用するほどの折lect的なデザインが採用されており、

追加のパターンを登録します。 XSLTテンプレートエンジンを使用すると、少なくともまったく異なるテンプレートを作成できます。



2)個々のデータタイプ用に作成された多数のパラメーター。 たとえば、カタログまたはオンラインストアを表示するためのパラメーターを持つ特別なページに加えて、パラメーターのグループを作成して、カタログの特定のセクションを表示できます。

問題を悪化させるために、開発時間を短縮し、特に重要なページのパラメーターの選択をこれらのページの識別子に結びつけるプログラマーの欲求が問題を悪化させる可能性があります。



多くの場合、「オンラインストアの必須パラメータ」という形式のページが特定の識別子で作成されます。 このページのプロパティにアクセスするには、プログラマー

テンプレートで直接この識別子を規定します。 コピーライター、または奇妙なことに、それはより頻繁に起こりますが、未知の顧客実行者が誤ってこのページを削除します。 オンラインストアが故障し、管理パネルで同じタイプのデータのページを作成するだけです

その識別子はテンプレートで指定された識別子と一致しないため、状況は保存されません。 プログラマーを引き付け、パターンを分析する必要があります。そのようなパターンがほとんどなければ良いでしょう。



3)プロジェクト機能の実装に使用されるツリーページの密接な関係。



特定の製品の写真のギャラリーを表示するタスクがあるとします。写真の数はいくつでもかまいません。 これは次のように実装できます。

画像ギャラリーが作成され、ページツリーの製品ツリーに埋め込まれ、その子ページになります。 テンプレートは子ギャラリーを検索し、ページに表示します。 コピーライターにとって、すべては非常に簡単です。 とにかく、彼はギャラリーを作成する必要があり、その製品の目的は、ツリーを通して適切な場所に移動することです。

ただし、ギャラリーが目的の製品に移動されない場合、製品テンプレートはそれを見つけられないため、何も表示されません。



製品プロパティ「ツリーへのリンク」を設定して特定のギャラリーを指定した場合、その動きは写真ディスプレイに表示されませんが、コピーライターは追加のプロパティを追加する必要があります。



これらのオプションはいずれも最終的な問題を解決しますが、欠点があります。



コンテンツを埋める際のエラーはプログラマーの生活を著しく複雑にする可能性があることを理解して、プログラマーは特定のプロジェクトで可能な限りページツリーを事前に最適化することをお勧めします。

そして、仕事のためにシステムを準備する段階でこれをすぐに行う必要があります。



1)可能性がある場合は、XSLTテンプレートエンジンを使用することをお勧めします。これは、システムに登録されているテンプレートの数を比較的簡単に減らすことができるためです。 これにより、コピーライターが難しい選択をする必要がなくなり、

プログラマーは、間違ったテンプレートを割り当てることによって発生したエラーを探して修正する必要がありません。 もちろん、同じTPLテンプレート内にさまざまな機能の出力を実装することもできますが、カスタムマクロとJavaScriptコードを記述するには多大な労力が必要です。 このアプローチの効率にもかかわらず

開発のスケジュールと複雑さが大幅に増加します。



2)Umi.CMSのプログラマーの作業は、新しいデータ型、および新規および既存のデータ型のプロパティの作成に限定されるため、「データテンプレート」モジュールで必要なすべての作業を事前に行うことをお勧めします。

パラメーターページのデータ型の作成には特に注意が必要です。 プロジェクトで特定のパラメーターを使用する場合、それらを多くの異なるページに配置するのではなく、目的のプロパティグループを使用して別のデータ型を作成することをお勧めします。

この種のページ自体は、誤って削除される可能性を減らすために、1つの場所にグループ化する必要があります。 これらのページに個別の親ページを作成できます。



パラメータの選択をページ識別子にリンクできないという点で、特別なデータ型が便利です。 代わりに、uselリクエストを実行して、パラメーターを持つページを検索できます。



たとえば、オンラインストアの設定ページがあります。 ページ自体ではなく、152などのデータ型の識別子が必要です。次の形式のgetSpecial.xml Uselリクエストを作成しましょう。



<?xml version="1.0" encoding="UTF-8"?> <selection> <target expected-result="pages count" force-hierarchy="1"> <type id="{1}" /> <category depth="{3}">{2}</category> </target> <limit page="{p}">{6}</limit> <sort order="{4}">{5}</sort> </selection>
      
      







次に、usel:// getSpecial / 152/0/0 / ascending / id / 1 /のようなクエリは、このデータ型の最初のページを返します。 コピーライターがこのページを誤って削除した場合、テンプレートを妨げることなく、管理パネルで直接新しいページを作成できます。 これは特に便利です

コピーライターがデータテンプレートモジュールにアクセスできないようにするには、個々のユーザーにその権限を制限して登録します。



プロジェクトテンプレートでは、ページ識別子をまったく使用しないことをお勧めします。 多くのページは、データ型またはUselプロトコルを使用した特別なプロパティで検索できます。



ページ識別子だけでなくデータ型識別子のテンプレートでの言及を減らすために、変数を積極的に使用できます。 例えば



 <xsl:variable name="commonParamsId" select="document('usel://getSpecial/152/0/0/ascending/id/1/')/udata/page[1]/@id" /> <xsl:variable name="commonParams" select="document(concat('upage://', $commonParamsId))/udata" />
      
      







テンプレートで最後の変数をさらに使用すると、データ型識別子152を使用する必要がなくなります。ただし、コピーライターがデータテンプレートにアクセスして削除した場合でも、すべてをやり直す必要があります。



3)ページの密接な相互接続は特定の問題を引き起こす可能性があるという事実にもかかわらず、その助けを借りて、「ここで好き」という原則に基づいてコピーライターのトレーニングを整理するのは簡単です。データのテストサンプルは非常に明確です。

商品の写真とともに例に戻りましょう。 ギャラリーのリストを含む別のコンテナページを作成し、製品の「ツリーリンク」プロパティを作成して正しいギャラリーを選択できます。 ギャラリーが割り当てられている場合、削除されるまで、製品ページに定期的に表示されます。

ただし、ギャラリーは別のブランチにあるため、製品との関係は明らかではありません。 コンテンツを記入するときは、製品がそこにあり、ギャラリーがどこかにあることを考慮する必要があります。 さらに、大きなページツリーから「ツリーリンク」を選択するのは不便かもしれません。

ギャラリーが製品に埋め込まれている場合、それらの関係は明らかです。



開発中にコピーライターの利便性を気遣うことの重要性を過小評価しないでください。もちろん、あなたのプロジェクトが修正のためにあなたに戻ってこないこと、そして説明する必要がないことが確実でない限りです。

コピーライターの決定の論理。 ドキュメントに加えてページツリーを最適化することは、コピーライターをプロジェクトに適合させる難しさを軽減し、デザインに関する質問の大部分を削除する方法の1つです。

その結果、プログラマはプロジェクトの技術サポートの段階で不必要なリスクを取り除きます。



All Articles