On 05/20/2010 11:32 AM, Joshua J. Kugler wrote:
On Thursday 20 May 2010, Jeff Ortel elucidated thus:
> If taking this approach, It would probably make sense to have a
> 'Context' per plugin type. The context for MessagePlugin(s)
> could/should probably be:
>
> MessageContext
> * method<-- method name
> * params<-- parameters passed.
> * envelope<-- outgoing envelope XML document root.
> * reply<-- depends on how called:
> received() : reply = raw text
> parsed() : reply = sax parsed reply
> returning(): reply = object being returned.
>
>
> Thoughs? Comments?
> Is this any better? Am I smoking crack?
How about SendingMessagePluging and ReceiveMessagePlugin (or some such)
so the MessageContext is more consistent for all calls in the class.
In other words, you would avoid "blank" fields. Dunno...just off the
top of my head.
Thanks for the feedback Joshua.
The context is not really meant to be just a wrapper for parameters to the plugin methods
but to provide context around the event in which the plugin is participating. In this
way, I'd expect the context to be cumulative.
I expected to populate the fields in natural progression:
All methods:
* method <- name of method (web server operation) being invoked.
for created() add (params). Now context has:
* method
* params
for sending() add (envelope). Now context has:
* method
* params
* envelope
for received(), parsed() and returning() add (reply). Now context has:
* method
* params
* envelope
* reply
j