All about the Strategy, Design, Customisation, Deployment and Development of SharePoint and its related Technologies

  Administration   All Me!! Baby!!   BDC   Book Review   Business   CKS   Conferences   CQWP   Development   Duffer Moments   Email   Errors   Family   Fixes   General   Groove   How To   How To Code   InfoPath   iPhone   IRM   Longhorn   Lotus Notes   Migration   Mobility   Office System 2007   Personal Projects   Powershell   Records Management   Search Server   Security   SharePoint   Silverlight   SQL   Tech Ed 2008   Testing   Vista   VSTO   WSS   XSL

[27/09/2007] MOSS2007 – Show InfoPath fields within CQWP (Yes you can)
 
Categories: Development, Office System 2007, InfoPath, SharePoint, CQWP, XSL
 

In the last post I had been investigating if it was possible to view the fields that are created by the "Administrator Approved" InfoPath forms. After a little tip from Adri Verlaan from Microsoft, I have been able to get the columns to render. To begin one the main issue was finding the actual field names that are being used. Using CAML you are able to find these but there is another simple way of doing this. The process is quite simple. It involves creating a new style and simply getting the style to render the internal names of the fields. To do this I have created a new style shown below:

Notice that the following lines:

The above lines will simply render the internal names that are actually being presented to the CQWP. When the CQWP renders it should look as below:

What I noticed here was that the field names were actually different to the CAML query names when presented to the CQWP. One of the fields within the CAML code was:

e21843e8_x002d_cd45_x002d_4185_x002d_88a0_x002d_368251a2382c

When it was shown in the CQWP it was actually the following:

e21843e8_x005F_x002d_cd45_x005F_x002d_4185_x005F_x002d_88a0_x005F_x002d_368251a2382c

As you can see they are quite different. Now that we have the real internal names that the CQWP uses I modified the CQWP properties as shown below:

Once these changes have been made the "ItemStyle.xsl" file will also need changing to the following:

Now when we put this all together it renders as shown below (ignore the formatting – it's just a demo).

What we can do to make life easier is to use the "DataColumnRename" property of the CQWP as per a comment from Adri Verlaan from Microsoft to rename the columns to something that makes a little more sense than the long GUID type names. In a further post we will look at this. J

 
6 Comments
 

Comments

Thursday, 27 Sep 2007 08:49 by Tobias Zimmergren
Great. Just great. This on top of your previous post on the subject is really good and perfect timing for me to read ;) Thanks Liam.

Thursday, 27 Sep 2007 08:57 by Liam Cleary
Hey Tobias, Hope you are well. Glad you find it informative. Always here to help!! Have to catchup at some point soon. :-)

Friday, 12 Oct 2007 08:03 by Luc
Hi Liam, Excellent post here! good timing for me. It saves me a lot of time. Now, I'm trying to group the result by using a metadata column created in my document library. How can I configure the CQWP to group, sort or filter the content by using a metadata field defined in my library? Thanks in advance. Luc

Tuesday, 2 Sep 2008 04:18 by Joe
Well, I tried this, but my webpart only saw three of my promoted fields, and only two of them rendered any data. What happened to my other half dozen fields? The little xsl code does not list them as fields.??????

Tuesday, 2 Sep 2008 06:48 by Joe
You put your CommonViewField values on separate lines, but if I do that it prepends _x000D__x000A__x0009 to each field. I have to put them on one line. And they still don't render.

Monday, 1 Jun 2009 05:55 by Anjali
Hi Liam, Thanxs for the nice post. I too had similar problem. Tried few things and now it worked. Solution below: 1. I had InfoPath Form containing fields CName & CResult 2. When published InfoPath form using "Administrator Approval" way The internal names for fields were changed CName => _x007b_e8e623a0_x002d_5bbd_x002d_4b56_x002d_8cea_x002d_9ae739e0b5b2_x007d_ CResult => _x007b_fbccad48_x002d_17c0_x002d_4883_x002d_8433_x002d_955eecef6b0e_x007d_ Note: In order to get the internal names; I created console application, used Sharepoint object Model and got this (As these are custom columns, they were not visible even after adding xslt to show all columns) 3. Once I got the internal names, I changed the property of CQWP: _x007b_e8e623a0_x002d_5bbd_x002d_4b56_x002d_8cea_x002d_9ae739e0b5b2_x007d_;_x007b_fbccad48_x002d_17c0_x002d_4883_x002d_8433_x002d_955eecef6b0e_x007d_ 4. Now, when we add custom xslt style in Itemstyle.xsl; we can see the new rendered column for these 2 fields Name : 5. The new fields name now is: CName => _x005F_x007b_e8e623a0_x005F_x002d_5bbd_x005F_x002d_4b56_x005F_x002d_8cea_x005F_x002d_9ae739e0b5b2_x005F_x007d_ CResult=> _x005F_x007b_fbccad48_x005F_x002d_17c0_x005F_x002d_4883_x005F_x002d_8433_x005F_x002d_955eecef6b0e_x005F_x007d_; 6. In most places, the reason given is that since there are spaces in names, the XSLT changes name before rendering. It replaces space by _x005F (But still not completely sure about this :-( ) 7. Now, few points to note: a. Query is made using the internal name b. Fields names are changed at the time of rendering and not at time of querying 8. Now, we want to give new name, so that it does not render the existing columns in more lengthy names. 9. Now, use another property of CQWP DataColumnRenames, _x007b_e8e623a0_x002d_5bbd_x002d_4b56_x002d_8cea_x002d_9ae739e0b5b2_x007d_,CName;_x007b_fbccad48_x002d_17c0_x002d_4883_x002d_8433_x002d_955eecef6b0e_x007d_,CTest; Format: OriginalName1,Newname1;OriginalName2,Newname2 Note: - OriginalName means the Internal name (actual internal name in SharePoint & NOT that is changed N rendered by XSLT) - New Name can be any. MOST IMP: Please DO NOT give any SPACES OR TAB while renaming multiple columns. Otherwise, only 1st column in row will be resolved.

Name:

URL:

Email:

Comments: