<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Rails vs Plone &#8211; The battle of design patterns</title>
	<atom:link href="http://www.jrandolph.com/blog/2005/07/11/rails-vs-plone-the-battle-of-design-patterns/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.jrandolph.com/blog/2005/07/11/rails-vs-plone-the-battle-of-design-patterns/</link>
	<description>software development and testing</description>
	<lastBuildDate>Thu, 24 Apr 2008 12:51:01 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Jeff Shell</title>
		<link>http://www.jrandolph.com/blog/2005/07/11/rails-vs-plone-the-battle-of-design-patterns/comment-page-1/#comment-59</link>
		<dc:creator>Jeff Shell</dc:creator>
		<pubDate>Tue, 19 Jul 2005 17:18:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.jrandolph.com/blog/?p=7#comment-59</guid>
		<description>A big chunk of the problem with Zope 2 based object-relational mapping (and perhaps why Ape is so difficult) is that there can be a lot of arbitrary attribute assignment going on. Ape goes through great leaps to map all of the many aspects of an individual object across many tables, because a direct one-to-one mapping is not the way to go in Zope 2. There&#039;s things like title, id, bobobase_modification_time, assorted properties, and on and on and on. In Plone, there&#039;s all of the Dublin Core metadata to work out. Ape is a very well written system, but it&#039;s in a different problem space (I believe) than products like ActiveRecord and SQLObject. They&#039;re all similar in that they do object-relational mapping, but Ape is really more of a full abstract persistence mechanism, allowing alternate marshalling types (flat and understandable files, for instance).

The situation should be much better in Zope 3. There are is a much smaller inheritance hierarchy imposed on model objects - most of the times, it&#039;s just &#039;Persistent&#039; and/or &#039;Contained&#039;. And with things being interface driven, you could replace an implementation of a model object with a SQLObject managed one. There&#039;s a suppport package for Zope 3 for this:

http://codespeak.net/z3/sqlos/

