a-blog cmsの、include・extendの実案件での活用について

これは、a-blog cms Advent Calendar 2018の12日目の記事です。
a-blog cms Advent Calendar 2018 - Adventar

今回は、かなり制作者向けの記事です。a-blog cmsを利用していても、運用やディレクションが中心の方には、少し難しい内容であることを前置きしておきます。ですが、テーマの制作をしている方は、ぜひ読んでいただけるとうれしいです。

はじめに

北海道住宅新聞社さんの情報サイト「いえズーム」の管理をはじめてから、一年半くらい経ちます。

【iezoom】(いえズーム)北海道の住宅会社選び | いえズーム(iezoom)

いえズームの制作をはじめた頃は、「includeの変数渡し」「extendによるコードの継承」はリリースされていませんでした(バージョン2.8.0から)。 旧来のインクルードを使用したまま改修を重ねていたら、テーマがカオス化してきたこともあり、新しい機能を使用してコード整理をしています。

新しい機能のそれぞれの特徴と、いえズームでの実際の利用場面を紹介します。

includeの変数渡し

概要

旧来のインクルードは、SSI風の書式で、読み込むファイル名を指示するのみのシンプルなものでした。

<!--#include file="/path/to/filename"-->

しかし、2.8以降では、JSON風の書式で、読み込み先で使用できる独自変数を渡せるようになっています。

@include("/path/to/filename", {"key": "value", "key2": "value2"})

詳細な仕様解説は公式ドキュメントを参照ください。
インクルード | テンプレート | ドキュメント | a-blog cms developer

構造図

図で解説すると以下の通りです。 「sample_01.html」と「sample_02.html」は同じパーツ、module.htmlを読み込んでいますが、変数「button」の値が異なるため、実際に表示されるコードが一部変わります。 「sample_01.html」では、新着記事一覧の下に「詳しくはこちら」ボタンが表示されるはずです。



includeの特徴

includeの変数はグローバル変数ではないので、読み込み先以外に干渉することはありません。いくつでも渡すことができ、変数の初期値も定義できますが、長いコードを渡すことはできません(できたとしても可読性が著しく落ちます)。

extendによるコードの継承

概要

いっぽうextendですが、WordPressやa-blog cmsに実装されている「親・子テーマ」の「コードの使い回し」を、テンプレート間で実行することができます。

テンプレート冒頭で「@extend」を書くと、指定したファイルを丸ごと読み込むことができます。ここまではincludeと変わりませんが…

@extend(/path/to/filename)

指定した読み込み元のファイルに「@section(任意の英数字名) 」〜「@endsection 」で囲んだ領域があると、読み込み先のファイルでコードを上書きすることができます。

@section(sample)
  <h2>内容を書き換えちゃうよ!</h2>
@endsection

つまり、読み込み先では、差分コードだけ記述すれば良いのです。

詳細な仕様解説は公式ドキュメントを参照ください。
テンプレートの継承 | テンプレート | ドキュメント | a-blog cms developer

構造図

図で解説すると以下の通りです。
レイアウト用に作成した非公開テンプレート「_layout.html」のコードを3つの公開テンプレートで使い回していますが、それぞれ実際の表示結果が変わります。特にsample_03.htmlの「継承しつつ追記」はいろいろ便利です。



extendの特徴

extendは、前もってレイアウト用のテンプレートを作り、どの箇所を継承可能にするか定義することになります。

長いコードをテンプレート間で渡すことができるので、似ているけれど微妙に違うレイアウトが多いサイトでは、書くべきテンプレートの行数を大幅に節約できます。反面、includeとは異なり、条件分岐などに使える変数を渡すことはできません。

いえズームでの活用

includeの変数渡し

いえズームは一見シンプルなサイトですが、訪問者の導線を意識しているため、コンテンツごとに記事の表示件数や体裁、ページ内での表示位置などが細かく違っています。改修を重ねているうちに、モジュール部分のテンプレート数が肥大してしまっていました。

例えば「summary_sub_story_future」モジュールと「summary_sub_story_recent」モジュールは、IDが違うだけでコードがまったく同じなのに別ファイルになっています。

<!-- BEGIN_MODULE Entry_Summary id="summary_sub_story_future" -->
・・・
<!-- END_MODULE Entry_Summary -->
<!-- BEGIN_MODULE Entry_Summary id="summary_sub_story_recent" -->
・・・
<!-- END_MODULE Entry_Summary -->

