Hi Steven,
see my comments inline.
[EMAIL PROTECTED] schrieb:
Hi guys,
I'm (re)reading the custom FieldHandler tutorial
(http://www.castor.org/xml-fieldhandlers.html) and tracing through the
code, starting from Mapping.loadMapping(), to figure out how and by what
class/method the FieldHandler gets set up, and hence where to start in
adding a format attribute to <field>.
Reading the FieldHandler tutorial is a good starting point as it may be
of much help to be familiar with them ;-)
Can you suggest any other good starting points? Also, is there anything
like http://castor.org/design-persist.html but about how the mapping stuff
is implemented? I.e. something that would explain the flow and process by
which the mapping file is converted into a tree of ClassDescriptors,
FieldDescriptors, FieldHandlers, etc?
I'm sorry but there is no such description on mapping available but I
don't think that you need to understand all of this crappy code that
really needs some refactoring. Just take a look at:
org.exolab.castor.mapping.loader.MappingLoader.createFieldDesc(..)
lines 670-699
and
org.exolab.castor.jdo.engine.JDOMappingLoader.createFieldDesc(..)
lines 398-427
on where the custom FieldHandlers get instantiated. You only need to
access the parameters to be passed to the handler, convert them if
needed and change the way the handler is instantiated. I think a good
idea would be to search for default constructor and a second one that
gets a java.util.Properties instance passed.
The package docs for Mapping are a good start:
http://castor.org/api/org/exolab/castor/mapping/package-summary.html
But I can't seem to find something similar for mapping/xml.
Once I have a clear idea of how to approach it, I'll open a JIRA issue
with the proposal.
On the attribute-vs-subelement question:
Adding a simple, single string attribute seems straight-forward enough and
non-controversial. The attribute can contain a formatting string
in whatever formatting syntax the FieldHandler can handle. This will be my
default approach, something like:
<field name="total" type="string" node="text"
handler="FormattingHandler" format="%9.2">
<bind-xml name="total"/>
</field>
I do want to think about how hard it might be to use an approach that
supports arbitrary XML tags. I'm not going to try too hard at it
(particularly because the rest of you seem rather skeptical at best about
this approach :-), but I figure it's worth taking a few minutes to
consider it. Maybe in a <format></format> tag set inside
<field>, like so:
<field name="total" type="string" node="text"
handler="FormattingHandler">
<bind-xml name="total"/>
<format>
<type>numeric</type>
<count>9</count>
<decimals>2</decimals>
</format>
</field>
The idea would be that everything inside the <format></format> tags is
entirely up to the FieldHandler implementer. The reason I like this
approach is because it would give developers a lot more
freedom/flexibility in designing their formatter. Having to drop
out of XML and use a printf() style formatting language seems kind of
ironic. They could even embed an XSLT script to be invoked for
formatting.
I thought again about the attribute-vs-subelement problem and also had a
short discussion with Werner. WE agreed that the subelement approch is
much more flexible and that it should be the prefered one. But I'd
propose a different syntax as outlined below.
<field name="total" type="string" node="text">
<bind-xml name="total"/>
<fieldhandler type="FormattingHandler">
<param name="type" value="numeric"/>
<param name="count" value="9"/>
<param name="decimals" value="2"/>
</fieldhandler>
</field>
This will allow the same flexibility as your suggestion but is much
simpler to implement. The drawback is that we will need to support the
handler attribute on field tag for backward compatibility. As done at
other areas of mapping we should allow to specify handler without
parameters as attribute on field tag but if fieldhandler tag is
specified the attribute will be ignored.
As far as I see the requiered tasks yet you need to:
- change mapping.xsd and mapping.dtd
- regenerate mapping/xml classes
(there is an ant target 'gen.mapping' available for this)
- change construction of custom handlers at codeareas mentioned above
- execute XML and JDO tests to verify nothing got broken
- adjust docs for XML mapping and field handler
- add info about changes to release notes
Steven J. Owens
[EMAIL PROTECTED]
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
Hope this helps
Ralf
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
