Modularity of Aegis type creators makes it cumbersome to customize, suggest a
type creator factory.
---------------------------------------------------------------------------------------------------
Key: XFIRE-816
URL: http://jira.codehaus.org/browse/XFIRE-816
Project: XFire
Issue Type: Improvement
Components: Aegis Module
Environment: independent
Reporter: benson margulies
Assigned To: Dan Diephouse
Attachments: tc.tar.bz2
The DefaultTypeMapping registry serves, amongst many other things, as the
factory for type creator objects.
I found myself wanting to change the behavior of the standard XMLTypeCreator.
The DefaultTypeMappingRegistry takes a TypeCreator via one of its constructors,
but this doesn't work, because it just turns around and manufactures
XMLTypeCreators as it goes.
I suggest that you introduce the idea of TypeCreatorFactory, and allow the
default type mapping registry to consume it.
I'm attaching three classes that demonstrate what I ended up with when trying
to customize. Note that, in addition to having to make a subclass of
DefaultTypeMapping registry just to ensure the use of my type creator, I has to
subclass both the XMLTypeCreator and the XMLBeanTypeInfo. The actual thing I
was trying to do, which was to impose my own ideas of appropriate namespaces,
is something of a hopeless cause at the level of individual Aegis class
mappings, due to the interactions with global namespaces. However, if my
crusade to control namespace prefix usage at the element/class level isn't
completely stupid, it seems to me that a similiar modularity question is raised
by the heft of the functions I had to copy just to do it.
All in all, I'm imagining changing NamespaceHelper from a bunch of static
functions to a legitimate object at the service level, which could be
customized to allow control over namespace prefixes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
