From dev-return-103085-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Mon Oct 31 13:22:00 2011 Return-Path: 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 0640B9836 for ; Mon, 31 Oct 2011 13:22:00 +0000 (UTC) Received: (qmail 75186 invoked by uid 500); 31 Oct 2011 13:21:59 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 75116 invoked by uid 500); 31 Oct 2011 13:21:59 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 75109 invoked by uid 99); 31 Oct 2011 13:21:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Oct 2011 13:21:59 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.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, 31 Oct 2011 13:21:51 +0000 Received: from localhost (localhost [127.0.0.1]) by rovere.tirasa.net (Postfix) with ESMTP id 6E270182446 for ; Mon, 31 Oct 2011 14:21:31 +0100 (CET) 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 adONAS5VeYZV for ; Mon, 31 Oct 2011 14:21:28 +0100 (CET) Received: from [192.168.0.2] (mogano.tirasa.net [192.168.0.2]) by rovere.tirasa.net (Postfix) with ESMTPSA id 94B9B182442 for ; Mon, 31 Oct 2011 14:21:28 +0100 (CET) Message-ID: <4EAEA0D8.2020200@apache.org> Date: Mon, 31 Oct 2011 14:21:28 +0100 From: =?UTF-8?B?RnJhbmNlc2NvIENoaWNjaGlyaWNjw7I=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [c3] sitemapNode setParameters( Map) ? (was Re: [c3] Implementing presentation logic in c3) References: <1319755181.4195.96.camel@mcKenny> <4EAA6253.5000700@apache.org> <1319793469.4071.26.camel@mcKenny> <4EAA7679.6020403@apache.org> <1319799535.4071.43.camel@mcKenny> <4EAC102C.9060907@apache.org> <1319906262.7148.10.camel@mcKenny> <4EAE8F7E.70204@apache.org> <1320064506.3765.27.camel@mcKenny> In-Reply-To: <1320064506.3765.27.camel@mcKenny> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 31/10/2011 13:35, Thorsten Scherler wrote: > On Mon, 2011-10-31 at 13:07 +0100, Francesco Chicchiriccò wrote: >> On 29/10/2011 18:37, Thorsten Scherler wrote: >>> On Sat, 2011-10-29 at 16:39 +0200, Francesco Chicchiriccò wrote: >>>> On 28/10/2011 12:58, Thorsten Scherler wrote: >>>>> [...] >>>> Finally, I've also made a fix for passing non-String parameters to ST, so $if$ is actually doing its job (take a look at cocoon-stringtemplate unit tests): unfortunately, this does not seem to work for sitemap, so I preferred not to update StringTemplate samples in cocoon-sample. >>>> >>>> Can anyone confirm (and possibly point out where to look, in case) that sitemap parameters are always cast to String? >>> /cocoon-sitemap/src/main/java/org/apache/cocoon/sitemap/InvocationImpl.java >>> >>> resolveParameter(String){ >>> ... >>> return result.toString(); >>> } >>> >>> I am not sure if we can change >>> org.apache.cocoon.sitemap.node.SitemapNode but in that interface we define: >>> void setParameters(Map parameters); >>> I reckon Map would the one we are looking for. >> Hi, >> see attached a patch letting sitemap parameters be actual Objects: check updated StringTemplate samples in cocoon-sample in order to see effective $if$ (finally!) in place. >> >> For the moment I preferred not to commit the attached patch, because it is a quite intrusive change (talking about interfaces, not only implementations). >> Besides all unit and integration tests defined, I've also made some others by-hand testing, and it *should* work. >> >> Please let me know if you run into any problem and if you think this patch to be committed. > I had a quick look and it seems fine with me. The only problem I had with the path is that it introduced some formating changes as well - making it hard to see right away the important change. > > I try to prevent this situation in > a) format the classes you will need to change BEFORE any change > b) commit that as "whitenoise" > c) do the work > > This way only the important changes can be seen on the patch without any "whitenoise". I've cleaned up the patch from formatting and attached to new COCOON3-79. > I would be +1. > > Maybe you want to call a vote to catch attention? Just done. Thanks. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/