Re: Address formatting functionality

[John Locke <..hidden..>]

Hi,

Just for reference (hope this HTML comes through ok -- cc'ing you directly Erik/Chris, just in case), here's the table schema the Drupal addressfield module stores its data in:

Column	Type	Null	Default	Comments
entity_type	varchar(128)	No		The entity type this data is attached to
bundle	varchar(128)	No		The field instance bundle to which this row belongs, used when deleting a field instance
deleted	tinyint(4)	No	0	A boolean indicating whether this data item has been deleted
entity_id	int(10)	No		The entity id this data is attached to
revision_id	int(10)	No		The entity revision id this data is attached to
language	varchar(32)	No		The language for this data item.
delta	int(10)	No		The sequence number for this data item, used for multi-value fields
field_address_country	varchar(2)	Yes		Two letter ISO country code of this address.
field_address_administrative_area	varchar(255)	Yes		The administrative area of this address. (i.e. State/Province)
field_address_sub_administrative_area	varchar(255)	Yes		The sub administrative area of this address.
field_address_locality	varchar(255)	Yes		The locality of this address. (i.e. City)
field_address_dependent_locality	varchar(255)	Yes		The dependent locality of this address.
field_address_postal_code	varchar(255)	Yes		The postal code of this address.
field_address_thoroughfare	varchar(255)	Yes		The thoroughfare of this address. (i.e. Street address)
field_address_premise	varchar(255)	Yes		The premise of this address. (i.e. Apartment / Suite number)
field_address_sub_premise	varchar(255)	Yes		The sub_premise of this address.
field_address_organisation_name	varchar(255)	Yes		Contents of a primary OrganisationName element in the xNL XML.
field_address_name_line	varchar(255)	Yes		Contents of a primary NameLine element in the xNL XML.
field_address_first_name	varchar(255)	Yes		Contents of the FirstName element of a primary PersonName element in the xNL XML.
field_address_last_name	varchar(255)	Yes		Contents of the LastName element of a primary PersonName element in the xNL XML.
field_address_data	longtext	Yes	NULL	Additional data for this address.

... It looks like they have a custom data entry form per country, but all data is stored in a table like this (this is a specific instance of an addressfield). Without digging deeper, I would expect to find a template that describes the input format and output template for each country, mapping to these columns. Any country that wants additional arbitrary fields would likely have them serialized in field_address_data.

So it sounds like the same basic approach you propose, Erik -- sounds totally reasonable to me.

I hope this column break-down is helpful...

Cheers,
John

On 05/07/2012 11:41 AM, Erik Huelsmann wrote:

On Mon, May 7, 2012 at 5:53 AM, Chris Travers <..hidden..> wrote:

On Sun, May 6, 2012 at 8:30 PM, John Locke <..hidden..> wrote:
> Drupal 7 has been addressing :-P these issues with an "addressfield" module
> ( http://drupal.org/project/addressfield ), which aims to incorporate the
> flexibility of xNAL - http://xml.coverpages.org/xnal.html .

Interesting idea.  I am all for incorporating work of others into
LedgerSMB.  However, I am not sure how this would be done since I
doubt our invoices, check printing, etc. will ever move off TT/LaTeX.
it seems to me we'd have to find out what they are doing regarding
address formats and convert these into TT snippets to be used.

Chris and I evaluated xNAL this afternoon and while it seems to be a very good tool to help design a schema for storing names and addresses, it doesn't seem to concern itself with actual representation of address data.

Some of the links enumerated by Havard elsethread do do that. Going over the examples provided by BitBoost.com, we've come up with the following solution:

We think about creating a default address template and adding the option to add a template per country.

When producing an address, the template (either the default or the country specific one) would be processed by template toolkit to fill out name, street, etc. Then the result will be post-processed to remove any white-space-only lines from the output.

The end result being an opaque array of lines to be printed on an envelope, invoice or other document -- without the need to build the same intelligence into every template.

Would this be a suitable solution to most situations you can imagine using LedgerSMB?

Bye,

Erik.

!DSPAM:4fa81801314441714917295!

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

!DSPAM:4fa81801314441714917295!

_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:4fa81801314441714917295!