My apologies for the repost, but nobody seemed to have anything to say in "General Development"....


Despite the fact that we have access to the Enterprise WSDL, I've decided to use the Partner WSDL for a new project of mine. 

Basically what I've built is a dynamic form that uses an Object's Fields to populate a form on our webserver with the appropriate controls at runtime, collects the values and submits them back into SF.  I've got everything worked out the way I like: field type interpretation, field creation, list population, and even got field validation working... except that I can't think of a good way for my Salesforce Admins to indicate that a field should be required.

Take our Survey object, for example.  If they add a custom field to Surveys and make it required, then when a salesperson creates a new Survey object INSIDE Salesforce, they must supply a value.  I'm just looking for a way to indicate that it needs to be validated at the end-user.  Right now I'm using the Field's name to determine if the Field should be required by prepending "SFF_" to indicate the Field should be on the form, and not just in SF, and "VAL_" to indicate that the Field should be required. 

I'd really like to use each Field's Description property for keywords, like "Required" and "ShowOnForm" instead.  I don't like the idea of forcing a naming convention on custom Fields, and would much prefer they can modify the field more easily using it's description.  Unfortunately, I can't figure out where Object's Field's Descriptions are stored.   Apparently not as a property of the Field object itself?

Does anyone know where I can find the Description property of a custom Field?

THANKS IN ADVANCE!

PS - You're probably thinking that there are other ways to do some of this, but I've built this little framework in such a way where I can use either Salesforce or a SQL database to describe these dynamic forms and collect data, so there's a little bit of abstraction going on that might seem a little unnecessary on the surface.

Despite the fact that we have access to the Enterprise WSDL, I've decided to use the Partner WSDL for a new project of mine. 

Basically what I've built is a dynamic form that uses an Object's Fields to populate a form on our webserver with the appropriate controls at runtime, collects the values and submits them back into SF.  I've got everything worked out the way I like: field type interpretation, field creation, list population, and even got field validation working... except that I can't think of a good way for my Salesforce Admins to indicate that a field should be required.

Take our Survey object, for example.  If they add a custom field to Surveys and make it required, then when a salesperson creates a new Survey object INSIDE Salesforce, they must supply a value.  I'm just looking for a way to indicate that it needs to be validated at the end-user.  Right now I'm using the Field's name to determine if the Field should be required by prepending "SFF_" to indicate the Field should be on the form, and not just in SF, and "VAL_" to indicate that the Field should be required. 

I'd really like to use each Field's Description property for keywords, like "Required" and "ShowOnForm" instead.  I don't like the idea of forcing a naming convention on custom Fields, and would much prefer they can modify the field more easily using it's description.  Unfortunately, I can't figure out where Object's Field's Descriptions are stored.   Apparently not as a property of the Field object itself?

Does anyone know where I can find the Description property of a custom Field?

THANKS IN ADVANCE!

PS - You're probably thinking that there are other ways to do some of this, but I've built this little framework in such a way where I can use either Salesforce or a SQL database to describe these dynamic forms and collect data, so there's a little bit of abstraction going on that might seem a little unnecessary on the surface.

Has anyone else noticed extremely high API usage with the Google AdWords app installed?  For some reason we're seeing 1500 API calls per day... which seems ridiculously high.

Maybe I have something set up improperly?

Message Edited by DDean on 09-25-2007 03:17 PM

My apologies for the repost, but nobody seemed to have anything to say in "General Development"....


Despite the fact that we have access to the Enterprise WSDL, I've decided to use the Partner WSDL for a new project of mine. 

Basically what I've built is a dynamic form that uses an Object's Fields to populate a form on our webserver with the appropriate controls at runtime, collects the values and submits them back into SF.  I've got everything worked out the way I like: field type interpretation, field creation, list population, and even got field validation working... except that I can't think of a good way for my Salesforce Admins to indicate that a field should be required.

Take our Survey object, for example.  If they add a custom field to Surveys and make it required, then when a salesperson creates a new Survey object INSIDE Salesforce, they must supply a value.  I'm just looking for a way to indicate that it needs to be validated at the end-user.  Right now I'm using the Field's name to determine if the Field should be required by prepending "SFF_" to indicate the Field should be on the form, and not just in SF, and "VAL_" to indicate that the Field should be required. 

I'd really like to use each Field's Description property for keywords, like "Required" and "ShowOnForm" instead.  I don't like the idea of forcing a naming convention on custom Fields, and would much prefer they can modify the field more easily using it's description.  Unfortunately, I can't figure out where Object's Field's Descriptions are stored.   Apparently not as a property of the Field object itself?

Does anyone know where I can find the Description property of a custom Field?

THANKS IN ADVANCE!

PS - You're probably thinking that there are other ways to do some of this, but I've built this little framework in such a way where I can use either Salesforce or a SQL database to describe these dynamic forms and collect data, so there's a little bit of abstraction going on that might seem a little unnecessary on the surface.