Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <42F93FF4.4030805@agssa.net>
Date: Tue, 09 Aug 2005 18:44:52 -0500
From: Antonio Gallardo <agallardo@agssa.net>
Organization: AG Software, S. A.
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Suggestion for XHTMLSerializer
References: <b677085305080202252fb491ff@mail.gmail.com>
 <1123067609.7378.9.camel@localhost.localdomain> <dcvjmk$j9v$1@sea.gmane.org>
 <42F3AC2F.4080307@gmx.de> <dd1uab$7o0$1@sea.gmane.org>
 <42F48BAF.3010808@gmx.de> <dd2pdg$tcm$1@sea.gmane.org>
 <42F4FE1D.3050704@lojjic.net> <dd3e86$17e$1@sea.gmane.org>
 <42F5477E.4040301@lojjic.net> <dd4i4d$li5$1@sea.gmane.org>
 <42F5E165.1090700@gmx.de> <dd502d$gn0$1@sea.gmane.org>
 <42F62F0F.3030306@gmx.de> <dd5fu2$k0t$1@sea.gmane.org>
 <42F64E31.8050002@gmx.de> <42F7B2DF.5090004@reverycodes.com>
 <42F7BA5B.10306@gmx.de> <42F7CA5C.9040502@reverycodes.com>
 <42F7DF76.6010604@pcextremist.com> <42F7F2D3.7090509@reverycodes.com>
 <42F922BD.3070703@gmx.de> <42F92E73.4080606@reverycodes.com>
In-Reply-To: <42F92E73.4080606@reverycodes.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Vadim Gritsenko wrote:

> Joerg Heinicke wrote:
>
>> I still don't see why we should add a component to the Cocoon 
>> codebase, where we know from the beginning that it is "not best 
>> practice" (better formulation than my "problematic", but meaning the 
>> same).
>
>
> I'll rephrase what I wrote in one short sentence:
>
>   Anything can be either used 'as recommended', or abused.
>
>
> I don't see how TraxSerializer is different. It can be used following 
> 'best practice', or it can be abused (as was shown in the snipped 
> part). It can be in the scratchpad forever and nobody will (ab)use it, 
> or it can be documented with well defined 'best practices' and in wide 
> use.
>
> It's not even much different from base Serializer interface - the 
> major difference is that it provides another implementation language. 
> Should we then ban JavaScript (Python, Ruby, etc) on the basis that it 
> makes development too easy? Or may be we should use them but remember 
> to apply 'best practices'?

OK Guys, I am wondering if all the developers are following this very 
interesting thread. I will suggest to start a new one and include in the 
title the "TraxTransformer" keyword.

Since, I am more practical than academic persons, I tend to agree that 
the new proposed serializer is a good idea. It will improve performance 
in some places and to me this is welcomed. Call me "crazy guy", because 
for me every nanosecond counts! ;-)

But, I will like to hear more opinions about this. :-)

WDYT?

Best Regards,

Antonio Gallardo.