איך נוצן אַ קאַלענדאַר צו שפּור טאַפליע דיסקוסיעס אויף אַ געגעבן טאָג. איך האָבן צוויי סעשאַנז: מאָרגן און נאָכמיטאָג. איך ווילן צו מאַכן אַ מיינונג וואָס ווייזט מאָרגן סעשאַנז בלויז ליסטעד אַלפאַבעטיקלי דורך אַ סעסיע שייַן. דאָס איז אַ ביסל טריקי צו ויספירן (סייַדן איך מיסט עפּעס עמעס קלאָר ווי דער טאָג).

איך קענען לייכט מאַכן אַ געפילטערט מיינונג וואָס נאָר ווייַזן די געשעענישן פון דעם טאָג. די קאַלענדאַר וועט ווייַזן אַלע די געשעענישן און אויב זיי אַלע פאַלן אין דער זעלביקער שעה, עס ליסטעד זיי זייַט ביי זייַט אין די שעה שפּעלטל. דאס איז געוואלדיג. די טריקי טייל איז אַז, דורכ פעליקייַט, עס וויל צו רשימה זיי אין שייַן פֿאָרמאַט. אַזוי, if I add "Session 02" and then "Session 01" צו די לוח, עס ווייזט זיי אין אַז סדר (י.ע, סעסיע 02 און דעמאָלט סעשאַן 01). צו רשימה זיי אין סעסיע שייַן סדר, איך געדאַנק צו פּרובירן די זאכן:

1. קאַנפיגיער די מיינונג מיט די וועב באַניצער צובינד. קיין גליק. עס זענען קיין אָפּציעס צו סאָרט זאכן אויף דעם וועג.

   זינט וואָס האט ניט אַרבעטן, I am now hoping there’s a CAML query somewhere in there that will allow me to override the sort. CQWP lets me make that kind of change, אפֿשר לוח וועט ווי געזונט?

2. רעדאַגירן די וועב טייל, look for an "export" פונקציאָנירן און … בזזז! I can’t export its XML. There is no export option.

   I’m still holding out hope that I can find and modify some CAML query. Since I can’t export the web part, אַז בלעטער שאַרעפּאָינט דיזיינער.

3. I add the calendar web part to a sandbox site and open that site using SharePoint Designer. I look at the markup for the web part and I find what I’m looking for. It’s encoded madness, אָבער עס ס דאָרט: "<ליסטוויעווקסמל …. >ענקאָודיד מאַדנעסס</ליסטוויעווקסמל>". ספּעסיפיקאַללי, דאָרט ס דעם יידלשטיין:

<אָנפֿרעג>
<ווו>
<דאַטעראַנגעסאָווערלאַפּ>
<FieldRef Name="EventDate"/>
<FieldRef Name="EndDate"/>
<FieldRef Name="RecurrenceID"/>
<Value Type="DateTime">
<חודש />
</ווערט>
</דאַטעראַנגעסאָווערלאַפּ>
</ווו>
<אָרדערבי><FieldRef Name="Session_x0020_ID" /></אָרדערבי>
</אָנפֿרעג>

(איך ווע דיקאָודאַד די &לט;'ס און &גט ס און שפּאַלטן זיי אויס צו קייפל שורות פֿאַר קלעריטי ס צוליב).

לייג די <אָרדערבי> ביסל און איצט עס סאָרץ דורך סעשאַן שייַן, נישט די ינערלעך רשימה נומער שייַן.

דזשייגאַניק שפּיץ אָדער’ די הוט צו בעקי יססערמאַן פֿאַר איר באַמערקונג צו ישאַ סאַגי ס בלאָג פּאָסטן: http://www.sharepoint-tips.com/2008/07/caml-sorting-by-file-name.html. I wouldn’t have put the <אָרדערבי> אין די רעכט אָרט אָן איר באַמערקונג.

איך האָפֿן צו שרייַבן דעם אַרויף מער קלאר מיט פאַרשטעלן שאַץ באַלד, אָבער אין פאַל איך קיינמאָל טאָן, לפּחות איך האט דאָס פיל.

</עק>

מיר קאַלעקטיוולי פאַרברענגען אַ גרויס געשעפט פון מאָל טראכטן וועגן שאַרעפּאָינט סאַלושאַנז — ווי צו שאַפֿן זיי, וואָס געצייַג צו נוצן, וואָס כאַפּאַנז ווען זיי פאַרפעלן צו צעוויקלען, טייַמער דזשאָבס, סקאָפּעס, אאז"ו ו. We spend so much time thinking about the up-front bits that it’s easy to forget that we need to retract them as well. Retracting solutions is probably more difficult, פון אַ קאַנסעפּטשואַל פּלאַן פּערספּעקטיוו, than deploying them. Deployment is basically a cookbook affair. Typically, ינסטאַלירן אַ שטריך, אפֿשר האָבן אַ שטריך ופנעמער מאַסע עטלעכע דאַטן אין אַ רשימה, that sort of thing. אָבער, ריטראַקטינג איז פּאַטענטשאַלי מער קאָמפּליצירט.

א געגעבן לייזונג זאל מאַכן אַרטאַפאַקץ ווי די:

• אינהאַלט טיפּ
• רשימה דעפיניטיאָן
• פּלאַץ דעפיניטיאָן
• דאַטע אין אַ רשימה
• אפילו ראַסיווערז
• ינפאָפּאַטה פארמען

די רשימה גייט אויף.

בשעת עס ס 'דאָך וויכטיק צו פּלאַן אַ לייזונג אַז ינסטאַנשיייץ יענע אַרטאַפאַקץ ריכטיק, it’s just as important to consider the update and delete cases. If your solution creates a new list and populates that list with data, וואָס כאַפּאַנז ווען די לייזונג איז ריטראַקטאַד? In some cases, the list should be deleted. In other cases, it should be left intact for historical purposes. Your business requirements will guide you to the right decision.

צו העלפן מיט דעם, create a matrix that lists each artifact your solution deploys to SharePoint. List three columns per artifact, איינער פֿאַר שאַפֿן, דערהייַנטיקן און ויסמעקן. For each case, באַשטימען די ריכטיק אַוטקאַם פֿאַר אַז אָפּעראַציע.

This sort of analysis is obviously best done before the solution is ever deployed to a SharePoint farm. אָבער, ווי סמאָוקינג, it’s never too late to start doing things correctly. Create that matrix and develop a plan to address the missing update/delete scenarios. It may be a hard problem to solve, אָבער לפּחות איר וועט האָבן שטעלן אַ קעסטל אַרום דעם פּראָבלעם.

</עק>

אַבאָנירן צו מיין בלאָג.

גיי מיר אויף טוויטטער בייַ http://www.twitter.com/pagalvin