> From: [EMAIL PROTECTED]
>
> Berin,
>
> I think it's unnatural for the job to have to worry about
> how many manipulators are in the chain. Instead, it should
> only worry about taking transactions from the input and
> putting them in the output. If the output happens to be a
> manipulator, then it should worry about pushing the
> transaction down the pipe.
Its easy enough to automate cycling through the manipulators.
I expanded the logic to show how it would deal with each instance.
>
> So the Job would have one input and one output and do the following:
>
> while ( ( transaction = input.getNextTransaction() ) != null ) {
> resp = m_output.process( transaction );
> m_notifier.handleResponse( resp );
> }
>
> If m_output happens to be a manipulator then it would do:
>
> Output:
>
> Response process( Transaction t ) {
>
> Transaction newTransaction = do_what_this_needs_to_do_to(t);
>
> if (newTransaction == null) {
> return new Response( ROLLBACK, t );
> }
>
> return m_output2.process( newTransaction );
>
> }
That seems reasonable, but it also requires the registration
method for the next stage.
What did you think about the Morphos proposal?
My spin is that I want to document creating components, and
have an easy to use system without adding too many dependencies.
I would have to document the Morphos system as well, which I
am not prepared to do at this time. I think it would be perfectly
valid after we cut the Version 1 ( aka book version ), but
until then I need to keep the system really simple.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
