Suddenly, i see people so enthusiastic about "custom fields" that they want almost all kind of data retrieval through custom fields only!!..(You can read the comments on my custom fields post.)
From parent-child cascading drop-downs, to grandchild drop-down to why now even great great grand child drop-down??!!!. I am seeing people asking me to give solutions wherein i am sure they will end-up making half a dozen custom fields on one Item Edit page itself!!!
Some wants Custom data from a SQL store. Others from custom List lying in differnt Site Collection. Some even want data from Partners date in Oracle apps!! I Know, the idea of custom fields initially marvelled the new comers (which includes me too) and was even true in a specific real life case that i pointed out in my post. But custom fields are far more generic solutions that scopes to entire server deployment and I purely feel is not Intended to be used if there is only a particular List or library that demands this special type of data retrieval
My question here is, where have BDC gone?? WebParts are also brilliant solutions to many problems. Only that these guys should be used at right places.
Let say, so if you have a special data retrieval requirement wherein on first drop-down select, you want values in second drop down and on its select, in third and finally on its select. you want a group of 5 textboxes to be pre-populated. I feel, its not justice to WSS 3.0/MOSS if we are to conclude that this should be done through custom fields and thus demoralizing clients by quoting ,let say, 120$/Hr * 120 hrs = 1440$ of development time for nothing. Why the Hell they bought this ECM package that costed them lots of $s already.
Dont you think, webpart here would still be a better and more maintainable solution. The perfect recipe for such scenario would be "Custom Content Type + webpart on edit page"
This webpart can then have custom Oracle connection or SQL connection code to get that data in the wildest ways precievable. Or even, a better approach here would be using BDC object model to get data from thrid party stores or WSS object model to get it from other List of lists in different Site Collections.
Custom fields are good, but not at all a solution if your custom data retrieval logic restricts to only a particular List or Library. So guys, please dont end up making a latin american or indian family of custom field controls, every where!!, every time!!
(opinions expressed here are purely from my experience and have got nothing to do with microsoft SharePoint's best practices and guidelines. Please contact Andrew or Rob or other MVPs if there is a difference of opinion here)
From parent-child cascading drop-downs, to grandchild drop-down to why now even great great grand child drop-down??!!!. I am seeing people asking me to give solutions wherein i am sure they will end-up making half a dozen custom fields on one Item Edit page itself!!!
Some wants Custom data from a SQL store. Others from custom List lying in differnt Site Collection. Some even want data from Partners date in Oracle apps!! I Know, the idea of custom fields initially marvelled the new comers (which includes me too) and was even true in a specific real life case that i pointed out in my post. But custom fields are far more generic solutions that scopes to entire server deployment and I purely feel is not Intended to be used if there is only a particular List or library that demands this special type of data retrieval
My question here is, where have BDC gone?? WebParts are also brilliant solutions to many problems. Only that these guys should be used at right places.
Let say, so if you have a special data retrieval requirement wherein on first drop-down select, you want values in second drop down and on its select, in third and finally on its select. you want a group of 5 textboxes to be pre-populated. I feel, its not justice to WSS 3.0/MOSS if we are to conclude that this should be done through custom fields and thus demoralizing clients by quoting ,let say, 120$/Hr * 120 hrs = 1440$ of development time for nothing. Why the Hell they bought this ECM package that costed them lots of $s already.
Dont you think, webpart here would still be a better and more maintainable solution. The perfect recipe for such scenario would be "Custom Content Type + webpart on edit page"
This webpart can then have custom Oracle connection or SQL connection code to get that data in the wildest ways precievable. Or even, a better approach here would be using BDC object model to get data from thrid party stores or WSS object model to get it from other List of lists in different Site Collections.
Custom fields are good, but not at all a solution if your custom data retrieval logic restricts to only a particular List or Library. So guys, please dont end up making a latin american or indian family of custom field controls, every where!!, every time!!
(opinions expressed here are purely from my experience and have got nothing to do with microsoft SharePoint's best practices and guidelines. Please contact Andrew or Rob or other MVPs if there is a difference of opinion here)
. I Know you must be feeling sorry for me.. even i am. This is not the solution..or is it?? We can very well have webparts in the Gallery with same Title.. who'll stop your client from doing it.
.
Posts
_1099.jpg)
_525_526.gif)
