Keith,
yes, I see what you're saying. There are certainly things you could do here to make
your handlers more reusable (e.g. using naming conventions and reflection) but they
all involve some extra work for developers. A hook into the TypeConverter would indeed
be the ideal solution but at least we have a stop gap solution in place ;-).
Thanks,
Max
Keith Visco wrote:
> Max Foxell wrote:
> >
> > Jaspreet,
> >
> > you could take the approach you outline but it has a number of drawbacks. The
> > following springs to mind:
> >
> > 1. Without a handler class your entity classes becomes constrained to the built
> > in types that Castor supports. Frequently developers want to use enumeration
> > classes (e.g. the ColourEnum class I described before). The benefits of using an
> > enum class include compile time checking (you can't have an invalid enum
> > reference), efficiency (you can do reference comparisons assuming a single JVM
> > and only references for classes loaded by the same class loader), extra type
> > safety (e.g. you can't compare a ColoursEnum with a TextureEnum because they're
> > different types, the same isn't true if you just store Strings) and the ability
> > to add behaviour as well as state to your enums. Handler classes mean you aren't
> > forced to map to static reference tables simply to store your enum values.
> > 2. Handler classes allow your object model more freedom which reduces the so
> > called "impedance mismatch" between your data model and your object model.
> > 3. Handler classes give you the opportunity to manage the interaction between
> > your classes and Castor
> > 4. Handler classes allow you to more easily map to existing object models (i.e.
> > they no longer need to be massaged to work with Castor).
> > 5. Powerful conversions can easily be added between database types and objects.
> > Over time a library of useful handlers could be developed that could be reused.
> > The potential possibilities here are vast ;-)
> >
> > I suppose at the end of the day it's up to you whether you stick to simple
> > Strings or introduce a handler class. The beauty of a handler class (and Castor
> > in general) is that it is unintrusive. Whatever you choose to do I certainly see
> > handlers as an extremely useful feature. Just my 2 cent's worth...
> >
>
> Max, those are all very good points..but the last one (#5) is a bit
> misleading. As Jeff Hoare points out in his mail, the FieldHandler is
> somewhat specific and not easily reused (you can see my response to
> that). The ideal feature you are both looking for is for the
> TypeConverter to be integrated into the mapping file. With this you can
> then build a nice library of TypeConverters.
>
> Hopefully the FieldHandler will allow you to get the job done, until
> someone takes the time to integrate the TypeConverter with the mapping
> file.
>
> Writing your own FieldHandler is ideal for those people who only have
> one or two cases which need special handling.
>
> Thanks,
>
> --Keith
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
