views:

2326

answers:

5

I'm not sure that there will be a definitive answer to my question, but I'd like to read some discussion from other folks on this... here's some quick background.

I'm creating a request form that will handle adding new equipment to our datacenter. I'm collecting some pretty basic info about the submitter and the equipment to add. Some of the metadata gets pretty complex, but I won't get into that here.

At first I started with a browser enabled InfoPath form, because most of our users aren't licensed for the InfoPath rich client. After much frustration I got things working, but could never get a level of performance that I was happy with. Since then I have been playing around with SharePoint's web services and I have a GREAT form that I've written in HTML (with some jQuery magic) that submits to a SharePoint list.

So now I'm asking myself... why not just use this form? First, I can get rid of InfoPath completely... that also helps us out with licensing since I won't need Enterprise licensing. Second, performance... Third, sure I have to hand code it, but I can, and I enjoy it.

So, InfoPath is out the door.

That leads to where I need some best practice ideas mixed in with new ideas. I've got this form that works great, but I want everything to work within SharePoint. As a test, I just created a new view for my list, removed the web part that shows the list, and plopped in my form. Aside from some CSS issues, everything works and it updates the list lightning quick!

But should it be a custom view? Should it live somewhere else? Should I just edit NewForm.aspx?

I'd love to hear some thoughts on this. Ultimately, my entire solution will be deployed as a Feature, but I'm not sure that's relevant.

Thanks!!

+3  A: 

I would've done it mostly the same way:

  • Create a new form (via SharePoint Designer or a custom ASPX page)
  • Encapsulate the form in a Web Part (you can use the SmartPart Web Part if you're in a hurry)
  • Create as many custom views as you want, it doesn't really interfere with the way you code the form

If you must modify NewForm.aspx, don't delete the default ListForm Webpart since it's used by SharePoint for other things. You're better of just hiding it to avoid future issues.

Hope that helps

amhed
It's been quite some time since I asked this question, and I should have marked an answer - I apologize for the delay. In reviewing all the answers, this one was definitely the most useful.
SeanW
A: 

There's nothing wrong with using a custom form or a completely seperate app to edit SharePoint data. You end up with the same data you would get from using the standard new form, so it can't possibly break anything beyond the modified view.

Setting up a custom newform is probably the most appropriate place for it - easy enough to change the newform url in schema.xml or through designer.

Tom Clarkson
+1  A: 

I think you should create custom form templates for your request SharePoint-List.
See MSDN: Creating Custom Form Templates.

I also recommend reading Understanding SharePoint: List Forms.

A: 

Hi All,

In addition to this scenario, I have a quick question. How do I print this ASPX form information which is stored in SPList as SPListItem in a word format?

Thanks& Regards Khushi

Khushi
A: 

How does the new custom form get mapped to the list?

darrell