ישנם גם פרויקטים שהסתיימו בלו"ז ועמדו בתקציב ואם שואלים את הלקוח אם הפרויקט היה מוצלח, לא תמיד נקבל תשובה חד משמעית, ולעיתים אף מגמגמת…

עמידה בלו"ז, עמידה בתקציב ושמירה מוגדרת של תיחום הפרויקט- אלה הן מטרות משנה שיובילו למטרה העיקרית של השבחת הערך לארגון, אם כי לא המטרות העיקריות של הפרויקט.

לכן יש להכניס ממד נוסף בבחינה של פרויקטים, במדידתם ואף לשלב זאת בשיטת הניהול והיא: "השבחת הערך הארגוני שהפרויקט מספק לארגון", לדוגמא: הגדלת תפוקה,  קיצור זמני תגובה,  מדידה ובקרה, הגדלת הרווח וכדומה.

תפיסה זו מובילה להתמודדויות אחרות ממה שאנו מכירים:

1. יש לבחון כל פרויקט עפ"י השבחת הערך שלו לארגון יחד עם קלות הביצוע.
2. יש למכן תהליך שוטף עבור פרויקטים בביצוע על מנת לבחון את תרומתם להשבחת הערך לארגון, ובפרויקטים שנמצאו כי הערך לארגון אינו משמעותי, יש לקבל החלטה אמיצה ולהפסיק את הפרויקט במהלכו.
3. על פרויקטים שמסתיימים והופכים למערכות המופעלות בשוטף, יש לוודא שהן ממשיכות לספק ערך ארגוני לאורך כל חיי מחזור המערכת, אחרת יש לבחון נחיצותה לארגון.

כתהליך תומך בניהול הפרויקט יש לכלול שיטה של ניהול הידע, ולהתייחס לכך כחלק ממשאבי הפרויקט.

אם לא ננהל משאב זה, הידע לא יישמר, לא יישאר ולא נוכל לעשות בו שימוש מושכל בשום שלב בפרויקט וגם לא לאחר סיום הפרויקט בשלב התחזוקה במחזור חיי המערכת.

אני מכירה פרויקטים גדולים מאוד שהבינו זאת רק בשלבים המאוחרים של הפרויקט ואז היה מאוחר מדי להחזיר את הגלגל לאחור ולשחזר את הידע, כי זה כבר לא אותו הדבר: הידע כבר לא שם, בכל אופן לא כמו שהיינו רוצים לשמר אותו.

לכן, יש להכניס את שיטת ניהול הידע כחלק בשיטת ניהול הפרויקט, כחלק משיטות העבודה של הפרויקט.

הסלפי הוא רק אחד התוצרים של עידן לא סוציאלי –חברתי שקם היום.

האדם במרכז וסביבו השאר: המשפחה, החברים, העבודה, התחביבים וכו'.

כלי הרשתות החבריות לאט לאט הביאו לתפיסה חדשה (ולא בטוח שזו הייתה הכוונה) של ME.

אולי כוונתם הייתה לשפר את הקשרים החברתיים אבל במקום זה הם גרמו לכך שכל אחד שם את העצמו במרכז ואת השאר סביבו.

משניתנה במה ל- ME, הוא עסוק ב"לטפח" סביבו את השאר על מנת להעצים את ה- ME:

כך שהוא רוצה להראות שיש לו הרבה חברים, שהוא עובד בעבודה ראויה, מבוסס עם משפחה לצידו ותחביביו משלימים את התמונה לאושר האידיאלי.

האם באמת ניתן ללמוד על אושרו האמיתי של אדם בצפייה בפרופיל שלו? חשבו על זה, אבל לא על זה רציתי לכתוב.

אנחנו נמצאים בעידן ה- ME, על זה אין ויכוח.

אבל עידן ה- ME, לא רק בא לידי ביטוי בחיינו הפרטיים, אלא גולש גם למקומות העבודה.

אם פעם יכולנו לשכנע עובדים לשתף ידע באמצעות סיסמאות של "ידע הוא נכס ארגוני וצריך לשתף ידע כי זה לטובת הארגון…" היום זה לא ישכנע אף עובד בארגון לשתף ידע.

לארגונים, שמעוניינים לשתף ולשמר ידע, זהו בהחלט אתגר לא פשוט להתמודד עימו.

