On Tue, 24 Sep 2013 09:30:57 -0300, Alessio Gambi <alessioga...@gmail.com>
wrote:
Hi list,
Hi!
in this last period I heavily used the Tapestry IoC fantastic machinery
in different non-web java applications, and I love it.
Yay!
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
Don't forget that Tapestry-IoC is about IoC and I think that's the only
thing it should focus.
(@Thiago: this is nice use case for you to understand if publishing -and
selling- "smaller" contents instead of BIG books, does actually pays off)
Thanks for the shoutout and suggestion! ;)
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.
I don't think that's common.
================================================================================
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.
I agree with Martin Kersten: this is an interface problem, not an IoC one.
Command-line is just another interface between your code and everything
outside it, be it users, other code or other machines. That shouldn't be
part of Tapestry-IoC.
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.
For the validation, why don't you use Bean Validation aka JSR 303? By the
way, if you pass some -Dxxx=yyy argument, it's turned into a symbol
automatically AFAIK. For adding new symbols, you just need an ordinary
contribution to FactoryDefaults or, if that's not possible or interesting,
you can contribute a SymbolProvider to SymbolSource.
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)
Go ahead and do it! :)
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
