Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 27228 invoked from network); 3 Mar 2005 16:01:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 3 Mar 2005 16:01:14 -0000 Received: (qmail 38363 invoked by uid 500); 3 Mar 2005 16:01:12 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 38328 invoked by uid 500); 3 Mar 2005 16:01:12 -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 Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 38312 invoked by uid 99); 3 Mar 2005 16:01:12 -0000 X-ASF-Spam-Status: No, hits=-10.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from minotaur.apache.org (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.28) with SMTP; Thu, 03 Mar 2005 08:01:11 -0800 Received: (qmail 27171 invoked from network); 3 Mar 2005 16:01:09 -0000 Received: from localhost.hyperreal.org (HELO ?127.0.0.1?) (127.0.0.1) by localhost.hyperreal.org with SMTP; 3 Mar 2005 16:01:09 -0000 Message-ID: <42273556.2090707@apache.org> Date: Thu, 03 Mar 2005 17:03:34 +0100 From: Carsten Ziegeler User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] A Unified Environment Model? References: <42239FC2.3020503@nada.kth.se> <422444FC.4040207@nada.kth.se> <4225F490.4000805@nada.kth.se> <42261931.5060703@nada.kth.se> <42264C8E.9010207@nada.kth.se> <4226C0C3.6010501@apache.org> <42272E3E.4040308@dslextreme.com> In-Reply-To: <42272E3E.4040308@dslextreme.com> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Rating: localhost.hyperreal.org 1.6.2 0/1000/N X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Ralph Goers wrote: > What exactly is this interface buying us again? > I think you missunderstood the idea, so I will try to explain it: Currently, the objects available in the object model are hard-coded, you can get a request object, a response object and some more. So something like objectModel.get(ObjectModelHelper.REQUEST_OBJECT) works. We don't want to change this! Or putting it in other words: accessing information contained in the object model will not change - the user side is not effected. So why are we doing this? Because we see the need in dynamically putting objects into the object model, so things like objectModel.get("systemproperties") or objectModel.get("user") will work . (This might be dumb examples, but I hope they get the idea across). So the question we try to answer is: how does this information get into the object model? And additionally we need a kind of a proxy here as well - some information are available beans, but it might be possible that other information needs some "calculation time" before it is available. In these cases we only want to generate it, when it is accessed. The basic idea is to have a component that delivers this information, when it is accessed. In our example, we register two components named "systemproperties" and "user" somewhere (this has to be defined) and when you do a get("user") on the object model the corresponding component fetches the user object from somewhere and returns it - this is totally transparent to the client site. HTH Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/