כי עכשיו יש להתמודד עם האתגר שעונה על השאלה: "איך זה יעזור לי בעבודה שלי?" ולא "איך זה יועיל לארגון?".

עידן הסלפי!

שלכם

אפרת קרמר

כולנו מדברים על "ניהול ידע", אבל תנאי מקדים לנהל את הידע בארגון הוא קודם כל להביא אותו למצב שבכלל נוכל לנהל אותו.

Ready for some changes?

I am starting a new independent blog, which will be my primary work related blog.
It is called “Itay as a Service”, and is available now under: http://blog.itayasaservice.com
The old link will work as well: http://blog.itaysk.com

As for this blog, I will keep posting here summaries of my new posts, in order for subscribed readers to stay in the loop. All the content that was written here will stay here and will not be moved.

Also, I am (finally) joining the twitter community with a new account specifically for my professional interests. 
Follow me on Twitter! @itayasaservice

Itay Shakury.

אתמול בלילה יצאה גרסת Review של SharePoint 2013.

ניתן להתקין את הגרסה על השרת שלכם או לחילופין ליצור חשבון ב Office 365 אשר מכיל את גרסת ה Review עבור SharePoint 2013.

למי שעוד לא יצא לראות את הגרסה החדשה להלן צילום מסך:

אני ממליץ לכולם להתקין ולהתחיל להכיר את הגרסה החדשה או לפחות לפתוח חשבון ניסיון בענן.

אם יש לכם שאלות אתם מוזמנים לשלוח לי דרך הבלוג.

אלכס לויטין

http://www.facebook.com/l.php?u=http%3A%2F%2Ftechnet.microsoft.com%2Fen-US%2Fevalcenter%2Fhh973397.aspx%3Fwt.mc_id%3DTEC_121_1_4&h=_AQHNzVmKAQFf7EXsqi5SwxKpaP4Jwmx4djBjeWfJAuJYdg&enc=AZME6ZzefMZaRpxT_hAf0eBuQWmi9utXmxBQT41irTvsW18iiZiN2qt9NwlkMZa4RcgcYSKY35bPEUcHKORiN8JA

כשיצא Windows Vista אני זוכר שקראתי ציטוט של מישהו ממיקרוסופט, שאמר משהו בסגנון שלמחשבים היום (אז) יש המון כוח עיבוד, (בצורת מעבדים חזקים, כרטיסי מסך משוכללים, וזכרון) והוא לא כל כך בא לידי ביטוי בשימוש יומיומי של גלישה באינטרנט ועריכת מסמכים. ולכן ניצלו את הכוח הזה ליצירת ממשק יותר יפה שנקרא Aero שגם על הדרך נותן תירוץ להשתמש בכל הכוח הזה שלרוב הוא לא מנוצל. Aero של Windows Vista וגם Windows 7 עושה שימוש בהרבה אלמנטים עיצוביים שדורשים כוח עיבוד רב כמו לדוגמא: שקיפות למחצה, אפקטים (לדוגמא, אפקט הזכוכית על חלון), צללים מאחורי חלונות, אנימציות, וכו.

הציטוט הזה היה נכון אולי לעולם של לפני 10 שנים, אבל למי שפספס, אנחנו בעיצומו (או אולי רק בתחילתו) של עידן חדש, והמגמה היא בדיוק הפוכה ממה שהציטוט מציג. המחשבים היום (אולי לא מדוייק לקרוא להם מחשבים, מדובר על טלפונים, טאבלטים וכו… נקרא להם התקנים – Devices), הם דווקא חלשים יותר ממה שהתרגלנו אליו בעבר. כלומר, אנחנו רוצים התקנים יותר ניידים ויותר קלים ויותר דקים, וזה עולה בביצועים, ולכן היום אנו דורשים מתכנה שתרוץ דווקא על התקנים חלשים יותר מבעבר. זה התחיל עם הנטבוקים, ועכשיו ממשיך עם הטאבלטים.

אני לא יודע אם זה היה רעיון גאוני מכוון של מישהו במיקרוסופט, או שזה באמת במקרה, אבל מטרו, השפה העיצובית החדשה של מיקרוספט היא בדיוק מה שעולם התכנה של מיקרוספט היה צריך כדי לבצע את המעבר הזה.

