views:

85

answers:

2

Hi All,

I'm building an web application to manage instructions based on different parameters (eg. JobCode, State, Customer, Product etc..). I have allocated some 20 filler fields for each of such parameters. The display names of the fields may differ from One Project to another. (multiple implementation).

Some project may not use all the 20 fields but only say 5-6 fields...

Now, one of my colleague is suggesting me to customise the stored procedure to return and accept the fields with column names required by the project, and let the SP do the lookup with actual column names. He also suggests to build controls dynamically.

I thought of providing static controls to all the 20 fields and just populate the labels with the necessary field names and interact with SP using field names "Filler1", "Filler2". This also means we need to make the non-required control invisible...

As more experienced users... Can you enumerate the pros and cons in both...

Thanks

A: 

Its never good practice to use a set number of fields as you are describing (its better to build it dynamically - but make sure you write efficient code). By creating a set number of controls, you are limiting yourself, and creating a big maintenance problem. You may not see it now, but later, what happens if the number of controls changes?

Your colleague's suggestion would work. At least you'll have the ability to change the number of controls at any time without recompiling your code.

Gabriel McAdams
But... Accessing the DB just to recreate the complete set of controls, so that they can be visible on postback... Dont you think that adds a great overhead...
The King
Can you point me to some resource which tells me efficient ways to handle dynamic controls...
The King
Yes. There is some overhead there. You can cache the results of the query (its unlikely to change very often).
Gabriel McAdams
As far as some reading on dynamically adding controls, look at this link:http://msdn.microsoft.com/en-us/library/kyt0fzt1.aspx
Gabriel McAdams
A: 

For the end user it is going to be quite hard to understand the interface if the fields that are not applicable for a particular case are still visible.

So I would indeed advise not to generate any fields you don't need, or at the very least hide them in case they are not needed.

As for where to put the logic...well it does make sense to pull the data that determines what fields should be shown when from the database. But I would recommend against putting all the logic that actually renders the page inside a stored procedure. Rather, you would use the SP to fetch the data, and use your language (PHP, C#/ASP.NET, Java Servlet, what haveyou) to actually process the data and render the page.

htht.

Roland Bouman
This is what I'm going to try... I'm sure I will have some challenges here...
The King