PowerCMS™

PowerCMS ブログ

ホーム > PowerCMS ブログ

テンプレートのよしあしを決めるものは何でしょうか。

人によって答えが違うと思いますが、よいテンプレートについては、多くの場合は早いテンプレートやサーバーへの負荷が少ないテンプレートを、わるいテンプレートは逆に時間がかかったりサーバーの負荷が高いテンプレートをあげられると思います。(期待する出力が得られるテンプレートや再構築を行うとエラーが発生するテンプレートは、よしあし以前の問題です)

しかし今回とりあげる「よいテンプレート / わるいテンプレート」は少し視点が異なります。

PowerCMS 製品サポートではテンプレートの書き方はサポートの範囲外となりますが、サポート対応の過程で多くのテンプレートを拝見します。 多くのテンプレートを拝見してきた中で培った「よいテンプレート / わるいテンプレート」は下記の二点です。

  • 適切なテンプレート / 適切でないテンプレート
  • メンテナンスが行いやすいテンプレート / メンテナンスが行いにくいテンプレート

見出しにぴんと来ない方もお付き合いください。

適切なテンプレート / 適切でないテンプレート

適切なテンプレートとは「記事の一覧を出力したいので MTEntries タグを使う」ということ意味ではありません。ここでいう適切なテンプレートは状況や場面に最適なテンプレートです。

例えば記事の一覧 5 件を下記のような HTML で出力する要件の場合、どのようなテンプレートを記述しますか?

<$MTTemplateNote value="出力例"$>
<ul>
    <li>記事1</li>
    <li>記事2</li>
    <li>記事3</li>
    <li>記事4</li>
    <li>記事5</li>
</ul>

次のテンプレートを書きました。

<$MTTemplateNote value="テンプレートの記述例"$>
<MTEntries limit="5">
    <MTEntriesHeader>
        <ul>
    </MTEntriesHeader>
        <li><$MTEntryTitle$></li>
    <MTEntriesFooter>
        </ul>
    </MTEntriesFooter>
</MTEntries>

※ 視認性を高めるためインデントを調整しています

いいですね。万能な記述、どこへ出しても恥ずかしくないテンプレートです。新人が書いてきたら誉めてあげてください。

しかし、もし下記の要件があった場合はどうでしょうか。

  • ウェブサイト(ブログ) には記事が最低1件、常に公開されている
  • 運用で記事の削除や非公開化は行わない

この要件を前提とした場合、テンプレートの記述は次のように修正できます。

<ul>
    <MTEntries limit="5">
    <li><$MTEntryTitle$></li>
    </MTEntries>
</ul>

※ 視認性を高めるためインデントを調整しています

修正前のテンプレートでは 記事が 1 件も公開されていない状況を想定して MTEntriesHeader と MTEntriesFooter タグを使い ul タグだけが出力される状況を回避していますが、記事が 1 件も公開されていない状況が存在しないのであれば ul タグは常に出力される前提で書くことができます。

これが状況や場面に最適なテンプレートです。

いやいやそんな要件ばかりでない、そのような意見の方が多いと思います。たしかに修正前の記述は万能でどこでも使えるテンプレートだと思いますが、出力したい内容が複雑なケースを考えてみましょう。

例えばカテゴリとそれに属する記事の一覧を出力したい場合、カテゴリがないときや記事がない時を考慮すると次のようなテンプレートを書くと思います。

<MTCategories show_empty="1">
    <MTIf name="__first__">
        <ul>
    </MTIf>
    <MTIf tag="CategoryCount" ge="1">
            <li><a href="<$MTCategoryArchiveLink$>"><$MTCategoryLabel$></a>
            <MTEntries>
                <MTEntriesHeader>
                    <ul>
                </MTEntriesHeader>
                    <li><$MTEntryTitle$></li>
                <MTEntriesFooter>
                    </ul>
                </MTEntriesFooter>
            </MTEntries>
            </li>
    <MTElse>
            <li><$MTCategoryLabel$></li>
    </MTIf>
    <MTIf name="__last__">
        </ul>
    </MTIf>
</MTCategories>

※ 視認性を高めるためインデントを調整しています

いいですね。万能な記述、どこへ出しても恥ずかしくないテンプレートです。新人が書いてきたら誉めてあげてください。
このテンプレートの利用ケースに下記の要件がある場合はどうでしょうか。

  • カテゴリは1件以上存在する
  • カテゴリには記事が最低1件、常に公開されている
  • 運用で記事の削除や非公開化は行わない

