Ich hatte das ja schon mal aufgebracht: Eine ruby-api für jackrabbit/
JSR 170(http://jackrabbit.apache.org/) wäre sehr schick. Es gibt bei
Content-Management-Systemen schließlich eine ganze Menge von Sachen,
die man *nur* mit rails und einer relationalen DB/ferret erstmal
mühselig nachprogrammieren müsste (für eine Einführung in jsr170/
jackrabbit siehe z.B. http://www.artima.com/lejava/articles/
contentrepository.html). Sachen wie Queries, Suche, Versionierung,
Content-Type-Definition, Zugriffsrechte usw. gibt's schließlich schon
in Jackrabbit.
Daneben wäre eine Implementierung einer Client-API für jsr170 auch
auf lange Sicht eine gute Sache, weil man dadurch standardisiert an
alle möglichen CMS rankäme: JSR170 Schnittstellen gibt es
mittlerweile für eine ganze Reihe von js170-fähigen CMS (z.B.
Vignette, Typo3, Alfresco, Day usw.)
Zusammen mit JRuby müsste sich eigentlich eine solche Anbindung an
Jackrabbit mit überschaubarem Aufwand bewerkstelligen lassen und dann
müsste man zumindest für den ganzen Hintergrund-Apparat eines CMS das
Rad nicht nochmal neu erfinden...
Viele Grüße
Stefan
Am 12.09.2007 um 09:23 schrieb Jens Kraemer:
Hi!
On Wed, Sep 12, 2007 at 08:52:11AM +0200, Ansgar Berhorn wrote:
Am 11.09.2007 um 17:34 schrieb Mike Zaschka:
Das Thema WCMS und Rails finde ich auch nach wie vor spannend und
so ein richtig gutes System hab ich für Rails noch nicht finden
können. Mal sehen was sich nach der Notengebung mit dem Prototypen
anstellen lässt...
Joomla, Typo3 und Konsorten gibt es nunmal schon. Da wird das Rad nun
nicht nochmal neu erfunden, weil Rails ein bisserl hipper vom Klang
ist als php.
Naja, mich persönlich hat noch kein derartiges CMS vom Hocker
gerissen,
von daher gibt's in jedem Fall noch Potential. Und da Rails nicht nur
'hipper' ist als PHP, besteht die Hoffnung dass was besseres
rauskommen
könnte...
Rails ist gut, um schnell eine maßgefertigte Anwendung mit genau den
benötigten Funktionen zu bauen. Da gibt es dann haufenweise Plugins,
Generatoren, etc.
Auch wenn mit Rails nahezu alles einfach ist muss man den
langweiligen Teil, also die Pflege-Masken für statischen und
semi-statischen content, ja nicht jedesmal neu bauen. Vor allem wo es
ganz schnell kompliziert wird, wenn der Kunde schon mal ein
'echtes' CMS
gesehen hat und den Wunsch äußert, mal eben hier ein Bild und da noch
einen Absatz einzufügen, und am Ende die Reihenfolge dieser auch noch
umsortieren will, oder genau diesen Absatz an andere Stelle
wiederverwenden will. Ein wie auch immer geartetes Rails-cms fände ich
da schon interessant.
Also wenn fände ich interessanter eventuell so etwas wie einen CMS-
Generator abzuleiten als das hundertste CMS zu kreieren.
Kommt drauf an. Wenn das CMS die Basis ist und ich nach belieben
eigene
Controller dazuwerfen kann, nehme ich das auch. Mittlerweile müsste
man
doch auch ein komplettes CMS in einem normalen Rails-Plugin
unterbekommen,
so wie das früher mit Engines möglich war, oder?
Generatoren halte ich bei nicht-trivialen Dingen für gefährlich, denn
ich möchte nicht derjenige sein der einen zu spät entdeckten
Generator-Bug
in einem Haufen von Projekten mit generiertem und dann abgeänderten
Code
fixen muss...
Grüße,
Jens
--
Jens Krämer
http://www.jkraemer.net/ - Blog
http://www.omdb.org/ - The new free film database
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
