Return-Path: Delivered-To: apmail-incubator-jspwiki-dev-archive@minotaur.apache.org Received: (qmail 51191 invoked from network); 16 Apr 2009 22:19:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Apr 2009 22:19:26 -0000 Received: (qmail 48781 invoked by uid 500); 16 Apr 2009 22:19:26 -0000 Delivered-To: apmail-incubator-jspwiki-dev-archive@incubator.apache.org Received: (qmail 48717 invoked by uid 500); 16 Apr 2009 22:19:25 -0000 Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jspwiki-dev@incubator.apache.org Delivered-To: mailing list jspwiki-dev@incubator.apache.org Received: (qmail 48707 invoked by uid 99); 16 Apr 2009 22:19:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Apr 2009 22:19:25 +0000 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=FS_NEW_XXX,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of andrew.r.jaquith@gmail.com designates 74.125.46.152 as permitted sender) Received: from [74.125.46.152] (HELO yw-out-1718.google.com) (74.125.46.152) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Apr 2009 22:19:19 +0000 Received: by yw-out-1718.google.com with SMTP id 6so530760ywa.0 for ; Thu, 16 Apr 2009 15:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=G6tV0folkud1kcN0/5qVMFyxgmaUO5nqtpNDD7kBhlE=; b=sqRPDTL+T8jCKNYWPY/HlGEBIHD4jbg05VyPromWh6R86brfEAhHmZlTn112P+maz4 0R/O6Ct1LvhyMzB8/mRnXu2z5dtTzELjmhJb+5oTMtQNVZLiH8hGJUcI+DczSTcVhqIA WSKot1tU5RAdEkEkDpCU7N8/YBiYZnYhRf1xY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=vLZ32lwG06ku7f1TzL7KQKunVKL0lSvnJTLvCKbtGjlZR+ATYCuuxiSP6GCjgKCHse Osyr2FKca1EdqNLsuSKKWSvPwMGcDLHk0+icDwBK/n3uC44ctYrF6GDWbxuSlLvhoARd 86WoQO3KQ2lqJAfLzg3Wf+GV9cFqBYxk6FVqg= MIME-Version: 1.0 Received: by 10.231.17.135 with SMTP id s7mr2132891iba.25.1239920337990; Thu, 16 Apr 2009 15:18:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Apr 2009 18:18:57 -0400 Message-ID: Subject: Re: new pages From: Andrew Jaquith To: jspwiki-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Funny, I was drafting an e-mail on this very subject. Here it is... --- As the 3.0 trunk starts to settle down, I'm headed back to the JSP tier to do some work. I wanted to get your thoughts on WikiPageTypeConverter -- an important component of how JSPWiki interacts with the Stripes layer. I'm thinking of changing how it works so that it resolves non-existent WikiPages. Background: the Stripes TypeConverter classes are pretty nifty. They extract parameters from the request stream and convert them into objects the target ActionBean wants. For example, if an ActionBean has a get/set property called "counter" and its return type is an integer, Stripes will convert the value of the request parameter "counter" (which is a String) into the correct integer, and cause the ActionBean's setCounter(int) method to be called with the converted integer value. For JSPWiki, I've created TypeConverter classes for wiki Groups, WikiPages, and Principals. The net effect is that when one of our ActionBeans is invoked by user's browser in an HttpRequest, all of the parameters are magically parsed, converted into their correct target types, and bound to the ActionBean. Once the properties are converted and populated, they become available for an event handler method to use. It works like magic. Now, the WikiPageTypeConverter I wrote is pretty interesting. When we see a String representing the name of a WikiPage, we look it up in the ContentManager. If it's not found, we return a null. Meaning, "we didn't find the page because it's not in the repository." The consequences of this is what is causing the problem. What this means is that ActionBeans with a WikiPage property on them won't have a WikiPage bound to them when we finally invoke the event handler method. For example, EditActionBean's "edit" method (which starts the editing screen) gives an NPE if we try to edit (create!) a page that doesn't exist, because the TypeConverter looked up the page, and not finding it, returned null as it should have. This is clearly a problem. There are two ways of dealing with this: (1) changing the behavior of WikiPageTypeConverter so that it returns a valid WikiPage object whenever it is presented with a non-null page name, even if the page does not exist. The other solution is to (2) ensure that the WikiActionBean that depends on the WikiPage has the correct code to detect the non-existent page condition, and then can create a new WikiPage to fill that gap. ViewActionBean provides an example of (2). I think (1) is a better option because it means we fix the problem once in WikiPageTypeConverter, and don't have to write special handling code in every WikiPage-related ActionBean. However, I don't fully understand how this would interact with ContentManager. Can you create new "temporary" Nodes that aren't persisted? Do we need a WikiPage method like isSaved() or similar to indicate whether it's been persisted to JCR? Dunno how hard this is. Andrew On Thu, Apr 16, 2009 at 5:05 PM, Janne Jalkanen wrote: > Heya! > > Could you Andrew walk me through exactly how new pages are supposed to be > created? As far as I can tell, everything just explodes if you try to edit a > page which does not exist, and there really isn't a place to call > ContentManager.addPage() either, since the WikiPage gets set in > WikiPageConverter, and non-existent page is considered an error. > > /Janne >