I don&#039;t know how complete it is, but it looks fairly comprehensive and is a good example of how extensible Zope 3 can be by providing SQL backed containers and traversers that should fit right into Zope 3 with a minimal amount of effort.</description>
		<content:encoded><![CDATA[<p>A big chunk of the problem with Zope 2 based object-relational mapping (and perhaps why Ape is so difficult) is that there can be a lot of arbitrary attribute assignment going on. Ape goes through great leaps to map all of the many aspects of an individual object across many tables, because a direct one-to-one mapping is not the way to go in Zope 2. There&#8217;s things like title, id, bobobase<em>modification</em>time, assorted properties, and on and on and on. In Plone, there&#8217;s all of the Dublin Core metadata to work out. Ape is a very well written system, but it&#8217;s in a different problem space (I believe) than products like ActiveRecord and SQLObject. They&#8217;re all similar in that they do object-relational mapping, but Ape is really more of a full abstract persistence mechanism, allowing alternate marshalling types (flat and understandable files, for instance).</p>
<p>The situation should be much better in Zope 3. There are is a much smaller inheritance hierarchy imposed on model objects &#8211; most of the times, it&#8217;s just &#8216;Persistent&#8217; and/or &#8216;Contained&#8217;. And with things being interface driven, you could replace an implementation of a model object with a SQLObject managed one. There&#8217;s a suppport package for Zope 3 for this:</p>
<p><a href="http://codespeak.net/z3/sqlos/" rel="nofollow">http://codespeak.net/z3/sqlos/</a></p>
<p>I don&#8217;t know how complete it is, but it looks fairly comprehensive and is a good example of how extensible Zope 3 can be by providing SQL backed containers and traversers that should fit right into Zope 3 with a minimal amount of effort.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mike bayer</title>
		<link>http://www.jrandolph.com/blog/2005/07/11/rails-vs-plone-the-battle-of-design-patterns/comment-page-1/#comment-46</link>
		<dc:creator>mike bayer</dc:creator>
		<pubDate>Sat, 16 Jul 2005 17:14:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.jrandolph.com/blog/?p=7#comment-46</guid>
		<description>just because Ape is a very difficult and hard to configure Data Mapper algorithm, doesnt mean Data Mapper is intrinsically complicated.  It just means Ape is complicated.

All datamapper essentially means is that your database metadata and code for dealing with that metadata is decoupled from your domain objects.  active record and datamapper both have the need to know about your database schema, so some kind of configuration is needed in both cases;  the trick is making the configuration as easy and sparse as possible.

All you really need is a good example of Data Mapper, implemented in a sparse &quot;ruby/python&quot; style, which would begin showing those people struggling to build large and complicated applications with Active Record the &quot;light at the end of the tunnel&quot;.

(of course, therein lies the challenge...)</description>
		<content:encoded><![CDATA[<p>just because Ape is a very difficult and hard to configure Data Mapper algorithm, doesnt mean Data Mapper is intrinsically complicated.  It just means Ape is complicated.</p>
<p>All datamapper essentially means is that your database metadata and code for dealing with that metadata is decoupled from your domain objects.  active record and datamapper both have the need to know about your database schema, so some kind of configuration is needed in both cases;  the trick is making the configuration as easy and sparse as possible.</p>
<p>All you really need is a good example of Data Mapper, implemented in a sparse &#8220;ruby/python&#8221; style, which would begin showing those people struggling to build large and complicated applications with Active Record the &#8220;light at the end of the tunnel&#8221;.</p>
<p>(of course, therein lies the challenge&#8230;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: scooviduvoctagon</title>
		<link>http://www.jrandolph.com/blog/2005/07/11/rails-vs-plone-the-battle-of-design-patterns/comment-page-1/#comment-41</link>
		<dc:creator>scooviduvoctagon</dc:creator>
		<pubDate>Fri, 15 Jul 2005 17:25:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.jrandolph.com/blog/?p=7#comment-41</guid>
		<description>I&#039;ve been wondering - 

What are the perceived benefits of Zope&#039;s ZODB? 

And when in what sorts of instances is Zope&#039;s ZODB not appropriate? ( For instance why had the author decided not to store any data whatsoever in the object database, but instead opted fully for an rdbms? )</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been wondering &#8211; </p>
<p>What are the perceived benefits of Zope&#8217;s ZODB? </p>
<p>And when in what sorts of instances is Zope&#8217;s ZODB not appropriate? ( For instance why had the author decided not to store any data whatsoever in the object database, but instead opted fully for an rdbms? )</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sam Newman</title>
		<link>http://www.jrandolph.com/blog/2005/07/11/rails-vs-plone-the-battle-of-design-patterns/comment-page-1/#comment-29</link>
		<dc:creator>Sam Newman</dc:creator>
		<pubDate>Tue, 12 Jul 2005 07:56:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.jrandolph.com/blog/?p=7#comment-29</guid>
		<description>Of course don&#039;t forget that usign ActiveRecord couples your domain objects to the underlying DB - you cannot test your domain objects without testing your DB. Many of the Rails&#039; people get excited by doing things like running SQLlite against a RAM disk to speed their tests up, rather than asking the question&#039;Why not just decouple the models from the DB?&#039;. 

To my mind, on a moderately complex system (which to be fair is certainly not rails&#039; sweet spot) you&#039;d need a seperate repository layer</description>
		<content:encoded><![CDATA[<p>Of course don&#8217;t forget that usign ActiveRecord couples your domain objects to the underlying DB &#8211; you cannot test your domain objects without testing your DB. Many of the Rails&#8217; people get excited by doing things like running SQLlite against a RAM disk to speed their tests up, rather than asking the question&#8217;Why not just decouple the models from the DB?&#8217;. </p>
<p>To my mind, on a moderately complex system (which to be fair is certainly not rails&#8217; sweet spot) you&#8217;d need a seperate repository layer</p>
]]></content:encoded>
	</item>
</channel>
</rss>