この要件を前提とした場合、テンプレートの記述は次のように修正できます。

<ul>
    <MTCategories>
    <li><a href="<$MTCategoryArchiveLink$>"><$MTCategoryLabel$></a>
        <ul>
    <MTEntries>
            <li><$MTEntryTitle$></li>
    </MTEntries>
        </ul>
    </li>
    </MTCategories>
</ul>

※ 視認性を高めるためインデントを調整しています

だいぶすっきりした記述になりました。

これはあくまで要件があってこそできる記述であり常にこのように書くことがその場面にあったテンプレートではありません。 例外に対応しなければならない要件もあると思いますが、修正前と後ではどちらのテンプレートが早く書けるでしょうか。 早く書ければ早く納品でき、コストは抑えられリリースまでにかかる時間も抑えられます。

出力結果は求めるもので、早く納品できるテンプレートはよいテンプレート だと思います。
要件にないためわからない場合も、クライアントと話してみると、例外を考慮して複雑なテンプレートを書くより短い時間ですむかもしれません。

メンテナンスが行いやすいテンプレート / メンテナンスが行いにくいテンプレート

先の適切なテンプレートに比べてとてもわかりやすく、見出しの通りです。書いた担当しか理解できないようなテンプレートはメンテナンスが行いやすいとは言えません。
メンテナンスが行いにくいテンプレートは色々な問題を巻き起こします。

  • 出力結果に問題が起きた場合、修正が難しく、問題の状態が長く続く
  • テンプレートに対して複雑な仕様書が必要
  • 限られた担当しか保守が行えない、保守担当を変更できない

メンテナンスが行いにくいテンプレートの条件はいろいろありますが、目立ったものとしては下記の二種類になります。

誤解しないで欲しいのはテンプレート変数とテンプレートモジュールを使うことが問題ではありません。それぞれにはきちんとしたメリットがあります。
しかしデメリットもあるため、メリットとデメリットのバランスをとって書きませんとメンテナンスが行いにくいテンプレートになります。

メンテナンスを行いにくくするテンプレート変数

次のテンプレートはメンテンナンスが行いにくい記述の一例ですがどこが問題でしょうか。

<$MTVar name="html_block"$>

問題はテンプレート変数 html_block が何を出力するのか、この記述だけではわからないことです。

え、そんなのどんなテンプレート変数だって同じだろう、はい、どのテンプレート変数にも共通して言えることです。テンプレート変数はそういうものと言ってしまえばそれまでですが。 例えば MTEntryTitle タグを使って記事のタイトルを出力している場合、だれが見ても MTEntryTitle タグが出力していると理解できます。

<h1><$MTEntryTitle$></h1>

テンプレート変数の場合、その値を自由に設定できますが、設定と出力が完全に分離するため、その両方を把握してようやく動作を理解できます。

<$MTEntryTitle setvar="entry_title"$>

<h1><$MTVar name="entry_title"$></h1>

仮に変数の名前が entry_title であってもその値が記事のタイトルであるかは変数の設定次第です。それでも下記のような記述に関してはさすがに怒ってよいでしょう

<$MTDate setvar="entry_title"$>

<h1><$MTVar name="entry_title"$></h1>

entry_title の例はシンプルなので理解することもそれほど難しくないですが、変数の中に変数が入ってくると一変、メンテナーの眉間の皺も本数が増えてきます。

<$MTSetVarBlock name="title_core"><$MTEntryTitle$><$/MTSetVarBlock>

<$MTSetVarBlock name="h1_title"><h1><$MTVar name="title_core"$></h1><$/MTSetVarBlock>

<$MTVar name="h1_title"$>

以上の内容はテンプレート変数の利用を否定するものではありません。 テンプレート変数は負荷の軽減はスニペットなど過去の資産の流用によって、コーディングを短時間済ませたり、再構築の負荷を軽減するなど様々な効果がありますが、 テンプレート変数におけるテンプレートの見通しを悪くするデメリットを意識して使うとあなたのテンプレートは「わかりやすくて直しやすい」という評判をえられるでしょう。 面と向かって言われなくても「読みにくくて直しにくいから○○さんのテンプレートには関わりたくない」と避けられることはなくなりますね。

テンプレートモジュール使って共通化している

テンプレートモジュールは主にサイト、テンプレートの共通部分をまとめるために利用するでしょう。

