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)
Posts
_1099.jpg)
_525_526.gif)
6 comments:
That's great! Do you have any more details about what you mean buy Web part + Content type? I would love to hear more about this as I am struggling with it right now. Is this something I can accomplish just in SPD or would it have to be done in VS2008? I appreciate your comments, I was actually starting to think along the very same lines this morning...as the prospect of writing custom fields is super daunting to me!
Hey,
you know what a content type is right??
you know that a content type is an Items' meta-data (be it list item/document item/picture Item, etc)
For a List/Library:
content type =
Doc Template (for doc libraries only, if any)
+ Site/ContentType columns
+ workflow (if any)
+ Item Display page (if any)
+ Item Edit page (if any)
+ custom rule/policy (if any)
+ etc (NOTE: etc is a way of saying I dont know more than this...:))
Does this ring any bell???
Yes, i guess. Tell your content type to have a custom edit page and instead of default ListFormWebPart you can have your own custom webpart that gets data in any which ways possible
I've learned some good stuff here. I do appreciate your efforts to create one of these magnificent informative websites.
Congratulations, your blog is appealing and informative. Going through your Information, I found quite a few new ideas to implement
Post a Comment