<?xml version="1.0" encoding="ISO-8859-1"?><!-- generator="wordpress/2.3-alpha" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: &#191;Un poco de DSL con su ensalada?</title>
	<link>http://www.estadobeta.com/2007/10/22/un-poco-de-dsl-con-su-ensalada/</link>
	<description>desarrollo web con estándares</description>
	<pubDate>Wed, 03 Dec 2008 20:32:07 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3-alpha</generator>

	<item>
		<title>By: Abunza</title>
		<link>http://www.estadobeta.com/2007/10/22/un-poco-de-dsl-con-su-ensalada/#comment-37209</link>
		<author>Abunza</author>
		<pubDate>Fri, 30 May 2008 03:55:34 +0000</pubDate>
		<guid>http://www.estadobeta.com/2007/10/22/un-poco-de-dsl-con-su-ensalada/#comment-37209</guid>
		<description>Hola caballeros les gustaria analizar esta pagina esta muy ..</description>
		<content:encoded><![CDATA[<p>Hola caballeros les gustaria analizar esta pagina esta muy ..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: EstadoBeta &#187; Archivo &#187; Usando bloques Ruby en lugar de m&#233;todos en Rails, parte I</title>
		<link>http://www.estadobeta.com/2007/10/22/un-poco-de-dsl-con-su-ensalada/#comment-23525</link>
		<author>EstadoBeta &#187; Archivo &#187; Usando bloques Ruby en lugar de m&#233;todos en Rails, parte I</author>
		<pubDate>Fri, 28 Dec 2007 00:12:02 +0000</pubDate>
		<guid>http://www.estadobeta.com/2007/10/22/un-poco-de-dsl-con-su-ensalada/#comment-23525</guid>
		<description>[...] un tiempo contaba sobre un proyecto cuya complejidad justificaba la creaci&#243;n de un simple DSL para estructurar de mejor forma la [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] un tiempo contaba sobre un proyecto cuya complejidad justificaba la creaci&oacute;n de un simple DSL para estructurar de mejor forma la [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Antoine</title>
		<link>http://www.estadobeta.com/2007/10/22/un-poco-de-dsl-con-su-ensalada/#comment-21025</link>
		<author>Antoine</author>
		<pubDate>Mon, 22 Oct 2007 20:53:15 +0000</pubDate>
		<guid>http://www.estadobeta.com/2007/10/22/un-poco-de-dsl-con-su-ensalada/#comment-21025</guid>
		<description>Aja, entonces la parte de acceso a datos quedaría solamente en Persona y la parte de reglas de negocio en sus herederas Usuario y Admin, ¿es así? Mi confusión vino porque entendí que el control de acceso quedaba fuera por completo de las clases AR (inclusive de las que heredaban de Persona, en el caso que comentas). Gracias por la aclaración, ahora entiendo y comparto tu punto de vista :)</description>
		<content:encoded><![CDATA[<p>Aja, entonces la parte de acceso a datos quedaría solamente en Persona y la parte de reglas de negocio en sus herederas Usuario y Admin, ¿es así? Mi confusión vino porque entendí que el control de acceso quedaba fuera por completo de las clases AR (inclusive de las que heredaban de Persona, en el caso que comentas). Gracias por la aclaración, ahora entiendo y comparto tu punto de vista <img src='http://www.estadobeta.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ismael</title>
		<link>http://www.estadobeta.com/2007/10/22/un-poco-de-dsl-con-su-ensalada/#comment-21024</link>
		<author>Ismael</author>
		<pubDate>Mon, 22 Oct 2007 20:22:31 +0000</pubDate>
		<guid>http://www.estadobeta.com/2007/10/22/un-poco-de-dsl-con-su-ensalada/#comment-21024</guid>
		<description>Antoine, el ejemplo esta bastante simplificado, pero el esquema que tengo es algo asi: Tengo una supeclase Persona. Usuario y Admin son subclases de Persona. Persona tiene una serie de utilidades y metodos protegidos que hacen el levantamiento de datos. Usuario y Admin solo definen las reglas con prepara_articulos. Esas reglas son procesadas por Persona (la superclase) para traducirlas a SQl, llamadas a ActiveRecord o el metodo que prefieras.

Por el momento &lt;code&gt;prepara_articulos&lt;/code&gt; en realidad es llamado dentro de metodos de instancia. Eso es bueno porque reuso la misma interface en distintos puntos:
&lt;pre lang="ruby"&gt;
def mis_articulos
    prepara_articulos do &#124;articulos&#124;
    articulos.add :from=&gt;self, :to=&gt;:all, :status =&gt; :all
    articulos.add :from=&gt;:all, :to=&gt;:self, :status =&gt; :public
    articulos.add :from=&gt;friends, :to=&gt;:all, :status =&gt; :all
  end

end
&lt;/pre&gt;

&lt;code&gt;prepara_articulos&lt;/code&gt; retorna un objeto ConfiguradorDeArticulos, que no es mas que un Array al que agregue un par de utilidades (ConfiguradorDeArticulo#add limpia y normaliza los parametros).

&lt;pre lang="ruby"&gt;
def prepara_articulos
  config = ConfiguradorDeArticulos.new
  yield config if block_given?
  config
end
&lt;/pre&gt;

El array de opciones se lo paso a un metodo que construye el SQL necesario para cargar los articulos indicados, pero bien podria pasarselo a otro adaptador que use Memcache, etc. 

La arquitectura completa es m&#225;s complicada, aunque el proyecto es tambien mucho mas complejo de lo que cuento aqu&#237; Espero que se entienda en todo caso el punto: este tipo de abstracciones valen la pena si hacen m&#225;s manejable el dominio del proyecto y separan las responsabilidades de cada m&#243;dulo.</description>
		<content:encoded><![CDATA[<p>Antoine, el ejemplo esta bastante simplificado, pero el esquema que tengo es algo asi: Tengo una supeclase Persona. Usuario y Admin son subclases de Persona. Persona tiene una serie de utilidades y metodos protegidos que hacen el levantamiento de datos. Usuario y Admin solo definen las reglas con prepara_articulos. Esas reglas son procesadas por Persona (la superclase) para traducirlas a SQl, llamadas a ActiveRecord o el metodo que prefieras.</p>
<p>Por el momento <code>prepara_articulos</code> en realidad es llamado dentro de metodos de instancia. Eso es bueno porque reuso la misma interface en distintos puntos:</p>
<pre lang="ruby">
def mis_articulos
    prepara_articulos do |articulos|
    articulos.add :from=>self, :to=>:all, :status => :all
    articulos.add :from=>:all, :to=>:self, :status => :public
    articulos.add :from=>friends, :to=>:all, :status => :all
  end

end
</pre>
<p><code>prepara_articulos</code> retorna un objeto ConfiguradorDeArticulos, que no es mas que un Array al que agregue un par de utilidades (ConfiguradorDeArticulo#add limpia y normaliza los parametros).</p>
<pre lang="ruby">
def prepara_articulos
  config = ConfiguradorDeArticulos.new
  yield config if block_given?
  config
end
</pre>
<p>El array de opciones se lo paso a un metodo que construye el SQL necesario para cargar los articulos indicados, pero bien podria pasarselo a otro adaptador que use Memcache, etc. </p>
<p>La arquitectura completa es m&aacute;s complicada, aunque el proyecto es tambien mucho mas complejo de lo que cuento aqu&iacute; Espero que se entienda en todo caso el punto: este tipo de abstracciones valen la pena si hacen m&aacute;s manejable el dominio del proyecto y separan las responsabilidades de cada m&oacute;dulo.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Antoine</title>
		<link>http://www.estadobeta.com/2007/10/22/un-poco-de-dsl-con-su-ensalada/#comment-21023</link>
		<author>Antoine</author>
		<pubDate>Mon, 22 Oct 2007 18:45:11 +0000</pubDate>
		<guid>http://www.estadobeta.com/2007/10/22/un-poco-de-dsl-con-su-ensalada/#comment-21023</guid>
		<description>Hola Ismael,
Es verdad que el DSL es mucho más legible y abstrae las reglas pero, ¿podrías indicar cómo lo integras en tu clase User desde la otra capa? Por tu artículo creo entender que cada clase (User, Admin, etc) implementa su propio prepara_articulos, pero no termino de entender cómo separa la lógica de negocio (que sería ese método prepara_articulos) de la capa de acceso a datos.</description>
		<content:encoded><![CDATA[<p>Hola Ismael,<br />
Es verdad que el DSL es mucho más legible y abstrae las reglas pero, ¿podrías indicar cómo lo integras en tu clase User desde la otra capa? Por tu artículo creo entender que cada clase (User, Admin, etc) implementa su propio prepara_articulos, pero no termino de entender cómo separa la lógica de negocio (que sería ese método prepara_articulos) de la capa de acceso a datos.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
