Hi Werner,
----- Original Message ---- > > Hi Kurt, > > Kurt Sorge wrote: > > Werner, > > > > > > > > ----- Original Message ---- > >> Kurt, > >> > >> Kurt Sorge wrote: > >>> Werner, > >>> > >>> Thank you for the quick reply. > >> You are welcome. > >> > >>> I was thinking it is in the > >>> binding.xml ... > >> Yes, it it, indeed. > >> > >>> or castorbuilder.properties somewhere. I had gone through > >>> that section of the reference guide the non-trivial example, and the > >>> pdf file. I guess I missed the part about attributeBinding (I am > >>> assuming that is what you are pointing me to). If that is the case I > >>> am still having trouble. > >>> > >>> I think I am looking for a more generalized solution. The example I > >>> give, topic_id, is just one of many attributes and elements with > >>> underscores in the name. I would find it impractical to map each > >>> instance in binding.xml and I would wager to guess my team would > >>> agree with me. > >> And I would agreed as well; if there's many of them, the solution I am > >> proposing is not the correct one. But let#s shave this discussion later > >> .... > > > > This leads me to believe that my request may not have a trivial answer. > It all depends. There's already 'global' naming rules that can be > specified within a binding file, but they deal with type/element name > conflicts through adding prefices and/or suffices. Maybe something > similar could be added. But again, this is not a trivial reqeust. I don't think that will be necessary, I have had a chance to talk to my colleagues and we came to the conclusion that something like this is a nice to have, but not a deal breaker. > > >>> I am not an xpath master, maybe I can match on any > >>> attribute with an underscore, but then I would find it hard to make > >>> the name camel case correctly. > >>> > >>> I have started experimenting with attributeBinding and have not had > >>> much luck so far. I found Jira #CASTOR-1117 with an example > >>> binding.xml using attributeBinding. I have a piece of schema that > >>> looks like: > >>> > >>> > >>> > >>> > >>> > >>> > >>> Now in my binding file I tried: > >>> > >>> > >>> > >>> > >>> with no success. The memeber name still gets generated as > >>> getTopic_id. I have also tried to move the complex type out of the > >>> element and then reference the attribute as > >>> "complexType:cWidgets/@topic_id" like in the example with the same > >>> result. Am I at least on the right track? > >> Yes, you are, and here's what I have been using > >> > >> > >> > >> > >> > >> which causes the right substitution to take place. > > I tried this, and it didn't work for me. Other projects will probably keep > > me from poking it with a stick until Monday. > Hmm; in the worst case, feel free to attach a working e.g. JUnit test > case that shows your problem. Question: how are you actually running the > code generator ? Through Maven ? Ant ? In any case, please makes sure > that your binding file is made known to the code generator through > configuration. That was my problem. I am using Ant and did not specify the binding file. Looking at W3C's x-path tutorial, I should also be able to match any "topic_id" attribute with something like "//@topic_id", but that did not seem to match anything. As a matter of academics, would you have any ideas why this would not work? > > >>> As a side note, I have been working with Castor for about a week now > >>> and I am impressed at how easy it is to pick up and use. I would just > >>> like to get passed this hurdle and another with multiple class > >>> generation when using , but that can wait for another > >>> day. > >> Feel free to throw this at us at any time, even if in parallel. > > I will take you up on that. > >>> Thanks Kurt > > > > Regards, > > Kurt > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
