From oak-dev-return-2615-apmail-jackrabbit-oak-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Sep 19 12:57:32 2012 Return-Path: X-Original-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 615A5DE82 for ; Wed, 19 Sep 2012 12:57:32 +0000 (UTC) Received: (qmail 253 invoked by uid 500); 19 Sep 2012 12:57:32 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 223 invoked by uid 500); 19 Sep 2012 12:57:32 -0000 Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oak-dev@jackrabbit.apache.org Delivered-To: mailing list oak-dev@jackrabbit.apache.org Received: (qmail 212 invoked by uid 99); 19 Sep 2012 12:57:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Sep 2012 12:57:32 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com designates 209.85.212.42 as permitted sender) Received: from [209.85.212.42] (HELO mail-vb0-f42.google.com) (209.85.212.42) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Sep 2012 12:57:27 +0000 Received: by vbbfs19 with SMTP id fs19so2299329vbb.1 for ; Wed, 19 Sep 2012 05:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=zYkHNZn3otkWuh6XBnuX1UNHt2jwSpk7FZOY9T9qkGE=; b=W8Drq+3wbchSavuEw+hUFHuznD5swv2q6olAECNPzFZ78cYlAqMj/Xq9BPodcBSLXe WVcNjs6gkm47D52Q+5BSDoEpnn/9SgkoMt3n5NQHSiSVfe7LciMte5Tc65C/lKSr18V2 zRewgHF04JquxTNvpBkLZz8C91k5ZwGcwRRYjqnlhwzqQIrffuhq6pUkXx3RB4CjsuGX v0lHAnSlSA2yIFkgAyS36CyGPXhzcNI4ScA7288o/9XkOXxcYKdg2oxfSSRk8F8nCdXf ojioEWN8HKE3CCaYwnKx6kH24KLG2oRb3xTgwg7QMqEB+CQ8Zn2qcK8FLnSNZ0sUjP/c ypnw== Received: by 10.58.227.106 with SMTP id rz10mr1964333vec.19.1348059425987; Wed, 19 Sep 2012 05:57:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.91.194 with HTTP; Wed, 19 Sep 2012 05:56:45 -0700 (PDT) In-Reply-To: <5059B660.3070800@gmail.com> References: <5059B660.3070800@gmail.com> From: Jukka Zitting Date: Wed, 19 Sep 2012 14:56:45 +0200 Message-ID: Subject: Re: On virtual content To: oak-dev@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hi, On Wed, Sep 19, 2012 at 2:11 PM, Michael D=FCrig wrote: > Incidentally I was playing around with something along these lines on top= of > the Tree interface lately. To see how things work out I implemented a > 'mounting' feature to mount a tree onto a sub-tree at a given path. My > implementation uses a decorator on top of the Tree interface for tracking > the mount point, the host tree and the mounted tree. Still very raw, but > workable: > https://github.com/mduerig/jackrabbit-oak/commit/9b1492e3c83aaed2f919196c= ddc60d5915add6f8 Nice! > My tree decorating approach is one way. However I feel this can get prett= y > complex for other cases where one for example wants to map virtual > properties into certain nodes. The main source of complexity is inherited > from the complexity of the Tree interface (mutators, navigators, helpers = and > so on). Right. I'm not sure if the decorator pattern is the right solution here, as it implies having to cover a lot of functionality and complex state. An internal extension point inside the Tree (or NodeState) implementation might be a simpler alternative. BR, Jukka Zitting