Sharepoint html element naming conventions, by Sharepoint Controls - sharepoint

A few times I've attempted to customize a SP2007 page using css, html, or javascript in Sharepoint Designer; however, in Sharepoint Designer I am not able to get direct access to the desired elements since they are generated by a Sharepoint Control (such as a web part or dataview) and appear only AFTER the page is rendered in the browser. I use use IE's F12 to tracked the element I wish to change. Then I can see an identifer such as name or id I can use in my javascript or css.
Example 1: SP2007 generates "name=ctl00$PlaceHolderMain$g_ba9196a9_2842_4607_b048_9a443cb4def5$ff2_1$ctl00$ctl00$BooleanField" for an input text box. I use that name to manipulate the text box as I desire.
Example 2: SP2007 generates "id=zz6_menu" for the "Welcome" text which I use to get the users full name.
So far this has worked out fine. Am I tempting fate?
Can someone refer me to a reference that discusses how these names and other Sharepoint Control element identifiers are generated?
Are they stable? Can I count on them to be the same provided the application I develop with my version of SP isn't updated to a later version of SP? And even if that case I'm thinking I can simply update to the identifiers created by the newer version of SP.
Is this a good practice? Any other comments?
All responses are welcomed.
Thanks.

SharePoint is based on ASP.NET and that's why the Ids are automatically genereated.
cf this article.
You should not use them to identify elements on css or js.
Do not write code that references controls using the value of the
generated UniqueID property. You can treat the UniqueID property as a
handle (for example, by passing it to a process), but you should not
rely on it having a specific structure.
In my opinion, the best way is to rely on the css classes because they are not automatically generated and should not change a lot.
Anyway, if you upgrade to SP2010 or 2013, lot of your modifications won't work anymore because the structure and css changed...

Related

Kentico 10 - Web Part content change via database

i was trying to understand in the Kentico's database model how can i change the web parts content using a database script.
So, basically i have a website based on Kentico with several articles, and internal hyperlinks in its content. But the problem is that the format of those hyperlinks are actually invalid. And i was looking for a way to build a script and do a bulk-update in order to replace some characters and update those hyperlinks to the valid format.
Any idea how can i build the query to get the content of all web parts used in all published pages.
Thank you
It depends on your web parts and how the content is rendered. There are different ways that web parts render their content:
The web part layout is used for markup
The ASCX file for the web part is used for markup
The web part makes use of a repeater that uses a Transformation to render the markup- The markup is generated in code behind
The last one can be tricky to change depending on the web part and whether you have access to all the code behind, but the others you can change either in code in your solution or within the Administration area itself.
Doing this in SQL would probably require a combination of T-SQL XML support and regular expressions to find what you're looking for. you effectively need to look in the CMS_WebPart and CMS_WebPartLayout tables to find what you're looking for.
However, reading your query, I'm not 100% sure you're talking about web parts, (my apologies if you are) as you talk about links in the article content itself. If these are set using the Editable text web part, then you need to look in the CMS_Document table at the DocumentContent field to find the links to replace. But you then need to look at how to correctly format those links going forward so that you do not need to repeat this process later.
Note:
You need to be really careful when doing this in SQL to make sure that you don't create invalid XML. Things go bad when you do that.
This won't flush your cache, so you'll need to clear your cache manually afterwards.
If you're using out-of-the-box web parts, you should really make a copy of them and use the copy if you're going to modify, this way, you're less likely to have pain in future upgrades.
Typically "content" is not set in a webpart. Webparts are configured to retrieve content from page types. There is an exception to this with specific webparts like Editable Text, Static Text, Static HTML, etc.
The configuration of a webpart is stored at the template level in the cms_pagetemplate table. The configuration for ALL webparts on that page template are stored in the PageTemplateWebParts field. So you'd have to parse through the XML and get the proper webpart and then perform an update on that field. You maybe able to do a regex to find that content and replace it as well.
Not ideal to do this via SQL simply because of version history and it can cause a lot of problems later on. I'd suggest finding out which API calls you can make to perform these updates and write a small program for it.

Kentcio v9 Smart Search Dialog with Results search mode localization