これを、includeの変数渡しに書き換えることで、ひとつのファイルでidだけ違うコードを出力することができました。

さらに、なんと、読み込み先のincludeのファイル名に変数を引き継ぐことができることに気付いてしまいました。エントリーの繰り返し部分の体裁だけが違うテンプレートも共通化できそうです。

@include("/include/module/summary_sub.html", {"mid": "summary_sub_story_recent", "loop": "story_media.html"})
<!-- BEGIN_MODULE Entry_Summary id="{{mid}}" -->
・・・
@include("/include/module_loop/{{loop}}")
・・・
<!-- END_MODULE Entry_Summary -->

extendによるコードの継承

いえズームは、すべてのページのフッタ上部に、「いえズームとは?」というサイトの概要が記載されています。



ですが、一箇所だけ例外があります。地域別企業一覧のページでは、ヘッダの地域紹介の直下にあるのです。

札幌圏の住宅会社(ハウスメーカー・工務店)一覧 | いえズーム(iezoom)



地域ページは、冒頭に地域情報のパーツがあったり、地域名を変数に入れていたりと、かなりレイアウトが異なっています。以前は地域ページだけまったく違うテンプレートを用意していたのですが、extendを使うことで、他のテンプレートが利用している「/_layout_col2.html」との共通化ができるようになりました。

@extends("/_layout_col2.html")

@section(head_before)
(地域名を変数に取得)
@endsection

@section(pagehead)
(地域情報とサイト紹介パーツ)
@endsection

以下略

まとめ、使ってみての雑感

このように、わかりやすいところから少しずつコードの整理をしています。

使ってみての感想は、やはりテーマ職人としては、extendが手応えがある分面白いなあと感じています。大幅にテンプレートの数を減らせそうです。ただし、テーマ全体の構成を把握していないと実装できませんから、コーダーとテーマ制作者が違う案件では苦戦するかもしれません。

includeの変数渡しは便利な反面、インクルード先のテンプレートで、その変数がどこから定義されたものなのかわかりにくいという欠点があります(変数名でテンプレートを検索すればいいのですが)。 同じような変数名を使いすぎてカオス化しないよう、ルール決めが必要です。

いえズームは現在も、数週間に一度のペースでコンテンツの改修や追加が続いています。 このため、私も手早く対応できるようにしなければなりません。テンプレートを整理することで余裕が出て、より良い制作や提案ができればと期待しています。


投稿者名 うぇびん(管) 投稿日時 2018年12月11日 | Permalink

「a-blog cms Training Camp 2018 TOKYO」に参加しました

ええりんご社長さんがむいてくれとるで、はよ食べりん



「a-blog cms Training Camp 2018 TOKYO」に参加しました。これまで沖縄開催はありましたが、東京は初開催です。
会場は茅場町のコワーキングスペースのコエドさんでした。

お昼ごはんを食べて会場に行くとなぜか大量のりんごがありました。シールがかわいいので名刺入れに貼り付けて保護しました。三河弁になっていることは見逃しません。

さて、今回のa-blog cms Training Campでのレポートなんですが、以下の話に絞ることにします。

  • 機能の追加・改良
  • a-blog cmsかるた

ユーザーセッションについてもご紹介したいのですが、今回もすごいボリュームなので、このふたつだけで記事一個分になりそうなんですよね…すみません。ツイッターの「#ablogcms」ハッシュタグをぜひ早めにご覧ください。

https://twitter.com/search?q=%23ablogcms&src=typd

機能の追加・改良

オープニングの後で、a-blog cmsのコア開発を担当しているアップルップル伊藤さんから、先月リリースされたバージョン2.9系、次期バージョンの2.10系の新機能紹介がありました。2.9.0の詳細は、こちらのリリースノートを参照ください。

https://developer.a-blogcms.jp/blog/changelog/release290.html

OpenStreetMapに対応

Google Mapsが規約の変更で気軽に利用できなくなったため、a-blog cmsでは地図機能でOpenStreetMapが選択できるようになりました。OpenStreetMapはAPIキーなどを設定せず利用できますが、メンテナンスなどで一時的に見られなくなったり、検索が優秀ではなどの難点はあります。

プレビュー機能



公開していないエントリーを、モバイル環境を再現した画面でプレビューできるようになりました。また、Pro版ライセンス以上では、URLを発行してプレビュー画面をクライアントと共有することも可能です。MovableType.netではURLプレビューが標準機能でできますが、モバイルプレビューはないので、どちらが良いかはワークフローの問題になってきますね。

