Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of donald.brown@gmail.com
 designates 64.233.170.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=CMAaKN4FQXERiui3Qj2ThcGTPm/vpaAgYZRgMDDGxnETmXAHRL6QDhrpxKTWtMT5Uj1gSG7o8qipaOh6ROPs6C/IDvQ/uD9taKKkUrcaeXSkrXu2ecgsZNkDf7JgySzCLy9HXHCz5lY9fVeGXq9ybNCATNWrswfqsZiCXx3BkgU=
Message-ID: <1c661f2f04112120114eb9b7c2@mail.gmail.com>
Date: Sun, 21 Nov 2004 20:11:31 -0800
From: Don Brown <donald.brown@gmail.com>
Reply-To: Don Brown <donald.brown@gmail.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [VOTE] Release Chain 1.0
In-Reply-To: <009201c4d047$292fa420$0302a8c0@mattlaptop>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20041121145254.T752@minotaur.apache.org>
	 <009201c4d047$292fa420$0302a8c0@mattlaptop>

I disagree - Context should extend Map.  I've used Chain in several
production applications and have enjoyed the methods Map brings to
Context.  It makes it easy for the context to be exposed to external
applications that don't need to know any more than Map interfaces, and
therefore are not required to know about Chain at all.  A good example
of this would be JXPath or JSTL tags.  I have used the methods you
mention in addition to ones like putAll() - very handy for moving from
one context to another.

As for ServletWebContext, I see your point, but I'd argue that
business classes would never see the actual ServletWebContext, but
rather get passed an application-specific context, which may or may
not contain ServletWebContext.  For Struts, I'm thinking we'd use an
ActionContext, which would look for objects in the scope hierarchy on
a get() as you suggest, if it detected a WebContext.  Otherwise, the
value would come right out of the ActionContext.  I could see the
value in bringing that scope logic to WebContext, however.

Don


On Sun, 21 Nov 2004 22:55:51 -0500, Matt Sgarlata
<matt.sgarlata@spiderstrategies.com> wrote:
> Before a 1.0 release, I would like to suggest an alternative Context
> interface.  Sorry, I realize I'm getting to the game a little late ;)  I
> think it is inappropriate for Context to extend from Map, because a Context
> as defined in the Chain package isn't really a Map.  Maps are great, but for
> what the Chain package is trying to do they're probably overkill.  One
> testament to this fact is the incredible difficulty of implementing the
> ServletWebContext class.  Implementing methods like entrySet(), keySet(),
> and values() are a real pain, and the implementations are all O(n)... ouch.
> 
> Below is my suggested alternative interface.  It's simple by design, to make
> it easy to implement.
> 
> public interface Context {
> 
>     public String[] getPropertyNames() throws ContextException;
> 
>     public Object get(String propertyName) throws ContextException;
> 
>     public void set(String propertyName, Object propertyValue)
>         throws ContextException;
> }
> 
> I also am concerned that the ServletWebContext class exposes too much
> information that is specific to the presentation tier.  Even if a business
> object were to depend only on the Context interface, if a ServletWebContext
> was passed in, the business object would be tied to HTTP symantics with
> calls such as context.get("sessionScope.myBean.myProperty").  I would
> recommend a context simliar to the one available to the JST: let request
> attributes be a scratchpad and let session and application items be visible
> so long as they aren't blocked by a lower level.
> 
> For full javadoc on my ideas behind contexts, please see the
> net.sf.morph.Context class and the net.sf.morph.context.* package.  Also,
> take a look at net.sf.morph.context.ServletWebContext.  Here's a link to the
> Morph homepage where you can access the Morph API:
> http://www.crystalcognition.com/sgarlatm/morph
> 
> I'm not on SourceForge yet but I applied on Friday so hopefully I'll be
> there soon!
> 
> Matt
> 
> 
> ----- Original Message -----
> From: "Martin Cooper" <martinc@apache.org>
> To: <commons-dev@jakarta.apache.org>
> Sent: Sunday, November 21, 2004 6:01 PM
> Subject: [VOTE] Release Chain 1.0
> 
> >I believe Chain is now sufficiently complete and stable to warrant an
> >official 1.0 release. There are no outstanding bug reports, and the
> >component is already in use in a number of projects.
> >
> > The plan is to release HEAD as Commons Chain 1.0 on completion of a
> > successful vote. I will be the release manager.
> >
> > ---------------------------------------------------------------
> >  [ ] +1  I support this release and am willing to help
> >  [ ] +0  I support this release but am unable to help
> >  [ ] -0  I do not support this release
> >  [ ] -1  I do not support this release, and here are my reasons
> > ---------------------------------------------------------------
> >
> > Here is my own +1.
> >
> > --
> > Martin Cooper
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org