1 :
nobodyさん:
ウェブサイトの管理するためにCMSはかなり重要だと思っています。
しかし、他のシステム(自作のショッピングカートシステムなど)と
CMSをうまく融合したいと考えます。
ショッピングカートをCMSのプラグインとして実装するのが
一番スマートなのでしょうが、そうすると、CMSに
依存する形となり安易に他のCMSに乗り換えられなくなります。
あきらめて、完全に分離した形にすると、今度は
CMSと他のシステムとのデザイン上の不一致や
それを修正するときに、CMSと他のシステムの両方を
修正しなくてはならなくなったりと不便です。
他のシステム内のデータ(静的な簡単なメッセージ等)を
CMSで管理できないのも悔しいです。
そこで、逆にあるフォルダ以下を他のシステムにし、
そのシステムからCMSのパーツを呼び出す方法を考えています。
とすると今度はCMSのパーツの呼び出し方が問題になってきます。
どちらもスマートな気がしません。
結構良くある事例だと思いますので、こんな方法で
うまいかんじに融合させたというテクニックありませんか。
自作のCMSと自作のカートを統合させました
お疲れ様でした
うーん
どうして融合させる必要があるのか逆に問いたい。
融合させなければスマートではないというのなら、1から自作する事
ぐらいしか思い浮かばない。
デザインの不一致というのは、分離する欠点にはならないよ。
なぜなら、大抵のCMSは、見た目はどうにでもなる。
システム内のデータに関して言うと、カートに出品する商品に
関してどのようにCMS側のデータと関連しているのか皆目
見当もつかない。
2度手間や、内容のダブリを防ぎたいという事ですか?
後・・・・
CMSのパーツというのは、どのような機能を呼び出さなければ
ならないのでしょうか?
>>2のように、自分で完全に1から自作したものであればまだ十分に
納得いくのだが・・・・。
デザイン重視で作るなら、全体を HTML + CSS で作って
動的な部分を適当なブログシステムなんかにする。
でもって、iframe で RSS 呼び出しってのはどう?
6 :
nobodyさん:2007/03/17(土) 06:36:40 ID:vc90ogzh
>>4 > 2度手間や、内容のダブリを防ぎたいという事ですか?
そういうことです。
同じ物を二つ以上作ってはならない。
Dry(Don’t Repeat Yourself)が原則です。
>ショッピングカートをCMSのプラグインとして実装するのが
>一番スマート
答えでてるやん。乗換えの事まで考えてたら融合なんてできないよ。
8 :
nobodyさん:2007/03/18(日) 01:00:12 ID:LFBeJ7d7
コンテンツの管理にはCMS(ブログ含む)の方が優れているのですよ。
でも、CMSっていくつもあるじゃないですか。
場合によってCMSを使い分けたい。
独自で何かシステム作ったとき(もしくは既に有る何かを使ったとき)、
これらのシステムと、使い分けるCMSとは柔軟に組み合わせられたほうがいいと思いません?
だから、なるべく依存しない融合テクニックがあればいいなと。
とりあえず、中間報告。
CMSや他の何かをプロキシのように使い内部でHTTP経由で独自システムを呼び出す方法。
これは独自システムの変更を必要としないためいいように思えたが、
プロキシ風ゆえにIPが変わってしまうため、独自システムがIP見ている場合
(ログ、セッション管理、アクセス制御)改造が難易度が高く
複雑になる可能性があると判断したのでボツ。
そこで、ユーザーは独自システムに直接アクセスする。
そして独自システムの改造を必要とするが、独自システムから
CMSに管理されたページ(場合によってはテンプレート)を取得し、
独自システムのビューやテンプレートとして利用することにした。
パフォーマンスは落ちるが、独自システムの改造はわずかになる(ことが多いだろう)
共通のヘッダとフッタ、CSSのカラーファイル読み込ませるだけで、ずいぶんと統一感が出ると思う。
それぞれのCMSは別のディレクトリにインストールしておく。
ユーザー登録データとか流用するのは難しいかもしれん。
>>9 多分それが一番普通の答えでしょうね。
だけど問題があるというかそれ以上のものを狙っています。
問題とは、
・共通のヘッダ/フッタにCMS(やそれで使われているtemplate)の命令が使われている場合どうするか?
(自分のシステムに、その命令解釈機能をつける?)
・共通のヘッダ/フッタがファイルではなくデータベースなどに格納されている場合どうするか?
(自分のシステムから、それらを直接読めるようにする?)
・ユーザー登録データも流用したい(つまり自分のシステム内に表示されるデータもCMSで管理したい)
(自分のシステムから、それらを直接読めるようにする?)
・CSSのセレクタ名の違いをどうするか
あと
>>8が酔っていたときに書いたので、意味が良くわかりません。あとで書き直します。
>場合によってCMSを使い分けたい。
この「場合」がわからんからなんとも言えんが、
CMSの方をプラグインなり改造するなりで変えていけば済むことじゃないの?
CMSが世の中に一つしかないなら、それでもかまわないが、
現実を見ればxoopsでXが使えるプラグイン、
drupalでXが使えるプラグイン、geeklogでXが使えるプラグイン
movabletypeでXが使えるプラグインと、大量にプラグインができている。
結構大変だよ。プラグインを作るのも。
逆に言えばプラグインでどーにでもなる話だって事だな
>>14 作れば出来る。
うん、じゃあ作ってください。
17 :
nobodyさん:2007/03/21(水) 22:36:30 ID:tvGv3xhV
>>16 じゃあ、GeeklogとYomi Searchを融合させてください。
もし、GeeklogでYomi Searchをあつかうプラグインがあれば
他のCMSでもいいですよ。
仕様はウェブで検索するか、ソースを見るか、作者に問い合わせてください。
求めているのは、いろんなシステムを融合させることができる、
テクニックなのですから、いろんな仕様に対応できなくてはいけません。
こまかい仕様なんて必要ないはずです。
もし必要だとしたら、それはGeeklogとYomi Searchをくっつけるだけの方法であり、
他のシステムには応用できない汎用性の無いものということになります。
なんだかグダグダになってきたな
>>1が妄想のような要望ばかりで何ら具体的な案を
出せていない件について
>GeeklogでYomi Searchをあつかうプラグインがあれば
無いのかと思って探したらあるじゃんw
CMSを使い分けたい「場合」の例をずっと待っているのだが・・・
22 :
nobodyさん:2007/03/22(木) 12:50:58 ID:yumaVeCV
ホームページ制作王の、性能や品質に対して、
具体的な批判が書き込まれたことは一度もない。
非標準ソフトを売買するAdobeやIBMが
世界標準に認定されているホームページ制作王への恐れと妬みから工作員を派遣し、
ホームページ制作王の普及を妨害しているのである。
我々は世界の権威であるCOMDEXの決定に従い、
ホームページ制作王のみが今世紀の世界標準であること、
ホームページ制作王が世界標準に認定されたのは性能、品質、ユーザビリティ、拡張性など
全ての分野において優位が認められたからに他ならないということ、
および、ホームページ制作王の標準化なくして我が国のWebが世界から評価される日は
決して訪れないということ、この3点を広く国内に告知している。
AdobeやIBMの工作員による根拠のない批判、
あるいはこれら工作員に洗脳された第三者がまきちらす風評に対し、強く抗議する。
真実は一つ。ホームページ制作王は、世界の権威COMDEXによって、
21世紀の世界標準に認定された、地球上で唯一のアプリケーションなのだ。
正義は勝つ。我々は戦い続ける!
>>21 普通に考えていくらでもあるでしょ?
ある案件ではmovabletypeを使い、ある案件ではお金出したくないとxoopsを使う。
個人でやっていても、別のCMSに乗り換えることなんて
いくらでも事例あるし。もしかして想像力ない?
「使い分ける」というか、金出す方からしたら
ブログが欲しいからMovabletypeを買って、ポータルサイトが作りたいから
XOOPSを使って、掲示板が欲しいからphpBBを使って...
ってしてたらコストかかると思うんだよな。オープンソースでも
自分がやるにせよ、誰かがやるにせよ時間というコストがかかる。
それぞれのCMSやシステムで似た箇所も多いから、融合できれば
使い勝手もよくなり、コストも短縮するだろうが、実際にその手の商品ってないもんな。
デザイン作成でもPhotoshopとIllustratorとFireworksを使い分けるぐらいだしw
>ブログが欲しいからMovabletypeを買って、ポータルサイトが作りたいから
>XOOPSを使って、掲示板が欲しいからphpBBを使って...
単に使いこなせていないようにしか見えないのだが・・・
>>23 だからその事例をだせっつってんじゃないの?
お前が想像力豊かなのはわかったからさ
使い分けをしなくて済むようにつったって要件は人それぞれだし、
最大公約数で落としどころを決めない限りマルチな融合なんて不可能でしょ。
試しにPhotoshopとIllustratorとFireworksを融合した所を想像してみたところで
使い勝手の悪い巨大アプリができるだけだと思われ。
つかぶっちゃけそれができるなら俺らの仕事無くなるよw
>>26 事例ってなんだ?
誰かがCMSを乗り換えた事例を出せと言っているのか?
ホームページでよくあるよな。
日記のところだけブログつかっていて
デザインが違っていて違和感ありまくりなの。
ああいうところも、きれいに融合できたらいいと思う。
>>28 いくらでも事例あるって書いたのはお前だべぇ
子供かよww
>>25 そりゃそうだ。基本的にオープンソース使う奴って自分でプログラム
組めなかったり、金がなかったりする奴だからな。
けどな、29も書いてるけど、デザイン(見た目)は各システムで
違うから、違和感出るんだよ。
得てしてプログラマーというのは、デザイン面は苦手だから、
違和感ないようなデザインに改造できないだろ?
仮に出来る奴はオープンソース使わずに、自分でプログラム組んでるよ。
>>32 の発言が全てを物語っているように
融合っていうのなら自分で1から組めば
良い訳であって、それさえ組めないのに
>>1のスキルでは、ないものねだりで
それ、夢のまた夢だろ。
>Dry(Don’t Repeat Yourself)が原則
なんていっている割には、オープンソース
で全て逃げようとしているのバレバレ。
後、言っておくがDryが、サイト構築やポー
タルにすべて当てはまると思ったら大間
違い。誰に吹き込まれたかしらないが、
オープンソースでDryを目指すなんて、
あまりに自殺行為。
少なくとも俺はようせんわ。
向上心の無い奴らだw
自分で組める奴でも、すでにあるならそれを巧く利用する。てのがオブジェクト指向的思考。
・既にあるものを使う→ソースを解読する→試す→動けば自分なりに巧く改造
・自分で組む
どう考えても後者の方が手間いらずだと思うが。
俺もそう思う。
フォーラムとか既存の使ってるけどなあ。みんな一から作ってるの??
そもそもフォーラムを使う用途がない。
仲間無いだけでの情報交換ならphpBBで良いと思うが
商売としてなら、それじゃいかんだろうし。
例えばメインの記事なんかにはブログを使いたい。
で、ブログの記事に対してあれこれ語りたいなんて場合にフォーラムの機能が欲しいこともある。
その時に記事を書いたら自動的にフォーラムにスレを立てたりとか、
フォーラムのレスをブログの方に反映させたりとかそういう機能があるといいんだよね。
実際にそういうサイトも作ったことあるけど、そのときは大幅に改造してDBに直書きさせるしかなかった。
これだと元のスクリプトがバージョンアップした時とかに対処が大変になるんだよな。
お互いがXML-RCPとかでインターフェイスを用意してくれればいいんだけど。
42 :
1:2007/04/15(日) 16:54:28 ID:???
>>41 XML-RCPとか対応していなければ、
URLを呼んでHTMLを取得すればいい。
たぶん、そのHTMLには余計な情報が沢山ついてあるだろう。
それなら、その部分を正規表現置換でもつかって削除すればいい。
処理的に無駄な部分があるだろうが、汎用性も高く確実で簡単な手段である。
取得したHTMLをテンプレートとして利用するのもありだね。
43 :
nobodyさん:2007/06/16(土) 01:06:20 ID:ZpDund+j
面白そうなスレタイなので食いついてみるんだが、
融合させたい部分のDB情報をフィード配信させて読み取るじゃだめ?
ポータルサイトのニュースが今その方法なんだけど。
>>43 読むだけなら簡単だが、
書き込みが入ると難しい。
自鯖ならphpなりjavaなりで自作すりゃいいじゃん。
phpは知らんが、javaなんて適当なフレームワーク
使えば楽に作れるじゃん。
46 :
nobodyさん:2008/10/28(火) 23:07:13 ID:l5n8a04n
47 :
nobodyさん:2008/10/30(木) 00:46:41 ID:DkFEgIcl
CMSがいまいちわからん
48 :
nobodyさん:2008/10/30(木) 11:53:05 ID:y8qOgvo/
ひとつの考え方ですが…
CMSはjoomlaを設置。同じサーバー内にショッピングカートのシステムを設置。
joomlaで作ったサイトのカートのページは、wrapper(ラッパーモジュール)で作り、
iflameとしてカートのページをページ内に表示するのではいかがでしょうか?
カートページのデザインをシンプルにしておけば、サイト内コンテンツとしても
さほど違和感がないと思いますし、joomlaの場合、同じサーバー内のコンテンツであれば、
ページにスクロールバーを出さずに表示できるので、ユーザーから見ると
自然に組み込まれているように感じると思いますが、いかがでしょうか?
俺もjoomlaだけどそれやってる。
スクロールバーはラッパーの設定でコントロールできる。
カートじゃないけどCGIを組み合わせたほうがプラグインを
入れるより扱いやすい場合があるよ。
50 :
nobodyさん:2009/10/29(木) 11:11:58 ID:cOi0xeeg
岡田外務大臣キタ━━━━━━(゚∀゚)━━━━━━ !!!!!
http://qb5.2ch.net/test/read.cgi/saku2ch/1256630318/1
早く記念カキコしないと埋まっちゃうwww
51 :
nobodyさん:2009/10/30(金) 00:59:26 ID:79VrpJDx
joomlaのラッパーにiframeの天地を自動的に
ないように合わせてJSで可変させる機能があるけど
あれってうまく動く?
俺ちゃんと動いたためしないんだけど…
乙どす
53 :
nobodyさん:2010/04/09(金) 14:32:06 ID:eGiCwGsM
ホームページ制作王は、世界の権威として名高いCOMDEXが
21世紀のワールドスタンダードに認定したWebパブリッシングアプリケーションである。
ホームページ制作王に不可能はない。
不可能があるとすれば、そこが人類の英知の限界点である。
21世紀、世界のWebはホームページ制作王を中心に回っていくのである。
にもかかわらず、ここ日本では、心ない風評のため、まだまだ普及に
遅れがみられる。
ホームページ制作王を普及させないかぎり、我が国のWebは、
世界の趨勢の後塵を拝するばかりである。
hoshu
そのうち使い慣れたテキストエディタが一番だと気づくんだよね。
これに勝る物は無いよ。定型文はスニペットで、タグは補完
あとは手打ちするのが一番自由で結果的に早く仕上がる。
Vimでおk
メインのシステムにAPIを作る
CMS側にはAPI接続用モジュール作成
最初は両方作る手間があるが、メインのシステム側は1度作ったらほぼ手入れ無し
そうすればCMS乗り換えるときはモジュールを作ればすむ
CMSって何の略?
CMS使うと、変わったことやろうとすると簡単なことも複雑になるからなー
pearやcakeもうぜーと思ってた人なら全部自分で作るのが一番早いわ
結局はDB直接叩くことばっかりになってCMSイラネーってなる
そう、いつぞやWPで不動産物件紹介のページ作ったが
結局フレームワーク使った開発となんら変わらん規模の作業になった
むしろWPベースなのでコードの見通し悪くブラックボックス化した箇所もありダメだと思ったわ
ウェーブ終了の字幕が出てからゴキの回しげり飛んでくるとかありすぎ
回線&割当て早い人と遅い人で表示に五秒は差があると思うわ