Hi list,
in this last period I heavily used the Tapestry IoC fantastic machinery in
different non-web java applications, and I love it.
However, I have the strong feeling that we (I and T5IoC) can do much more with
just a little more effort... but unfortunately I have no time to dive into the
code to find this out
(@Thiago: this is nice use case for you to understand if publishing -and
selling- "smaller" contents instead of BIG books, does actually pays off)
Currently, I am facing a design dilemma (which is common to many T5 users/devs)
and I really like to hear your voice and opinions about possible solutions.
================================================================================
The Problem
========
The non web application under design receives command-line arguments as inputs.
Some of them are optional, some of them have constrained values (i.e., ranges),
and some of them must have specific values.
Current Solution
==========
I am using the commons-CLI [1] library to
- define the various inputs commands/short-/long-name for the options,
- parse the various command lines options and values
I also wrote a lot of code (too much for my taster) to validate these inputs,
and also some code (really necessary ?!) to "export" the various options as
symbols to be used inside
my T5-driven application.
An Ideal Solution ?
===========
My current solution just work, but I feel it a bit hacky, and definitively
improvable. From my understanding of the T5 Philosophy I would rather plan to
design something like:
A new Tapestry (Sub-) Module that :
- builds upon commons-CLI (or equivalent library) to parse CLI options
and input arguments
- exploits/reuse the current validation framework to validate them*
- optionally (this is just to show off) reuse the internationalization
framework (for example in the description via the standard --help switch)
- a service (if symbols is not the right medium) that can be used to
query about inputs.
Needless to say, everything must be configured via the distributed
configuration framework that is already in place:
- "new" options /switches can be added by other modules
- new validators can be defined
- validators can freely associated to the different command line
options. (NotNull to any non optional module, min/max for range, and so on)
================================================================================
Ciao
-- Alessio
[1] http://commons.apache.org/proper/commons-cli/
