commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vic <...@friendvu.com>
Subject Re: [VOTE] Release Chain 1.0
Date Mon, 22 Nov 2004 13:21:52 GMT
Not to jump all over you, but Chain was there for a year, and I too used 
it in prouduction. Alternative interfaces would mean redesign and maybe 
even problems for current users, it is not backwards compatible.

A key to its power is the Map. I realy think that if you got a chance to 
use it it would come to you.

I too agree that WebContext caries to much info. Also... the point of 
the map is to add what you need. I can think of 100 "Contexts" (Portlet, 
Hessian, Soap, JSF, JMS, Jabber, .... ).
Maybe in the 1.1 release those things are marked for deprecation.

.V


Matt Sgarlata 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


Mime
View raw message