אף פעם לא חיבבתי את XML.
העבודה עם השפה עצמה מסורבלת, קל מאוד לטעות ולדפוק קובץ שלם ויש יותר מדי תווים מיותרים שלא תורמים כלום לתוכן האמיתי.
אפילו השם מגעיל: איכס אמ אל.
יש נטייה להשתמש בXML כשפה לקבצי קונפיגורציה. אפשר לראות את זה בהמון פרוייקטים (למשל Tomcat ו Pidgin).
XML כשפה מנסה לפתור כל מני בעיות שלא מעניינות במיוחד את רוב המפתחים, ולכן המימוש של קוראי XML תקניים הוא מורכב.
הדבר במעצבן ביותר בXML היא שהיא קשה גם לאנשים שמנסים לקרוא אותה (או לשנות אותה), וגם למחשבים – או יותר נכון למפתחים – שמנסים לקרוא אותה.
ניקח לדוגמא את פיסת הXML הבאה (קוד אמיתי מההגדרות של טומקט):
[code lang="xml"]
[/code]
הרבה מלל כדי להגיד שיש דבר כזה UserDatabase, ויש בתוכו שני זוגות Key-value, לא?
אפשר גם לציין את אותו מידע כך:
[code lang="java"]
ResourceParams{
UserDatabase{
factory : org.apache.catalina.users.MemoryUserDatabaseFactory
pathname : conf/tomcat-users.xml
}
}
[/code]
יותר קומפקטי ופחות פלצני.
השפה שבה השתמשתי בפעם השניה היא Swush, שפה שהגדרתי ומימשתי בסופ"ש.
Swush (סוו'ש בעברית, נראה לי שאני אדבוק באנגלית), תומכת בהערות בסגנון C/C++ וbash:
[code]
// C++ single line comment
/* C multi-
line comment*/
# Bash style comments
[/code]
בנוסף, סטרינגים בSwush לא מחייבים גרשיים, אבל אם משתמשים בגרשיים אפשר להגדיר סטרינגים עם רווחים ואפילו שורה-חדשה בתוכם.
[code]
string1
"another string"
"multi
line
string"
[/code]
המימוש שלי לSwush הוא בשפת ג'אווה, אבל בהחלט אפשרי שיהיו מימושים בשפות נוספות (בין אם שלי או של אנשים אחרים).
Swush תומך ברשימה פשוטה של מפתח-ערך, למשל:
[code lang="java"]
host : "locahost"
port : 8080
[/code]
ככה שאפשר בקלות רבה להחליף אותו קבצי properties של ג'אווה.
מבחינת הקוד, השתדלתי שהוא יהיה מה שיותר פשו לשימוש.
אפשר ליצור אובייקט Swush בכמה צורות:
[code lang="java"]
Swush fromFile = new Swush(new File(filename));
Swush fromString = Swush.constructFromString("swush:rocks","UTF-8");
Swush usingCode = new Swush();
usingCode.add(new Swush("key","value"));
usingCode.add(new Swush("node"));
usingCode.getChildren(1).add(new Swush("key2", "value2"));
[/code]
אחת הפונקציות המעניינות של המימוש שלי היא פונקציית select, שמחזירה רשימה של צמתים שמתאימים לקריטריות שצויין, לדוגמא – אם יש לנו קובץ Swush כזה:
[code lang="java"]
addressbook
{
max_size : 30
item
{
phone : 123
name : "The dude"
address : "Multi
Line address"
}
item
{
phone : 3454
name : "Another dude"
address : unknown
}
}
[/code]
ואנחנו רוצים לגשת לצמתים של הItem, נוכל לעשות משהו כזה:
[code lang="java"]
Swush swush = new Swush(new File(filename));
List
[/code]
הרשימה שחוזרת תכיל את שני הצמתים המתאימים (מסוג item שנמצאים בתוך addressbook).
Swush ממומשת עם Antlr, וההגדרה שלה מאוד פשוטה, אפשר להעביר אותה בכמה דיאגרמות:
Swush משוחררת ברשיון BSD, ואפשר להוריד אותה מפה.
נראה לי שאתה די קרוב להמצאה מחדש של YAML
http://yaml.org
יש עוד כמה פורמטים דומים למיטב זכרוני, אולם אני לא זוכר כרגע את שמו של אף אחד אחר.
במבט ראשון גם די מזכיר JSON
מה רע באמת ב-JSON או בYAML ?
כן, אכן די דומה לYAML.
אם כי יותר פשוט, ולראיה – אני לא צריך תיעוד באורך הגלות: http://yaml.org/spec/1.2/
לגבי JSON, הוא יותר מותאם למכונות מאשר לאנשים.
לא אידיאלי לקבצי קונפיגורציה, יותר מדי פסיקים וגרשיים מיותרים.
להוכיח בעזרת קובץ עם שתי פרופרטיס שXML זה overkill מקביל לטענה שלא צריך D9 כדי לחפור בור לעץ; אתה צודק אבל מפספס את הנקודה.
משפט די סתום.
1. לא הוכחתי, טענתי.
2. נתתי יותר מדוגמא אחת, ורובן יותר מורכבות משני פרופרטיז.
3. אם אני צודק, מה בדיוק הנקודה שלך?
YAML פשוט מאוד בבסיסו. המפרט המדוייק רק מראה שאנשים באמת משתמשים בו גם לצרכים מורכבים ויתר.
ר' גם http://search.cpan.org/dist/YAML-Tiny/lib/YAML/Tiny.pm
אתה לא חייב את כל הכוח של YAML אם אתה לא ממש צריך.
אני לא מכיר את YAML וזה נורא חבל כי הדוקמנטציה של XML הרבה יותר קצרה משלו
לדעתי היתרון הוא לא במבנה הקובץ. אלה כמה באמת קל לך להתעסק עם הנתונים לאחר מכן.
ולמתכנתי ג'אווה במתעסקים ב XML.. כן זה כואב.
במקום לרוץ על רשימת ערכים ולפלטר את התג הפותח של ה XML . למההה…
פשוט מבקש בSELECT פשוט ומקבל את התוצאה.
נראה מבטיח
תודה .
דוגמה לקובץ YAML:
http://cpansearch.perl.org/src/ADAMK/YAML-Tiny-1.36/META.yml
לכל מודול פרל ב־CPAN יש קובץ YAML שמתאר אותו.
המצאת את הגלגל בהצלחה
כמו שכתבו לפני, YAML כבר נותן פתרון מעולה (גם אם התיעוד שלו ארוך) ויש פתרונות פשוטים יותר לקונפיגורציה כמו ini.
http://en.wikipedia.org/wiki/INI_file
http://en.wikipedia.org/wiki/YAML
YAML דומה, אבל אני לא אוהב את התחביר שלו.
INI שקול פחות או יותר לרשימת מפתח-ערך, זה חלש מדי להרבה שימושים.
דבר ראשון, כל מה שאתה אומר על XML נכון.
דבר שני JSON הוא מימוש של YAML רק עם פחות אפשרויות בתחביר.
כמו שאמרו, הרעיון של YAML עושה בדיוק מה שאתה צריך.
במידה ואתה רוצה, אתה יכול גם ליישם את הרעיון של APACHE אם הוא מתאים (בקשר לקבצי הגדרות)
עמרי,
קודם כל, מרשים.
אני מכיר XML מעט, ולא כל כך מכיר את החסרונות שאתה מתייחס אליהם, אבל אני בהחלט רואה שהשיטה (שפה) שאתה מתאר פשוטה יותר בדוגמאות שהבאת וכנראה גם מעבר לזה. לא ברור לי, אם XML כל כך בעייתי, למה עושים בו שימוש אינטנסיבי עבור קונפיגורציה. אחרי הכל, אם יש שפה חדשה כמו שלך ושפות דומות, ובוודאי דומות שאפשר היה לפתח שהן פשוטות יחסית, לא נראה לי שמחסור במימוש הוא הבעיה. כלומר, לא נראה לי שמתמשים ב- XML רק כי "זה מה יש" ושקיימים עבור פרסרים בכל שפה וסביבה.
דבר נוסף שאני חושב שכדאי לך לעשות: הצג את השפה (מבחינת התחביר) ואת השימוש בה (ב- Java במקרה שלך) באיזה שהוא פורום מתאים ורחב יותר (פורום של XML?) ותראה שם מה התגובות. מה שחשוב זה תחביר השפה והשימוש כמובן, ולא המימוש.
דרך אגב, בעיני, שלא מבין כלום ב- Java, זה מרשים מאוד שהצלחת לכתוב מימוש בסוף שבוע אחד. מעניין כמה מסובך לכתוב מימוש ב- Perl או ב- Python.
IK5, אולי התכוונת שJSON הוא מימוש של ג'אווהסקריפט עם פחות אפשריות תחביר.
עוד מישהו רוצה לספר לי על YAML?
יונתן:
כולם משתמשים בXML לקונפיגורציה בגלל ש.. כולם משתמשים בXML לקונפיגורציה.
כשמתכנת מתחיל רואה שהוא מקנפג כל מני דברים עם XML הוא ילך אחר כך ויכניס XML לפרוייקט שלו כקובץ קונפיגורציה.
סתם כי זו הדוגמא שהוא ראה.
לגבי הזמן שזה לקח:
הכל עניין של שימוש בכלים הנכונים.
במקרה הזה השתמשתי בANTLR כדי לייצר את הפרסר הבסיסי בזמן הפרוטוטייפינג של השפה.
למעשה קניתי את הספר של אנטלר בסופ"ש, ואני באמצע קריאה שלו.
אולי אני אכתוב איזה פוסט מתישהו שמדגים איך עובדים עם אנטלר.
עמרי, ההסבר שלך לכך שכולם משתמשים ב- XML כי כבר מכירים את זה/כולם משתמשים בזה קצת בעייתי לדעתי, גם אם אין לי דרך לסתור אותו. אבל מה דעתך על ההצעה שלי? אם תפרסם את ההצעה שלך בפורום המתאים, תוכל לקבל תגובות מחכימות יותר. מה שכן, באמת שווה לך לקרוא על YAML לפני זה כי בטח גם שם יתייחסו אליו.
לגבי ANTLR: זה בהחלט יכול להיות מעניין. ויפה. אתה מיישם מהר את מה שאתה לומד 🙂
לא ברורה לי ההתייחסות שלך לסיום שורה. סיום שורה קוטע ערכים?
שים לב לבדל שיש כאן בין YAML לבין JSON ו־XML . שני האחרונים (כמו גם C, Java וכל השפות הדומות) מתעלמות מהחלוקה לשורות. סוף שורה הוא סתם עוד תו רווח.
לעומת זאת YAML (כמו גם פייתון) מחלקת לבלוקים לפי עימוד.
עוד משהו שחסר בפורמט שלך הוא ערך קסם בתחילתו. מקובל שמסמך יתחיל בכמה תווים שיזהו את סוגו. כך עובדת הפקודה file, לדוגמה.
צפריר,
אני מתעלם לגמרי מתווים לבנים (רווח, טאב, שורה חדשה), אלא אם הם בתוך סטרינג עם גרשיים (ואז הם נכנסים לתוך הסטרינג).
חשבתי על ללכת לכיוון של עימוד שקובע בלוקים, אבל החלטתי שזה שביר מדי.
לגבי כותרת לקובץ, צודק – אני כנראה אוסיף איזה איזו כותרת עם גרסאת תחביר ואולי גם קידוד אופציונלי.
עוד משהו שאני שוקל להוסיף זה תמיכה במערכים.
היום יש מערך של מפתח-ערך בלבד, אבל יהיה נחמד להוסיף מערך של ערכים לתחביר.
אולי משהו כזה:
some_array ["string 2" word1 ]
כלומר, מערך עם שם שיכול להכיל סטרינגים או מילים (מילה אצלי היא סטרינג בלי גרשיים ובלי רווחים וכו').
יונתן, תראה את זה:
http://stackoverflow.com/questions/791761/xml-for-configuration-files-why
תודה עמרי, קראתי קריאה מהירה.
לפחות לגבי התשובות שקבלת, נראה שדווקא התשובה שנתת לי די מקובלת ("ולם משתמשים בXML לקונפיגורציה בגלל ש.. כולם משתמשים בXML לקונפיגורציה.[…]".). התשובות שקיבלת שם בהחלט מראות שיש סיכוי לפורמט שלך (וששווה לקדם אותו?).
טוב, קראתי יותר לעומק. נראה שאכן מסכימים שם שמשתמשים ב- XML עבור קבצי קונפיגורציה כי קיימים כבר פארסרים נפוצים בכל סביבה.
מה שאומר שיש מקום לשפת קונפיגורציה טובה, עכשיו אתה רק צריך לשכנע שמה שיש לך טוב יותר מ- YAML.
לפחות מישהו אחד השתכנע מהטיעונים שלי, והוא בדרך לכתוב מימוש סווש בC++.
יפה!. זה יהיה ממש מעניין אם זה יתפוס ואם תהיה שפה כזו על שמך.
נראה נחמד מאוד 🙂
בהצלחה שייתפס. אני תמיד תומך במה שייגרום לפחות כתיבת תווים.
ממליץ לקרוא על הפורמט המקוצר של PLIST:
http://en.wikipedia.org/wiki/Property_list
http://code.google.com/p/networkpx/wiki/PlistSpec
אחד שמבין,
PLIST הוא נחמד, אבל כשמו כן הוא – רשימה.
הוא לא תומך בקינון, ולכן מוגבל.
נראה שהאתר ההורדה לא זמין, מקבלים שגיאה 404…
עובד לי כרגע.
לא תומך בקינון ?!? ברור שכן.
אוקיי, אז זה לא ברור בעליל מהתיעוד בוויקיפדיה.
בגלל זה הבאתי את הלינק השני
http://code.google.com/p/networkpx/wiki/PlistSpec
תסתכל שם על דוגמא ב Example serialization.
אולי שווה להרים את הכפפה ולעשות קורא shorthand plist
אוקיי,
ראיתי ואני חושב שהפורמט של סווש יותר אלגנטי וחסכוני.
אז אני לא מבין. אם הפורמט שלך דומה אבל קצת יותר אלגנטי וחסכוני, לא עדיף לנסות לדחוף את השינויים לפיליסט, ולא להמציא את הגלגל עם סווש?
נראה לך לשניה שplist ישונה כי אני דוחף את השינויים?
אין סיכוי.
חוץ מזה, איפה הכיף פה?