Last post Mar 28, 2011 12:11 AM by abhisheks
Mar 26, 2011 11:08 AM|sambilbrey|LINK
I am not sure if this is the correct place to post this question. If not, please forgive and point me.
If it helps, every element they build on that page (textbox, textarea, checkbox, select, hidden) ends up in our db in a attribute form that simply stores the input as key/value pairs with the element id as the key, and the value as the value.
I am thinking there must be a beter way to do this.
Maybe develop web services that each form submits to and leave the form building and scripting up to standard tools. But to do this we would need to be able to make custom controls (or custom properties in common controls) available. For example, we have
dropdown lists that use sql to get the keys and values for the options. A more elaborate example, we have user lookup dialogs, region lookup dialogs, site lookup dialogs, etc.
At this point I am looking for suggestions regarding architectures.
Mar 28, 2011 12:11 AM|abhisheks|LINK
From your post, are those the correct assertions
1) The development environment is basicaly used for submitting request for creation of site with dynamic controls.
2) The metadata for creation of site and controls are entered by users for developer to be able to create the site.
If those two are valid assertions, it just has all the ingredients for a smelly architecture. You should probably be better off looking for alternatives to move away from this archtecture.
I might sound cynical, but you might have valid reasons supporting the architecture that you probably inherited. I would be interested to hear more on the reason for using the architecture that you mentioned and what kind of benefits users get from this
architecture? Also, what is it that you are trying to achieve?