מסך הפתיחה של Windows 8 (דוגמא לממשק מטרו)

ננסה לפרט את העקרונות שמגדירים את מטרו:
ממשק פשוט, נקי ומינימליסטי, שימוש בטיפוגרפיה (טקסט בעיקר) כאמצעי ניווט שולט, בנוסף, הוא מתאפיין בצבעים אחידים ופשוטים, וצורות מרובעות.

מסך הפתיחה של Windows Phone 7.5 (דוגמא לממשק מטרו)

אני אישית מאוד אוהב את השפה העיצובית הזאת וחושב שהיא מאוד אסתטית ויפה. אבל האם זה כל מה שעומד מאחורי המניע לשינוי הדרמטי הזה?

אם מסתכלים על המאפיינים של מטרו שתיארתי מקודם, קל לשים לב שהעקרונות מכתיבים ממשקים מאוד פשוטים, לא רק פשוטים למשתמש, אך גם פשוטים למחשב.
מבחינה עיבודית, כשמכונה כמו מחשב צריכה לצייר (to Render) מסך של מטרו, זה הרבה יותר פשוט מאשר מסך כמו של Android לדוגמא, או אפילו Windows 7.
עכשיו קחו את מה שאמרתי, ותוסיפו לזה את המגמה האדירה של עולם התכנה לכיוון אפליקציות מבוססות דפדפן, שגם הפכה למיינסטרים ב Windows 8, ותבינו איך הגעתי לחשוב על הקונפירציה הזו – אם אני רוצה לצייר בדפדפן באמצעות HTML\JS\CSS מסך של מטרו, זה הרבה הרבה הרבה יותר פשוט מלצייר לדוגמא מסך של אנדרואיד, או של מק. זו עבודה פשוטה מאוד, גם לדפדפן וגם למתכנת.

מסך הפתיחה של Android with HTC Sense (דוגמא לממשק שאינו מטרו)

בואו נסתכל העקרונות שתיארנו מקודם, ונראה איך הם עוזרים לא רק לאסתטיקה, אלא גם לביצועים:

• ממשק פשוט, מינימליסטי, נקי – מבחינת המחשב זה פשוט מאוד. כמה שפחות דברים שהוא צריך לצייר למסך, הוא יעשה את זה יותר מהר. אם אנחנו אומרים שאנחנו רוצים מסכים פחות עמוסים בפקדים, זה אומר שהמסך ירוץ יותר מהר.
• צבעים אחידים – בשביל מחשב לצבוע ריבוע בצבע כחול, זה הרבה יותר קל מלצבוע אותו בצבע מדורג (Gradiant) שהופל מכתום לכחול. אם מסתכלים עם דפדפנים זה אפילו יותר בולט, כשצביעה בצבע אחיד היא פעולה טריוואלית, בעוד שצבע מדורג היא פעולה לא פשוטה בכלל. אם נתחיל להשוות לאפקטים למיניהם כמו שקיפות למחצה, או אפקט הזכוכית, כאן זה כבר הבדל עצום בביצועים, וכשמדברים על דפדפן זה גם קשה למימוש עד בלתי אפשרי (תלוי באפקט).
• ריבועים – צורות מלבניות למיניהן, הן יחידת ציוד די בסיסית למחשב. זאת לעומת צורות מורכבות יותר כמו לדוגמא, צורה של טיפה (סתם דוגמא). זה נובע מהמתמטיקה שמאחורי הצורה, אבל בשורה התחתונה, המחשב יצייר ריבועים הרבה יותר טוב מאשר טיפות, או לדוגמא ריבועים עם פינות מעוגלות (שרואים הרבה לדוגמא באייפון). אם נדבר על דפדפנים אז כאן ריבועים זה אבני היסוד של דפים. לצייר טיפה בדפדפן זו עבודה לא פשוטה בכלל וצורכת הרבה יותר משאבים מציור מלבן שפחות או יותר מסתכם בשורה אחת המייצרת Div עם Border ו Background-Color.
• טיפוגרפיה – קחו לדוגמא את ממשק הפנורמה של Windows Phone 7. הוא מורכב רובו ככולו מטקסטים בלבד. אין אייקונים או סמלים מיוחדים, או תמונות או צורות אחרות. כמעט הכל שם זה טקסט. כתיבת טקסט היא גם אחת הפעולות הבסיסיות של המחשב ושל כל תשתית UI. אין צורך בכלי ציור מתוחכמים כדי לכתוב טקסט למסך. במיוחד כשמדובר על דפדפנים שבמקור נבנו עבור המטרה היחידה של הצגת טקסט, ולכן עושים זאת בקלות רבה מאוד.
• ממשק ללא תמונות – זו אינה עיקרון ישיר של ממשק מטרו, אבל אם תשימו לב, לרוב באפליקציות מטרו אין תמונות אשר משמשות לבניית הממשק. אני לא מדבר על תמונות שהן חלק מהתוכן כמו לדוגמא תמונה של תל אביב בכתבה שמדברת על תל אביב. אני מדבר על תמונות שבונות את הממשק, כמו לדוגמא אייקונים למיניהם, תמונות רקע, חלקים מהתפריט, וכולי. לצייר תמונה על המסך זו לא עבודה קשה למחשב, אבל בטוח שיותר קשה מלצייר קו, או ריבוע. בנוסף, מעבר ליתרון בביצועים, עם תמונות קשה להתעסק. כדי שיראו טוב צריך שיהיו ברזולוציה גבוהה, וזה אומר נפח גדול. צריך לדאוג לשמור על פרופורציות. לפעמים צריך לספק כמה גדלים לאותה תמונה עבור שימושים שונים, ואי אפשר להגדיל או להקטין אותן בקלות תוך שמירה על המראה המקורי.

