Bar pulchellus princeps est adhuc extendi, MUSCUS

Hodie, I was working with a client and describing how to modify the content query web part and display additional bits of information from a content type.

"First, you configure the CQWP to connect to its data sources, then you export it to your workstation, modify <CommonViewFields>, upload, remove the original and now it’s ‘primed’ to display those other columns. Postero, open up SharePoint designer, navigate to the site collection root and locate ItemStyle.xsl. Copy one of the templates as a useful starting point. Go back and modify the CQWP to make use of this new template. Tandem, modify the template to render your new fields! (Don’t forget to check it back in so that other users can see the results)."

It’s all quite clear to me (and most of us SharePoint developer types) what’s going on and how it’s quite nice, vere, that the data retrieval aspects of the CQWP are so well-separate from the data presentation aspects. Sed, it’s not so easy to explain, is it?

<Finis />

Technorati Tags: ,

Propono Content Quaero Web Part Results in a risus / Mensam

Overview et obiectiva

Ex arca archa, MUSCUS’ Quaero Web content Parte (CQWP) ostenditque fructus ejus in elencho format, similar to search results. It is also possible to display the results in a grid format (i.e. HTML mensam format). Grid formats are better in some circumstances. I describe how to achieve that effect in this article.

Negotium Missionem

I have worked with a client on an enterprise-wide MOSS rollout. We have designed their taxonomy such that projects are first class citizens in the hierarchy and have their own top level site. Project managers maintain a singleton list of project summary information, ut tituli, budget, consummatio expectatur date, remaining budget and other summary type fields. By "singleton" I mean a custom SharePoint list guaranteed to contain only one item. Simplistically, is vultus amo is:

imaginem

The technical approach is much the same as described hic (http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!447.entry). The CQWP uses an XSL transform to emit HTML for the browser to render.

I always envision the result before diving into the XSL because XSL is a nightmare. Here’s my desired result:

imaginem

HTML like this generates that result:

<html>
 <corpus>
 <centrum>
 <mensamque border=1>

<!-- Labels -->
 <tr bgcolor=blue>
 <td><font color=white><b>Project Name</b></font></td>
 <td align=right><font color=white><b>Complete Date</b></font></td>
 <td align=right><font color=white><b>Budget</b></font></td>
 <td align=right><font color=white><b>Actual Expense</b></font></td>
 <td><font color=white><b>Overall Status</b></font></td>
 </tr>

<tr>
 <td>Re-wire computer room.</td>
 <td align=right>02/01/08</td>
 <td align=right>22,500.00</td>
 <td align=right>19,000.00</td>
 <td>In Progress</td>
 </tr>

<tr>
 <td>Provision servers for SQL Upgrade</td>
 <td align=right>04/01/08</td>
 <td align=right>7,500.00</td>
 <td align=right>0.00</td>
 <td>Planned</td>
 </tr>

</mensamque>
 </centrum>
 </corpus>
</html>

Approach

Follow these steps to create the grid:

  1. Identify the components of the grid (rows/columns).
  2. Define and create necessary site columns.
  3. Create sub sites for the projects and singleton lists.
  4. Add the CQWP to a web page and configure it to search for your lists.
  5. Modify the CQWP’s XML to gather up the additional columns.
  6. Modify the XSL to generate a table.