ウェブサイト(ブログ)の垣根を越えて使えることもテンプレートモジュールのメリットの一つで、サイトの規模が大きく複数のウェブサイト(ブログ)で同じ共通化できるとメリットはより大きくなると思います。

しかし、共通する内容が少ないものをテンプレートモジュールにして共用するため、テンプレートモジュールの内容が煩雑になったケースを見かけます。

下記は極端な例ですが、100 のウェブサイト一つのテンプレートモジュールを利用し、そのテンプレートモジュールの中に 100 ウェブサイト分の分岐を設けたケースがあります。

※ テンプレートモジュールの内容

<MTIf name="blog_id" eq="1">
    blog_id=1 用の記述
<MTElsif eq="2">
    blog_id=2 用の記述
<MTElsif eq="3">
    blog_id=3 用の記述
<MTElsif eq="4">
    blog_id=4 用の記述
<MTElsif eq="5">
    blog_id=5 用の記述
(省略)
<MTElse>
    例外の記述
</MTIf>

これは共通部分をまとめていると言ってよいのでしょうか。 たしかに修正するテンプレートは一つへ共通化できていますが、その中にウェブサイトの数だけ分岐があってはウェブサイトごとにテンプレートモジュールがあるのとあまりかわりません。また、分岐がなかった場合でも 100 ウェブサイトで同じテンプレートモジュールを利用しているためテンプレートを修正する場合の影響範囲は 100 ウェブサイト、1 ウェブサイト分の修正を行うために残り 99 ウェブサイト分のリスクを背負って作業しなければなりません。

また、複数のウェブサイト(ブログ)を跨いでテンプレートモジュールを利用する場合、テンプレートモジュールを修正できない場合もあります。 例えばウェブサイトA(blogid=1)に作られたテンプレートモジュールを、ウェブサイトB(blogid=2)で利用する場合、ウェブサイトAとウェブサイトBの両方に対してテンプレートを編集する権限がないとメンテナンスは行えず、ウェブサイトBの権限しかない担当者はメンテナンスが十分に行えません。

テンプレートモジュールを利用する際は、その範囲やテンプレートモジュールの内容をよく考えてまとめる必要がありますが、まとめた後のことも考える必要があります。

まとめ

今回、よいテンプレート / わるいテンプレートとして、その場面に最適なテンプレートとメンテナンスの行いやすさについて紹介いたしました。 こんなことは当たり前の方もいらっしゃるでしょうし、今回初めて気づいた方もいらっしゃればよいと考えております。 立ち位置や視点がかわれば異なる気づきがあります。 色々な視点から、自分なりのよいテンプレートやわるいテンプレートを見つけ、よきテンプレートライフ、コーディングライフをおくられますように。

また、本記事の異論反論オブジェクションもお待ちしております。

それでは最後に、記事執筆者が個人的に「悪魔の所業」「親の敵も同然」と思う「わるいテンプレート」を紹介して終わりたいと思います。

<MTIncludeBlock name="$module_name" blog_id="$module_blog_id">
<$MTVar name="$module_contents"$>
</MTIncludeBlock>

まだ数日残っておりますが2020年はありがとうございました。

2021年も何卒よろしくお願い申し上げます。

カテゴリー
サポートテンプレート作成Tipsトラブルシューティング

以前、コマンドラインツールで行うインポートをご案内しておりましたが import-export-object では、ユーザーデータをインポートすることはできません。
そこで、ユーザデータのみインポートする import-authors-from-csv をご紹介させていただきます。

使用手順

  1. PowerCMS のあるサーバの適当な位置にインポート用のディレクトリを作成。
  2. ユーザデータをもつ CSV ファイルを、上記のインポート用ディレクトリに配置する。
  3. mt-config.cgi に以下の記述を追加する。
  
AuthorsCSVImportPath [インポート用ディレクトリのパス]
  
  1. import-authors-from-csv を実行する。
  
 cd MT_HOME
 perl tools/import-authors-from-csv --debug=1
  
  1. PowerCMSの管理画面からユーザーの追加もしくは更新が行われたか確認する。
    注)ユーザーデータでは name を一意の値とし、同じ name があれば上書き、無ければ新規登録となります。

権限について

ユーザーデータ の csv の形式につきましては、以下FAQでご案内しています。

ユーザ情報の登録だけであれば、こちらで登録可能ですが、権限の付与を行いませんと登録したユーザは管理画面へのアクセスもできません。