בואו נראה את ההבדלים בפועל:

זהו מסך ההגדרות של אייפון. ציינתי על התמונה אלמנטים ש”מכבידים” על הממשק מבחינת ביצועים:

לעומת ממשק ההגדרות של Windows Phone:

זו לא תחרות מי יותר יפה. רק שימו לב להבדלים מנקודת מבט תכנותית.

דוגמא נוספת:

שולחן העבודה של Windows Vista:

(האמת שיש כאן המון אפקטים קטנים, אבל רק הדגשתי את הבולטים מביניהם.)

לעומת שולחן העבודה של Windows 8:

הנה ציטוט מהבלוג של צוות הפיתוח של וינדוס 8, שמראה מה השתנה בעיצוב:

“To complete the story, we updated the appearance of most common controls, such as buttons, check boxes, sliders, and the Ribbon. We squared off the rounded edges, cleaned away gradients, and flattened the control backgrounds”

הדוגמאות האלו נועדו להמחיש את הנקודה שלי – שממשקי מטרו הם פשוטים יותר לתצוגה על ידי המחשב, ולכן באופן טבעי יציגו ביצועים טובים יותר מעיצובים “עמוסים” אחרים.

פעם הראיתי לחבר שלי כמה מהיר הממשק של Windows Phone 7, והוא ענה בזלזול "בטח שיהיה יותר מהיר, יש לך רק 2 צבעים במסך וכמה ריבועים וטקסט". צודק, אולי כאן טמון הסוד?

If any of you have a permit to work in the U.S, the following might interest you.
I have a friend who owns an IT staffing agency in California and he is constantly looking for
Developers, Engineers and IT people who would like to work for young start-up companies
over there (mainly in Silicon Valley). If you're interested, let me know and I can pass on your CV.

Cheers,

Yuval

הערה: למי שהיה בהרצאה שלי בכנס SharePoint Extreme האחרון, מדובר על אותה הרצאה.

The common belief is that BCS is the new version of BDC, and that in the new version the name was changed from BDC to BCS. According to this, there is no reason to use the term BDC in the context of SharePoint 2010.
This is not exactly correct.
BDC was and still the infrastructure that allows SharePoint to connect to other systems. It has the concept of metadata and descriptors, and is still present in 2010 under the name “Business Data Connectivity”. BCS is based on BDC and is what makes all the advanced connectivity scenarios possible (such as integration with Office, ECT,…).

In the bottom-line, the terms BDC and BCS is used interchangeably, so you should too. But you don’t have to be angry if you see BDC in the same sentence with SharePoint 2010

Here are some supporting quotes from MSDN:

“Business Data Connectivity (BDC) service is the new version of the Business Data Catalog that was provided in Microsoft Office SharePoint Server 2007”
http://msdn.microsoft.com/en-us/library/ee556407.aspx

