Return-Path: 
 <dev-return-103562-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
X-Original-To: apmail-cocoon-dev-archive@www.apache.org
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 69B2D9987
	for <apmail-cocoon-dev-archive@www.apache.org>;
 Mon, 23 Apr 2012 14:55:01 +0000 (UTC)
Received: (qmail 98285 invoked by uid 500); 23 Apr 2012 14:55:01 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 98191 invoked by uid 500); 23 Apr 2012 14:55:00 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 98184 invoked by uid 99); 23 Apr 2012 14:55:00 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Apr 2012 14:55:00 +0000
X-ASF-Spam-Status: No, hits=0.7 required=5.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [78.134.5.44] (HELO rovere.tirasa.net) (78.134.5.44)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Apr 2012 14:54:54 +0000
Received: from localhost (localhost [127.0.0.1])
	by rovere.tirasa.net (Postfix) with ESMTP id C32B0183E09
	for <dev@cocoon.apache.org>; Mon, 23 Apr 2012 16:54:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at tirasa.net
Received: from rovere.tirasa.net ([127.0.0.1])
	by localhost (rovere.tirasa.net [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id uYp9+qjS+V02 for <dev@cocoon.apache.org>;
	Mon, 23 Apr 2012 16:54:26 +0200 (CEST)
Received: from [192.168.0.2] (mogano.tirasa.net [192.168.0.2])
	by rovere.tirasa.net (Postfix) with ESMTPSA id 01213183D44
	for <dev@cocoon.apache.org>; Mon, 23 Apr 2012 16:54:25 +0200 (CEST)
Message-ID: <4F956D22.6000101@apache.org>
Date: Mon, 23 Apr 2012 16:54:26 +0200
From: =?UTF-8?B?RnJhbmNlc2NvIENoaWNjaGlyaWNjw7I=?= <ilgrosso@apache.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: potential SAX builder helper class
References: 
 <CAAqLGLNY8Zpwh8jLxG2Zb_BhdMmZiaVEO+obeoZOWzk09T0eyA@mail.gmail.com>
In-Reply-To: 
 <CAAqLGLNY8Zpwh8jLxG2Zb_BhdMmZiaVEO+obeoZOWzk09T0eyA@mail.gmail.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org

On 23/04/2012 16:35, Simone Tripodi wrote:
> Hi all guys,
>
> One thing I've always found a little "annoying" - "boring" is maybe
> the more appropriate therm - of SAX APIs is that, when crating even
> simple XML snippets via ContentHandler APIs, the following boilerplate
> code has to be written:
>
> +--------+
> ContentHandler handler = ... ;
> contentHandler.startDocument();
> contentHandler.startElement( "", "project", "project", new AttributesImpl() );
> contentHandler.startElement( "", "modelVersion", "modelVersion", new
> AttributesImpl() );
>
> String modelVersion = "4.0.0";
> contentHandler.characters( modelVersion.toCharArray(), 0,
> modelVersion.length() );
>
> contentHandler.endElement( "", "modelVersion", "modelVersion" );
> contentHandler.endElement( "", "project", "project", new AttributesImpl() );
> contentHandler.endDocument();
> +--------+
>
> I think you would agree with me that to obtain the following snippet
>
> +--------+
> <?xml version="1.0" encoding="UTF-8"?>
> <project>
>   <modelVersion>4.0.0</modelVersion>
> </project>
> +--------+
>
> that code is maybe an overkill :P
>
> So, at company I developed a small SAX wrapper that would help on
> transforming the previous code in the following:
>
> +--------+
> ContentHandler handler = ... ;
> SAXEventsBuilder.newDocument( transformerHandler )
>     .start( "project" )
>         .start( "modelVersion" ).body( "4.0.0" ).end()
>     .end()
> .endDocument();
> +--------+
>
> isn't more "sexy"? It still supports elements that require
> namespaces/attributes but reduces the lines of code for hardcoded XML
> documents - especially when closing elements.
>
> It also allows users to add manually-generated elements in an existing
> ContentHandler:
> +--------+
> ContentHandler handler = ... ;
> SAXEventsBuilder.wrap( transformerHandler )
>     .start( "modelVersion" ).body( "4.0.0" ).end()
>     .start( "groupId" ).body( "org.apache.cocoon.sax" ).end()
>     .start( "artifactId" ).body( "cocoon-sax" ).end()
>     .start( "version" ).body( "3.0.0-beta-1" ).end()
> +--------+
>
> without starting/closing the document.
>
> If you like it, I would be pleased to commit it in the Cocoon repo -
> as a side question: which component that would fill?

Hi Simone,
looks fine and helpful to me, +1

I'd put it in cocoon-sax, under org.apache.cocoon.sax.util package.

Cheers.

-- 
Francesco Chicchiriccò

Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/