|
From: Jeff M. <je...@mk...> - 2003-05-02 11:11:53
|
On Thu, 2003-05-01 at 22:04, Jeff Duska wrote:
> I don't see how MockHttpServlet.getAttribute can work correctly when
> setAttribute and the getAttribute looking at different collections. This
> will work fine, if you only plan to set an Attribute or get an
> Attribute. In my case, I'm chaining two objects implementing a command
> pattern together. The first command sets some attributes with the
> standard setAttribute() , but when the next command tries to use
> getAttribute(). This will call myAttributeValues.getNextReturnObject(),
> but setAttribute appeared to use myAttributes.addActual(new
> MapEntry(aKey, aValue)). I don't see how it will find my attribute ever
> in the second command. It would seem to me that needs to update both of
> these collections, so the getAttributes would work correctly.
The problem is how do I know which collection I should be using when.
When does getAttribute return an object from setAttribute and when does
it return one from setupGetAttribute?
The way I get around this is to make sure setupGetAttribute has all the
objects that I expect setAttribute to set. I should know this as I will
be setting up setExpectedAttribute.
To be honest I really try and avoid using attributes as they're really
open to abuse. I use a single CustomSession object which contains all
the in scope objects I'm using. So get/setAttribute is something I
descourage from my projects.
>
> Next, I not sure I that getAttribute should use getNetReturnObject,
> because it appears to requires that the attribute be in the collection.
> In my usage of the HttpSession, I have a couple places where I test for
> the existence of the attribute like this
> (_session.getAttributte("mykey")==null). This will not work, because it
> will fire off an exception due to the attribute not existing in the
> myAttributte ReturnObjectBag.
session.setupGetAttribute(null);
;-)
This way your being explicit about all the inputs in to your component.
Not just the ones that exsist but also which ones don't exist.
>
> I think some of this can be turned off by turning setFailonVerify, but I
> could not see how MockHttpSession object could do this.
>
> Regards,
>
> Jeff Duska
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
--
Jeff Martin <je...@mk...>
|