You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Maryam Moazeni <mm...@gmail.com> on 2006/07/12 11:03:34 UTC
[Axis2]Google SoC - ADB Project
Hi All,
Regarding the implementation of complex content restriction,
I need to check each element that is going to be written with
its correspondent in the base type.
For each element in the complex content restriction I'm thinking of
following these rules:
1) if an optional element is missing from the base type,
override the getter and setter corresponding to the element and throw
appropriate exceptions.
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.
3) if the minOccurs and maxOccurs differs, (????)
4) if the attributes of the restricted type are different, (????),
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.
* 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();
* In (2) just another element is added to the tree like before.
* I need suggestions on (3) and (4).
Comments are appreciated ...
Thanks,
Maryam
[Axis2]Google SoC - ADB Project
Posted by Maryam Moazeni <mm...@gmail.com>.
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 < ajith.ranabahu@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [Axis2]Google SoC - ADB Project
Posted by Maryam Moazeni <mm...@gmail.com>.
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 <aj...@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [Axis2]Google SoC - ADB Project
Posted by Ajith Ranabahu <aj...@gmail.com>.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2]Google SoC - ADB Project
Posted by Maryam Moazeni <mm...@gmail.com>.
Sure, I will do that.
Thanks,
Maryam
On 7/17/06, Davanum Srinivas <da...@gmail.com> wrote:
>
> Maryam,
>
> Could you please open a JIRA issue and upload the code changes that
> you have now? I would like to review the code a bit
>
> thanks,
> dims
>
> On 7/12/06, Maryam Moazeni <mm...@gmail.com> wrote:
> >
> > Hi All,
> >
> > Regarding the implementation of complex content restriction,
> >
> > I need to check each element that is going to be written with its
> > correspondent in the base type.
> > For each element in the complex content restriction I'm thinking of
> > following these rules:
> >
> > 1) if an optional element is missing from the base type,
> > override the getter and setter corresponding to the element and
> throw
> > appropriate exceptions.
> > 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.
> > 3) if the minOccurs and maxOccurs differs, (????)
> > 4) if the attributes of the restricted type are different, (????),
> > 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.
> >
> > * 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();
> >
> > * In (2) just another element is added to the tree like before.
> >
> > * I need suggestions on (3) and (4).
> >
> > Comments are appreciated ...
> >
> > Thanks,
> >
> > Maryam
> >
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
>
Re: [Axis2]Google SoC - ADB Project
Posted by Davanum Srinivas <da...@gmail.com>.
Maryam,
Could you please open a JIRA issue and upload the code changes that
you have now? I would like to review the code a bit
thanks,
dims
On 7/12/06, Maryam Moazeni <mm...@gmail.com> wrote:
>
> Hi All,
>
> Regarding the implementation of complex content restriction,
>
> I need to check each element that is going to be written with its
> correspondent in the base type.
> For each element in the complex content restriction I'm thinking of
> following these rules:
>
> 1) if an optional element is missing from the base type,
> override the getter and setter corresponding to the element and throw
> appropriate exceptions.
> 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.
> 3) if the minOccurs and maxOccurs differs, (????)
> 4) if the attributes of the restricted type are different, (????),
> 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.
>
> * 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();
>
> * In (2) just another element is added to the tree like before.
>
> * I need suggestions on (3) and (4).
>
> Comments are appreciated ...
>
> Thanks,
>
> Maryam
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org