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 <chris.trav...@gmail.com
<mailto:chris.trav...@gmail.com>> wrote:
On Sun, May 6, 2012 at 8:30 PM, John Locke <m...@freelock.com
<mailto:m...@freelock.com>> 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
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
!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/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
