#1540 adds constants for the properties uitype, displaytype and presence in Vtiger_Field_Model

It's a good idea. I'm not totally sure about the first three in terms of the descriptive name, but to be honest I can't think of anything better right now ;-)

Added 1 commit:

• a8fd66c5 - #1540 (closed) Adds uitype constants to the Vtiger_Field_Model class

const UITYPE_USER_picklist = 32;

should be

const UITYPE_USER_PICKLIST = 32;

Thanks Martin, it's fixed now :)

Added 1 commit:

• e07c2d4f - #1540 (closed) cleanup: changes const name to uppercase

@ruben.estrada Adding and usage of constants is limited to Field model, Is there a thought to extend this to other api's for example in CRMEntity.php and others?

I could do CRMEntity if you want, but those codes are all over the code base. Maybe we can go file by file and merge that one by one. Otherwise it may take long and after we have replaced all the codes we would have to solve merge conflicts.

I would propose merging this. Then I'll do CRMEntity, have it merged, then we can see which other files we can do. What do you think?

IMHO, these constants should be moved into a "top-level" class, or dependency, which is always available. Then as we find uses of uitype integers anyone can update that part of code with the approriate constant.

Try running:

grep -rn "uitype =" .

At the top of your vtiger repo ;-)

which top-level class would you suggest? I wasn't sure about putting the constants in that class, but since there were already similar constants there, that was the easiest thing to do.

I agree about replacing the integers as we find them. Of course grep would be the way to go. But the list is somewhat huge. There's many tpls that use them. So the constants need to be available in that context too.

@ruben.estrada That's the $64,000 question ;-) I would think the architects of vtiger should suggest the best location.

@lord_alan ok, then let's wait for the official response from @uma.s

Title changed from #1540 (closed) adds constants for the properties displaytype and presence in Vtiger_Field_Model to #1540 (closed) adds constants for the properties uitype, displaytype and presence in Vtiger_Field_Model

@ruben.estrada I think moving these constants to 'Vtiger_FieldBasic' class will make this available to vtlib package as well, So that webservice can also make use of these.

Incrementally we should focus on cleaning up the constants across the files.

@lord_alan fyi

ok, so would you agree with this?: move all DISPLAYTYPE, PRESENCE, UITYPE to Vtiger_FieldBasic, modify the use of the constants inside of Vtiger_Field_Model (change self for Vtiger_FieldBasic), then merge that change, then replace integers for constants in CRMEntity, merge it, and then do the rest little by little?

@ruben.estrada Yes! I do agree to go with this. But we need to have a stratergic plan to get it executed effectively.

• The changes should be documented with the validated test-cases
• We should make sure to validate different end points (webservices, Http requests)
• Specific api altreation, should carry well defined comments to explain the change.

Status changed to merged