On 02/02/2013 15:35, Simone Tripodi wrote:
Salut mon ami,
In the case of converter, where would you stop? a module for date, one for
exceptions, one numbers, one for currencies....?
That was my thought indeed :P
I just wonder how many modules we will finally have?
Usually in such case, I like having a org.onami.converter.all for guys
like me who are lazy (I prefer declaring one module than many) and who
dont' care handling big jars :)
Thx, Eric
dependency, and also with a ConverterRegistry (such as [1]).
we don't have currently such registry since the conversion is
delegated to the Guice core, we just plug conversters in the binder
and let Guice do the work.
The reason why converters were included in the [configuration] module
was that users can load from properties files and bind values to
custom types.
Not sure if a registry is worth, but we can always let evolve that new
convertion module.
Thanks!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Feb 2, 2013 at 4:20 PM, Eric Charles <[email protected]> wrote:
Well, logging split makes perfectly sense (if I use log4j, I don't use
logback... for example).
Although I am a big fan and pusher for modularity, I have constated that
most of developers I met/talk to in real life have tendance to split less
than I would do.
In the case of converter, where would you stop? a module for date, one for
exceptions, one numbers, one for currencies....?
I would simply start with a single parent module
(org.apache.onami.converter) with a single child module
((org.apache.onami.converter.core) as long as there is no 'heavy' external
dependency, and also with a ConverterRegistry (such as [1]).
But if you code it, that's all in your hands :)
Thx, Eric
[1]
https://github.com/dhanji/sitebricks/blob/master/sitebricks-converter/src/main/java/com/google/sitebricks/conversion/ConverterRegistry.java
On 02/02/2013 14:55, Simone Tripodi wrote:
just have a look at how the logging module has been organized... I
like the modules granularization here, where users include only the
logger they need, keeping outside what is unneeded.
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Feb 2, 2013 at 3:51 PM, Simone Tripodi <[email protected]>
wrote:
Salut mon ami!
not only I would move the converters package to a 'TLP'
org.apache.onami.converters module, I would even split converters in
different small submodules, so users bring just the converters they
need.
Let's say someone just needs a DateConverter... which is the sense of
including all the converters in the application?
Something suggests me we should take more care about modularization...
does it make sense?
TIA, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Feb 2, 2013 at 2:30 PM, Eric Charles <[email protected]> wrote:
btw, sitebricks for which I have just created a pull-request for
validation
with bval-guice [1] has a dedicated module for convertion [2].
So it confirms convertion deserves a dedicated module.
Thx, Eric
[1] https://github.com/echarles/sitebricks/tree/validation
[2]
https://github.com/dhanji/sitebricks/tree/master/sitebricks-converter
On 02/02/2013 13:27, Eric Charles wrote:
Hi Simo,
Do you mean moving to a toplevel onami module
(org.apache.onami.converters)?
Just asking to be sure, but it makes sense to me as any other module
potentially need convertion.
Thx, Eric
On 02/02/2013 12:13, Simone Tripodi wrote:
Hi all guys,
I wonder if it would make sense extracting the converters from
[configuration] in separated modules - my objective is defining all
that modules in a fine granularization in order that users just
include in their application what they really need, and not everything
by default.
So I'd move all converters in a separated branch with sub-module.
Do you have any observation on that?
TIA and have a nice WE,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