How can i localize the drop down option for the search mode? I did some digging and was able to adjust the localization for the search form labels but i'm at loss here.
The CMS Module SearchDialog.ascx call the drop down list here, but i can't see where the values come from.
<cms:CMSDropDownList runat="server" ID="drpSearchMode" CssClass="DropDownField" />
Go to the localization App and create resource strings for
"srch.dialog.AllWords"
"srch.dialog.AnyWord"
"srch.dialog.anywordorsynonyms"
"srch.dialog.ExactPhrase"
Believe those are the 4 you need.
I couldn't find official documentation that helps much with this, though there have been articles in the past on older versions. However, one trick I've used previously is to look in the ~/CMSResources/cms.resx file, find the localized string there, and add a new one with the same key to the Localization module in Kentico. That is, add a new resource string in Kentico with the same key (the naming will be different depending on your version of Kentico).
Here's the docs discussing setting up a multilingual interface: https://docs.kentico.com/display/K9/Setting+up+a+multilingual+user+interface
And here's a screenshot of the resx file:
So in your case I'd create a new resource string within Kentico called "srch.dialog.allwords" as an example and that should overwrite and take priority over whatever is in the .resx file, plus you can manage it via the Kentico admin. There may be a quicker or more reliable way to view the list of default resource strings but in my recent installs of Kentico, the list is hidden from the admin interface.
Alternatively, of course, you could manage the resource strings via various .resx files as in the documentation, but I try to manage as much of these pieces via Kentico as possible for convenience.

How to integrate a "shortcode" feature in Sharepoint wikis

I would like to "customize" my sharepoint wiki by doing something very simple.
I would like to be able to run a regex on wiki pages looking for [math] and [\math] tags, then take the expression written in the middle (assume this value is stored in a variable x) and replace the whole block by
"<img src='http://latex.codecogs.com/gif.latex?" + x +"'/>"
So for example, the shortcode [math]a^2+b^2=c^2[\math] should end up being displayed as an image as follows (thanks to this online tool):
I have never developed anything in sharepoint, and I've been using it for a week.
Can anybody tell me how I should proceed to add such a feature (if it's possible)?
You can use existing solution like ShortPoint.
Sure - this is simmply done via two methods - 1) You could modify the page directly using SharePoint designer - fly in the code where you want it, 2) The better way - add your code to text file, upload the text file to a document library then use the Content Editor web part, drop it on the page, point it (through the properties) to the text file.
Note: The Content Editor part will allow you to modify the background HTML/Script, however, it has a nasty habit of overriding your code and I've had it actually duplicate itself (adding repeat scripts). Using the Text file eliminiates that issue.
If i understand you correctly, I don't think that the content editor web part is the solution you are looking for. I believe you are wanting to implement a shortcodes solution such as that found in WordPress, correct? In that case, the issue becomes a bit more complex. To really get any kind of custom code that would execute at the necessary stages, you would need a custom solution either implementing additional functionality in the existing rich text editor, or roll your own custom rich text editor.
At that point, you would have complete control over how the content is parsed and interpreted, so you could have both server-side and client side processing. You could make use of templating engines like mustache or handlebars.
To do this, you would need to write your own Custom field type, inherit from SPFieldMultiLineText, override the property FieldRenderingControl, and return your custom control. That way you have the option of implementing it in several different places (custom pege fields in a page layout, custom webparts, custom lists, etc.) and you still get the benefits you want from the out-of-the-box control.

Sharepoint 2007 with MS Office 2007 footers

