A Fake Edit Control Block (ECB)
Yes, it's fake! But works just the same!
So you can set the Action Name and these properties. These settings for this demo are not really important because I needed something this does not provide. Here, you can only set a url and though you can pass a parameter such as ID, you can not really set a good popup dialog because it treats it like a new action no matter if it is the same page or set to new window. It's okay because we are going to make this do what we want!
So once you save this, you will then be able to move on to editing the (BDL) webpart to make it do the cool stuff!
So, if you have not added this webpart, you can add it to a page. Once you are in edit mode, you can edit the web part and select the external content type. The real neat thing here is that you can edit the view as show to the left. This will allow you to select the fields just like a regular list view.
So, notice that I have set in this case the "RequirementName" as the first field, and more importantly, that I set it as the "Title" field. This is denoted by the red circle. This is the piece that brings the coolness back because now, it will use this field to attach the custom action we defined earlier!
And there it is, you see that if you hover directly over the item, it will draw an icon similar to a listview. It is not exactly the same, but it functions the same way in that it will now display a dropdown when clicked. When I reached this point, I knew I just had to have something to work with so I started following this rabbit down the hole to get to what I needed. The dropdown is shown next.
So, it does indeed draw a dropdown with our defined custom action. If you stopped here, it would do exactly what was defined in the action, and that may be enough. However, it is just not quite evil enough for me!
So I dug into the dev tools in IE and Chrome to see how this box gets drawn. It took me a few minutes to notice that the first piece is actually done in the XSL for the webpart! And, this webpart gives us the ability to change it! That was the first change I needed to make. It is actually not too much to change here. Also, for FYI purposes, some of my screenshots are from different sites so there may be slight differences in field names that you see!
So here is the first section of the XSL. Basically I added a new parameter (curid) for the ID field. For me its just easier to do it this way. I added this to 2 places in the code as pointed out below:
So there is the first part! Basically I added the xsl-with-param for the curid to both calls to the "OpenActionsMenu" template.
This causes the system to pass the ID and not the BCDIdentity to the function because the ID field is what the stored procedures use and it is the primary key in the database. So then I needed to figure out what was next. This next piece of XSL is the updated "OpenActionsMenu" template.
So this is the last part of the XSL. Notice that I used the $curid parameter instead of id. As stated, this is necessary for this to work. So now that the XSL is updated, I had to then find the next step.
This webpart uses a file called wssactionmenu.js from the "HIVE" to draw the action menu dropdown. The basic functions of the file are to use an ajax like request to poll the external content type to find out what actions are setup and then draw these actions on the page inside the dropdown box. And due to how the file gets loaded, all we have to do, is override the functions in a different file and add this to our page!
It looks like this:
So that is the magic! The first thing that I do in this case is use a function from the AWESOME SPServices library found here. The "GetGroupCollectionFromUser" function will test if the current user is a member of the passed in group. If so, the "isplanner" variable is set to true. This is used to display the "Edit" and "Delete" options in the dropdown.
If you go back and look at the XSL, you will see that we set this up to call a function called "showActionMenu". I took this code from the wssactionmenu.js file and modified it to do what I wanted. So this function just in turn calls the "displayActionMenu" and passes in the variables from the other function. The key variable for us here is the itemID variable as this is what we passed from the modified XSL code as the id of the item.
This is the file that loads the CustomActionMenu.js file and reacts to the menu items when clicked. Basically the function will just open a dialog to the View or Edit forms that I have customized, or if the user selects Delete, it will use the client object model to delete the item. There is a neat little jQuery snippet here on line 44 that after the item is deleted, will basically click the filter link to refresh the items searched showing the user that the item was deleted.
And of course, this is what the dropdown looks like:
So there it is! A user friendly "FAKE" Edit Control Block on a Business Data List webpart. It is security trimmed to a point and can be customized to add any other functionality that you would want.
Until Next Time!!