“Business Data Connectivity (BDC) service succeeds the Business Data Catalog that was provided in Microsoft Office SharePoint Server 2007”
http://msdn.microsoft.com/en-us/library/ee558876.aspx

“BDC is the foundation of Business Connectivity Services”
http://msdn.microsoft.com/en-us/library/ee559650.aspx

“Business Data Connectivity (BDC) service in Microsoft Business Connectivity Services (BCS) is the underlying framework in the Microsoft SharePoint Foundation 2010 platform on which Business Connectivity Services is built”
http://msdn.microsoft.com/en-us/library/ee557963.aspx

Consider the following scenario:

You have an object model like this:

   1: public class Car

   2: {

   3:     public string Model { get; set; }

   4:     public int Year { get; set; }

   5:     public IEngine Engine { get; set; }

   6: }

   7:  

   8: public interface IEngine

   9: {

  10:     void Work();

  11: }

  12:  

  13: public class ElectricEngine : IEngine

  14: {

  15:     int batteryPrecentageLeft;

  16:     public int BatteryPrecentageLeft

  17:     {

  18:         get { return this.batteryPrecentageLeft; }

  19:         set { this.batteryPrecentageLeft = value; }

  20:     }

  21:  

  22:     void IEngine.Work() { }

  23: }

  24:  

  25: public class InternalCombustionEngine : IEngine

  26: {

  27:     int gasLitersLeft;

  28:     public int GasLitersLeft

  29:     {

  30:         get { return this.gasLitersLeft; }

  31:         set { this.gasLitersLeft = value; }

  32:     }

  33:  

  34:     void IEngine.Work() { }

  35: }

And you use it like so:

   1: Car myCar = new Car();

   2: myCar.Model = "Ford Focus";

   3: myCar.Year = 2011;

   4: myCar.Engine = new ElectricEngine() { BatteryPrecentageLeft = 70 };

   5:  

   6: myCar.Engine.Work();

If you would try to serialize myCar using the regular XmlSerializer, you will get the error above.

There are many reasons why you shouldn’t want to serialize an interface typed member. I will not dive into this debate right now. I assume that you have considered this before, and are just looking for a workaround.

So first lets understand what we are trying to achieve.

In the example above, I expect the serialized output of myCar to be something like this:

   1: <Car xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

   2:   <Model>Ford Focus</Model>

   3:   <Year>2011</Year>

   4:   <Engine>

   5:     <ElectricEngine FullAssemblyQualifiedTypeName="Common.ElectricEngine, Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">

   6:       <BatteryPrecentageLeft>70</BatteryPrecentageLeft>

   7:     </ElectricEngine>

   8:   </Engine>

   9: </Car>

I have asked a question on StackOverflow, and Jens Granlund has pointed me in the right direction.

The workaround that I have implemented consists of the following steps:

1. Mark all interface typed members with the XmlIgnoreAttribute, that tells the XmlSerializer to not serialize those members.
2. Now serialize the class to produce an output similar to the one above, but without the problematic members.
3. For-each member marked with the attribute, get it’s current value, and that value’s type. That can only be done in runtime.
4. Use that type to create a standard XmlSerializer, and use that serializer to serialize that value.
5. Inject those serialized values to the parent class’s serialized xml.
6. In order to allow regular use of the XmlIgnoreAttribute, implement a new attribute that act like it.
7. During deserialization perform the same process in reverse.

