Fabio, Forgive my misunderstanding then. I do remember you talking about mapping sources and I didn't understand what you meant, as the code I was looking at was passing XmlElements around everywhere and it seemed impossible (or extremely difficult) to decouple the mapping model building from XML.
Looking at the /trunk code now, I see that XSD.exe-generated schema classes are being passed around (i.e. HbmClass) which is significantly better, but still based heavily on an XML source. There is a lot of magic and core logic that goes on inside the binders which would be a very difficult task to duplicate in another "mapping source." This was my concern. Since almost all the mapping logic and assembly is in the XML-based (or XSD-generated-XML-schema-class-based) binders, it's prohibitively difficult for someone to write a new mapping source. I was afraid that adding another "mapping source" would duplicate much of the functionality in the binders and create TWO definitive mapping sources which would be chaos to maintain. So, it seems the only proper way to add a new mapping source is to have this source build up the various "Hbm*" XML-based classes. However, we still haven't progressed very far from the XML-based model. -c On Tue, Nov 11, 2008 at 11:32 AM, Fabio Maulo <[EMAIL PROTECTED]> wrote: > Hi Chad.There is a difference between what do in NH-Core and what to for > NH-Core. > In NH-Core we can continue using XML and XMLbinders. > > As you read in Fluent-NH-list we are completely open to have some other > "mapping source". > More than one year ago I write about the possibility to have some other > "mapping source" without use XML. > NH metadata are decoupled from XML because we had moved a lot of > responsibility from XMLbinders to MetaData classes (sometime not > all responsibility). A demonstration is available in NHibernate.Validator. > > As I write in Fluent-NH-list, and here in the past, who want can inherits > from Configuration and extend it, and the method CreateMappings is public > and is the same used for all XMLBinders (HbmBinder in H3.2.6). > > If you, or somebody else, want start a project to map classes without use > XML we are here to help. > IMO is better to start the prj in NH-Contrib but there is no problem to > start the prj in some other place. > The advantage of NH-Contrib are: > 1) More closer to all NH developers (and there are more than one that know > how metada are working) > 2) More easy for users to find all NH related projects > 3) NHForge available for wiki, blog and so on (available even for > "external" project too) > 4) JIRA available > > If somebody speak Spanish or Italian I can explain how much we are > interested to create another "mapping source"... if the name NHibernate.ORuM > is not clear. > > NH is extensible and injectable, we are working for that but... if nobody > try to create alternatives nobody can understand what is possible without > deep changes in NH-Core. > > I don't understand why, each time somebody want write something to extend > NH capability, the first step is: "we need change NH APIs because NH is > coupled with...". > Let me know where NH is coupled with something and I will decoupled it. > > Sometime I must write the first class of NH.ORuM to be more clear (I write > C# better than I write English). > > Fabio. > > P.S. don't ask to decouple NH from Iesi.Collection because .NET FW don't > give us an alternative (btw Iesi.Collections are part of NH sources). > > 2008/11/11 Chad Myers <[EMAIL PROTECTED]> > > I approached this list about 6 months ago about the possibility of redoing >> the mapping configuration in NHibernate to remove the strong XML dependency. >> The decision, at that time, was to not proceed for a number of good and >> prudent reasons at the time. >> >> The subject has since come up again on the fluent-nhibernate development >> list and several people have suggested that we re-visit this decision again >> and see if the feeling is still the same. I was wondering if any of you have >> interest in this. >> >> There are several thoughts about how best to approach the XML-decoupling >> and I'd like to discuss them if anyone is open to hear them. If the will >> of the team is still that the configuration should remain the same >> (XML-based), then I won't bother you further. >> >> Thank you for your time! >> >> Sincerely, >> Chad Myers >> >> > > > -- > Fabio Maulo >
