Would it be neccessary to build the whole tree for the schema even if i just
need part of the information from the xml file. For example, a
faces-config.xml contains information on validators, converters, components,
managed-beans etc. I just need info on managedbeans. I was thinking I would
just generate classes for managed-bean and its child elements and forget
about the rest. Does anybody see any reason to generate classes for stuff we
will not use?
On Mon, Jun 23, 2008 at 1:20 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> Yes, that looks like the correct conversion. Jaxb does not enforce (or
> even check) that elements are in the correct order when reading a document,
> so the ordering declaration in the generated bean won't effect you.
>
> -dain
>
>
> On Jun 22, 2008, at 3:12 PM, Karan Malhi wrote:
>
> But a choice does not require elements to be in a certain order whereas a
>> sequence does. Here is how I changed from a choice to a sequence (notice
>> the
>> propOrder attribute of the @XmlType annotation. I am not sure if i did it
>> correctly or not, could you please confirm if the below is the correct way
>> of doing it
>>
>> Here is the original xsd :
>> <!-- **************************************************** -->
>> <xsd:complexType name="faces-configType">
>>
>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>> <xsd:element name="application"
>> type="javaee:faces-config-applicationType"/>
>> <xsd:element name="factory"
>> type="javaee:faces-config-factoryType"/>
>> . . . . . . . . .
>> . . . . . . . . .
>> <xsd:element name="faces-config-extension"
>> type="javaee:faces-config-extensionType"
>> minOccurs="0"
>> maxOccurs="unbounded"/>
>> </xsd:choice>
>> . . . . . . . . .
>> </xsd:complexType>
>> <!-- **************************************************** -->
>>
>> Here is what I changed it to:-
>>
>> <!-- **************************************************** -->
>> <xsd:complexType name="faces-configType">
>> <xsd:sequence >
>> <xsd:element name="application"
>> type="javaee:faces-config-applicationType"
>> minOccurs="0" maxOccurs="unbounded"/>
>> <xsd:element name="factory"
>> type="javaee:faces-config-factoryType"
>> minOccurs="0" maxOccurs="unbounded"/>
>> . . . . . . . . .
>> . . . . . . . . .
>> <xsd:element name="faces-config-extension"
>> type="javaee:faces-config-extensionType"
>> minOccurs="0"
>> maxOccurs="unbounded"/>
>> </xsd:sequence>
>> </xsd:complexType>
>>
>> <!-- **************************************************** -->
>>
>> And here is the final output of FacesConfigType.java
>> <!-- **************************************************** -->
>>
>> @XmlAccessorType(XmlAccessType.FIELD)
>> @XmlType(name = "faces-configType", propOrder = {
>> "application",
>> "factory",
>> "component",
>> "converter",
>> "managedBean",
>> "navigationRule",
>> "referencedBean",
>> "renderKit",
>> "lifecycle",
>> "validator",
>> "facesConfigExtension"
>> })
>> public class FacesConfigType {
>>
>> protected List<FacesConfigApplicationType> application;
>> protected List<FacesConfigFactoryType> factory;
>> protected List<FacesConfigComponentType> component;
>> protected List<FacesConfigConverterType> converter;
>> @XmlElement(name = "managed-bean")
>> protected List<FacesConfigManagedBeanType> managedBean;
>> @XmlElement(name = "navigation-rule")
>> protected List<FacesConfigNavigationRuleType> navigationRule;
>> @XmlElement(name = "referenced-bean")
>> protected List<FacesConfigReferencedBeanType> referencedBean;
>> @XmlElement(name = "render-kit")
>> protected List<FacesConfigRenderKitType> renderKit;
>> protected List<FacesConfigLifecycleType> lifecycle;
>> protected List<FacesConfigValidatorType> validator;
>> @XmlElement(name = "faces-config-extension")
>> protected List<FacesConfigExtensionType> facesConfigExtension;
>> <!-- **************************************************** -->
>>
>> On Fri, Jun 20, 2008 at 1:57 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
>>
>> I also typically replace choice groups with a sequence of optional
>>> elements. When JAXB generates java code for choice groups, it creates a
>>> List<Object> instead of fields for each choice, which just annoying to
>>> work
>>> with. JAXB will parse the documents file with the change.
>>>
>>> -dain
>>>
>>>
>>> On Jun 20, 2008, at 7:29 AM, Karan Malhi wrote:
>>>
>>>
>>> There's really nothing in the docs about cheating at this level.
>>>>>
>>>>>
>>>> :)
>>>>
>>>> Best bet is to try and trim the schema down to only what you really want
>>>>
>>>>> to generate. You may have to hack on the resulting java code a bit to
>>>>> wire
>>>>> it into any existing objects we already have jaxb objects for. If
>>>>> you're
>>>>> lucky there won't be too much overlap or any at all.
>>>>>
>>>>> Hmm... I didnt realize I might have to tweak the generated code. Good
>>>>> to
>>>>>
>>>>> know this.
>>>>
>>>>
>>>> --
>>>> Karan Singh Malhi
>>>>
>>>>
>>>
>>>
>>
>> --
>> Karan Singh Malhi
>>
>
>
--
Karan Singh Malhi