I have followed that basic recipe to create my own “RuntimeXmlSerializer”. You use it the same way you would use the standard XmlSerializer.

   1: public class RuntimeXmlSerializerAttribute : XmlIgnoreAttribute { }

   2:  

   3: public class RuntimeXmlSerializer

   4: {

   5:     private Type m_type;

   6:     private XmlSerializer m_regularXmlSerializer;

   7:  

   8:     private const string k_FullClassNameAttributeName = "FullAssemblyQualifiedTypeName";

   9:  

  10:     public RuntimeXmlSerializer(Type i_subjectType)

  11:     {

  12:         this.m_type = i_subjectType;

  13:         this.m_regularXmlSerializer = new XmlSerializer(this.m_type);

  14:     }

  15:  

  16:     public void Serialize(object i_objectToSerialize, Stream i_streamToSerializeTo)

  17:     {

  18:         StringWriter sw = new StringWriter();

  19:         this.m_regularXmlSerializer.Serialize(sw, i_objectToSerialize);

  20:         XDocument objectXml = XDocument.Parse(sw.ToString());

  21:         sw.Dispose();

  22:         SerializeExtra(i_objectToSerialize,objectXml);

  23:         string res = objectXml.ToString();

  24:         byte[] bytesToWrite = Encoding.UTF8.GetBytes(res);

  25:         i_streamToSerializeTo.Write(bytesToWrite, 0, bytesToWrite.Length);

  26:     }

  27:  

  28:     public object Deserialize(Stream i_streamToSerializeFrom)

  29:     {

  30:         string xmlContents = new StreamReader(i_streamToSerializeFrom).ReadToEnd();

  31:         StringReader sr;

  32:         sr = new StringReader(xmlContents);

  33:         object res = this.m_regularXmlSerializer.Deserialize(sr);

  34:         sr.Dispose();

  35:         sr = new StringReader(xmlContents);

  36:         XDocument doc = XDocument.Load(sr);

  37:         sr.Dispose();

  38:         deserializeExtra(res, doc);

  39:         return res;

  40:     }

  41:  

  42:     private void deserializeExtra(object i_desirializedObject, XDocument i_xmlToDeserializeFrom)

  43:     {

  44:         IEnumerable propertiesToDeserialize = i_desirializedObject.GetType()

  45:             .GetProperties().Where(p => p.GetCustomAttributes(true)

  46:                 .FirstOrDefault(a => a.GetType() ==

  47:                     typeof(RuntimeXmlSerializerAttribute)) != null);

  48:         foreach (PropertyInfo prop in propertiesToDeserialize)

  49:         {

  50:             XElement propertyXml = i_xmlToDeserializeFrom.Descendants().FirstOrDefault(e =>

  51:                 e.Name == prop.Name);

  52:             if (propertyXml == null) continue;

  53:             XElement propertyValueXml = propertyXml.Descendants().FirstOrDefault();

  54:             Type type = Type.GetType(propertyValueXml.Attribute(k_FullClassNameAttributeName).Value.ToString());

  55:             XmlSerializer srl = new XmlSerializer(type);

  56:             object deserializedObject = srl.Deserialize(propertyValueXml.CreateReader());

  57:             prop.SetValue(i_desirializedObject, deserializedObject, null);

  58:         }

  59:     }

  60:  

  61:     private void SerializeExtra(object objectToSerialize, XDocument xmlToSerializeTo)

  62:     {

  63:         IEnumerable propertiesToSerialize =

  64:             objectToSerialize.GetType().GetProperties().Where(p =>

  65:                 p.GetCustomAttributes(true).FirstOrDefault(a =>

  66:                     a.GetType() == typeof(RuntimeXmlSerializerAttribute)) != null);

  67:         foreach (PropertyInfo prop in propertiesToSerialize)

  68:         {

  69:             XElement serializedProperty = new XElement(prop.Name);

  70:             serializedProperty.AddFirst(serializeObjectAtRuntime(prop.GetValue(objectToSerialize, null)));

  71:             xmlToSerializeTo.Descendants().First().Add(serializedProperty); //TODO

  72:         }

  73:     }

  74:  

  75:     private XElement serializeObjectAtRuntime(object i_objectToSerialize)

  76:     {

  77:         Type t = i_objectToSerialize.GetType();

  78:         XmlSerializer srl = new XmlSerializer(t);

  79:         StringWriter sw = new StringWriter();

  80:         srl.Serialize(sw, i_objectToSerialize);

  81:         XElement res = XElement.Parse(sw.ToString());

  82:         sw.Dispose();

  83:         XAttribute fullClassNameAttribute = new XAttribute(k_FullClassNameAttributeName, t.AssemblyQualifiedName);

  84:         res.Add(fullClassNameAttribute);

  85:  

  86:         return res;

  87:     }

  88: }

Notice that this solution doesn’t handle situations in which the interface typed member is not a direct descendent of the type being serialized. In example if Car has a member of type List<IWheel> or if Car has a member of type Dashboard which has a member f type IGauge, than serialization will fail.

This can be solved by recursively performing the “Runtime” serialization on all members, until we reach a primitive member which we can serialize using the regular serializer.

You can find the Visual Studio project in this link:

