[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Address formatting functionality


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  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...


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?



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/


Ledger-smb-devel mailing list