ユーザーの切り替え

これはイベント前に気がついてスクショを撮っていたのですが、管理者でログインしていると、管理画面内で他のユーザーに切り替わることができるようになりました。もちろん、元に戻せます。 このユーザーではどのように見えるのだろう、とか、特定のユーザーで有効になる判定をチェックしたいときに使えます。

テキスト置換



ユーザー待望の、テキスト一括置換機能が実装されました。カスタムフィールドを指定して置換できるので、フィールドに施設名を入れていて、その施設名が変わってしまった…という状況に役立ちます。ただし、正規表現は使用できません。

管理画面カスタマイズの簡略化

テーマ製作者に好評の、@extendsが改良され、@sectionの入れ子ができるようになりました…と言ってもわかりませんよね。私もわからないです。

ですが、管理ページの左メニューや投稿画面のカテゴリー・タグなどを、自作テーマ側で隠したり上書きできるようになりました、と書くとなんとなくわかるかと思います。これまで本当に苦労したので感動にむせび泣いていました( T-T )

サブカテゴリーの実装

これはリリース予定の、2.10系の機能です。Movable Typeの特徴的な機能としてご紹介してきた、「プライマリカテゴリー」「サブカテゴリー」の概念がa-blog cmsにも実装されます。

個人的には、サイト設計に大きく関わる変更と捉えています。a-blog cmsはシングルカテゴリーによるシンプルなマッピングを特徴としていたため、方針の変換とも言えます。a-blog cmsが中心の方向けにライトニングトークでもざっくり解説しましたが、これについては専用の記事を書きたいと思います。

エントリー編集画面の統一オプション

これまで、a-blog cmsは公開サイト内での見たまま編集を前提としつつ、管理ページの「エントリー」からも管理ページ画面での編集が可能となっていました。これが混乱を招くケースがあったり、背景に強い色を使っているサイトではa-blog cmsのUIが合わないということで、どちらかに固定できるようになりました。



ただし、管理ページに固定した場合の「このページを見る」ボタンの位置がわかりにくいという感想を持っています。やはり、Movable TypeやWordPressのように、タイトル直下にあるとよいかと。

a-blog cmsかるた、なまら遊ばさるんだけど



一日目のセッション終了後は、アップルップルさんが毎回いろいろネタを持ってくるグループワークでした。なんと、今回は「a-blog cmsかるた」でした。

取り札に機能名やタグ名が書いてあって、スタッフが持っている読み札にはその説明が書いてあります。

「初心者」「中級者」「エバンジェリスト」でチーム分けされてしまったため、プレッシャーが上がるエバンジェリストたち。しかもやたら難しい。管理画面用のタグとか使わないし。微妙に綴りが違う引っ掛け問題があるし。

取りながら「これは知ってたw」「知らなかったw」「感覚で憶えちゃってるから読み札の説明を聞いてもわからんw」と変なテンションで盛り上がりながらのプレイでした。



私が取れたのはこの6枚。URLコンテキストのキーやフォームオプションの判定など、他のCMSでも使用されている機能や用語ばかりになりました。

キャッシュバスティングとは、ブラウザキャッシュは有効のまま、CSSやJSなどの依存ファイルのみキャッシュを無効化する技術もしくは機能です。WordPress、a-blog cmsだけでなく、Drupalも実装していたかと思います。

優勝は神戸の岡田さんと大阪の坂本さんの、それぞれ7枚でした。全然使ったことがないグローバル変数やタッチモジュールを知っていてさすがです。

こういうゲーム形式の勉強は会話も発生して楽しいですね。初心者グループのみなさんがついて行けたか心配なので、初級者セット・上級者セットがあるといいのかもしれません。

雑感:a-blog cmsのエンタープライズ化

今回は体調が良く、イベントのほぼ全日程にきちんと参加することができました。2.9系以降、また、将来的な新しいCMSの話を聞いて感じるのは、a-blog cmsは確実にエンタープライズCMSへ向かっているということです。

いえ、以前から向かっていましたし、エバンジェリストのほとんどはディレクターのスキルを持った人が多いです。ですが、機能に関する部分で、ディレクター、デザイナー、フロントエンドエンジニア、クライアントの四者が円滑に協業できることを意識した変更が増えているように感じます。投稿画面の固定化、プレビュー共有などがそうです。

