Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 22007 invoked from network); 12 Nov 2007 20:19:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Nov 2007 20:19:19 -0000 Received: (qmail 13452 invoked by uid 500); 12 Nov 2007 20:19:06 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 13433 invoked by uid 500); 12 Nov 2007 20:19:06 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 13424 invoked by uid 99); 12 Nov 2007 20:19:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2007 12:19:06 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sandro.boehme@gmx.de designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 12 Nov 2007 20:19:55 +0000 Received: (qmail invoked by alias); 12 Nov 2007 20:18:47 -0000 Received: from port-83-236-207-190.static.qsc.de (EHLO [192.168.1.27]) [83.236.207.190] by mail.gmx.net (mp042) with SMTP; 12 Nov 2007 21:18:47 +0100 X-Authenticated: #1646957 X-Provags-ID: V01U2FsdGVkX18vFx9YcuAvm9W5qtZNdtWNPR+pJ2IW7iCdc6Y/7C v2XncBWMFRN1tx Message-ID: <4738B52B.3040006@gmx.de> Date: Mon, 12 Nov 2007 21:18:51 +0100 From: =?ISO-8859-1?Q?Sandro_B=F6hme?= User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: users@jackrabbit.apache.org Subject: Re: Jackrabbit Best Practices/Design Patterns (an attempt) References: <13621138.post@talk.nabble.com> <13624765.post@talk.nabble.com> <510143ac0711070718i430fc7c8ha55e68a89a497849@mail.gmail.com> <4734C9A4.4050302@gmx.de> <510143ac0711111233i2736f4bdi12fa1ec9679e4984@mail.gmail.com> In-Reply-To: <510143ac0711111233i2736f4bdi12fa1ec9679e4984@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org Jukka Zitting schrieb: > Hi, > > On Nov 9, 2007 10:57 PM, Sandro B�hme wrote: >> Especially in this case a simple >> NodeIterator "node.getNodesByType(String nodeTypeName)" >> would be very handy. But as it is not available I would personally >> favor wrappers for that. >> >> Hoping that expert group folks are reading this: >> I'm just curious, was this usecase already considered by the expert >> groups and discarded for some reason? > > I wasn't around for JSR 170, so I can't say. > > Personally I tend to prefer using paths for node selection (for > example have all "songs" as /songs/ nodes) and node types > only for deciding what to do with an already selected node. In my > experience such late binding works wonders for modularity and > flexibility. > > Such a design would for example allow you to make no distinction > between a custom mymusic:Song node and a standard nt:file MP3 node > uploaded through the standard WebDAV servlet. As long as your > application has handlers for both mymusic:Song and nt:file, it can > simply list everything within ./songs/*. In fact the application > doesn't even need to have such handlers, but the code that lists the > songs will still work fine. > > BR, > > Jukka Zitting > Hi Jukka, this solution is interesting. It clearly shows that one could also solve this problem using loose typing and the available API. Additionally I think it would just be cool if strong typing would also be supported with a method along the lines of getNodesByType(nodeTypeName). Bye, Sandro