Hi Jeremy,
Jeremy Haile wrote:
>
> Keith,
>
> I don't understand why adding a FieldHandlerFactory is buried so deep in
> the API.
OK...I'll tell you why it's there...the short story is that's the one
class where it was needed to allow the functionality to exist.
I added the Factory class because I needed it for a project. I only had
time to add it directly to the Introspector, which is the class that
it's used in. I didn't have time to provide a way to do it from the
mapping file, properties file, or other class APIs. This is all stuff
that needs to be done, but it's not going to happen for the 0.9.5.3
release. That release has all it's features frozen, only regression
issues will be fixed. But this is something I plan on adding for
0.9.5.4.
This is the main reason that I don't really advertise this Factory
class, because it's not yet worked it's way through all the code. The
code is there if someone really needs it or wants to experiment with it,
but obviously it's not "easy" to get at...yet.
>
> Shouldn't we be able to say:
> unmarshaller.addFieldHandlerFactory( fhf );
That would be a lot easier, but then again, it would have to add a bunch
of code to keep ClassDescriptorResolver updated...what happens if a user
sets both a custom ClassDescriptorResolver and a
FieldHandlerFactory...ugh. It gets to be complicated at
times. Of course what needs to happen is that the default
ClassDescriptorResolver "defer" to a custom one and if the custom one
can't find the class, then the default one takes over, but that's not
what happens right now. It's very similar to the IDResolver stuff we
were talking about, with that different that if you set a Custom
ClassDescriptorResolver, the default one isn't used at all. All of these
"design" issues need to get cleaned up. The functionality is
there...just been built up over the years and never really refactored.
Refactoring is a good thing sometimes, it just takes time to do it.
>
> One thing I really don't like about the current usage is that we must
> implement an instance of ClassDescriptorResolverImpl.
No you don't have to implement an instance of
ClassDescriptorResolverImpl, you just need to instantiate one and pass
it in to the Unmarshaller. But again, I changed the one class that
required changing in order to add support for FieldHandlerFactory. Other
classes will change to accomodate this new feature.
> This makes the user have to know about Castor internal implementation classes and
> violates the code-to-an-interface paradigm.
It's not that bad! Ugly yes...but in reality it's only a couple lines of
code. A pain, sometimes...but at least the functionality now
exists...for the past 4 years it wasn't even possible in Castor to do
that...now it's possible and that's definately an improvement.
I thought I mentioned when I first told you about the
FieldHandlerFactory that it was a bit of a pain to configure but that I
would be changing that. Yes, I'm pretty sure I said something like that.
Once 0.9.5.3 final is released we can start tackling those other design
issues, such as the IDResolver one and this one. And all bugs and
enhancements that didn't make it in 0.9.5.3.
Right now we need to focus on making 0.9.5.3 as stable as possible
without tackling API improvements or new features.
Thanks,
--Keith
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