これだけ機能が揃っていると、すでに5万円ではおさまらないCMSとなっており、次期CMSは確実にライセンス料がアップします。その場合、私のようなCMSの決定権を持たないエンジニアは、どのようにa-blog cmsを選択してもらえるか真剣に考えないと、実務で使えなくなってしまいます。そんな危機感も持っています。


いつまでついていけるだろうか、とも感じつつ、参加するたびにモチベーションがこれだけ上がるのはa-blog cms Training Campくらいです。スタッフ、エバンジェリストの皆さんとの話も、濃くて勉強になります。 私は仕事のためだけではなく、自分の維持のためにCampに向かうのです。


投稿者名 うぇびん 投稿日時 2018年11月21日 | Permalink

CMSでの「事例コンテンツ」の5つの構築パターン


先月の「WCAN 2018/10」で、講師の谷口さんが、WordPress 5.0のGutenbergに対する懸念と同時に、小規模のコーポレートサイトはこれまでのWordPress一択ではなく、ASP型のシンプルなCMSへ移行していく選択肢もあるというお話をされていました。

コーポレートサイトの軽量化が進む中でも、CMSで構築すべきコンテンツはいくつかあります。そのひとつが「ユーザー事例」「導入事例」などの、事例コンテンツです。

事例コンテンツは、クライアントの業種、業態などで適したパターンが異なるので構築の最適解がありません。だいたいはすでに決まっているワイヤーに添って構築することが多いですが、私が中間の制作会社さんに「このパターンはこういうリスクがありますが大丈夫ですか」と提案したり、逆に意見を求められることもあります。

だいたい、5パターンに分けられると思うので、今後のために特徴と構築手法をまとめてみます。

ワイヤーがかなり縦に長いので、少し読みづらいですがご容赦ください。画像はクリックで拡大できます。

リッチテキスト型


冒頭にお客様の画像と名前が入り、その後はリッチテキストの自由文となります。
最も軽量なパターンで、特別なフィールドもお客様名くらいですから、JimdoなどのASP型も含め、どのCMSでも実装可能です。

このパターンの欠点は、データの再利用性が低いこと、リッチテキストであるためウェブ担当者のセンスに左右されることです。固定ページとほぼ同じですね。


データベース型


すべての項目をカスタムフィールドでがっちり構築し、事例の情報を細かいデータとして開示します。

大手企業さんで数回経験しました。すべての情報の再利用性を考えていることや、大きな社内で投稿ルールを統一するのが難しいからではないかと思います。

上記の通りデータの再利用性が高い、つまりAPI連携、リニューアルにめっぽう強いことが長所として挙げられます。一方で例外が許されなかったり、この事例だけ思い切り推したい、ということができないのが欠点です。このため、中間のテキストをリッチテキストの自由文にして、HTMLを書けるようにしておくという「逃げ」を考えたりします。

工数も多くなりますし、CMS本体への負荷も高めです。そういう意味でも大企業向けなように思います。


ギャラリー型


画像とキャプションがグループになった「繰り返しフィールド」を作り、カルーセルとして表示します。繰り返しフィールドについてはまとめで後述します。

jQueryが普及した頃から現在まで人気があり、コンパクトで、クライアントのOKも出やすそうなパターンですが、私はこのパターンにあまり良さを感じません。

このパターンは、最初に画像が集中しているため、画像と文章を対比して見ることができません。文中に「キッチンのタイルのあしらいは…」と書かれていて気になっても、ページの最初まで戻って、カルーセルをめくらなければならないのです。

また、スマートフォンの普及で画面が狭くなり、かつ訪問者の滞在時間が少なくなったため、2枚目以降を見てもらいにくいです。縦長の素材が多いとますます見づらくなってしまうのも難点です。文章は少ないけど良い写真がたくさんある、というなら採用しても良いかと思います。


リピートフィールド型


前項のギャラリー型の変形です。画像、キャプション、見出し、本文がセットになった繰り返しフィールドを重ねてページを作成します。見出しやキャプションは必ずしも必要ありません。

縦長の画像にも対応できたり、画像と文章を対比できるなど、ユーザビリティに利点があります。更新担当者にも説明しやすいパターンですが、同じパーツの繰り返しなので、そうとう文章に力を入れなければ単調になってしまいます。 また、途中に任意のコンテンツを割り込ませることができません。

画像に力が入っているならギャラリー型、文章に力が入っているならリピートフィールド型がいいのかなと考えています。