http://blogs.microsoft.co.il/files/folders/1078707/download.aspx

First is the "Enterprise Wiki" site template. It's a template that can be used to create site collections, or sub-sites. The Enterprise Wiki site template creates a site that is dedicated to wiki content. The main component in the site is the "Pages" Library. We will explorer it later.

Second is the "Wiki Page Library" list template. This Wiki Library can host wiki pages. It can be created in any kind of site.
As a matter of fact, this Wiki Library list template is used as the default pages library in the "Team Site" site template.

According to this article on MSDN, here is a short comparison between the two:

These are nice guidelines, but what is the real difference of each?
I am now going to go through the detailed process that I took for investigating the case. You can skip to the end if you want the summary.

Wiki Page Library

The template is part of the feature called "WebPageLibrary". In this feature, you can find the list definition at: "14\TEMPLATES\FEATURES\WebPageLibrary\ListTemlpates\WebPageLibrary.xml".
If you look at it, you'll notice that the list template id is 119, and BaseType="1", which means it is a regular document library.

If we take a look at the schema.xml file at "14\TEMPLATES\FEATURES\WebPageLibrary\WebPageLib\schema.xml", we will see that the template associates a content type with ID 0x010108 to the library. This content type is called "WikiDocument", and is defined in: "14\TEMPLATES\FEATURES\ctypes\ctypeswss.xml". It inherits from the base "Document" content type, does 2 things: Add the "WikiField", and remove the "Title" field.
The "WikiField" field is what holds the content of the page.

Enterpries Wiki

This is an entierly different beast. First of all, it's a site definition. You will find the "Enterprise Wiki" site definition at 14\TEMPLATE\1033\XML\webtempsps.xml. Let's take a closer look at it.
The site definition onet.xml file is at: 14\TEMPLATE\SiteTemplates\ENTERWIKI\XML\onet.xml. In here, we can see that this is actually a publishing site (publishing features, such as "Publishing 22A9EF51-737B-4ff2-9346-694633FE4416" are activated).

In addition to the standatd pablishing features, there's an additional feature with id "76D688AD-C16E-4cec-9B71-7B7F0D79B9CD". This is the EnterpriseWiki feature, you can find it's source at: 14\TEMPALTE\FEATURES\EnterpriseWiki.

If you take a look at EnterpriseWikiContentTypeBinding.xml, you will see that the feature takes the default pages library that is created with the publishing infrastructure, and binds to it 2 content types. One is the standard Redirect Page content type, and the other is the Enterprise Wiki content type.
The Enterprise Wiki content type is defined at: 14\TEMPALTE\FEATURES\EnterpriseWikiContentTypes, and defines the following fields: ModifiedBy, PublishingPageContent, Rating, RatingCount.

If we take a look at the page layout at: 14\TEMPALTE\FEATURES\EnterpriseWikiLayouts\PageLayouts\EnterpriseWiki.aspx, we will see that the field that holds the content of the page is "PublishingPageContent". This field is just like the "WikiField" field that we discussed earlier.

Rendering

Handling wiki style markup is integrated into SharePoint foundation. From what I have found, it seems that the translation from wiki syntax to html is done in the field level (not UI control). The class "SPFieldMultilineText" has a property called "WikiLinking" (boolean), that toggles the feature on or off.
For publishing pages, the "HtmlField" inherits indirectly from SPFieldMultilineText, so it supports this too.

You can use this feature with regular publishing pages as well (not nessicarely wiki page layouts).
If you look at the source of a publishing page you will see a line similar to this: document.getElementById('ctl00_PlaceHolderMain_PageContent_RichHtmlField_displayContent').WikiLinking = 'on';
This controls whether or not the wiki syntax translation is active.

Summary

SharePoint has different 2 solutions for wiki style editing:

1. Wiki Library – a web pages library that uses the "Wiki Document" content type. This content type has a field called "WikiField" to hold the wiki content.

2. Enterprise Wiki – a site definition that is based on the publishing infrustructure. As such, it is based on the built in "Pages" library. It uses a content type called "Enterprise Wiki", in which the field "PublishingPageContent" is used to hold wiki content.

This knowledge can be helpful if you are developing solutions that are usign the wiki features programmatically.

– My name is Itay Shakury, and I'm a SharePoint consultant –