March 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBossXB] - Re: Attributes problem

by adrian＠jboss.org

"alex.loubyansky(a)jboss.com" wrote : I am fine the structure of the schema. The bizarre thing is how it is treated during unmarshalling. I am for ease of use too and clarity. But I don't know what "correct" is :) | | We need to set attributes on a node that don't belong to that node. Ok. What is confusing to me is why only on CDATA and not others? | Especially in the way you just wrote the schema: the cdata is a node on the same level as other elements. Why the attribute is lost on others? | | All I want to know is whether there is any other reason than "I don't need it in my example"? Because that isn't what is happening. It's probably easier to see with the property parsing. I'll repeat everything again, because although you say you understand you don't seem to be getting the key point. ;-) | <property name="blah" replace="false">x</property> | Is really in our underlying model | <property name="blah"><value replace="false">x</value></property> | The user can write it the long way if they want, but we give them the "short form" version. In this case, we've got a specific type we can store the "replace" on, so we don't need the wrapper hack because we can do it in our @XmlValue method. In the generic case (like the map's key/value) we don't have this option so we need to "synthesize it" during the parsing. i.e. it goes something like: | <map> new AbstractMapMetaData | <entry> new MapEntry | <key> new StringValueMetaData (SVMD) | <list> oops not CDATA discard the SVMD and use AbstractListValueMetaData | We need to put the SVMD in place early otherwise we've got nothing to set the attributes on (if there are any). This is an artifcat of attributes are processed being processed before the CDATA in the parsing. NOTE: There really aren't any attributes on "key" in our real model. They exist on the key in the xml just for ease of use. Key isn't even a type it's a property of MapEntry which accepts an interface which maps in xml to a group of posslble values including the synthetic SVMD wrapping the CDATA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134812#4134812 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134812

18 years, 1 month

1
0
0 / 0

[Design of JBossXB] - Re: Attributes problem

by alex.loubyansky＠jboss.com

I am fine the structure of the schema. The bizarre thing is how it is treated during unmarshalling. I am for ease of use too and clarity. But I don't know what "correct" is :) We need to set attributes on a node that don't belong to that node. Ok. What is confusing to me is why only on CDATA and not others? Especially in the way you just wrote the schema: the cdata is a node on the same level as other elements. Why the attribute is lost on others? All I want to know is whether there is any other reason than "I don't need it in my example"? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134801#4134801 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134801

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: State of the JAXB parsing

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : So there's really only 4 failures | due the wrapper problem, if you exclude the alias and policy parsing. ;-) It turned out that not all the 4 failures were due to the wrapping problem, but I've fixed these as well. The only errors now are in the old xml parsing tests, so I'm happy that this works now. ;-) The next step is to get jboss-reflect released so we can do a jbossxb-2.0.0.CR7 which will allow us to remove container from the MC project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134799#4134799 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134799

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DynmanicFromContext was Re: enums, generics and other an

by adrian＠jboss.org

"alesj" wrote : | It looked cool at that time. | Beware of "cool features". :-) They'll come back to haunt you when you need to make changes and realise it is no longer supportable in its current form because you did a "quick and dirty". Or in this case, DONT realise you are removing a feature because there's no contract or test for it. :-) Don't do a feature unless it is obviously correct, but even then only when somebody asks for (needs) it. It's less to support, maintain, fix and answer annoying questions (from users that can't be bothered to read the docs) about in future. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134798#4134798 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134798

18 years, 1 month

1
0
0 / 0

[Design of JBossXB] - Re: Attributes problem

by adrian＠jboss.org

"alex.loubyansky(a)jboss.com" wrote : | Yes, I understand this is what you need. But this, as a rule, looks very bizarre to me :) And I've been trying to make it more general hoping that it would make it less bizarre :) At least less bizarre to me and still do what you need :) It's bizarre because it is an ease of use thing. A fairly common one I would imagine? That is unless you want to piss off your users with verbose xml and redundant elements just to be "correct". :-) What is actually being done here is not something that xsd lets you express directly. Something like :-) | <type mixed="true"> | <choice> | <element name="list"/> | <element name="value"/> | <cdata/> | ... | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134797#4134797 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134797

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DynmanicFromContext was Re: enums, generics and other an

by alesj

"adrian(a)jboss.org" wrote : "alesj" wrote : "adrian(a)jboss.org" wrote : I don't understand why there is an InjectOption and an InjectionOption? | | | | | So, it the case you use annotations, you cannot get the DynamicFromContext. | | ... | | For FromContext see DynamicFromContext. | | | | What is that rubbish? :-) | Deleted. :-( It looked cool at that time. So that I wouldn't have to write new impl every time Diesler wanted to pull some detail from the underlying component. :-) So, another enum coming up. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134796#4134796 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134796

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: enums, generics and other animals

by adrian＠jboss.org

"alesj" wrote : | The Cardinality can be whatever, not just those 4 usual usages. | e.g. 2..7, 5..n, etc | ok. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134794#4134794 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134794

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - DynmanicFromContext was Re: enums, generics and other animal

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : I don't understand why there is an InjectOption and an InjectionOption? | | | So, it the case you use annotations, you cannot get the DynamicFromContext. | ... | For FromContext see DynamicFromContext. | What is that rubbish? :-) Why are you exposing "random" things? How do we know what people have used in the api if they can just select parts of it using reflection? You might as well let people write | <property><script type="javascript">do what you like here but its not very declarative | or guaranteed to work in future versions</script></property> | It also exposes things that are "private interfaces" | // Intended for the user | public interface ControllerContext {} | | public class MyControllerContext implements ControllerContext, | ImplementDetails // Not intended for the user and subject to change without notice | { | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134792#4134792 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134792

18 years, 1 month

1
0
0 / 0

[Design of JBossXB] - Re: Attributes problem

by alex.loubyansky＠jboss.com

adrian wrote : With the current rules it will parse the attribute and set it on the CDATA type | (StringValueMetaData). But since there is no CDATA, it is child element | instead, the attribute will be discarded and the child type used e.g. ListValueMetaData. | | We don't currently throw an exception for this. The spurious attribute is just ignored. Yes, I understand this is what you need. But this, as a rule, looks very bizarre to me :) And I've been trying to make it more general hoping that it would make it less bizarre :) At least less bizarre to me and still do what you need :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134790#4134790 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134790

18 years, 1 month

1
0
0 / 0

[Design of JBossXB] - Re: Attributes problem

by adrian＠jboss.org

"alex.loubyansky(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : The @XmlChild from some other part of the group | | needs to replace the CDATA. The CDATA and subelements are mutually | | exclusive. You can't have | | | | | <key class="java.lang.Integer">12 | | | <list ...> | | | </key> | | | | | | | It doesn't make sense. :-) | | Ok, if that doesn't make sense we can throw an exception. My question is then does the following make sense? Not in the given MC example but in general. Can this be useful? | | | | <wrapper attr="val1"> | | <child ...> | | </wrapper> | | <wrapper attr="val2"> | | <wildcard-content ...> | | </wrapper> | | <wrapper attr="val3">12</wrapper> | | | | My point was it didn't matter what the content of wrapper was, the attr should still be set in the same way. With the current rules it will parse the attribute and set it on the CDATA type (StringValueMetaData). But since there is no CDATA, it is child element instead, the attribute will be discarded and the child type used e.g. ListValueMetaData. We don't currently throw an exception for this. The spurious attribute is just ignored. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134786#4134786 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134786

18 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008