ユニット型


本文中のすべてのパーツを「ユニット」として自由に並べていくパターンです。

このブログへ何度か来られた方はすでにご存知かと思いますが、a-blog cmsが最も得意としているパターンです。concrete5も実質このパターンになります。WordPressのGutenbergやMovable Typeのブロックエディタも…近い、とは言えます。

例外対応ができる、段組ができる、事例専用のユニットを追加できるなど、なんでもありですが、a-blog cmsのエバンジェリストとして敢えて言うと「データの再利用性が低い」「手厚い導入説明が必須」という問題があります。このため、急ぎ案件やまとめてインポートをしたい場合には向きません。

また、これはリッチテキストエディタと同質の問題でもありますが、投稿ルールを決めておかないと、各ページがカオス化しがちです。


まとめ


以上、事例コンテンツのパターンをまとめてみました。いつものように突っ込みを待つことにします。

繰り返しフィールドは、「リピートフィールド」「フィールドグループ」などと呼ばれ、a-blog cmsはコアでこの機能を持っています。WordPressでは「Advanced Custom Fields」プラグインのPROライセンス、Movable Typeでは「FreeLayoutCustomField」で可能です。

個人的にはデータベース型はけっこう好きだったりしますが、サイトのレイアウトがデータに大きく縛られてしまうため、やはり繰り返しフィールドと単体フィールドの併用が良いのかなと思います。

すべてのパターンに言えることですが、事例を「インタビュー」としていた場合は「インタビューに応じてくれる寛容なお客様が、今後どのくらいいるのか」について検討しなければなりません(私はこれを「希望的観測問題」と呼んでいます)。なので、インタビューと通常事例でカテゴリー分けをして、通常事例はギャラリー型などにすることが考えられます。

なんにせよ、なぜ事例コンテンツを作りたいのか、事例を通して訪問者(将来の顧客、もしくは掲載された顧客)に対してどのようなユーザー体験を与えたいのか、この二点を明確にしてから進めたいものです。


投稿者名 うぇびん(管) 投稿日時 2018年11月10日 | Permalink

ブログをリニューアルしました


このブログ、つまり、ウェビングスタジオのメインブログをリニューアルしました。

リニューアルというか、長年積み重なった設定を初期化して、a-blog cmsのブログ用公式テーマ「blog2015」をベースにしたという縮小に近い改修です。
blog2015は読みやすく扱いやすいテーマです。使っている他の人のブログを見て気になっていました。この機会に使ってみることにします。

15年近く続けてきたブログが昨年ころから書けなくなり、g.o.a.tへ移転してみたり、非公開の場所で完全にプライベートの日記を書いてみたりしていました。
一方でTwitterやFacebookは大量に投稿していたので、書けなかったのは「役に立つ情報が充実した、人気が出そうな記事を書かなければならない」というプレッシャーのせいだと思います。
私のライフログが、私のドメインにまったく残っていないのは、やっぱり悲しいです。

純粋な技術情報はQiitaで書いているので、今後はブログをはじめた頃の原点に戻って、私個人の日記と対外活動を中心に書いていこうと思います。

ちょっと待て、カテゴリーを消す前に

リニューアルにあたって、記事の分類を、タグのみにしました。昨今のレンタルブログはカテゴリーを廃したものが多いですし、ブログのような雑多な記事は複数のタームを持つタイプの分類の方が自分自身も後々探しやすいです。

a-blog cmsはエントリーからカテゴリーを外すのが簡単です。管理ページで全記事を選択して、一括修正のプルダウンで「カテゴリー>なし」を選ぶだけです。

300件から、えいやっとカテゴリーを剥がしたところで、あることに気づきました。

a-blog cmsは、エントリーURLにカテゴリー名が含まれるということに。

例えば、このブログ内で歴代最高の人気記事となっている「GitHubとBitbucketの比較:Webデザイナーの業務にはBitbucketが向いている」だと、

https://webbingstudio.com/weblog/internet/entry-651.html

https://webbingstudio.com/weblog/entry-651.html
になり、すべての被リンクが切れてしまうということです。

心の中で「ああああああああああああああああああああああああああああああああああああああああああ」と叫びましたがもう遅いです。それに、ある程度手数やリスクをかけても、このタイミングでカテゴリーは廃止したい気持ちは変わりません。

加筆

