Common Interfaces about quickbooks-sync HOT 11 CLOSED

@PleasantD Between now and Sunday.

from quickbooks-sync.

I have a fork that includes some common interfaces for the Ret types. I don't think I did anything with VendorAddress and BillAddress, but on quick check both of those are already partials. I have been meaning to do a PR for a long time. I'll try to go look at the status of my fork and see if I can get that in.

@jsgoupil accepts PRs if you wanted to add the interface for VendorAddress and BillAddress and any of the address address types that have common fields.

from quickbooks-sync.

Adding a partial is a good idea, however, it also allows you to add fields/properties. And that would be problematic for the XML generation. This would allow people to add types the way they want.
Adding an interface ourselves is also a possibility but the maintainability can be quite the nightmare; finding common types can be quite suggestive. Deciding what is a common type ourselves can be complicated.

What do you think @tofer regarding this? what approach would you go? I don't see anything being partial right now.

from quickbooks-sync.

OK, PR #45 created

from quickbooks-sync.

@jsgoupil You don't see anything partial? Seems like every class generated in Objects.cs is partial.

Looking at the XSD, we should absolutely be able to add a common interfaceto the Addresses. Most of them reference either group AddressData or AddressBlockData. Might be able to do it similarly to the way I did for the *Ret intefaces I just did the PR for.

<xsd:element name="LegalAddress">
	<xsd:complexType>
		<xsd:sequence>
			<xsd:group ref="AddressData"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:element>

<xsd:element name="BillAddress">
	<xsd:complexType>
		<xsd:sequence>
			<xsd:group ref="AddressData"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:element>

<xsd:element name="BillAddressBlock">
	<xsd:complexType>
		<xsd:sequence>
			<xsd:group ref="AddressBlockData"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:element>

<xsd:element name="VendorAddress">
	<xsd:complexType>
		<xsd:sequence>
			<xsd:group ref="AddressData"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:element>

from quickbooks-sync.

Well it was really easy to add interfaces for the AddressData and AddressBlockData groups in the XSD (IQbAddress and IQbAddressBlock), so I went ahead and just did it and pushed another commit to the PR here.

While I was in there, I noticed some other very commonly used groups, namely ContactInfo, CommInfo, and PersonName, so I also added interfaces IQbContactInfo, IQbCommInfo, and IQbPersonName respectively as well in case that is useful.

from quickbooks-sync.

Strange on the partial...

Maybe it has to do with how it's packaged?

from quickbooks-sync.

Oh yea, I forgot partials all have to be in the same library. So if you are decompiling to view source, that is probably not shown since it can't be treated as partial across libraries.

from quickbooks-sync.

So he couldn't really do partial then in his own project. We needed a PR.
Thanks for that PR. I will be updating this real soon.

from quickbooks-sync.

So he couldn't really do partial then in his own project. We needed a PR.

This is correct. Partials only exist withing a compilation unit and don't allow for extending a type.
They are just a friendly way for a large type to span multiple files, or for generated code to allow for custom extension within the compilation unit it is generated in.

This kind of common interfacing will help reduce the duplication I currently need.
When is a new release expected?

from quickbooks-sync.

Fixed in 2644a55
Released as qbxml-2.2.0

from quickbooks-sync.