Hi, sure you should abstract the comandline away. That the ui layer. So when your application dos something linke parse, process or validate that something that should be done in a service. Also check out the registry.autobuild feature. It works with everything not just bo und services.
For your app you should also consider antlr and generate a parser and lexxer for your needs . dont be shy grab the book and learn it if you dont know it now. It even gives you the possibility to extend the parser with logic like if a file exists or if a certain Option matches another one. Your commands are actually an interface language. And that makes it a domain specific language and that requires a paser generator or you end up with lots of code. Cheers, Martin Kersten, Germany Am 24.09.2013 14:31 schrieb "Alessio Gambi" <alessioga...@gmail.com>: > 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/
