On Jul 26, 2006, at 11:00 AM, Jason Carreira wrote:
I understand that there are different ways to skin the cat, but
what if I want to reuse my actions in different contexts? What if I
want to call my action from a JBPM workflow? Do I need to subclass
it to override the result that's returned?
Yes, that is exactly what you'd do. You'd use a mechanism that every
java developer is already intimately familiar with - subclassing.
But let me ask you this: out of all WW2 actions that exist (not just
in your project, but everywhere) how many do you think get reused in
a non-web context? 10%? 5%? I know XWork is designed to allow
this, but is it a common case? Would you not be better off if it
took less work to write up the majority of actions that are web-only,
and then through subclassing or some other similar setup, could
extend and override the behaviour for other contexts?
I agree that XML has it's place, but used for configuration data that
doesn't change at runtime, it has several downsides:
- it is less easily compiled/validated
- you naturally have to have linkage between XML and code, leading
to repetition
- /new/ developers have to learn your XML dialect to become
productive
On a side note, have you seen the stuff where people try to do code
versions of the configuration for Spring? It looks horrible, even
when they've gone to the effort to try to develop DSL-type helper
methods.
No I haven't, but I can imagine. I'm not a big spring user. But
even here, I've argued before that I'd much rather see injection
sites declared using annotations in code (e.g. @Dependency
("someServiceName/Type")) than in XML. That keeps all the
information about the class in one place. But I think actual service
configuration makes sense in XML (ok, honestly I'd prefer YAML, but
that's another story), and doing this in Java would likely lead to an
unreadable mess.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
