Hi all,
I am a novice in Ofbiz. This is the best project :) I have a question about Person. I need to put Person Language and Person Nationality, but I don't find the way during creating a Person. May be, this is good idea to add this functionality in Ofbiz entities (Person) like fields Language and Nationality. I am not sure if this is the right way? I need of suggestion and I will be glad to help about this. Thanks! |
somebody can correct me if i am off base.
I think you you can use the contactmech type and purpose for this. Stanimir Todorov sent the following on 9/10/2007 3:25 AM: > Hi all, > > I am a novice in Ofbiz. This is the best project :) > > I have a question about Person. I need to put Person Language and Person > Nationality, but I don't find the way during creating a Person. > May be, this is good idea to add this functionality in Ofbiz entities > (Person) like fields Language and Nationality. > > I am not sure if this is the right way? > I need of suggestion and I will be glad to help about this. > > Thanks! > > > > |
In reply to this post by stodorov
For entity Person, you can extend it (using <extend-entity>) to include those 2 fields.
I've not seen any OFBiz codes dealing with Person/Party language or nationality. You may have to roll your own here. Jonathon Stanimir Todorov wrote: > Hi all, > > I am a novice in Ofbiz. This is the best project :) > > I have a question about Person. I need to put Person Language and Person > Nationality, but I don't find the way during creating a Person. > May be, this is good idea to add this functionality in Ofbiz entities > (Person) like fields Language and Nationality. > > I am not sure if this is the right way? > I need of suggestion and I will be glad to help about this. > > Thanks! > > |
In reply to this post by BJ Freeman
Contact mechs are used for contact mechanisms. Doesn't direct tie/relate to a Person.
While it could be possible to attach "language" to a contact mech, it'll be weird for a Person to have say Mobile Phone A on which only English can be spoken and Mobile Phone B on which only Spanish can be used. This is still valid, though, for a PartyGroup that has various contact mechs in different countries/locales speaking different languages. Language and Nationality are best tied to the Person himself/herself, not to the Person's contact mechs. Jonathon BJ Freeman wrote: > somebody can correct me if i am off base. > I think you you can use the contactmech type and purpose for this. > > Stanimir Todorov sent the following on 9/10/2007 3:25 AM: >> Hi all, >> >> I am a novice in Ofbiz. This is the best project :) >> >> I have a question about Person. I need to put Person Language and Person >> Nationality, but I don't find the way during creating a Person. >> May be, this is good idea to add this functionality in Ofbiz entities >> (Person) like fields Language and Nationality. >> >> I am not sure if this is the right way? >> I need of suggestion and I will be glad to help about this. >> >> Thanks! >> >> >> >> > > |
Administrator
|
In reply to this post by jonwimp
Yes AFAIK for now there is nothing regarding Language and Nationality in the data model, hence the code. This might be interesting
as a contribution. Jacques De : "Jonathon -- Improov" <[hidden email]> > For entity Person, you can extend it (using <extend-entity>) to include those 2 fields. > > I've not seen any OFBiz codes dealing with Person/Party language or nationality. You may have to > roll your own here. > > Jonathon > > Stanimir Todorov wrote: > > Hi all, > > > > I am a novice in Ofbiz. This is the best project :) > > > > I have a question about Person. I need to put Person Language and Person > > Nationality, but I don't find the way during creating a Person. > > May be, this is good idea to add this functionality in Ofbiz entities > > (Person) like fields Language and Nationality. > > > > I am not sure if this is the right way? > > I need of suggestion and I will be glad to help about this. > > > > Thanks! > > > > |
In reply to this post by jonwimp
yes, Jonathon.
I think this is the right way, to create <extend-entity> to include Nationality and Language. I mean to say, Nationality like child's place of birth or bloodline. This is personally for all life and can not be changed. I not mean citizenship. A citizenship can be changed or one person can have two or more citizenships. In this case concactmech with purpose is better idea. But in different country, citizenship and nationality can be different means or they can be the same. I think to use <extend-entity> and to include this fields. Thanks!
|
Hmm. Then I think... citizenship might be better modeled with an entity like PartyCitizenship or
PersonCitizenship, where to primary key would be [partyId, citizenship]. Something like that. It never occurred to me that a Person can have more than 1 citizenship! Thanks. :) Jonathon stodorov wrote: > yes, Jonathon. > > I think this is the right way, to create <extend-entity> to include > Nationality and Language. > I mean to say, Nationality like child's place of birth or bloodline. This is > personally for all life and can not be changed. > I not mean citizenship. A citizenship can be changed or one person can have > two or more citizenships. In this case concactmech with purpose is better > idea. > But in different country, citizenship and nationality can be different means > or they can be the same. > I think to use <extend-entity> and to include this fields. > > Thanks! > > jonwimp wrote: >> Contact mechs are used for contact mechanisms. Doesn't direct tie/relate >> to a Person. >> >> While it could be possible to attach "language" to a contact mech, it'll >> be weird for a Person to >> have say Mobile Phone A on which only English can be spoken and Mobile >> Phone B on which only >> Spanish can be used. This is still valid, though, for a PartyGroup that >> has various contact mechs >> in different countries/locales speaking different languages. >> >> Language and Nationality are best tied to the Person himself/herself, not >> to the Person's contact >> mechs. >> >> Jonathon >> >> BJ Freeman wrote: >>> somebody can correct me if i am off base. >>> I think you you can use the contactmech type and purpose for this. >>> >>> Stanimir Todorov sent the following on 9/10/2007 3:25 AM: >>>> Hi all, >>>> >>>> I am a novice in Ofbiz. This is the best project :) >>>> >>>> I have a question about Person. I need to put Person Language and Person >>>> Nationality, but I don't find the way during creating a Person. >>>> May be, this is good idea to add this functionality in Ofbiz entities >>>> (Person) like fields Language and Nationality. >>>> >>>> I am not sure if this is the right way? >>>> I need of suggestion and I will be glad to help about this. >>>> >>>> Thanks! >>>> >>>> >>>> >>>> >>> >> >> > |
In reply to this post by Jacques Le Roux
Nationality/race/minority/whatever would be in the PartyClassification and related entities. Language we'd need more info about to model. If you want to model all languages spoken I think we would need a new entity def, though actually PartyClassification could be used for that too. If you are looking for a language preference for application interaction, the UserLogin entity is the way to go. -David Jacques Le Roux wrote: > Yes AFAIK for now there is nothing regarding Language and Nationality in the data model, hence the code. This might be interesting > as a contribution. > > Jacques > > De : "Jonathon -- Improov" <[hidden email]> >> For entity Person, you can extend it (using <extend-entity>) to include those 2 fields. >> >> I've not seen any OFBiz codes dealing with Person/Party language or nationality. You may have to >> roll your own here. >> >> Jonathon >> >> Stanimir Todorov wrote: >>> Hi all, >>> >>> I am a novice in Ofbiz. This is the best project :) >>> >>> I have a question about Person. I need to put Person Language and Person >>> Nationality, but I don't find the way during creating a Person. >>> May be, this is good idea to add this functionality in Ofbiz entities >>> (Person) like fields Language and Nationality. >>> >>> I am not sure if this is the right way? >>> I need of suggestion and I will be glad to help about this. >>> >>> Thanks! >>> >>> > |
David E Jones wrote:
> > Nationality/race/minority/whatever would be in the PartyClassification > and related entities. > > Language we'd need more info about to model. If you want to model all > languages spoken I think we would need a new entity def, though actually > PartyClassification could be used for that too. If you are looking for a > language preference for application interaction, the UserLogin entity is > the way to go. Except when the party is not an OFBiz user. |
Adrian Crum wrote: > David E Jones wrote: >> >> Nationality/race/minority/whatever would be in the PartyClassification >> and related entities. >> >> Language we'd need more info about to model. If you want to model all >> languages spoken I think we would need a new entity def, though >> actually PartyClassification could be used for that too. If you are >> looking for a language preference for application interaction, the >> UserLogin entity is the way to go. > > Except when the party is not an OFBiz user. Hence the question about intended use. If they aren't an OFBiz user then the language preference for application interaction wouldn't matter, so the other or something like it would be what they want. Either way, until the original person specifies more of what they're looking for... who knows! -David |
David E Jones wrote:
> Adrian Crum wrote: > >> David E Jones wrote: >> >>> >>> Nationality/race/minority/whatever would be in the >>> PartyClassification and related entities. >>> >>> Language we'd need more info about to model. If you want to model all >>> languages spoken I think we would need a new entity def, though >>> actually PartyClassification could be used for that too. If you are >>> looking for a language preference for application interaction, the >>> UserLogin entity is the way to go. >> >> >> Except when the party is not an OFBiz user. > > > Hence the question about intended use. If they aren't an OFBiz user then > the language preference for application interaction wouldn't matter, so > the other or something like it would be what they want. > > Either way, until the original person specifies more of what they're > looking for... who knows! Yeah, I realized you already said that after I clicked Send. :p |
In reply to this post by David E Jones
Hi David,
Oh, yes! The PartyClassification is the best place for it. PartyClassification already has comprehensive suite of CRUD services/functions done. In PartyMgr. There are even some examples of its use. Like in Promos -> Rules. Also in the Marketing module. Thanks! > If they aren't an OFBiz user then the language preference for application > interaction wouldn't matter Still, it'll be useful and "standard practice" (in conformance with OFBiz data structures) to use PartyClassification. For the "language preference for user interaction with OFBiz app", I think that can still use PartyClassification, unless a single Party uses multiple languages based on which UserLogin is used for "interaction with OFBiz application". PartyClassication will also allow us to attach multiple citizenships to a single Party. Also possible are multiple language preferences, language abilities, and such, for a variety of functions (eg marketing). Jonathon David E Jones wrote: > > > Adrian Crum wrote: >> David E Jones wrote: >>> >>> Nationality/race/minority/whatever would be in the >>> PartyClassification and related entities. >>> >>> Language we'd need more info about to model. If you want to model all >>> languages spoken I think we would need a new entity def, though >>> actually PartyClassification could be used for that too. If you are >>> looking for a language preference for application interaction, the >>> UserLogin entity is the way to go. >> >> Except when the party is not an OFBiz user. > > Hence the question about intended use. If they aren't an OFBiz user then > the language preference for application interaction wouldn't matter, so > the other or something like it would be what they want. > > Either way, until the original person specifies more of what they're > looking for... who knows! > > -David > > |
In reply to this post by Adrian Crum
Hi peoples, sorry for my late answer
Yes, partyClassificationGroup is a good opportunity. This is a easy way to relate partyId with classificationGroups Nationality. My point is that nationality is samothing like "this person is under jurisdiction on this government in this country". This is important when this person is visiting in other country. Example: I am Bulgarian I have a problem, I will take this problem to Bulgarian embassy. This is the point. I can take protection of delegation on Bulgarian government in visited country. This model is enough for my needs and even more. Thanks for this good advice and I will use this way :) For language, I think to use partyAttribute may be. For me is important to know what kind of language speak my guest because I have a need to communicate with him. But the better decision may be is creating entity for relationship between Person and StandartLanguage. StandartLanguage exists in the data model. Only is nesassary to extend the existing data model with entity PersonLanguage for the relationship. Thank you!
|
Free forum by Nabble | Edit this page |