アップルップルのかずみちさんから「.htaccessを書かなくてもいいんだよ」と、「entry_301_redirect」オプションのことを教えていただきました。これがオンになっていると、エントリーのファイル名に重複がなければ、カテゴリーを変更してもエントリーのリンクが切れません。

結局、以下のように.htaccessを書いてリダイレクトさせました。どう考えてももっと短い書き方があります。

# a-blog cms以外のコンテンツ(a-blog cmsを動作させないディレクトリ)
RewriteCond %{REQUEST_URI} !^/?weblog/life/
RewriteCond %{REQUEST_URI} !^/?weblog/work/
RewriteCond %{REQUEST_URI} !^/?weblog/cms/
RewriteCond %{REQUEST_URI} !^/?weblog/webdesign/
RewriteCond %{REQUEST_URI} !^/?weblog/others/
RewriteCond %{REQUEST_URI} !^/?weblog/internet/
RewriteCond %{REQUEST_URI} !^/?weblog/study/
RewriteCond %{REQUEST_URI} !^/?weblog/think/

・・・

# ブログカテゴリー廃止
RewriteCond %{REQUEST_URI} ^/?weblog/life/
RewriteRule ^/?weblog/life/(.*)$ https://%{HTTP_HOST}/weblog/$1 [R=301,NE,L]

RewriteCond %{REQUEST_URI} ^/?weblog/work/
RewriteRule ^/?weblog/work/(.*)$ https://%{HTTP_HOST}/weblog/$1 [R=301,NE,L]

RewriteCond %{REQUEST_URI} ^/?weblog/cms/
RewriteRule ^/?weblog/cms/(.*)$ https://%{HTTP_HOST}/weblog/$1 [R=301,NE,L]

RewriteCond %{REQUEST_URI} ^/?weblog/webdesign/
RewriteRule ^/?weblog/webdesign/(.*)$ https://%{HTTP_HOST}/weblog/$1 [R=301,NE,L]

RewriteCond %{REQUEST_URI} ^/?weblog/others/
RewriteRule ^/?weblog/others/(.*)$ https://%{HTTP_HOST}/weblog/$1 [R=301,NE,L]

RewriteCond %{REQUEST_URI} ^/?weblog/internet/
RewriteRule ^/?weblog/internet/(.*)$ https://%{HTTP_HOST}/weblog/$1 [R=301,NE,L]

RewriteCond %{REQUEST_URI} ^/?weblog/study/
RewriteRule ^/?weblog/study/(.*)$ https://%{HTTP_HOST}/weblog/$1 [R=301,NE,L]

RewriteCond %{REQUEST_URI} ^/?weblog/think/
RewriteRule ^/?weblog/think/(.*)$ https://%{HTTP_HOST}/weblog/$1 [R=301,NE,L]

私らしいフォント

CSSフレームワークが完成したので、屋号サイトも、シンプルでコンテンツ押しのデザインへのリニューアルを考えているところです。

ブログの外観は公式テーマのままですが、全体のフォントを新しいサイトで使用予定のフォントにしました。
中見出し、本文は「FOT-セザンヌ ProN M」、大見出しは「FOT-ロダンカトレア Pro DB」を採用しています。

https://webfont.fontplus.jp/font-list/cezannepron-m



セザンヌは東京駅でも採用されている比較的ありふれたゴシック体ですが、ヒラギノよりも文字幅が細く、文字の書き始めに強い力が入った跡があります。
背筋を伸ばし、凛と声を張って話す、年配の女性を連想させます。
それは私がなりたい姿で、このサイトに合っている文字かなと考えて選びました。


そんなこんなで、またブログの記事が長くなってしまうのでこの辺で。
書きたいことは浮かんでいるのだから、タイトルだけ付けた下書き記事を作っておくといいのかも。


投稿者名 うぇびん(管) 投稿日時 2018年11月01日 | Permalink

CMSの構築を考慮したコーディングとかクラスの命名規則の話


先日、CSSフレームワークについて記事を書いてから、今後のコーディング設計について具体的に考えています。

【Webdesign】Atomic Designの思想で、文系でもわかるCSSフレームワークを作りたい | ウェビンブログ

というより、再利用性のある業務用テーマの制作をいくつか依頼されており、いずれにしても着手しなければならないのです。

私の主業務が、CMS(それも特定のブランドによらない)を組み込んだサイトの制作であることを前提に、自分はどう設計していったらよいか、考えていることを書いておきます。


投稿者名 うぇびん 投稿日時 2017年07月08日 | Permalink