I’m going to concentrate on number six. Numbers one through four are straight-forward and something that any CQWP user has already done. Number five has been well-documented by others including this exhaustive screen-shot laden article from MSDN hic (http://msdn2.microsoft.com/en-us/library/bb897399.aspx) and Heather Solomon’s blog hic (http://www.heathersolomon.com/blog/articles/CustomItemStyle.aspx).

Nuts And Bolts

Begin and implement steps one through five as per the MSDN documentation and Heather Solomon’s article.

Ad hoc, you’ve added your CQWP to the page and you have your <CommonViewFields> configured as necessary.

Following the usual steps, I get these intermediate results:

1. Partum a content type, a templatized custom list for that content type and two sites. Here is the content type:

imaginem

Here is the site structure:

imaginem

2. Add the CQWP after creating my project subsites and singleton project summary lists:

imaginem

3. Add all the additional information I want via the <CommonViewFields>:

        <proprietate nomen="CommonViewFields" typus="filum">Project_x0020_Name;Project_x0020_Expenses;Project_x0020_Status;Project_x0020_Start_x0020_Date;Project_x0020_End_x0020_Date;Project_x0020_Budget</proprietate>

Note that I had to keep all the property fields on one line or it would not work (CQWP would tell me that the query returned no items).

4. Ad hoc, we’re ready to move beyond the MSDN article and flip on over to Heather Solomon’s article. Follow her steps starting near step #5 to create a customized / unghosted version of ItemStyle.xsl. I follow Heather’s advice, up through step 11 and get these intermediate results:

4.1: Name my XSL template as follows:

<p:template name="Grid" match="Row[@Style=’Grid’]" mode="itemstyle">

I also slightly modify her suggested <p:nam quisque- …> by adding a <br /> tag to provide a cleaner listing:

    <p:nam quisque- elige="@*">
      P:<p:valor ex- elige="nomen()" /><br/>
    </p:nam quisque->

4.2: I modify the web part, go to appearance and select my "Grid" style:

imaginem

Apply the change and here is the result:

imaginem

We can see from the above that the fields we want (Project name, expense, status, etc) are available for us to use when we emit the HTML. Not only that, but we see the names by which we must reference those columns in the XSL. Verbigratia, we reference Project Status as "Project_x005F_x0020_Name".

Ad hoc, we depart from Heather’s blog and from the shoulders of these giants, I add my own little bit.

ContentQueryMain.xsl

MONUMENTUM: Cum utrisque mutationibus tam ContentQueryMain.xsl ItemStyle.xsl, tu opus ad reprehendo retro in conspectu illorum lima videtis effectum mutationes tuas.

Nam eget consilium-factionis, MOSS uses two different XSL files to produce the results we see from a CQWP. To generate the previous bit of output, we modified ItemStyle.xsl. MOSS actually uses another XSL file, ContentQueryMain.xsl to in conjunction with ItemStyle.xsl to generate its HTML. As its name implies, ContentQueryMain.xsl is the "main" XSL that controls the overall flow of translation. It iterates through all the found items and passes them one by one to templates in ItemStyle.xsl. We’ll modify ItemStyle.xsl to generate the open <mensamque> tag emiserit ante in primo versu de notitia et occlusio <mensamque> tag after emitting the last row. To accomplish this, ContentQueryMain.xsl is modified to pass two parameters to our "grid" luctus in ItemStyle.xsl, "last row" and "current row". ItemStyle.xsl uses these to conditionally emit the necessary tags.

Heather scriptor Salomon usura ars, we locate ContentQueryMain.xsl. It is located in the same place as ItemStyle.xsl. This screen shot should help:

imaginem

His motus ad opus:

  • Vel demutare p template, "CallItemTemplate" that actually invokes our Grid template in ItemStyle.xsl. We will pass two parameters to the Grid template so that it will have the data it needs to conditionally generate opening and closing <mensamque> tags.
  • Modify another bit of ContentQueryMain.xsl that calls the "CallItemTemplate" to pass it a "LastRow" parameter so that LastRow may be passed on to our Grid template.

Locate the template named "OuterTemplate.CallItemTemplate" identified by the string:

  <p:Template nomen="OuterTemplate.CallItemTemplate">

Replace the whole template as follows:

  <p:Template nomen="OuterTemplate.CallItemTemplate">
    <p:param nomen="CurPosition" />

    <!--
      Add the "LastRow" parameter.
      We only use it when the item style pass in is "Grid".
    -->
    <p:param nomen="LastRow" />

    <p:elegerit>
      <p:cum test="@Style='NewsRollUpItem'">
        <p:apply-templates elige="." mode="itemstyle">
          <p:cum param- nomen="EditMode" elige="$cbq_iseditmode" />
        </p:apply-templates>
      </p:cum>
      <p:cum test="@Style='NewsBigItem'">
        <p:apply-templates elige="." mode="itemstyle">
          <p:cum param- nomen="CurPos" elige="$CurPosition" />
        </p:apply-templates>
      </p:cum>
      <p:cum test="@Style='NewsCategoryItem'">
        <p:apply-templates elige="." mode="itemstyle">
          <p:cum param- nomen="CurPos" elige="$CurPosition" />
        </p:apply-templates>
      </p:cum>

      <!--
              Pass current position and lastrow to the Grid itemstyle.xsl template.
              ItemStyle.xsl will use that to emit the open and closing <mensamque> tags.
      -->
      <p:cum test="@Style='Grid'">
        <p:apply-templates elige="." mode="itemstyle">
          <p:cum param- nomen="CurPos" elige="$CurPosition" />
          <p:cum param- nomen="Last" elige="$LastRow" />
        </p:apply-templates>
      </p:cum>

      <p:alioqui>
        <p:apply-templates elige="." mode="itemstyle">
        </p:apply-templates>
      </p:alioqui>
    </p:elegerit>
  </p:Template>

The comments describe the purpose of the changes.

Utique, the "OuterTemplate.CallItemTemplate" is itself called from another template. Locate that template by searching for this text string:

<p:Template nomen="OuterTemplate.Body">

Scroll through the instructions in OuterTemplate.Body and insert the LastRow parameter as follows (shown as a comment in italics):

<p:Template voca- nomen="OuterTemplate.CallItemTemplate">
  <p:cum param- nomen="CurPosition" elige="$CurPosition" />
  <!-- Insert the LastRow parameter. -->
  <p:cum param- nomen="LastRow" elige="$LastRow"/>
</p:Template voca->

After all of this, we finally have things set up properly so that our ItemStyle.xsl can emit <mensamque> tags at the right place.

ItemStyle.Xsl

MONUMENTUM: Iterum, check in ItemStyle.xsl after making any changes so that you see the effect of those changes.

We have two tasks here:

  • Replace the entire Grid template. You can copy/paste from below.
  • Add some mumbo jumbo outside the template definition that enables "formatcurrency" template to work. (You can tell that I have a tenuous handle on XSL).

Primum, near the top of ItemStyle.xsl, add this line:

  <!-- Some mumbo jumbo that enables us to display U.S. currency. -->
  <p:decimales format- nomen="staff" digit="D" />

  <p:Template nomen="Default" match="*" mode="itemstyle">

Note that I added it directly before the <p:template name="Default" …> definition.

Postero, go back to our Grid template. Replace the entire Grid template with the code below. It is thoroughly commented, but don’t hesitate to email me or leave comments on my blog if you have questions.

  <p:Template nomen="Grid" match="Row[@Style='Grid']" mode="itemstyle">

    <!--
      ContentMain.xsl passes CurPos and Last.
      We use these to conditionally emit the open and closing <mensamque> tags.
    -->
    <p:param nomen="CurPos" />
    <p:param nomen="Last" />

    <!-- The following variables are unmodified from the standard ItemStyle.xsl -->
    <p:variabilis nomen="SafeImageUrl">
      <p:Template voca- nomen="OuterTemplate.GetSafeStaticUrl">
        <p:cum param- nomen="UrlColumnName" elige="'ImageUrl'"/>
      </p:Template voca->
    </p:variabilis>
    <p:variabilis nomen="SafeLinkUrl">
      <p:Template voca- nomen="OuterTemplate.GetSafeLink">
        <p:cum param- nomen="UrlColumnName" elige="'LinkUrl'"/>
      </p:Template voca->
    </p:variabilis>
    <p:variabilis nomen="DisplayTitle">
      <p:Template voca- nomen="OuterTemplate.GetTitle">
        <p:cum param- nomen="Title" elige="@Title"/>
        <p:cum param- nomen="UrlColumnName" elige="'LinkUrl'"/>
      </p:Template voca->
    </p:variabilis>
    <p:variabilis nomen="LinkTarget">
      <p:si test="@OpenInNewWindow = 'True'" >_blank</p:si>
    </p:variabilis>

    <!--
      Here we define a variable, "tableStart".  This contains the HTML
      that we use to define the opening of the table as well as the column
      labels.  Note that if CurPos = 1, it includes the HTML in a CDATA tag.
      Otherwise, it will be empty.

      The value of tableStart is emited every time ItemStyle is called via
      ContentQueryMain.xsl.
    -->
    <p:variabilis nomen="tableStart">
      <p:si test="$CurPos = 1">
        <![CDATA[
        <table border=1>
          <tr bgcolor="blue">
            <td><font color="white"><b>Project Name</b></font></td>
            <td align="right"><font color="white"><b>Complete Date</b></font></td>
            <td align="right"><font color="white"><b>Budget</b></font></td>
            <td align="right"><font color="white"><b>Actual Expense</b></font></td>
            <td><font color="white"><b>Overall Status</b></font></td>
          </tr>
        ]]>
      </p:si>
    </p:variabilis>

    <!--
      Another variable, tableEnd simply defines the closing table tag.

      As with tableStart, it's always emited.  This is why its value is
      assigned conditionally based upon whether we've been passed the last
      row by ContentQueryMain.xsl.
    -->
    <p:variabilis nomen="tableEnd">
      <p:si test="$CurPos = $Last">
        <![CDATA[ </mensamque> ]]>
      </p:si>
    </p:variabilis>

    <!--
      Always emit the contents of tableStart.  If this is not the first
      row passed to us by ContentQueryMain.xsl, then we know its value
      will be blank.

      Disable output escaping because when tableStart it not blank, it
      includes actual HTML that we want to be rendered by the browser.  If
      we don't tell the XSL parser to disable output escaping, it will generate
      stuff like "&LT;mensamque&gt;" instead of "<mensamque>".
    -->
    <p:valor ex- elige="$tableStart" disable-output-erepta="Imo"/>


    <tr>
      <!--
      P:Project_x005F_x0020_Name
      P:Project_x005F_x0020_End_x005F_x0020_Date
      P:Project_x005F_x0020_Budget
      P:Project_x005F_x0020_Expenses
      P:Project_x005F_x0020_Status
      -->
      <td>
        <p:valor ex- elige="@Project_x005F_x0020_Name"/>
      </td>

      <td align="ius">
        <p:valor ex- elige="@Project_x005F_x0020_End_x005F_x0020_Date"/>
      </td>

      <td align="ius">
        <p:Template voca- nomen="formatcurrency">
          <p:cum param- nomen="valor" 
elige="@Project_x005F_x0020_Budget"></p:cum param-> </p:Template voca-> </td> <td align="ius"> <p:Template voca- nomen="formatcurrency"> <p:cum param- nomen="valor" elige="@Project_x005F_x0020_Expenses">
</p:cum param-> </p:Template voca-> </td> <td> <p:valor ex- elige="@Project_x005F_x0020_Status"/> </td> <!-- All of the following is commented out to clarify things. Autem, bring it back and stuff it into a <td> to see its effect. --> <!-- <div id="linkitem" class="item"> <p:if test="string-length($SafeImageUrl) != 0"> <div class="image-area-left"> <a href="{$SafeLinkUrl}" target="{$LinkTarget}"> <img class="image-fixed-width" src="{$SafeImageUrl}"
alt="{@ImageUrlAltText}"/> </a> </Div> </p:si> <div class="link-item"> <p:Template voca-
name="OuterTemplate.CallPresenceStatusIconTemplate"/> <a href="{$SafeLinkUrl}"
target="{$LinkTarget}" title="{@LinkToolTip}"> <p:value-of select="$DisplayTitle"/> </a> <div class="description"> <p:value-of select="@Description" /> </Div> </Div> </Div>
--> </tr> <!-- Emit the closing table tag. If we are not on the last row, this will be blank. --> <p:valor ex- elige="$tableEnd" disable-output-erepta="Imo"/> </p:Template> <p:Template nomen="formatcurrency"> <p:param nomen="valor" elige="0" /> <p:valor ex- elige='numerum format-($valor, "$DDD,DDD,DDD.DD", "staff")' /> </p:Template>

Vexillum WSS / MUSCUS Data Entry praetexit non favent SUMMISSUS occumbo-pertulerat (aut alia ab communicationis intra-)

UPDATE (04/2008): Magnum hoc blog introitu ostendit a bono javascript dicentur aditus ad hoc problema: http://webborg.blogspot.com/2008/04/add-functions-and-events-to-sharepoint.html

UPDATE II: (04/2008): Hoc blog introitu spectat tam promittens: http://www.cleverworkarounds.com/2008/03/13/free-mosswss-2007-web-part-hide-controls-via-javascript/

Plures temporibus a septimana, si minus quotidie,, forum users describe a requirement that would normally be met via cascading drop-downs. Verbigratia, Habeo duas occumbo-down imperium:

  • List of U.S. civitatium
  • List of U.S. urbes.

Author UI ut suggero, sic operari volumus:

  • Paulus deligit U.S. state from the drop-down.
  • This causes the cities drop-down to filter only those cities that belong to the selected state.
  • Paulus deligit a civitate hac percolantur album.

There is no out-of-the-box support for this feature. In facto, there is no OOB support for any kind of direct intra-form communication. This includes programmatically hiding/enabling/disabling fields in response to field changes elsewhere on the form.

Hic articulus ad describeret obiectiva rerum solutionum possibilis, et haec sunt bene ut ego cognosco eas,:

  1. Develop a custom column type. As a custom-column-developer, you have full control over the "world" of that custom column. You can implement a cascading drop-down that way.
  2. Consider using workflow. In some cases, you want to automatically assign a value to field based on another field’s value. In hoc, vos Northmanni conantur uti ratione agmen, sed interdum, it just won’t get the job done. SharePoint Designer workflow is a relatively administer-friendly alternative to dropping down into code and visual studio. If you go this route, Quaestio salutari sentire hoc articulum (http://paulgalvin.spaces.live.com/blog/cns!CC1EDB3DAA9B8AA!405.entry).
  3. Tracto vicis: Sicut workflow, this is an after-the-fact solution. Your event handler is a .NET assembly (C #, VB.NET) to which SharePoint passes control. The object you develop has access to the data of the list (et totum illud exemplar,) et potest facere aliquod opus calculus.
  4. Use SharePoint Designer to create custom entry forms. I don’t have direct experience with this approach, but I hear they are doing good things with NewForm.aspx these days 🙂
  5. Volvite introitu tuo ASP.NET notitia muneris (ut stet-solus textus partem aut paginae) et quod utor instead.

Si quis scit et / vel potius bene, Vestibulum eget velit et corpus, consectetur adipiscing elit felis.

<Finis />

Technorati Tags:

Yes/No (reprehendo arca archa) Content Textus Quaero filtering in Parte

To filter for a query for the Yes/No check box entitled "PG Milestone", configurare haec CQWP:

imaginem

Hoc est aliud unum ex his patet, quondam vos scire, sed difficile invenies-ad-modum-responsum ad quaestiones:: Ita quam ad spurcamen in / box nullo morante usura query telam contentus parte.

Prima quaero praecessi I find using the search term "filter yes/no content query web part" planae de iniuriam est, Lorem ita ego eum hoc loco potest, si recte et ex dine Search Results.

Suus facile: True values = "1" and false values do not equal "1" (pulchellus RED, ultro).

In superiore exemplo, I created site column of type "Yes/No (checkbox)" named "PG Milestone". I added it to a doc library, Lorem paucis documentis, posuit et valorem copulabis expertus.

<Finis />

Creare Bar graphs in SharePoint

Overview:

(UPDATE 12/04/07: Accessit aliud interesting resource fine ad alterum conjunctio blog quod hoc est per aliquam partem valde interesting)

This blog entry describes how to create a bar graph in SharePoint. This works in both WSS and MOSS environments as it only depends upon the data view web part.

Altiore adventu est ut sequitur:

  1. Partum a album vel documenti library quod continet notitia vis F.
  2. Pone adiunctam document bibliotheca / vectigal elencho onto et convertam page ad a notitia ex parte sententia telam (DVWP).
  3. Temperare scriptor DVWP p generare HTML quod ostendit F.

Negotium Missionem / PRAEFIXUS:

Ego creavi consuetudo album vexillum Title agmine uno addito agmen, "Status". This models (ipsa simplistically) an "Authorization For Expense" quo titulo missionis project repraesentat et status ex numero aestimanda:

  • Proposuerat
  • Evolutis
  • Stabulari

Propositum est ad producendum horizontali bar Lorem ipsum his patet, quod status codicibus F.

Ego similis hoc genus hominum album:

imaginem

Data partum Textus View Parte:

DVWP addendo ad paginam creare consuetudinem album (site pagina causam meam) et sequi mandatis hic (http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!395.entry).

Praeter simpliciter partum DVWP, we also need to set the paging property to show all available rows. Enim me, hoc spectat huic simile:

imaginem

Ad hoc, I always close SPD and the browser. I then re-open the page using the browser. This avoids accidentally mucking up the web part layout on the page.

Temperare XSLT:

Suus 'iam tempus ad modify XSLT.

I always use visual studio for this. (Videte hic nam circa insigniore note intellisense quod multum proderit).

Fasciculi novi addunt quatuor project ego creo inani (replacing the words "Original" and "New" ut conveniens):

  • Original.xslt
  • New.xslt
  • Original Params.xml
  • New Params.xml

In meam, is vultus amo is:

imaginem

Modify the web part and copy the params and XSL to the "Original" version in Visual Bulla.

Objectum est causa p transfigurare nobis impetro tergum consequitur query in a DVWP HTML reddentis quasi F.

Ad hunc finem, it helps to first consider what the HTML should look like before we get confused by the insanity that is known as "XSL". (Patere, haec est simpliciter exemplum; don’t type it or copy/paste into visual studio. I provide a full blow starting point for that later in the write-up). The following sample graph is rendered as per the HTML immediately following:

Sample Bar Aliquam lacinia purus

Debita HTML:

<html>
<corpus>
<centrum>
<mensam width = LXXX%>
<tr><td><centrum>Aliquam lacinia purus eros Talea</td></tr>
<tr>
<td align="center">
<table border="1" width = LXXX%>
<tr>
<width = p X%>Aperi</td>
<td><mensam cellpadding ="0" cellspacing ="0" border = 0 width = L%><tr = rubrum bgcolor><td>&nbsp;</td></tr></mensamque></td>
</tr>
<tr>
<width = p X%>Concluserat</td>
<td><mensam cellpadding ="0" cellspacing ="0" border = 0% XXV width =><tr = rubrum bgcolor><td>&nbsp;</td></tr></mensamque></td>
</tr>
<tr>
<width = p X%>Stabulari</td>
<td><mensam cellpadding ="0" cellspacing ="0" border = 0% XXV width =><tr = rubrum bgcolor><td>&nbsp;</td></tr></mensamque></td>
</tr>
</mensamque>
</td>
</tr>
</mensamque>
</corpus>
</html>

I used a dead simple approach to creating my bars by setting the background color of a row to "red".

In hac hic accipere-a: In finem, porticus et columnas cum loquimur omnia creavit HTML.

Template XSLT:

I’ve copied the XSLT that generates a horizontal bar graph. It’s fairly well commented so I won’t add much here except for these notes:

  • Coepi cum eo p defaltam SharePoint Designer dedit mihi primo creavit DVWP.
  • EGO eram validus ut interficiam de isto SPD scriptor 657 lineas 166 lines.
  • Non tatam circa ambitum file pron (Et scies quod est separatum a p dico cum ad se temperare DVWP; duo ordines commutare potest). Autem, ut eam simpliciorem, I did remove nearly all of them from the XSL. This means that if you want to make use of those parameters, you just need to add their variable definitions back to the XSL. That will be easy since you will have the original XSL variable definitions in your visual studio project.
  • You ought to be able to copy and paste this directly into your visual studio project. Igitur, remove my calls and insert your own calls to "ShowBar".
  • Ad EXERCITATIO operatur creando <a href> sicut est hodie: http://server/List?FilterField1=fieldname&FilterValue1=actualFilterValue. This technique may be of value in other contexts. Primo, Putabam me opus conformare ad magis complexu format: http://server/List/AllItems.aspx?View={guid}&FilterField1=blah&FilterValue1=blah, but in my environment that is not necessary. The List’s URL is passed to us by SharePoint so this is quite easy to generalize.

Hic est:

<p:stylesheet version="1.0" excludere, unde praemittit,="Rs z o s ddwrt dt msxsl" 
xmlns:msxsl="Urna:Microsoft-schemas com-:xslt" xmlns:p="http://www.w3.org/1999/XSL/Transform"
xmlns:SharePoint="Microsoft.SharePoint.WebControls" xmlns:__designer="http://schemas.microsoft.com/WebParts/v2/DataView/designer"
xmlns:áspidis="http://schemas.microsoft.com/ASPNET/20" xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime"
xmlns:O="Urna:Microsoft-schemas com-:muneris" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882"
xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:Rs="Urna:Microsoft-schemas com-:rowset" xmlns:z="#RowsetSchema"
xmlns:ddwrt2="Urna:frontpage:internum"
> <p:output methodo="html" indent="nulla" /> <p:decimales format- Nan="" /> <p:param nomen="ListUrlDir"></p:param> <!-- Hac-tenus EGO postulo suffrago terebra. --> <p:Template match="/" xmlns:SharePoint="Microsoft.SharePoint.WebControls"
xmlns:__designer=http://schemas.microsoft.com/WebParts/v2/DataView/designer xmlns:áspidis="http://schemas.microsoft.com/ASPNET/20"
> <p:variabilis nomen="dvt_StyleName">Mensam</p:variabilis> <p:variabilis nomen="Deambulacra" elige="/dsQueryResponse / ordinibus / Row" /> <p:variabilis nomen="dvt_RowCount" elige="Numerabitis($Deambulacra)" /> <p:variabilis nomen="IsEmpty" elige="$dvt_RowCount = 0" /> <p:variabilis nomen="dvt_IsEmpty" elige="$dvt_RowCount = 0" /> <p:elegerit> <p:cum test="$dvt_IsEmpty"> Nulla notitia F!<br/> </p:cum> <p:alioqui> <!-- Interesting effercio hic incipitur. Oportet definire par variabilium pro singulis ordinibus in F: Numerus           . --> <p:variabilis nomen="totalProposed" elige="Numerabitis(/dsQueryResponse / ordinibus / Row[normalize spatium-(@ Status) = 'Propositum'])" /> <p:variabilis nomen="percentProposed" elige="$totalProposed p $ dvt_RowCount" /> <p:variabilis nomen="totalInProcess" elige="Numerabitis(/dsQueryResponse / ordinibus / Row[normalize spatium-(@ Status) = 'Processu'])" /> <p:variabilis nomen="percentInProcess" elige="$totalInProcess p $ dvt_RowCount" /> <p:variabilis nomen="totalStalled" elige="Numerabitis(/dsQueryResponse / ordinibus / Row[normalize spatium-(@ Status) = 'Stabulari'])" /> <p:variabilis nomen="percentStalled" elige="$totalStalled p $ dvt_RowCount" /> <!-- Noster hie definimus mensam HTML. Im mutuatus nonnullos signiferos           . Puto colet           . --> <mensamque latitudo="100%" cellspacing="0" cellpadding="2" style="FINIS-IURE: 1 # solidum C0C0C0; FINIS-SOLUM: 1 # solidum C0C0C0; FINIS-sinistram-stilo: solida; FINIS-amplitudo sinistram-: 1; FINIS-stilo summo-: solida; FINIS-width summo-: 1;"> <tr> <td align="centrum"> <mensamque border="1" latitudo="100%"> <!-- Uterque enim status volumus F, we call the "ShowBar" Template. Nos transire,: 1. Nam in versu pittacium. Hoc est permutatum a Hyperlink. 2. In sentio (variabilis desursum). 3. Ipso nomine agro Codicis a subiecta album. Hoc                      . 4. Pro pretio agri matched #3. 5. Summa Codicis status hujus items (Non omnes eu wisi                      ). Emittit <tr></tr> et linea horizontali bar F. Hoc enim ipsum dicimus unicuique ordini Codicis uolumus considerate. --> <p:Template voca- nomen="ShowBar"> <p:cum param- nomen="BarDisplayLabel" elige="'Propositum'"/> <p:cum param- nomen="BarPercent" elige="$percentProposed"/> <p:cum param- nomen="QueryFilterFieldName" elige=""Status""/> <p:cum param- nomen="QueryFilterFieldValue" elige="'Propositum'"/> <p:cum param- nomen="TotalItems" elige="$totalProposed"></p:cum param-> </p:Template voca-> <p:Template voca- nomen="ShowBar"> <p:cum param- nomen="BarDisplayLabel" elige="'Stabulari'"/> <p:cum param- nomen="BarPercent" elige="$percentStalled"/> <p:cum param- nomen="QueryFilterFieldName" elige=""Status""/> <p:cum param- nomen="QueryFilterFieldValue" elige="'Stabulari'"/> <p:cum param- nomen="TotalItems" elige="$totalStalled"></p:cum param-> </p:Template voca-> <p:Template voca- nomen="ShowBar"> <p:cum param- nomen="BarDisplayLabel" elige="'Processu'"/> <p:cum param- nomen="BarPercent" elige="$percentInProcess"/> <p:cum param- nomen="QueryFilterFieldName" elige=""Status""/> <p:cum param- nomen="QueryFilterFieldValue" elige="'Processu'"/> <p:cum param- nomen="TotalItems" elige="$totalInProcess"></p:cum param-> </p:Template voca-> </mensamque> </td> </tr> </mensamque> </p:alioqui> </p:elegerit> </p:Template> <!-- Template hoc facit opus ostentans singulis linearum in bar F. Youll 'forsit plerique vestrum tweaking hie. --> <p:Template nomen="ShowBar"> <p:param nomen="BarDisplayLabel" /> <!-- Pittacium ostendere --> <p:param nomen="BarPercent"/> <!-- Cento totalis. --> <p:param nomen="QueryFilterFieldName"/> <!-- Usus ad salire ad query & spurcamen --> <p:param nomen="QueryFilterFieldValue"/> <!-- Usus ad salire ad query & spurcamen --> <p:param nomen="TotalItems" /> <!-- totam comitis hoc barlabel --> <tr> <!-- Bar ipsum pittacium. --> <td genus="ms-formbody" latitudo="30%"> <!-- Sequenti statuto de hac quaestione sententias aedificat filo sino           . Hic utimur pauca: 1. Possumus transire ad elenchum FilterValue1 FilterField1 et in columna ut spurcamen. 2. SharePoint transiret a key parameter ad nos, ListUrlDir that points to the underlying list against which this DVWP is "running". Est non fun p? --> <p:text disable-output-erepta="Imo"> <![CDATA[<a href ="]]></p:text> <p:valor ex- elige="$ListUrlDir"/> <p:text disable-output-erepta="Imo"><![CDATA[?FilterField1 =]]></p:text> <p:valor ex- elige="$QueryFilterFieldName"/> <p:text disable-output-erepta="Imo"><![CDATA[&FilterValue1 =]]></p:text> <p:valor ex- elige="$QueryFilterFieldValue"/> <p:text disable-output-erepta="Imo"><![CDATA[">]]></p:text> <p:valor ex- elige="$BarDisplayLabel"/> <p:text disable-output-erepta="Imo"><![CDATA[</a>]]></p:text> <!-- Sequenti frenum ostendit aliqui numeri in format: "(totalis / % totalis)" --> (<p:valor ex- elige="$TotalItems"/> / <!-- Hoc facit a nice pro cento nos label. Gratias, Microsoft! --> <p:Template voca- nomen="percentformat"> <p:cum param- nomen="sentio" elige="$BarPercent"/> </p:Template voca->) </td> <!-- Tandem, emittere <td> tag pro se bar.--> <td> <mensamque cellpadding="0" cellspacing="0" border="0" latitudo="{rotundum($C: * BarPercent)+1}%"> <tr bgcolor="red"> <p:text disable-output-erepta="Imo"><![CDATA[&nbsp;]]></p:text> </tr> </mensamque> </td> </tr> </p:Template> <!-- Hoc accipitur immediate ab aliquo p inveni in MS template. --> <p:Template nomen="percentformat"> <p:param nomen="sentio"/> <p:elegerit> <p:cum test="numerum format-($sentio, "@, 0 @ #%;-#,##0%')= "Nan"">0%</p:cum> <p:alioqui> <p:valor ex- elige="numerum format-($sentio, "@, 0 @ #%;-#,##0%')" /> </p:alioqui> </p:elegerit> </p:Template> </p:stylesheet>

Eventus:

Et p hoc de generat supra F:

imaginem

EXERCITATIO ad subjectam strepitando in notitia status Code:

imaginem

Decernentes Cogitata:

Hoc potest esse generativus?

Hoc amo conceptus graphing, but I hate the fact that I have to go in and do so much hand-coding. I’ve given a little thought to whether it can be generalized and I’m optimistic, but I’m also a little fearful that there may be a brick wall somewhere along the path that won’t offer any work-around. If anyone has some good ideas on this, Nibh vel a note in ineo email me.

Verticalis graphs:

This is a horizontal bar graph. It’s certainly possible to create a vertical graph. We just need to change the HTML. I would start the same way: Create an HTML representation of a vertical bar graph and then figure out how to get that via XSL. If anyone is interested in that, I could be persuaded to try it out and work out the kinks. If someone has already done that, Et commodo sciam quod libenter link to vestri blog 🙂

Puto provocatio cum verticali F est titulus pro F sunt procreare difficilius, profecto inpossibilia.

Agro nomen Gotcha scriptor:

Ad minus duo nomina agro tuo quaerere.

Primum, a field name with a space has to be escaped in the XSL. This will probably be an issue here:

        <p:variabilis nomen="totalProposed" 
elige="Numerabitis(/dsQueryResponse / ordinibus / Row[normalize spatium-(@ Status) = 'Propositum'])" />

If your "Status" column is actually named "Status Code" then you need to reference it as "Status_x0020_Code":

   <p:variabilis nomen="totalProposed" 
elige="Numerabitis(/dsQueryResponse / ordinibus / Row[normalize spatium-(@ Status_x0020_Code) = 'Propositum'])" />

Secundo, et sum adhuc, quamquam in hac, but you also need to be on the alert for field name changes. If you name your field "Status Code" et tunc postea, rename it to "AFE Status", the "internal name" does not change. The internal name will still be "Status Code" and must be referenced as "Status_x0020_Code". The "other resources" potest auxilium egritudo links et corrigere hujusmodi Problema.

Circa colorem:

I picked "red" because it’s pleasing to me at the moment. It would not be a big deal to show different colors so as to provide more than just a visual description of a number, but to also provide a useful KPI. Verbigratia, if the percentage of "stalled" AFE est scriptor > 10% deinde ostendere rubro, otherwise show it in black. Utor <p:elegerit> perficerent.

Aliaque:

Beatus transformans!

<Finis />

Scribet ad mea blog!

SharePoint non providere “Qui Access” Nuntiatus

UPDATE 01/28/08: This codeplex project addresses this issue: http://www.codeplex.com/AccessChecker. I have not used it, but it looks promising if this is an issue you need to address in your environment.

UPDATE 11/13/08: Joel Oleson wrote up a very good post on the larger security management issue here: http://www.sharepointjoel.com/Lists/Posts/Post.aspx?List=0cd1a63d-183c-4fc2-8320-ba5369008acb&ID=113. It links to a number of other useful resources.

Forum users and clients often ask a question along these lines: "How do I generate a list of all users with access to a site" or "How can I automatically alert all users with access to list about changes made to the list?"

There is no out of the box solution for this. If you think about it for a moment, it’s not hard to understand why.

SharePoint security is very flexible. There are at least four major categories of users:

  • Anonymous users.
  • SharePoint Users and Groups.
  • Active Directory users.
  • Substructio formae authenticas (FBA) users.

The flexibility means that from a security perspective, any given SharePoint site will be dramatically different from another. In order to generate an access list report, one needs to ascertain how the site is secured, query multiple different user profile repositories and then present it in a useful fashion. That’s a hard problem to solve generically.

How are organizations dealing with this? I’d love to hear from you in comments or email.

</finem>

Technorati Tags: ,

MUSCUS refert me mea Column nomen est Reserved vel In Usu … Sed suus Non

UPDATE 12/04/07: Videte this Microsoft KB (http://support.microsoft.com/kb/923589) enim related notitia.

Actu, vertit ex est, sed tricksy MOSS had to make it difficult.

My customer does some development work on his MOSS site over the weekend. It’s a bit of a jumble as to what he actually did, sed in finem ex est hoc:

  • He tries to add a site column called "Quantity" and MOSS replies: "The column name that you entered is already in use or reserved. Choose another name."
  • He attempts to add it to another environment and that works. Therefore, "Quantity" is not a reserved name.
  • He tries to find an existing site column named "Quantity" in that site collection. He cannot find it.

I did some research, and even some coding, waxed philosophical and finally found that a column named Quantity did, in facto, exist. It was in the "_Hidden" group. Hence, we could not find it via the SharePoint user interface.

How did it get there? I do not know, but I have a theory (or as my wife would call it, "blah blah blah"). Alicubi in linea, a fabulous forty template was added and probably activated at a site in the site collection. It was then deactivated (or the site removed). The site column, autem, remained but in the "_Hidden" group. If someone knows better, please let me know via email or post in the comments.

SharePoint was telling the truth. It’s hardly worth pointing out that that message is not as helpful as it could be. It would be nice to see that message fork into two different messages in the future: 1) Say that the column name is reserved or it is not. 2) If it’s not reserved, show the site, or at least the group, where the column name is already used.

</finem>

OM praesentissimum Data Via a Consuetudo List (aut, Tamen Alia OM Data Displayor [sicut YACC, sed diversis])

Hodie, I spent a handful of hours tracking down the root cause behind the message "The column name that you entered is already in use or reserved. Choose another name."

Agitur agmen posset creari, deletum et re-creata in alia environment, so I knew it wasn’t a reserved name. Autem, I simply couldn’t find the column anywhere via the standard SharePoint user interface at any site in the site collection.

I posted to MSDN forums here and the indomitable Andrew Woodward pointed me in the direction of the underlying object model data.

I went off to codeplex to find some tools that would help me peer into the underlying OM data and help me locate the trouble.

I tried several tools and they were very cool and interesting but in the end, the UI wasn’t good enough for my purpose. I’m not criticizing them by any means, but clearly the tool-makers didn’t have my problem in mind when they created their UI :). Most people seem to be investing a fair amount of time and effort in creating workstation / client applications that provide tree views, right-click context menus and so forth. These are nice and all, but it’s a lot of work to create a top-of-the-line user experience that is also very flexible.

I really needed an answer to this problem. It occurred to me that if I could get all of the site columns in the site collection into a custom list, I could filter, sort and create views that would help me find this supposedly existing column (which it did, BTW). I went ahead and did that and an hour or two later, had all my site columns loaded into a custom list with grouping, sorting and so forth. I found my answer five minutes later.

If and when I successfully take over the world, I think I will decree that all SharePoint tools providers must seriously consider surfacing their object model data in a custom list. That way, I have the power to search any way I want (constrained, utique, by standard sharepoint features).

SharePoint amet Workflow Consuetudo Actionis — Observatione About <Agro Tie amet Type =”StringBuilder” … />

Ut wisi magna vivos observatur differentia inter has duas definitiones:

<FieldBind Field = "InParam1" Excogitatoris Type = "String adipiscing" Id = "II" Text = "Input parameter # I" />

versus:

<FieldBind Field = "InParam1" Id = "II" Text = "Input parameter # I" />

Primo ostendit hoc in SPD:

imaginem

haec ostendit sicut hoc:

imaginem

I’m not sure how helpful these screen shots are but I put in the effort to make them so you have to view them 🙂

Hoc est, observetur: StringBuilder sino vos ædificare filum (Manifestum) commiscendo simul filum literals et notitia workflow (via the "Add Lookup" pyga in inferiorem sinistram angulo). When you use the Add Lookup button, it inserts a token in the form "[%signum%]". When SharePoint invokes your custom action, (C # code in causam meam), SharePoint transit signum ipsum, not the value of the token. If you use the default designer type (secundi generis), SharePoint dilatat actu et transit signum valoris signum actionis.

StringBuilder = BAD, Annum amet type = BONA.

Utique, that’s not what I really mean. Just don’t try and pass a parameter to your custom action when the designer type = StringBuilder. Use the default designer type and chain a StringBuilder to it up front if you need to build complex strings in your workflow (quod per accidens est prorsus quod facit subiectum creare dynamicam actionem email, sed quod est subiectum alterius ingressum blog, Har Har).

<Finis />

Immatura Workflow Activation — A Non-medica Solutio

UPDATE: Hoc MSDN disputatione, maxime ultimum introitu: http://forums.microsoft.com/MSDN/showpost.aspx?postid=2631057&siteid=1. It describes a condition that may short circuit this whole thing. In short, simplex sit amet agros facere saltem.

Mihi documentum bibliotheca sustinet octo contentus genera.

I have a SharePoint Designer workflow that wants to calculate and assign a "reminder date" simpliciter per subtractionem 30 ex diebus alterius columnae, "due date". This should only happen for one of the content types, "Insurance". The business objective is to produce a KPI that shows two categories of insurance documents: "about to expire" and "expired." (Vos can lego magis ac magis substantialem EXERCITATIO-descendit de huiusmodi KPI hic).

I have configured the workflow to fire when a new item is created and when an item is modified. The idea is that when an insurance document is uploaded, we calculate a "warning date" based on the expiration date. A pair of views work in connection with a KPI List to highlight these conditions when users hit their home page.

Hoc ipsum non operari cum upload documento.

I upload the document and I am presented with the meta data entry screen. Ad hoc, I’m already in trouble. SharePoint has already, praepropere a prospectu, fired the workflow. I haven’t had a chance to pick the correct content type nor assign a due date. Simul, the workflow does not fire when I hit the submit button at this time. There’s some built-in logic that "believes" that first submit is part of the "create" event. Ita … et accensus est workflow meum cum supplicio, it was passed default meta data values.

The best work-around I know of is to insert a "pause until" activity in the workflow. I have the workflow pause for 1 minute. While it’s pausing, Ego recta Eligunt content type, enter the meta data and submit. The pause completes and the workflow proceeds as needed. (Nota quod in environment, timer workflow activities from SPD do not work out of the box. You may have the same trouble. Videte hic pro more details).

I don’t like "magic delay" work-around. What happens if the user uploads a document and the phone rings and the ensuing conversation outlasts the pause? I can make the pause longer, sed adhuc non placet.

Scripsi hoc in forums hic MSDN: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2430725&SiteID=1