システム権限につきましては、以下のカラムを設定し値に 1 を設定することで権限の付与が可能です。

権限 カラム
システム管理者※全ての権限にチェックが入ります is_superuser
ブログの作成 can_create_blog
システムログの閲覧 can_view_log
オブジェクトグループの管理 can_manage_objectgroup
フォーム項目の管理 can_manage_formelement
管理画面へのアクセス can_access_cms

ロールにつきましては、[ブログID_ロール名]の形式で以下のように複数登録することが可能です。

  
name,nickname,email,password,status
user1,ユーザー1,foo@alfasado.jp,password,1,1_ウェブサイト管理者,2_会員ページの閲覧
  

システム権限については全ての項目には対応していませんのでご注意ください。

カテゴリー
PowerCMS 4PowerCMS 5プラグイン
投稿者
keiko.kurihara

11月初め、久しぶりに検定を受けてきました。
受験したのは、色彩検定で2018年に新しく新設された、UC(色のユニバーサルデザイン)級です。
学生時代に色彩学を勉強したり、幼少期から色に人一倍興味もありましたが、色彩検定の内容が難しいと感じたこともあり、検定は避けてきました。

老眼と向き合う時がきた

色のアクセシビリティは、実際にデザインを作る際にチェッカーをかけたり、見えやすさ、理解しやすさを考慮したりと、独自に勉強をしてきました。しかし、高齢者の色の見え方はコントラスト比が弱いと見えにくい以外にはあまり知見がありませんでした。

同世代の友人との会話に「目が見えにくくなった」「暗いと見えない」という内容が入ってくるようになり…ついに「老眼」に向き合う時がきた、と感じ始めました。色自体や見え方ではなく、老眼によって、見え方はどう変わっていくか?という疑問を解決すべく勉強をスタートしました。

見え方は人それぞれ。色覚の多様性を考える

実際に公式テキストを取り寄せて中を見ると、水晶体、トーン、色相環、マンセル。
学生時代や過去にやった仕事を思い出しつつ、やはり苦手な色と光のところは避けて通れぬ道なのか、と思いつつも、ページを進めます。
色覚障害の見え方については、今までにも聞いたり、調べたりしましたが、高齢者の目の変化や見え方の変化、高齢による病気の症状は初めてしっかりと読んだ気がします。目の変化で、硬化、濁る、低下など切ない気持ちになる単語が見え隠れ…。

色覚の多様性という言葉がよく出てきました。一般的に健常者といわれている人たちが見えている色も1人1人少しずつ違って見えたり、その色をどう感じるかは個人で違います。
しかし、色だけではなく、太さや書体、形、そもそもの見た目などにも配慮して物を作っていくことが重要です。感覚でわかっていたことが明確に書いてあり、安心するところもありました。
公式テキストには、配色の改善例なども掲載されており、とてもわかりやすかったです。

結果は?

さて、久しぶりに大学のキャンパスに行き、受験をしてきました。受講者の年齢層は幅広かったです。
そして、無事にUC級合格することできました!

知識として知っている内容もありましたが、アクセシビリティだけではなく、ユニバーサルデザインの内容も含まれているので、その知識の幅を少し広げることができました。
興味ある分野だったためか、勉強も楽しかったです。
高齢になると、青と黒の区別が付きにくいことなど新しく得られた知見もあり、今後の制作に活かしていきたいです。

アルファサードの web アクセシビリティの取り組み

弊社では、web アクセシビリティ向上への取り組みとして、無償ツールの提供の他、「 JIS X 8341-3 」への準拠を支援する「 PowerCMS 8341」の開発・提供、各種サポートサービスを行っています。評価版もございますので、実際にお試しの上、安心してお使いいただけます。お気軽にお問い合わせください。

お問い合わせ

Web アクセシビリティに関する弊社製品・サービス

PowerCMS 8341
「 JIS X 8341-3:2016」準拠支援ツール

導入事例:公益財団法人 長寿科学振興財団様 「 Webアクセシビリティへの対応と、PowerCMS クラウドの使いやすさ、運用への安心感が選定の決め手となりました。」

ColorTester
「 JIS X 8341-3:2010」( WCAG 2.0)の達成基準に基づき、画像の背景色と前景色のコントラストを確認するソフトウェア
ColorQuest
スクリーン上の色の名前を表示するソフトウェア
カテゴリー
その他

Recent Entries