Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I am trying to create a list with following structure in sharepoint 2010. enter image description here

Is it possible to create like this? You may say that enter values by leaving title as blank. But here Title Filed should be required field. If any one help me to do in programatically(C# code) I would feel great. As per the suggestion of PirateEric final out come like this. enter image description here

But no possibility as per my requirement!!

share|improve this question
    
not sure to understand. You want to able to type in a grid the value, leaving blank when equals to parent? Or do you want to produce a visual output like this? –  Steve B Jul 31 '12 at 15:20
3  
Tomato is a fruit FYI –  Steve B Jul 31 '12 at 15:21
    
@SteveB what a observation, great. I am just asking as an example. Thanks for your info.. :) –  Mihir Aug 1 '12 at 3:30
    
@SteveB I want to make title column as a required column. When we leave as blank for second entry then how we can insert the value?? –  Mihir Aug 1 '12 at 3:31
add comment

4 Answers

up vote 2 down vote accepted

3 columns, Title, Products, and Price.

Create a list View, with the columns Product and Price and group it by Title with it expanded by default. That will get you close enough to that.

share|improve this answer
    
Hi PirateEric... please see my updated post –  Mihir Aug 1 '12 at 4:19
add comment

I'd create a second list called something like "Product Groups", containing items for each value like Vegetable and Fruits in the Title column (which you can rename if you want to). Then in the Products list, I'd have three columns:

  • Title - Containing your values [Potato, Tomato, ...] - You can rename this Title column to Product if you want.
  • Product Group - A Lookup column to the Product Groups list
  • Price - The Price, as above

For your views, you could group by Product Group, etc.

And yes, a tomato is a fruit.

share|improve this answer
    
A lookup column for that? A plain choice column would work too. Depending on the number of values, that might be unneeded overhead. –  PirateEric Aug 1 '12 at 2:18
    
I almost alwats use lookups over coices for more flexibility down the line: sympmarc.com/2012/07/23/… I could see a need to add to or edit the Product Groups regularly. Making it a lookup based on list contents means we can apply separate permissions, etc. –  Marc D Anderson Aug 1 '12 at 12:10
add comment

You can achieve the same with creating one more column call CustomTitle. And refer this filed into your view instead of default Title.

Or you can make this title filed optional from the FieldsExplorer tool.

share|improve this answer
add comment

I would definitely go for Marc's approach as well, by using a lookup field for the product category.

Looking at it from a relational point of view, a product category is an entity in itself, so that should be stored in a separate table. The problem with using just the title or only a plain choice field is that it violates at least the first normal form.

You are likely going to run into problems when you don't use a lookup field. Imagine when you want to change the name of a category. In any other approach that would result in having to update multiple entries, because changes are not reflected in other records. Changes made on a looked up value however, immediately show in your products list too.

Plus, using the title field for category has the drawback of constantly having to type your category name when adding a new product, which could easily result in unexpected behaviour when making a typo.

For future expansion, say you want to store additional information about your categories, then at least the lookup-based solution already allows you to do this without any significant changes.

Also, when querying your data, I'd say lookup fields work better too, as you can at least query on an ID instead of a plain string value, one which in this case happens to be the name of the category too. Your mileage may vary here, but the ID-based solution seems a little more robust to me.

Possible minor overhead is easily outweighed by the advantages you're getting by using a lookup field.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.