OK, thanks for the link, I will study...
Jacques
From: "BJ Freeman" <[EMAIL PROTECTED]>
I have not written much on the wiki yet because is very complicated.
however part of the proposal is the stages and sequence to get this done
so people that have data already in use will not suffer.
in the light
yes there will be a series of patches probably under different task in
the same jira.
http://docs.ofbiz.org/display/OFBIZ/Address+Schema+Change+Proposal
Jacques Le Roux sent the following on 8/9/2008 10:26 AM:
From: "BJ Freeman" <[EMAIL PROTECTED]>
Yes it save a lot of programming. mostly in matching the stored address
with the with the user input.
that is part of the change plan to to implement that.
the stored postal address, would be already postoffice formatted for the
country. so the matching algorithm for the user input and the screen to
do this is more complicated, but will worth the effort making sure there
is a usable address in the system.
This is interesting. I think we will look forward for a Jira with
patch(es). I write patch(es) because if it's a large piece of code it is
worth to split it in patches.
For instance at least data model and code separated. Maybe more
separation between code from functionnalities, etc.
Jacques
Jacques Le Roux sent the following on 8/9/2008 3:22 AM:
I agree that addresses should not be specific to a party and could be
shared. Let see what other think. There may be a good reason it's build
like that... It introduces some redundancy but maybe save programming
efforts...
Jacques
From: "BJ Freeman" <[EMAIL PROTECTED]>
ah, well I am working a plan to remove toname and attnname.
if you read the data books it was not laid out that way.
my concept was
contactMechtoPostalAddressAssoce
postal addresss -------------->postaladdressid
ContactMechID <------------contact Mech
the toname and attentent name would become part of the contact mech
types with those types using the same relationship.
so one postal address is in the database.
Just like in the real world that is just one address, or location.
Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
To answer you question you have only to have a look at the
PostalAddress
definition
There are specific fields there like toName and attnName which can't
shared. A PostalAddress is only an administrative mean to contact, not
to locate
Jacques
From: "BJ Freeman" <[EMAIL PROTECTED]>
so when someone else puts in the same address will they point to the
same address or will a new record be added?
Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
----- Original Message ----- From: "Jacques Le Roux"
<[EMAIL PROTECTED]>
To: <dev@ofbiz.apache.org>
Sent: Friday, August 08, 2008 11:24 PM
Subject: Re: Latitude, Longitude in PostalAdress
From: "BJ Freeman" <[EMAIL PROTECTED]>
contact mech may not always be the same address and geopoint
for an address it will always have the same geopoint
1) how do you connect an address that already exists with a New
ConactMech.
2) how do you connect the assoicated Geopoint that goes with that
address.
My last proposition should cover your previous demand. If you
expire
an address then the geo-point this address used (point to) would
still
exist but as the address is obsolete we don't have to care (this
address and its associations should not be used anymore)
Let see your new questions now:
1) Not sure to understand this one since an address is a type of
ContachMech. Did you not used a word for another ?
2) PostalAddress.ContactMechId -> ContacMech ->
ContacMech.TerrestialPositionId -> TerrestialPosition
Sorry should have been PostalAddress.contactMechId -> ContacMech ->
ContacMech.terrestialPositionId -> TerrestialPosition
Jacques
Jacques
Jacques Le Roux sent the following on 8/8/2008 1:00 PM:
Yes , this is a good point to note. Actually the geo point
continues to
exist (it may be used by another thing) but the relation between
it and
the address does not.
Jacques
From: "BJ Freeman" <[EMAIL PROTECTED]>
but some means would need to link the terrestrial position to
the
address so if the address part is disabled, through the
enddate, in
the
contact mech, so is the position associated with it.
I agree on the rest.
Adrian Crum sent the following on 8/7/2008 2:57 PM:
Jacques Le Roux wrote:
Yes actually, I was just thinking about the
EntityNameContactMech
pattern, not a rule indeed.
And because I wondered why we'd use this pattern in most other
cases
and not for GPS Geolocation, I just reviewed how Len
Silverston
suggests to deal with contact informations.
At this stage I must admit that things were not much more
clear. As
far as I read Len speaks only about PartyContactMech and
FacilityContactMech, but it's easy to extrapolate more
usages as
it's
done in OFBiz.
Now, please let me think loud. What is the difference
between a
postal
address and a GPS point ? Is there more differences between
them than between, say a telecom number and a postal address ?
Obviously telecom numbers and a postal addresses have
something in
common that a GPS point does not share: they are
mechanismes to
contact somebody (or something at large). A GPS point is
only a
mean
to locate somebody (or something at large), you can't
contact a
GPS point. So yes, it makes sense to differntiate a GPS point
from
other contact mech. A GPS point is not a contact mech as Len
Silverstion defines one. It's a mean to locate not to
contact. So
now
I better understant why you wanted things to point to it
rather than having it point to other things. I still wonder
though if
we should not think a bit more about it. Putting a
terrestrialPositionId in ContactMech does not make sense, as
it's not
a mean to contact but locate. Should we not introduce
something else. Like a LocateMech, which could be maybe
used for
other
stuff in future ?
I like the idea of making terrestrial position another contact
mech
type.
I disagree that you can't contact a GPS point. You can if you
have
a GPS
device and a means of transportation - the same as a postal
address. How
is locating someone via car plus GPS device any different than
locating
someone via car plus a map?
I can think of other uses for a terrestrial position contact
mech
type -
locating facilities or fixed assets like electrical
transmission
towers,
cell towers, etc. They aren't going to have a postal address or
phone
number. If terrestrial position was another contact mech type,
then we
could use existing services, etc to associate that location to
the
facility.
-Adrian
