Hi Ajith,
Thanks for sharing your thoughts,
regarding point 3:
I thought if the original element is an array and it still remains to be an array in the derived type, then I should change the validate method of the array and replace the apptoperiate counts in :
<xsl:if test="not(@unbound)">
if (param.length > <xsl:value-of select="@maxOccurs"/>){
throw new java.lang.RuntimeException ();
}
</xsl:if>
<xsl:if test="$min!=0">
if (param.length < <xsl:value-of select="$min"/>){
throw new java.lang.RuntimeException();
}
</xsl:if>
BBut if the element is the derived type is not an array any more( it's still a subset of an array),
then I should rewrite the element.
Please confirm if that's the right assumption.
Thanks,
Maryam
On 7/12/06, Ajith Ranabahu <
[EMAIL PROTECTED]> wrote:
Hi Maryam,
Please see my comments inline
> 1) if an optional element is missing from the base type,
> override the getter and setter corresponding to the element and throw
> appropriate exceptions.
Yes. This seems appropriate
> 2) if the type of the element is a subtype of its corresponding type in the
> base type,
> write the element and its getter and setter as a not inherited field in
> the class.
This is alright too.
> 3) if the minOccurs and maxOccurs differs, (????)
This is a bit tricky. If the original field had minOccurs/maxOccurs
greater than 1 then it will become an array and if the occurance
counts differ from the basetype it is just a matter of generating the
setters with proper counts. if for a field that had min and max occurs
as 1 (which should have made the field non-array) then we should be
generating a seperate field and relevant getters and setters. For the
original field I would say you'll have to override the relevant
getters and setters to throw exceptions
> 4) if the attributes of the restricted type are different, (????),
I don't see any other option than overriding the getters and setters
and generating the new attributes.
> Also please note that processing attributes are not handled completely
> in the current version.
>
> So far we have two cases, either I should write the element completely as a
> field with its getter and setter
> or just overriding the getter and setter.
Overriding the getters and setters is the better way AFAIU.
>
> * In (1) the DOM tree generated in the
> JavaBeanWriter.addPropertyEntries(...) needs to be edited
> since the removed element is not an inherited element any more. There are
> two approaches here, either adding a "isRestricted"
> attribute to the property nodes or we can have separate nodes named
> "restricted" per missing elements.
> But, in order to edit this tree I need to have the root element of the
> tree, but some how it returns null when I use:
> Element root = model.getDocumentElement();
Hmm... this is something I have to look at.
>
> * In (2) just another element is added to the tree like before.
>
> * I need suggestions on (3) and (4).
>
> Comments are appreciated ...
>
> Thanks,
>
> Maryam
>
>
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