We had a need for a document management solution and were hoping SharePoint 2007 would satisfy our needs. We felt our needs were relatively simple. We needed to manage versioning, have searching capabilities, and having an approval workflow.
SharePoint handled these three aspects great out of the box.
However, we also require that the footer on the Office 2007 (Word, Excel, and PowerPoint) documents reflect the document version, last person to modify, and last modification date. These things can be done with office automation, but we have yet to find a complete solution.
We first tried to do it on the checking-in and checked-in events and followed this path for a while, however, the complication we ran into was after we made the changes to the document we had to no way of preventing the save from updating the version number. This resulted in something similar to this:
Document checked-in – the document version should be v0.1 however it is v0.2 because we save the document after the footer is replaced. If we look in the document history we there are 2 separate versions v0.1 does not have the footer v0.2 has the footer but it says v0.1 as that is the version the document was when it was replaced.
This is an unacceptable solution for us as we want the process to be completely handled on the user side so they would have full control to revert back to a version where the footer would be incorrect and not contain the correct data. When we attempted to create a custom approval/check-in workflow we found that the same problem was present. The footer is necessary so that hard-copies can be traced back to their electronic counterpart.
Another solution that was proposed to us was to build plugins for office that would handle the replacement of the footer. This is inadequate for our needs as it requires a client side deployment of our plugins which is undesirable by our clients. What we are looking for is a clean solution to this problem.
Here is a blog post which seem to be exactly the solution of your problem.
Basically they create a custom field in the document library and use event receivers to keep the current version of the document in this field.
The "trick" is that on the client side this custom field shows up as a property of the document the value of which you can easily embed into the document's contents.
I'm not sure why changing the field won't increase the version of the document, but I guess it is because you're only changing metadata, not the actual document.
They do use a little VBA script which runs on the client side, but it doesn't require any client side deployment as it is downloaded with the document. However I'm not sure if any security settings changes on the client side may be needed to allow the script to run.
Does this information need to be in the footer? A lot of the information is available within the Office 2007 application. If you click on the round button in the upper left, and select "Server", you can view the version history, a lot of the other properties are available by clicking the round button and opening the "Prepare" menu, and selecting Properties.
If this information must be displayed in the document footer I would investigate creating a custom Information Management Policy. This may be a good place to start.

SharePoint SPContext.List in a custom application page

I have a custom SharePoint application page deployed to the _layouts folder. It's a custom "new form" for a custom content type. During my interactions with this page, I will need to add an item to my list. When the page first loads, I can use SPContext.Current.List to see the current list I'm working with. But after I fill in my form and the form posts back onto itself and IsPostBack is true, then SPContext.Current.List is null so I can't find the list that I need to add my stuff into.
Is this expected?
How should I retain some info about my context list across the postback? Should I just populate some asp:hidden control with my list's guid and then just pull it back from that on the postback? That seems safe, I guess.
FWIW, this is the MOSS 2007 Standard version.
Generally speaking I try and copy whatever approach the product group has taken when looking to add functionality of my own. In this case they add their own edit/view/add pages via the list definition itself.
I built a solution that also needed its own custom "New" form, not open source unfortunately, though if you are interested you can download it, its called "Tagged Links" (Social Bookmarking for SharePoint) and you can find some links on my blog.
To give you a few hints and tips, the following should set you off in the right direction:
Created a new list definition.
Created a new Content Type In the content type you can define your own "FormTemplates" that references a Rendering Template which determine what gets displayed in the "Middle" bit of those forms.
Copied the standard Rendering Template, but then made the changes to it that I
needed.
Wrapped it all up in a solution, and deployed.
My Rendering Template actually included an overridden "Save" Button where I did a lot of the extra work I needed to do during the save.
Anyway, it is a little too much work in my opinion but, I think, it most closely matches the standard approach taken by the product developers. Let me know if you need more detail and I will see if I can put together a step-by-step blog post, but hopefully this gets you off on the right direction.
I would be surprised if you could do something in a _Layouts file that you can't do in a forms template. You have pretty much the same technologies at your disposal.
Looking at the way SharePoint works with ListItems and Layouts pages (for example "Manage Permissions" on a list item), I can see that they pass some variables in via querystrings:
?obj={76113B3A-FABA-4389-BC85-4BB2CC5AB423},6,LISTITEM&List={76113B3A-FABA-4389-BC85-4BB2CC5AB423}
Perhaps they grab the context back each time programmatically using these values.
I'm not using a custom "new form", so this might not apply. I added an event receiver to my custom content type and then do my custom code in the ItemAdded or ItemAdding events. This code fires when the event is added to a list. You can use the event receiver properties to get to the parent List, Web, and Site.
I'd like to think my issue is "special" here, since I am using a custom form. I chose to use a custom form rather than a custom FormTemplate simply because I'm doing a lot of stuff that's not very SharePoint list-like (making ajax calls to get info from a third-party app then generating some dynamic form elements based on that ajax result, then subsequent processing of that data on postback). I thought it'd be a nightmare to try this within the usual custom rendering template mechanism.
I also don't think I can supply the custom form declarations in the list definition itself, because I have multiple content types associated with this list, and each content type has its own custom form (the other type is thankfully much simpler).
Actually, my simple way of keeping the list guid in my hidden field was a very low impact way to address this specific problem. My main concern is that I'm not sure why the SPContext just loses all its usefulness when I postback here, which makes me think I'm doing something wrong.

Resources