XOOPS Cube Legacyは、"CMS(Content Management System)"ではない。
XOOPS Cube Legacyは、正確に言うならば、"CMF(Content Management Framework)" だろう。
XOOPS Cube ベースで、CMSと呼べるモノとすれば、HDあたりだろう。
因みに、XOOPS Cube は、"Modulable Web Application Platform" です。
XOOPS Cube公式サイトに、日本語サイトができました。
http://xoopscube.sourceforge.net/ja/
日本語による様々な情報が掲載されてますので、XOOPS Cubeに興味のある方は、まずここから始められると良いでしょう。
XOOPS Cube は、XOOPSの国内版ではありません。
XOOPS Cube Project は、XOOPS Project からフォーク（派生）しました。
XOOPS Cube Legacy 2.1 は、XOOPS2.0 と「上位互換」です。
（実質の最新版とご理解ください。）
XOOPS2.0のモジュールは、XOOPS Cube Legacy 2.1 で利用可能。
XOOPS2.0のテーマは、XOOPS Cube Legacy 2.1 で利用可能。
XOOPS Cube の公式サイトは、
http://
xoopscube.jp は、単なるコミュニティサイトです。
xoopscube.org は、単なるコミュニティサイトです。
XOOPS 2.0-JP版 は、今現在、公式な開発は止まってます。
[追記]（但し、有志によるメンテは続いています。）
BCOOLさんが作られた、XOOPS Cube Projectのリンクバナーです。
XOOPS Cube Project のURLは、http://xoopscube.sourceforge.net/ です。
http://xoopscube.jp/ ではありません！お間違いの無いように！
もし、URLが古いままでしたら、リンク先の変更をしてください。
Characters in XOOPS Cube のツッコミを少々・・・。^^;;
--------
インストール画面でおなじみきゅーぶくん。じっと見てるとだんだん「もじぴったん」がやりたくなってきます。あたまのエックスはプロペラだったことが最近判明しました。
--------
「もじぴったん」、面白いです。ウチの娘も夢中！！
頭のプロペラは脱着式の「蚊取り線香」かと思ってた。。。orz
--------
2006年頃、 CUBE TIMES にコラムの連載を持っていた某国のエージェント。キューバ危機から世界を救うために奔走した高名なエージェントを父に持ち、自身はキューブ危機のために戦っている。 Legacy 用コードジェネレータ cubson の名前の元になりました。
--------
cubson氏には、母親はいなかったのか？との疑問がある。
母親はキュラリス・デジーグという。彼女は、幼少の頃、カリオストロ伯爵に育てられ、２人の子供を生んだ直後、「カリオストロの４つの謎」と呼ばれる内のひとつである、マリー・アントアネットの首飾りの謎に纏わる事件に巻き込まれ、誘拐され、その後の消息は判っていない。
また、cubson氏が追い続けてる闇の組織は崩壊したとの噂も耳にしたのだが・・・・。
正確な続報を待とう！
--------
理想的なモジューラブル設計がなされている理想郷ガンダーラを目指して旅する豚。１００歩進むたびにトラブルに遭う。
--------
「ガンダーラを目指して旅する豚」？？。それは猪八戒とは言わないのか？？
--------
……誰か組み合わせてリトル・キュロとか作ってください。
--------
僕からもお願い。誰か作ってください。・・・・って、いるのか？
Google Mapsの地図をサイトに取り込んで地図を使ったデータベースは、大変有用なデータベースになると思いますが、色々問題点もあるように思われます。
GoogleMapsには、マイマップというサービスがありますが、まず、それと簡単に比較してみます。
GoogleMaps マイマップ
+ 特定の情報を、地図を使ってデータベース化できる。
+ それを「公開」すれば、GoogleMaps での地図検索に表示される。
+ KMLを取り込む事が可能。
- KML出力が可能で、それをサイトに簡単な表示可能。但し、詳細な情報もサイトに表示する場合、多少の技術を必要とする。
(*) KML : 地図情報のデータのXML形式フォーマット
サイト内で、GoogleMapsを使う
+ 特定の情報を、比較的簡単に地図を使ってデータベースがサイト内に構築できる。
- 基本的には、GoogleMaps での検索には反映されない。
理想的な形としては、
「サイト内の地図データベース」が、「GoogleMaps のマイマップ」と連動して、地図検索に反映される。
更に、Google以外の地図検索サービスにも反映されれば、モアベタよ^^;;
では、XOOPSのGoogleMapsモジュールについて考えてみます。
・KML出力機能があれば、「GoogleMaps のマイマップ」へ情報を送れる。
但し、その都度、手動で行う事になると思われる。
・KMLの入力機能があれば、「GoogleMaps のマイマップ」の情報をマージできる。
入力のタイミングやキャッシュ方法に工夫は必要だと思うが、ほぼ自動化出来ると思われる。
実験の余地がありそうです。時間が出来たら実験してみます。
IBMサイトで面白い記事を発見したので、ここにメモっておきます。
PHP V5 でマルチタスク動作のアプリケーションを開発する
XOOPS Cube のXCube_Service なんかで使えないだろうか？？
複数のサイトに検索結果をリクエストした時、並列で処理可能なようなので、高速処理が可能になるのでは無いだろうか？
Locale を利用するケースとしては、地域リストなどが考えられる。
locale : JP
-------------------------------
$AreaListArray = array(
0 => "LANG_HOKKAIDO",
1 => "LANG_AOMORI"
)
-------------------------------
language : ja-JP
-------------------------------
define( 'LANG_HOKKAIDO' , "北海道");
define( 'LANG_AOMORI' , "青森");
-------------------------------
language : en-JP
-------------------------------
define( 'LANG_HOKKAIDO' , "Hokkaido");
define( 'LANG_AOMORI' , "Aomori");
-------------------------------
locale : US
-------------------------------
$AreaListArray = array(
0 => "LANG_ALABAMA",
1 => "LANG_ALASKA"
)
-------------------------------
language : en-US
-------------------------------
define( 'LANG_ALABAMA' , "alabama");
define( 'LANG_ALASKA' , "alaska");
-------------------------------
language : ja-US
-------------------------------
define( 'LANG_ALABAMA' , "アラバマ");
define( 'LANG_ALASKA' , "アラスカ");
-------------------------------
つまり、プログラム側では、
JPの地域リストだろうが、USの地域リストだろうが意識せず、
適用されているlocaleの地域リストを呼び出す処理が必要。
コミュニティを維持する為には、基本的には、ある程度の組織構造が必要になると考えます。
ただ集まる事が目的のコミュニティであれば、コミュニティ規模が大きくても、それほど組織構造は必要無いでしょう。
しかし、OSSなどの開発を目的としたコミュニティであれば、その規模に比例した組織構造が必要になるでしょう。
コミュニティ規模が大きくなれば、情報の整理やコミュニティの管理など様々な仕事が増える為に、当然、作業・タスクの分担を行う必要があります。
但し、それは会社などの業務ではありませんので、担当者に対して「義務」としてタスクを与える訳にはいきません。
あくまでも、ＯＳＳのプロジェクトの担当としてですので、その当事者の意思にまかせるしかありません。
それは、往々にして、「集団無責任」な状態になってしまいます。
もしくは、特定の個人に全て皺寄せされてしまうケースだってあるでしょう。
いぜれにせよ、それでは、そのＯＳＳプロジェクトが崩壊するのも時間の問題です。
それを回避する為に、「ＮＰＯ法人」や「財団」という形にするプロジェクトもあります。
「ＮＰＯ法人」や「財団」を形成する確かな基盤があれば、その選択肢もありだと思います。
もし、その確かな基盤が無いのであれば、当然ですが、「ＮＰＯ法人」だろうと「財団」だろうと、続きませんし、崩壊するでしょうね。
ＯＳＳプロジェクトっていうのは、元々、個人の小さなプロジェクトから始まったモノが多いでしょう。
そして、それが優秀なプログラムや便利なアプリであれば、自然とユーザーが増え、開発協力者も増えてきて、ユーザーも含めた大きなコミュニティが形成されるのかと思います。
たいていは、その時に、どういう組織構造を取るべきか選択を迫られるのかと思います。
そうでなければ、「集団無責任」の道を辿り、コミュニティの崩壊に進むのかと思います。
せっかく育ったコミュニティが崩壊すれば、そのＯＳＳプロジェクトは、また一から始めなければなりません。
業務でも無いプロジェクトに、それだけの魅力が見出せるほどのプログラム（アプリ）であれば、もしかしたら、やり直しは可能かもしれませんが、もしかしたら、また同じ道を辿るかもしれません。もしかしたら、それは大きな博打かもしれません。
「XOOPS Cubeプロジェクト」も、「XOOPSプロジェクト」からフォークした後、その選択をしなければなりませんでした。
そして、「XOOPS Cubeプロジェクト」が取った選択は、『大きなプロジェクトを形成しない』という方向に進む事に決定しました。つまり、「小さな政府」にするという事です。
XOOPS Cube自体を、Webアプリの中核（コア）となるべき部分のプログラムに特化し、可能な限り、縮小化しました。それに伴い、コミュニティも可能な限り、縮小しました。
しかし、Webアプリの中核（コア）だけではWebアプリは成立しません。
そのコアを元に、必要なライブラリ、システム、アプリケーションなどが必要です。
その為に、XOOPS Cube というコアを使った場合には、そのライブラリやシステムなどをモジューラブルに換装可能にして、開発者やエンドユーザーが柔軟にWebアプリを構築できる様な仕組みを目指しています。
OSやミドルウエアー等の他のＯＳＳプロジェクトと比較した場合、Webアプリの場合は、よりエンドユーザーに直結していますので、そのニーズに対する要望は無限にある事になります。
それら全てに答える事、対応する事、取り入れる事は、ハッキリ言って無理です。
それを解決する為には、やはりコアを小さくし、モジューラブルに必要な時に必要なモノを連結出来る仕組みにしなければなりませんでした。
当然、それらのライブラリやシステムにも、個々にプロジェクトが形成されるでしょう。
そこで、XOOPS Cubeを中心とした小さなプロジェクト（コミュニティ）が集まる事で、全体として巨大なプロジェクトが形成可能になる筈です。
それらのプロジェクトは、XOOPS Cube とは独立したプロジェクトであり、基本的に個々に運営してもらいます。
そして、それらの中から必要なプログラムをチョイスして、パッケージングし、ディストリビューションなどへ発展していくと面白いですよね。そのような発展もXOOPS Cube とは全く関係無いところでも自由にやり安くなると思います。
一部の巨大なＯＳＳプロジェクトを除けば、小さなＯＳＳプロジェクトはテールエンドの如く存在する筈です。
これは、その小さなプロジェクトが生き残る為の一つの方向性では無いかとも思っています。
（本末転倒かもしれませんが・・・・、）
そのようなコミュニティ形態を形成する為には、XOOPS Cube 自体にモジュールブルにライブラリやシステムを連結出来るような仕組みを持たせる必要があります。
そのモデルとして、「OGRE 3D」を大いに参考にさせてもらいました。
XOOPS Cube 自体も、まだ理想とする完全なモジューラブルな世界には到達していません。
某氏の発言を引用するならば、その世界とは、
(*)ガンダーラ...どこかにあると言われているが行き方が不明のユートピア
なのです。
現在、ガンダーラを目指し（笑）、XOOPS Cube の更なる発展の為に開発がすすめられています。
♪どうしたら行けるのだろうか・・・、教えて欲しい・・・・。 (爆)
Language と Locale について( ..)φメモメモです。
language
locale
あとで、追記するかもしれない・・・・・^^;;;
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |
最近のコメント