I'm trying to create a web part that will enable users to edit items without ever leaving the AllItems.aspx page. The web part should have a similar functionality like the EditForm.aspx page.
I've created a simple web part with a ConnectionConsumer("Row") that successfully shows the selected ListItem but I'm trying to figure out how to programmatically create a form depending on the list with a save/update functionality.
I would appreciate a simple solution or a nudge in the right direction.
Thanks
What you are trying to do is not possible out of the box but it should be possible to use the SPGridView and the ListFieldIterator decorated with AJAX to get the things working as you wanted.
You can refer to the below items and build a control that does what you want.
Using SPGridView in WebParts
Articles on ListFieldIterator
ListFieldIterator
Once you build it you can try sharing the code as this is a pretty common thing everyone wants and I didn't find a good implementation of this kind so far.
This definitely sounds like a nice feature. I would love it if you could put the solution on codeplex, you're choice of course.
I've had a sneak peak on SharePoint 2010 and AJAX enabled editing is found on lots of places so I wouldn't be surprised if some kind of feature like the one you are working on will be included.
Good luck!
Related
I am stuck with a problem. I am having tool part where I get all the Lists present in the Site.
I have other web part which should get the selected List in the tool part.
I see that the web part is loaded first then the tool part. so the web part is unable to the List selected in the tool part.
Please note that the text box is in a User Control.
Please help me.
I have looked at your code and found the following:
First things first. You need to move AWAY from using ToolParts and the SharePoint native webpart. they are deprecated and are a remnant from SPS2003. In MOSS / WSS 3.0 you can and should use the ASP.NET WebPart.
Secondly, I think you are mixing things up. The ToolPartGetLists is not a toolpart, it is a webpart, that in itself loads the CustomToolPart, which in turn allows you to select a list.
This toolpart is only shown when you edit the shared webpart in the UI. The list you select is then persisted to the SelectedList property of the webpart using the toolpart.
The connected webpart then tries to read the SelectedList property I guess.
Like I said, I could go and try to fix the code for you, but it is not the way to go, you really (REALLY) need to switch to ASP.NET WebPart based webparts. The native sharepoint one WILL be fased out in the (near) future.
Here you can find an example, with code! (scroll to bottom for download link). As a bonus, it uses the built in sharepoint listpicker
I don't know of any way you could control the load order of elements (web parts) on the same page.
Sounds more like you want to have your second web part (the display of the lists) have a "default" when the page loads--which could be empty. Then it would be changed to the selected list only when the user clicked a new selection in the other web part (the list of lists).
I'm very new to SharePoint, so apologies if this sounds a little basic.
I want to create a List in SharePoint that is just purely URL links, but then make it available to every site collection that we will create.
Once this list is created, I need it to display in a webpart (like that standard 'links' webpart). I guess I will need to create a Feature, so that it can be activated at Site Collection level.
Any ideas how this can be achieved please?
Thank you all kindly in advance, Ash ;-)
I did something similar - but I created it as a Web Part with it's own security trimming. I covered some of the basics here:
http://www.codersbarn.com/?tag=/webpart
What you would need is a view on your list of links (that view will display the content of your list). Have a look here for more details on List View Web Parts. Once you figure out how to create it and what you want in your view, coding it shouldn't be too hard (You can either use SharePoint Designer on your site to create the view you want and then reverse engineer it into code using SPSource or you can create it from the schema.xml of you list).
You should note however, that with WSS you will not be able to view the content of a list on another site collection (i.e. you can only views of your list on the site collection where the list was created). Cross-site list views are a lot more complex to implement (you can buy components that do it though). I'm not sure how MOSS deals with cross-site list views but if you use MOSS, you should make sure that you can do it before you start developing your view.
EDIT : I would definitely go with what IrishChieftain suggested if your list isn't too complicated and has a structure that won't change much. Dealing with cross-site list views is a pain.
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!!
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
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.
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.
I have a task that I need to perform for a friend as a favor, to modify some forms on a MOSS/Sharepoint site to add some javascript to each form for some SEO tracking purposes.
I've had a little bit of exposure to Sharepoint, but it is mostly by using the Sharepoint Designer 2007 tool.
I am able to navigate to the site, and I can see the content in Sharepoint Designer. However, I am not able to see the forms, and I'm a bit stuck.
Here is an example of a form that I need to modify:
http://www.MY_SITE_GOES_HERE.com/forms/covg_order.aspx
I've read a little online, but I'm stuck. I don't know if these are infopath forms or what. I just need to modify the forms.
Is there a simple answer to this problem? Or a good resource to get up to speed quickly for this task?
I'm not a sharepoint expert, so thank you in advance for answering a simple question.
While hardly the simplest approach, but since this is a developer site, I would recommend creating a DelegateControl to add to your site. Using DelegateControls has several benefits, for example:
the ability to selectively activate and deactivate the controls through features
no need to modify any out-of-the-box files which would break supportability
ability to output different content on a page-by-page basis
You can opt to use one of the DelegateControls of the default master pages if you need to deploy to an existing site based on one of the default site definitions. The AdditionalPageHead is a favorite among developers, as it allows multiple overrides to be active at the same time.
If you want to create your own master pages you can add DelegateControls as you like.
If you want to learn more about DelegateControls you can check out the first issue of Understanding SharePoint Journal (Disclaimer: I wrote that issue). Also, check out the MSDN article on How to customize a Delegate Control.
.b
you can also check PowerForms which is a silverlight webpart that fully customizes sharepoint forms. You can add business logic in forms using custom assemblies and a lot other advanced tasks. Give it a try, i think it will solve a lot of problems.
http://www.bpc.gr/powerforms
You have a couple of options here:
If you need to add a unique code, like Google analytics you should probably deploy your code to the master page.
In case you need to customize forms for lists you will have to do it with SharePoint designer. In that case you will find EditItem.aspx and NewItem.aspx with SharePoint Designer pages or any other custom page. Open SPD, locate your list, expand it, look for Forms subfolder and you will find all the forms there.
Microsoft Office SharePoint Designer is now free, as of 1-Apr-2009. It's a good tool, not only for modifying individual pages, but for entire sites.
I've built a web part for Sharepoint that retrieves data from an external service. I'd like to display the items in a way that's UI-compatible with Sharepoint (fits in with its surroundings.)
I'm aware of the "DataFormWebPart" but was unable to get one working properly. It requires a valid DataSource and I was unable to build one from the results of a web service call... Part of the problem is that my web service wrappers don't expose the XML return info, rather I have a bunch of deserialized objects. There doesn't seem to be an easy way to turn actual objects into a datasource, or populate a "generic" datasource from object data.
I could use an SPGridView to get the same UI, but the grid control doesn't have much in the way of smarts -and- it forces every field into its own column. I'd prefer to render each list item as a single cell with complex rendering (for instance the way that StackOverflow shows its lists of questions.) I'd also like to get as much of the Sharepoint-standard UI as possible, such as the sorting, filtering, and paging controls.
So, first: Has anyone here written a Sharepoint control that does this, and if so do you have sample code to share? If not: am I overlooking some useful control, whether MS-supplied or available in an external library?
Thanks!
Steve
Sharepoint: Best way to display lists
of non-Sharepoint content with
“compatible” UI?
Take a look at the built in sharepoint web controls:
Microsoft.SharePoint.WebControls Namespace
It contains all the controls used in sharepoint. I'd tell you more, but the documentation is very thorough.
Problem with SharePoint is that there are a bunch of different ways to do this. If your data is not changing too often and is not overly large it may be worth considering entering it into a list for display.
If you have the Enterprise licence it may be worth getting your data into the BDC and using it there.
you may have to convert the objects into xml or use the serialised objects with the XML webpart for display. This still has the issue of custom rendering using XSLT.
Here's a great article that explains how to configure BDC connections to web services using the BDC Definition Editor:
Creating a Web Service Connection by Using the Business Data Catalog Definition Editor
http://msdn.microsoft.com/en-us/library/bb737887.aspx
The best way to do this IMO is to make a Web Part. As a Web Part the UI will be automatically rendered to be the same as the theme the site is using (unless you override it) and it will be able to be placed anywhere by anyone with admin privileges.
Tutorial on making a Web Part
Tutorial on packaging and deploying a Web Part
Example Web Part Source Code
You could create a custom web part and use an SPGridView. You say you don't like it, because it forces every field into its own column, but that's not true. You can create a template (ITemplate) for every column and fully customize what's shown inside it, just like you would using a normal ASP.Net GridView. Using this approach I've added the little "New" images right next to a list item's Title, just like SharePoint does itself.