> That had occured to me. However, in that situation,
>
> that you have Mailets and Gemlets, you have to make
> sure that you are very disciplined to put all your
> code into the Gemlets, to make sure it is possibly
> reusable by future Gemlets. In that scenario every
> single mailet consists of one line of code:
> Gemlet.execute("foobar");
>
> In that case you can just write one Mailet that
> handles every possible case with some config
> option telling it which Gemlet to call. And then
> Mailets become irrelevant.
Actually not irrelevant because you are still using a mailet, albeit only one.
The same argument can be leveled at many other technologies, in this context notably
servelets, it is theoretically possible to write a single sevelet which can process
any expected request, or to bypass servelets altogether and write a bespoke
application which processes http requests.
The issue then becomes at what point the cut off between productivity and features
drives you down the route of creating individual servelets/mailets for every task,
then your servelets/mailets can become very simple too, drawing on generic classes
which perform specific functions and are highly re-usable, and not constrained to work
within the context of a specific servelet/mailet API.
The added value is in allowing easy layering of the technologies so you rapidly arrive
at the specific functionality required, yet built from robust, tested and widely used
components, not your own ducttape, paper and string. You can then concentrate your
teams expensive resources on producing the application specific elements, not
re-inventing the wheel.
In your scenario there is still a role for matchers, they will filter irrelevant
requests from your mailet/gem gateway and allow configuration settings alone (not hard
code) to determine what requests are passed to which, if any, gemlet.
IMHO, d.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
