Runtime: منفذ System.Xaml إلى .NET Core

مرحى! اعتراف رسمي / إقرار! ونعم ، أدرك أن هذه الكلمات لا تعني "التزام" ولكن هذا بالتأكيد أفضل من أي شيء رأيته حتى الآن. terrajobst أنت بطلي. : قلب:: قلب:: قلب:

cwensley و SuperJMN ، سيكون من الرائع إجراء بعض الحوار بين الجميع هنا. من الناحية المثالية (من وجهة نظري) ، يجب على الجميع في النهاية استخدام منفذ / إصدار واحد من مكتبة Xaml الجديدة وليس لديهم إصدارات / لهجات مختلفة من Xaml هناك. هل هذا ممكن حتى عن بعد؟ أنا موافق على ذلك إذا لم يكن الأمر كذلك ، لكني أود أن أرى ما إذا كان بإمكاننا ذلك. :)

أيضًا ، أنا حاليًا في "إجازة عمل (من عملاء متسلطين LOL)" ولدي 3-4 أشهر من المقرر أن أعمل عبر منصة Xaml وحدها. يمكنني حرفيا العمل بدوام كامل والمساعدة في ذلك خلال ذلك الوقت إذا لزم الأمر. أي شيء من أجل القضية (وأيضًا ، أنا انتهازي للتوقيت الجيد!)

إذا حصل System.Xaml على مصدر مفتوح ، فأنا متأكد من أن المجتمع يمكنه نقله إلى .net core وفقًا لمتطلبات المشروع وأهداف التصميم ، سيحتاج مشرفو المشروع فقط إلى توجيه المجتمع. يتيح الاستفادة من قوة مجتمع .net.

@ Michael-DST ، أوافق على أن وجود لهجة واحدة من xaml أمر مهم. ومع ذلك ، قد يكون تنفيذ ذلك مختلفًا تمامًا. يعتمد التوحيد على تطبيق واحد على المجتمع حقًا.

بالنسبة لـ Portable.Xaml وهو منفذ PCL 259/136 من تطبيق Mono الممتاز System.Xaml (مرخص من معهد ماساتشوستس للتكنولوجيا) ، مع العديد من إصلاحات الأخطاء. الفكرة هي دعم كل ما يقوم به System.Xaml من MS (بما في ذلك القراءة / الكتابة) باستخدام نفس واجهة برمجة التطبيقات ، ولكن ليس بالضرورة أن يقتصر عليها.

كمثال على الوظائف الموسعة ، يدعم Portable.Xaml استخدام محولات النوع على العناصر الموجودة في قائمة ، حيث يستخدم System.Xaml IList.Add (كائن) الذي يجب عليك تنفيذه باستخدام مجموعة مخصصة لدعم أنواع مختلفة.

cwensley أدعي جهلي بهذا ... ولكن ما الفرق بين .NET Core و PCL؟ واعتقد انهم كانوا نفسه؟ بمعنى ، كنت أفهم أنك إذا صممت وفقًا لملف تعريف PCL معين ، فسيتم نقله إلى .NET Core ... كان هذا منذ فترة (وبصراحة كنت أنتظر .NET Core إلى RTM / W) ، حتى الآن هو الوقت المناسب للتحديث. : ص

أفهم / انطباعي أن Portable.Xaml هو بالفعل منفذ mono's System.Xaml ، بينما OmniXaml هو إعادة كتابة من الألف إلى الياء تتميز ببعض السخونة الجديدة في حلبة الإعراب. من الناحية المثالية (من وجهة نظري الخاصة) سيكون من الرائع دمج الاثنين بطريقة ما ، لكنني لست متأكدًا من أن هذا ممكن ، أو حتى مرغوب فيه بين القاعدتين. في رأيي (بدون القيام بالبحث عن الكهوف / التحليل) هو في الأساس دمج نضج أحدهما (Portable.Xaml) مع السخونة الجديدة للآخر (OmniXaml).

@ Michael-DST PCL 259 متوافق بالفعل مع .NET Core ، وفقًا لهذا المنشور . لقد قمت بالفعل بتضمين \lib\dotnet كهدف في حزمة nuget لـ Portable.Xaml ، لذلك يجب أن يكون قابلاً للاستخدام كما هو مع .NET Core ، على الرغم من أنني لم أختبره.

لم يكن لدي الوقت الكافي للنظر في OmniXaml ، ولكن إذا كانت بالفعل إعادة كتابة من الألف إلى الياء ، فقد لا يكون من المنطقي دمج المشروعين لأنني متأكد من أن الأمور كانت ستتم بشكل مختلف تمامًا. لست متأكدًا أيضًا من فائدة مثل هذا الشيء إذا كان Portable.Xaml كاملًا في الغالب كما هو. قد أكون مخطئا بالرغم من ذلك (؛

:) نعم ، أستكشف الخيارات هنا ، وأتعامل أيضًا مع جهلي بالتواجد حقًا في عالم مفتوح المصدر. أنا أكره فكرة وجود العديد من قواعد الكود التي تقوم بنفس الشيء. وبالأخص مع كون مجتمع Xaml أصغر ، سيكون من الممتع أن يتم تجزئته فور بدء التشغيل (أليس من المفترض أن يحدث ذلك بعد أن يصبح شيء ما ناجحًا جدًا لمصلحته ؟! هاها). على أي حال ، سيكون من الرائع سماع رأيSuperJMN في هذا الأمر. أعلم أنه بدا حازمًا جدًا على تعديلاته الجديدة. على سبيل المثال ، استخدام MarkupExtensionContext بدلاً من IServiceProvider لامتدادات الترميز ، والذي سيكون تغييرًا جذريًا لأي شخص يريد نقل كود موجود إلى هذا العالم الجديد.

للتوضيح ، جميع ملفات تعريف PCL متوافقة مع .NET Core. مجموعات العقود والعوامل التي لدينا الآن هي تطور لملفات PCL. لا ينطبق هذا على المكتبات المحمولة "القديمة" (التي تم تجميعها مقابل mscorlib ، وما إلى ذلك) والتي لا تتوافق على الفور مع .NET Core.

@ مايكل- DST

terrajobst أنت بطلي. : قلب:: قلب:: قلب:

بينما أقدر بشدة حماسك ، أود أن أوضح أنه يمكن لأي شخص تقديم طلبات مثل هذه. لست بحاجة إلى أي رعاية أو إقرار منا من أجل تقديم مشكلات ، وطلب العمل :-) أنا فقط قمت بتقديمه بنفسي لتوفير بعض الوقت وألا أكون أعرجًا ("لا تتردد في تقديم خطأ") :-)

LOLterrajobst لا بأس ، حماسي هو نصف لسان في الخد ونصف جاد ... لقد التزمت MSFT الصمت بشكل أساسي بشأن هذه القضية منذ ما يقرب من عام الآن ، على الرغم من العديد من الأصوات والمحادثات المكثفة .

لذا ، ضع في اعتبارك أن ما فعلته يعادل وضع وجبة تحت باب شخص محبوس في الحبس الانفرادي لمدة عام تقريبًا. : stuck_out_tongue:

[تحرير: بعد قراءة هذا القياس (ورؤيته مقتبسًا أدناه) ، يجب أن أقول إنه فظيع وربما متأثر بمقال كنت أقرأه في ذلك الوقت - لعنة الأخبار ، لماذا يجب أن تؤثر علي هكذا؟! من المحتمل أن يكون الشخص الأفضل / المناسب هو الحصول على حقنة نقدية تشتد الحاجة إليها من جولة ملاك بعد عام من التشغيل على الأبخرة.]

نسخة إلى: @ Harikm86 ، صاحب System.Xaml

أنا أحب XAML. إنها لغة توضيحية رائعة لكل شيء بدءًا من Silverlight (نعم ، لقد قلتها) إلى Windows Workflow والآن إلى النظام الأساسي العالمي للتطبيقات الجديدة. يتيح النقل إلى Core إمكانية نقل التقنيات الأخرى التي تعتمد على XAML. نحن بحاجة إلى هذا!

من الرائع سماع دعمكrschiefer! شكرا لك على المدخلات الخاصة بك. يرجى التأكد من أن لديك مطوري Xaml آخرين تعرفهم للانضمام إلى هذا الموضوع والمساعدة في المحادثة / الاتجاه.

أنا أيضًا معجب بـ Silverlight وكنت أطارد التجسد التالي منذ عام 2011 (المكونات الوقحة: إذا كنت ترغب في السماح لفريق Visual Studio بمعرفة أنك ترغب في رؤية الشكل التالي الأكثر ذكاءً من Silverlight ، فالرجاء التصويت والسماح لهم تعرف هنا ).

أرغب في أخذ ثانية والتأكد من أنه عندما نقول "Xaml" يجب أن نطمح إلى نظام / مجموعة ميزات Xaml الموجودة في .NET 4.x + (أو "System.Xaml"). حتى Xaml من Silverlight 5 سيفي بالغرض حقًا.

(بالطبع ، من المرغوب فيه أيضًا إضافة التحسينات الجديدة الموجودة في OmniXaml .)

طالما أنها ليست النسخة "الجديدة" المبطنة في UWP التي يجب أن يكون قد تم نقلها من قبل فريق من المتدربين ، حيث أننا جميعًا نعاني منها منذ ذلك الحين (انظر الأصوات التي أذكرها في رسالتي أعلاه).

أنا أتردد حقًا في تسمية ذلك نظام "Xaml" ، لأنه في الحقيقة XML مع بعض التحليل الإضافي للرموز لحسن الحظ (وهو ما يحتاجه بوضوح). حقيقة ممتعة: يستخدم نظام Xaml الخاص بـ UWP في النهاية تجميع System.Xaml أثناء عملية الإنشاء. ط ط ط ... # روني.

من الناحية المثالية ، بمجرد وضع هذا المنفذ في مكانه ، سيتم إهمال نظام UWP Xaml تمامًا واستخدام هذا المنفذ بدلاً من ذلك. يمكننا بعد ذلك وضع هذا الفصل من تاريخ Xaml المحرج وراءنا ، وسوف يكون هناك الكثير من ابتهاج المطور.

إن استعادة Silverlight بشكل أحدث وأفضل لن يكون أمرًا سيئًا أيضًا. :) :) :)

@ مايكل- DST

لذا ، ضع في اعتبارك أن ما فعلته يعادل وضع وجبة تحت باب شخص محبوس في الحبس الانفرادي لمدة عام تقريبًا. : stuck_out_tongue:

عادل بما يكفي: ابتسم:

@ مايكل- DST

لقد تجنبت بالفعل UWP حتى هذه النقطة وأنا أعلم أن الكثير قد تغير وأنني نسيت أن UWP تستخدم "نسختها" من Xaml. شكرا لتذكيري.

أوافق تمامًا ، يجب نقل System.Xaml ومن ثم يمكننا إصلاح UWP لاستخدام Xaml الحقيقي.

أوافق تمامًا ، يجب نقل System.Xaml ومن ثم يمكننا إصلاح UWP لاستخدام Xaml الحقيقي.

آسف terrajobst ، لدي بطل جديد الآن فيrschiefer. :ابتسامة ابتسامة ابتسامة:

شكرا لكم جميعا على المناقشة. هذا رائع جدًا بالنسبة لي (ولكن يمكنني الإعجاب بسهولة!).

تضمين التغريدة

helmsb نعم! لول هاها!

FWIW ، تقنية تصميم المواد الشهيرة للويب (Angular.js) والتطبيقات (Android) وما إلى ذلك من Google متاحة أيضًا مفتوحة المصدر. آمل أن تساعد هذه الحجة في إقناع الرؤساء والكيانات التي تشبه الرؤساء.

dsaf ماذا تقصد؟

FWIW لقد أشرت إلى هذه المشكلة في مقال نُشر اليوم بعنوان Is the Tide Turning on project.json؟ ، نظرة على كيف أن Xaml هي الآلية المفضلة لوصف كائنات .NET من منظور تقني و MSFT للأعمال / IP.

حسنًا ، ماذا عن صفقة Xamarin ، هاه! هناك شيء يخبرني أن هذه القضية ستزداد انشغالًا في الأشهر المقبلة. :ابتسامة:

ليس بالضرورة. قد تكون هناك فرصة جيدة لأن تصبح Xaml's Xaml أو Xamarin من Xamarin من UWP تصبح مكتبة عبر الأنظمة الأساسية. وهو ما قد يعني أنه لا يوجد منفذ من System.Xaml أو حتى تنفيذ Xaml مُدار بحتة قد يحدث.

نظام Xamarin الخاص بـ Xamarin مغلق / داخلي على الرغم من أنه لا يوجد مكان قريب من النضج مثل System.Xaml. الشفرة نفسها واهية إلى حد ما (مصدر قلق معترف به من نهايتها - في الواقع يعد استخدام هذا أحد أسباب إغلاقه / داخليًا). بالإضافة إلى ذلك ، فهو مقترن بإحكام بـ BindingObject وهو أمر باهظ إذا كنت ترغب في إجراء تسلسل POCO ، وما إلى ذلك.

وكما هو موضح أعلاه ، فإن نظام Xaml الخاص بـ UWP فظيع. ما لم يكن هناك شيء تعرفه ولا أعرف عنه. : stuck_out_tongue:

هل يمكن أن تشرح ما تقصده بـ "تنفيذ Xaml مُدار بحتة"؟ FWIW ، توقعاتي هنا ليست بالضبط منفذ 1: 1 مباشر من System.Xaml ولكن مكتبة System.Xaml (Microsoft.Xaml؟) "جديدة" تأخذ كل المزايا من System.Xaml ، Xamarin.Core.Xaml ، و ... حسنًا ، أود أن أقول Xaml من UWP ، لكن ...: غمز:

لقد سمعت أن هناك تفضيلًا داخليًا لـ Xaml من UWP على WPF و Xaml ، على الرغم من أنه من الواضح أن الفرق المختلفة في Microsoft قد يكون لها آراء مختلفة. Xaml من DotNet هو بلا شك أكثر قوة ومرونة ، ولكن كما هو الحال مع أي شيء مع تلك الواصفات التي من المحتمل أن تأتي مع عيوب هي السبب وراء تقليص UWP.
ومن خلال عدم الإدارة البحتة ، فإنني أشير إلى الشيء الجميل الوحيد حول Xaml الخاص بـ UWP في أنه ليس DotNet حصريًا. لذلك يمكن أن يكون Microsoft.Xaml المستقبلي المحتمل تطبيقًا أصليًا متعدد الطبقات بواجهة مُدارة بحيث يمكن استخدامه خارج DotNet. (سيؤدي ذلك أيضًا إلى استبعاد تضمينه في dotnet / corefx ما لم يتم تحديد هذه المكتبة المستقبلية باعتبارها أحد مكونات CoreFX)

حسنًا ، أنا في حيرة من أمري. عندما تقول .NET ... أنت تتحدث 4.6 ، أليس كذلك؟ من وجهة نظري ، هذا مخصص لمكتبة .NET Core Xaml ، والتي بحكم طبيعتها متعددة الأنظمة الأساسية و .NET (4.6) حصرية؟ عندما تقول "ليست DotNet حصرية" تقصد "هل DotNet شامل"؟ سلبيات مزدوجة. : stuck_out_tongue: من الواضح أن هذا ليس صحيحًا لأنه لا يمكنك استخدام UWP Xaml في .NET 4.6 (ولا تريد: stuck_out_tongue :).

من فضلك قل لي ما هو خطأ هنا. بالإضافة إلى ذلك ، يتمثل الهدف الجيد هنا في شحن Xaml كجزء من CoreFX. كانت بعض المناقشات تدور حول هذا لبعض الوقت . - وبالتأكيد ، إذا لم أكن مخطئًا @ RichiCoder1 ، فلديك صوتك للقيام بذلك بالضبط في هذا الموضوع ... كنت أتساءل أين رأيت علامتك من قبل! :ابتسامة:

وأود أيضًا أن أقول إنني استمعت أيضًا إلى الميول الداخلية تجاه Xaml من UWP ، ولكن كان ذلك قبل أن يكون هناك بعض النقاش المجتمعي حوله بدءًا من هذا الموضوع إلى أبعد من ذلك ( مناقشة Twitter على Tim Heuer ). لقد تحركت الإبرة بالتأكيد منذ ذلك الحين. على الأقل ، كان أفضل! الضحك بصوت مرتفع. هناك من لديهم فكرة خاطئة مفادها أن "Xaml مخصص لواجهة المستخدم" ومن ثم هناك البقية منا الذين يفهمون كيف يعمل. : stuck_out_tongue:

عندما أقول DotNet ، أعني DotNet بما في ذلك الأساسي والإطار. وأنا أدرك أنه لا يمكنك استخدام UWP Xaml خارج تطبيقات UWP ، كنت أشير إلى القدرة على استخدامه في تطبيقات C ++ UWP. لذلك عندما أقول عدم امتلاكها حصريًا لـ DotNet ، أعني أن أكون على وشك استخدامه من C ++ (أو من المحتمل أن تكون لغات أخرى). وأتخيل سبب عدم اعتبار الفريق الذي يمتلك XAML حالات الاستخدام خارج واجهة المستخدم على محمل الجد لأنه إما غير شائع أو ، في بعض الحالات ، ينتقد بشدة مع Microsoft أو مع الشركاء. ليس رأيي الشخصي ، أنا أقدر أنه تعبير وقوة.

حسنًا ، شكرًا @ RichiCoder1 على التوضيح. أعتقد أنني _أكثر _ أتابعك تمامًا الآن ... عندما تقول "إطار العمل" تقصد 4.6؟

من وجهة نظري ، سأقول أن جزءًا من السبب الذي يجعل الفريق الداخلي يشعر أنه من غير المألوف استخدامه خارج واجهة المستخدم له علاقة بضعف التفاعل مع المطورين ، كما أعتقد أن منشور Tim يظهر. أنا أيضًا مذنب بهذا لأنني حقًا لم أشعر بالمرح بشأن إشراك MSFT حتى حوالي عام أو نحو ذلك؟ في الواقع ، كانت تغريدة Tim حول تصويت قمت به ، بعد أن كنت شخصيًا / خاصًا أشتكي للجميع منذ Windows 8.0 أن نظام Xaml كان مختلفًا تمامًا وعلى عكس ما ينبغي أن يكون. عندما سمعت التذمر بأن UWP (Windows 10) Xaml كان في الأساس هو نفسه - بعد 3 سنوات من عدم الابتكار أو التحسين - كان ذلك عندما تقدمت. في الإدراك المتأخر ، كان ينبغي أن يكون ذلك في وقت أقرب بكثير.

من الآمن القول أن هذا كان درسًا تعليميًا كبيرًا. أنا (أو على الأقل أشعر أنني كذلك) الآن أكثر اندماجًا في النظام البيئي وأشعر أنني مسموع. في الواقع ، لقد تم وضع علامة "قيد المراجعة" على تصويت - مهم جدًا - أجريته منذ ما يزيد قليلاً عن أربعة أشهر من قبل فريق Visual Studio المرموق في وقت سابق من هذا الأسبوع. أن أقول إن عالمي قد هز هو بخس. :ابتسامة:

حسب الإطار ، أنا أستخدمه للإشارة إلى سطح المكتب .Net. يبدو أن هذه هي الطريقة الشائعة للتمييز بين Core والإطار الكامل.

أنا موافق. أحد الأشياء الرائعة في جميع تحركات Microsoft الأخيرة هو أنه يكاد يفرض مشاركة أفضل مع المطورين :).

أنا متحمس جدا لذلك! الآن فقط لنرى كيف سيكون ذلك. قد يعني ذلك أي شيء من جعل تطبيقات Xamarin من الدرجة الأولى جانبًا من تطبيقات UWP باستخدام مشاريعهم المشتركة ، أو قد يعني شيئًا عالي المستوى بعد ذلك. فقط الوقت (وأعتقد ، // بناء) سيخبرنا.

حسنًا رائع ... شكرًا لك على المعلومات. : +1:

أما // بناء ... في الواقع. :) أنا شخصياً أرغب في رؤية نموذج جديد كليًا (بشكل فضفاض؟) يعتمد على UWP واستخدام ميزات Xamarin الجديدة لنقله إلى iOS / Droid. لن يضر نموذج Xaml الأقوى أيضًا. أعتقد أننا يجب أن نحافظ على هذا الخيط هادئًا حتى بعد 28 أبريل ، بعد كل شيء. : stuck_out_tongue:

أتمنى أن تفعلوا ذلك يا رفاق! :)

تخمين أن شباب UWP سيتبنون بسهولة أكبر تطبيق XAML الذي لا يسحب كود .NET (حتى لو كان هذا الرمز هو .NET Core stuff).

مثل الصندوق الأسود القائم بذاته (أو اعتمادًا فقط على UWP ، لكننا لا نريد ذلك نظرًا لأن UWP ليس متعدد الأنظمة الأساسية [حتى الآن] وإذا كان لا يزال هناك إصدار مُدار منه يمكن تشغيله في .NET / Silverlight [لا يمكن قفل تطبيقاتك لهدف Win10 فقط]).

ولكن أعتقد أن هذا الأمر خيالي إلى حد ما ، إلا إذا قمت بعمله باستخدام طبقة تجريد ووصلات قابلة للتوصيل / برامج تشغيل للتطبيقات المختلفة لـ XAML (لـ UWP UI ، لـ Workflow ، لـ WPF / .NET ، لـ Silverlight وما إلى ذلك). مثل الطريقة التي يبدو بها DirectX جهازًا عبر HAL (طبقة تجريد الأجهزة) ، والذي يفتح أيضًا إمكانية لـ HEL (طبقة محاكاة الأجهزة - راجع الإشارات على http://www.developer.com/net/asp/article.php/968461/What -هو- DirectX.htm). بالطبع ، إذا لم تكن حريصًا ، فقد يفتح الباب أمام الجحيم فيما يتعلق بالأداء ، ولكن نظرًا لأن DirectX يمكن أن يسحبه ، أعتقد أن هذه البنية ليست سيئة

+1 لنقل System.Xaml إلى .NET Core.
آمل أن أرى لغة XAML واحدة موحدة (.NET Xaml و UWP Xaml و Xamarin Xaml) يتم استخدامها على جميع الأنظمة الأساسية في المستقبل.
يعتقد أن إصدار .NET Core من System.Xaml ضروري لتحقيق ذلك.

+1

لتجنب تنبيهات الإشعارات الجماعية ، لدينا الآن طريقة جديدة لإجراء 1+ للتعليقات الفردية على GitHub ، لإظهار اهتمامنا / رد فعلنا للموضوع قيد البحث:

Haha @ jasonwilliams200OK لا مانع من تنبيهات الإخطار الجماعي من أعضاء المجتمع الذين يعبرون عن اهتمامهم الأولي بحل System.Xaml القوي عبر الأنظمة الأساسية. : angel: ربما مواضيع أخرى أود مشاركة ألمك / انزعاجك / إحباطك ، مع ذلك. :غمزة:

نقطة صالحة (وقيمة) ، على أي حال. لقد أضفت: +1: من أجل القضية.

تضمين التغريدة

شكرا لاستدعاء هذا!

FWIW ، لقد قمت للتو بدعوة فريق Xamarin.Forms للانضمام إلى المحادثة هنا:
https://bugzilla.xamarin.com/show_bug.cgi؟id=26740

أو في حالة وجود أي شيء ، اجعل الجميع _هنا_ على دراية بالمحادثة _ الموجودة_. :ابتسامة:

حصلت على بعض المناقشات الرائعة الجارية في التعليقات على هذا المنشور:
https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

بشكل أساسي JSON vs Xaml لنظام المشروع الجديد الذي يبدو أنه قيد التنفيذ لـ Visual Studio (الصيحة!). لا تتردد في الانضمام. :) سعيد للغاية لرؤية أن هذا يأخذ نظرة أخرى.

@ Mike-EEE ، ألق نظرة أيضًا على خريطة الطريق هذه: https://github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md. سيكون نظام المشروع الجديد الذي يعمل بنظام Roslyn .. ثمينًا.

قف ... مجنون لأنني أسمع عن هذا الآن. يجب أن يكون هذا ما كان يشير إليه سكوت هانتر في منشور المدونة المذكور أعلاه فيما يتعلق بمزيد من المعلومات القادمة في منشور مستقبلي. جيد أن نرى. تنمو قوة روزلين. على الرغم من ذلك ، سأشعر براحة أكبر عند رؤية بعض المشكلات لتعريفات مشروع Xaml المتسلسلة. :غمزة:

راجع الملف التمهيدي لهذا الريبو: https://github.com/dotnet/roslyn-project-system#welcome -to-the-roslyn-c-and-visual-basic-project-system (والرابط إلى مدونة VS MSDN ) ، يبدو أننا سنكون قادرين على استبدال المكونات المختلفة باستخدام MEF ، مما يجعل من الممكن إدخال مُسلسل إضافي لتحليل تعريف المشروع المكتوب بلغة XAML. شخصياً ، لقد نمت لأفضل JSON على XAML / XML عندما يتعلق الأمر بوصف خصائص المشروع والتبعيات وما إلى ذلك لأن JSON أقل ضوضاءً (حسنًا ، YAML أقل ضجيجًا من JSON ويدعم معيار lang التعليقات على عكس std-JSON ، ولكن في عالم dotnet ، لم تكتسب YAML والنغمات الأخرى ذات البنية الواعية للمسافات البادئة قوة دفع)

أنا شخصياً نمت لأفضل JSON على XAML / XML

الأمان! قم بإزالة هذا الرجل !!! مهم يعني ... :)

أنا جميعًا لأخذ أفضل ما في العالمين. قد يتحدث SuperJMN و @ Grokys أكثر عن هذا ، لكنني أعتقد أن الجهود تُبذل في OmniXaml لجعله أقل إسهابًا وثرثرة.

مشكلتي مع JSON ليست w / JSON في حد ذاته ، ولكن منهج التصميم الذي كان أيضًا أساس تكوين .NET (والذي أفترض أنه كان مصدر إلهام له) ، وهذا يعني أن مخطط الكائن هو "قطعة أثرية أخرى" يجب على المطور إدارة / صيانة و _ لا _ تعريف الفئة. هذا هو ، في برمجة Xaml (كما تعلم!) تعريف الفئة _is_ مخطط المستند. نتيجة لذلك ، يضفي هذا إحساسًا طبيعيًا جدًا على تطوير المستند ، كما يساعد / يساعد في الأدوات أيضًا.

ناهيك عن سلامة المطور. : ابتسامة: لا شيء يغضبني أكثر من الاضطرار إلى مطاردة بعض مستندات المخطط الغامضة ومعرفة كيفية تثبيتها والحصول على أبسط تحسس للعمل.

المشكلة الأخرى التي أواجهها مع JSON ليست خاصة بـ JSON ، ولكنها تتعلق بعقلية الويب وهي اصطلاح التسمية. عانى تكوين .NET من هذا أيضًا. بمعنى ، قد تحدد POCO مثل:

public class MyPoco {
    public string Property {get; set;}
}

وسيبدو JSON (أو app.config) الخاص به مشابهًا (ويمكنك أن تدرسني على هذا إذا كان لدي هذا الخطأ!):

{
 { "property": "Hello world I have inconsistent naming conventions!" }
}

هنا مرة أخرى ، يتم محاذاة Xaml بين تعريف الفئة ونظيره المتسلسل ، ولهذا السبب أفضلها.

يجب أن أقول إن تكوين .NET كان الأسوأ لأن تصميمه أسفر عن أربع عيوب لكل كيان تكوين:

1. العنصر في web / app.config
2. ملف .xsd الذي كان عليك ربطه بطريقة سحرية بالويب / app.config (لم أحصل على هذا للعمل مطلقًا!)
3. العناصر ConfigurationElement و / أو ConfigurationSection التي أخذت القيم من app / web.config (وعينت حالة الجمل غير المتناسقة على PascalCase - يا الجنون!)
4. POCO الذي تم توصيله في النهاية من عنصر التكوين. (يا إلهي!)

لم أدرس تصميم مشروع JSON بما يكفي لمعرفة ما إذا كان هناك كائن POCO يتم إجراء تسلسل له مع مستند .JSON أو ما إذا كان التعيين الدخيل الموضح أعلاه يحدث أيضًا. أود أن أسمع ما إذا كنت تعرف الإجابة على هذا.

في أي حال ، يعمل Xaml على تحسين هذا التصميم من خلال طلب قطعتين اثنتين فقط:

1. ملف الفصل (.cs)
2. ملف البيانات (.xaml)

أخيرًا ، شكرًا على هذا الرابط إلى الملف التمهيدي! أنا مرة أخرى "ذلك الرجل" الذي لا يفعل الشيء ذاته الذي يطلبه هذا الملف. : يضحك:

إذا كان هناك كائن POCO يتم إجراء تسلسل له مع مستند .JSON أو إذا كان التعيين الدخيل الموضح أعلاه يحدث أيضًا. أود أن أسمع ما إذا كنت تعرف الإجابة على هذا.

أعتقد أنه إذا كنت تفكر في سمات [DataContract] و [DataMember] ، فإن إطار عمل .NET (على مستوى BCL) يساعد JSON ومصنعي تسلسل البيانات الآخرين. ومع ذلك ، لا يوجد كائن JavaScript أصلي / منخفض المستوى يدعم انتقال C # POCO بواسطة مترجم مثل JSON إلى JavaScript (والعديد من اللغات الأخرى) أو CSON إلى CoffeeScript. ومع ذلك ، على عكس XML بكل روابط XPATH XQUERY XSLT ، فإن JSON لديها مفهوم المخطط للتحقق من صحة البيانات ويدعمها JSON.net مثل البطل.

بالنسبة إلى C # 6 وما فوق ، ألق نظرة على هذه المشكلات / المقترحات https://github.com/dotnet/roslyn/issues؟utf8=٪E2٪9C٪93&q=is٪3Aopen+is٪3Aissue+author٪3Agafter+ القاموس ، وخاصة https://github.com/dotnet/roslyn/issues/6949 واتبع الروابط الموجودة بداخله. مع بناء جملة مُهيئ القاموس C # 6 الجديد وهذه المقترحات ، يبدو أن C # أصبحت أكثر صداقة مع لغة JSON.

لا بد لي من القول أن تكوين .NET كان الأسوأ

موافق ، يمكنك أيضًا الاستمتاع بنمط "التكوين" و "IOption" الذي قدمه فريق ASP.NET كحزمة توصيل وتشغيل: https://github.com/aspnet/Configuration ، https://docs.asp.net/ en / latest / fundamentals / configuration.html ، والذي يحل محل مدير التكوين القديم سيء السمعة المرتبط بـ XML.

لدى JSON مفهوم المخطط للتحقق من صحة البيانات ويدعمه JSON.net مثل البطل.

يبدو مثل تعريف فئة كمخطط. :) :) :)

يبدو أن C # أصبحت أكثر صداقة مع JSON من الناحية المعنوية.

هاها جيدًا للتأكد ، _ أي كائن متوافق بالفعل مع JSON. يعد JSON أمرًا رائعًا للقيام بما يُفترض القيام به: قم بتدوين تعريفات الكائنات بطريقة موجزة وسهلة القراءة. وليس هناك شك في أن JSON.net يقوم بعمل رائع لتحقيق هذا الهدف. عندما تبدأ في وصف التطبيقات ، فإننا نبدأ في الدخول إلى المنطقة التي تبدأ فيها هذه المحادثة ، بسبب عدم وجود كلمة أفضل. :ابتسامة:

في النهاية ، هناك سيناريوهان هنا (بالنسبة لي ، على الأقل): وصف الكائنات التي من المفترض نقلها بين حدود الخدمة (خفيفة الوزن) ووصف التطبيقات التي تنشئ تلك الكائنات (مهمة). أنا شخصياً أحب أن أسعى لتحقيق الاتساق بكل الطرق الممكنة وتقليل تبديل السياق. طالما أننا نحتفظ بخياراتنا ( IOptions ؟: الضحك :) مفتوحة ونسمح للمطورين باختيار التنسيق الأكثر منطقية بالنسبة لهم (ويسمح لهم باستخدام الأدوات التي تجعلهم يشعرون بأكبر قدر من الكفاءة! ) ثم فزنا جميعًا هنا. : +1:

يحتوي UWP XAML على ميزات أقل مقارنةً بـ .NET WPF XAML الكلاسيكي. من أكثر الميزات التي أفتقدها هي TypeConverters.

حاولت إنشاء TypeConverter الخاص بي كما هو مقترح هنا https://msdn.microsoft.com/en-us/library/bb546926 (v = vs.90) .aspx (المقالة خاصة بـ WPF TypeConverters)

في UWP ، أحصل على هذا "النوع غير المعروف" سيارة "في مساحة اسم XML" باستخدام: App2TypeConverters ""

        <ListBox>
            <local:car></local:car>
        </ListBox>

هل من غير الممكن حقًا إضافة محول TypeConverter مخصص في UWP؟ أم أن هناك حلا؟ قرأت في مكان ما أن XamlCompiler يستخدم IServiceProvider الداخلي لتسجيل TypeConverter. ربما يمكن أن يكون مسجلا معها بطريقة أو بأخرى؟
أنا مهتم أيضًا بمعرفة المزيد حول الخلفية المتعلقة بتجميع XAML. هل سيستمر إنشاء XAML في BAML؟ هل يمكننا بطريقة أو بأخرى ربط تجميع XAML؟
لذا ، يرجى فتح System.Xaml.

Sooooooo ... هل هذا يعني أن System.Xaml سينضم أخيرًا إلى الحفلة ؟؟؟ :ابتسامة ابتسامة ابتسامة:
https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/

سأدخل هنا وأقول:
أ) أحب حقًا تشغيل XAML مع .Net Core و
ب) إذا حدث ذلك ، فسيكون من المنطقي استخدام نكهة UWP ، حيث يتم نقلها بالفعل إلى بنيات أخرى (على سبيل المثال ، دفع إنترنت الأشياء على Raspberry Pi).

سيكون الحصول على WPF XAML أمرًا رائعًا ، إذا كان ذلك ممكنًا.

بنفس الطريقة التي أعيد بها بناء .NET core بشكل أساسي من الألف إلى الياء ، بناءً على العقد الماضي من التعلم ، أعتقد أنه يجب القيام بنفس الشيء مع XAML. لقد كان تطور WPF / Silverlight / WinRt-XAML كارثة كاملة. خطوة واحدة للأمام ، وخطوتين للخلف (واحدة جانبية). لم يأتِ الوعد بـ XAML و Expression Blend وما إلى ثماره أبدًا.

سمعت سكوت هانتر يبرر عدم وجود واجهة مستخدم متعددة المنصات في Dotnet Core قبل أيام بقول "حسنًا ، لم تظهر أبدًا بشكل جيد. يتوقع مستخدمو Windows زرًا يشبه Windows ، على Mac زر Mac". حسنًا ، أنا آسف - أين كان منذ 5 سنوات ؟؟؟ يهيمن الويب تمامًا على تصميم واجهة المستخدم الآن ولا يوجد على الويب شيء مثل "الزر القياسي" - ولكن خمن ماذا؟ تمكن المستخدمون من حلها. هذه الحجة تقف ببساطة ضد كل الأدلة. تهيمن واجهات مستخدم الويب هذه الآن على التجارة على هذا الكوكب. لكن يبدو أن هذا ليس جيدًا بما يكفي لـ Dotnet Core. لماذا لا يمكننا الحصول على منصة XAML عبر النظام الأساسي دون التقليل من أي طموح [وهمي] "مظهر ومظهر نظام أساسي قياسي"؟

تتمثل العقبات التقنية الرئيسية التي أفترضها في كيفية التعامل مع "XAML" (أو أيًا كان ما يسمى الجيل التالي من منصة واجهة المستخدم) بواجهة برمجة تطبيقات ثلاثية الأبعاد عبر الأنظمة الأساسية - حيث من الواضح أننا لا نستطيع الاعتماد على Direct3D / Direct2D على نظام MacOS وما إلى ذلك. تم حل هذه المشكلة بواسطة Unity إلخ الذين تمكنوا من تحقيق هذا الهدف.

لقد كانت هناك الكثير من التباطؤ من قبل Microsoft حول موضوع المصادر المفتوحة لعائلة تقنيات XAML ، على المرء أن يتساءل عما إذا كانت مخبأة بداخلها عبارة عن ذاكرة تخزين مؤقت سرية لعملات البيتكوين أو المفاتيح الخاصة لموقع microsoft.com.

احصل عليه مع MSFT: Open Source WPF / Silverlight / WinRT-XAML ودع الحقبة الذهبية التالية لتجربة المستخدم تبدأ.

إنه لأمر مدهش جدًا أن تسمع ما تقوله عن Scott Hunter ،JackUkleja. هل لديك مصدر / رابط لذلك؟ إذا كان ما تقوله صحيحًا ، فهذا بالإضافة إلى ما تقوله يظهر جهلًا (مفاجئًا) من عدة جبهات:

1. هذا هو بالضبط ما حاولت Xamarin.Forms معالجته.
2. تعد تجربة المستخدم / التفاعلات / الأنماط الخاصة بالمنصة (أو المحاكاة كما هي) مصدر قلق يمكن ويجب معالجتها بواسطة الموضوعات. هذا ما كان WPF جيدًا جدًا فيه (على الرغم من أنه يمكن ويجب تحسينه حسب وجهة نظرك).
3. الأسوأ من ذلك كله ، أن هذا لا يضع أي ثقة في مجموعة المواهب التي نجحت في إنشاء WPF ، والذي يمكن القول إنه أعظم إطار عرض تقديمي في كل العصور. هل تقول أنهم لم يعودوا قادرين على حل هذه المشكلة؟ أو على الأقل اعمل نفس السحر الذي جعل WPF ناجحًا للغاية بطريقة متعددة المنصات؟

تجربة المستخدم الجيدة هي تجربة مستخدم جيدة. كما أشرت ، يوضح الويب ذلك بوضوح. مستخدمو التطبيق الأصليون مشروطون بالتأكيد بمظهر وإحساس معينين لواجهاتهم الأصلية ، ولكن مرة أخرى يجب أن يكون هذا قابلاً للحل من أحد السمات.

تخيل أن تكون قادرًا على عرض تطبيق على جهاز iOS في "مظهر" Droid (كامل مع السلوك) والعكس صحيح. كان هذا / ممكنًا مع WPF وهو بالضبط نوع التفكير الذي يجب المضي قدمًا فيه. وهذا يعني أن الشكل / الإحساس / التجربة لا ينبغي أن يعيق تطوير التطبيق وتصميمه. يجب أن تكون قادرًا على تطبيق موضوع ، والحل ، "إنه يعمل فقط". هذا للأسف كان / منتقدًا لـ Xamarin. الأشكال في ذلك بينما تمثل منصات مختلفة ، هناك الكثير من الاحتكاك الذي ينطوي عليه التأكد من أن كل شيء يعمل كما هو متوقع على كل منصة مستهدفة.

@ Mike-EEE أنا متأكد من أن سكوت هنتر قال كلمات بهذا المعنى في حلقة dotnet rocks: https://www.dotnetrocks.com/ ؟

يكرر:

"تجمع المواهب الذي نجح في إنشاء WPF ، يمكن القول إنه أكبر إطار عرض تقديمي في كل العصور"

... ما أفهمه هو أن عددًا كبيرًا من المهندسين المعماريين الأصليين قد ترك بعض المتورطين في WPF MSFT وذهبوا إلى Google وشاركوا في Angular. تظهر الكثير من الأفكار من WPF في Angular والأطر ذات الصلة مثل القوالب. ولكن بغض النظر عن الطريقة التي تقطع بها أطر عمل الويب هذه ، أعتقد أنه سيكون لديك دائمًا رائحة HTML / CSS في الخلفية. ليس من المنطقي أن تكون جميع واجهات المستخدم قائمة على المستند / الدلالي وهذه هي طبيعة HTML ، ولهذا السبب أعتقد أن العالم لا يزال بإمكانه الاستفادة من "نواة XAML".

[جاك ... لا أعتقد أن البيانات صحيحة حول مهندسي شركة جوجل و WPF]

@ rrelyea كان هذا ما فهمته ولكن قد أكون مخطئا. كان بإمكاني أن أقسم أنني قرأت أن بعض فريق WPF عمل على Angular على الرغم من .... إيان إليسون-تايلور من بين آخرين؟ (على الرغم من أنه يبدو أنه عاد إلى MSFT الآن ...)

رائحة HTML / CSS في الخلفية

كلما زاد التوافق والتقارب مع معايير HTML CSS الموحدة أو أي نوع من المعايير في هذا الصدد (C ، C ++ ، JavaScript) ، كان هذا العالم أفضل. بدلاً من ذلك ، يمكن لـ XAML بميزاته الفريدة أن تقدم نفسها كإطار عمل شامل لمكدس HTML + CSS وما إلى ذلك أو ببساطة كمحرك أمامي بديل لـ ASPNET's Razor: https://github.com/aspnet/Razor/issues/78 : مصباح:

@ jasonwilliams200OK FWIW / FYI يوجد بالفعل منفذ HTML / CSS "قياسي" من .NET في JSIL . جميع مخرجاته متوافقة مع HTML5 بنسبة 100٪ وتعمل في أي متصفح حديث. هذا هو نوع التفكير الذي يجب أن نطمح إليه بالطبع (وكان يجب أن يكون هو التفكير منذ زوال Silverlight مرة أخرى في عام 2011 ، لكنني استطعت الاستطراد).

وهذا هو ، (بالنسبة إلى وجهة نظرك ، آمل) أن السؤال المثالي هو أن مطوري .NET يجب أن يتعاملوا فقط مع .NET / C # / F # / VB.NET وألا يضطروا أبدًا إلى لمس CSS / HTML / JS ، تمامًا مثل الطريقة لا يتعين على مطوري Xamarin .NET لمس أسس iOS / Droid (مهما كانت _they_.: wink:).

@ Mike-EEE ، في اللغات الفائقة (TypeScript إلى JavaScript أو Less to CSS) ، يمكننا استخدام كود lang للمجموعة الفرعية في مجموعة فائقة في نفس الملف ، ولكن ليس العكس. لذا فإن مفهوم المجموعة الفائقة يتجاوز قليلاً كيفية عمل phonegap و cordova وما إلى ذلك. :)

Haha yeah @ jasonwilliams200OK أريد فقط التأكد من أننا لن ننتهي بوضع حالة خاصة لنهجنا / إستراتيجيتنا مع إعادة .NET إلى المتصفح. يجب أن يُنظر إلى لمس CSS / JS بنفس ازدراء لمس الملف الثنائي. : stuck_out_tongue:

على سبيل المثال ، هناك أيضًا مشروع آخر Fayde يستخدم Xaml (yay) ، ولكنه يعتمد أيضًا على TypeScript (بوو). هذه هي الطريقة لعدم القيام بذلك ، حيث ينتهي بك الأمر مع قاعدتين من التعليمات البرمجية غير المتوافقة - واحدة في TypeScript / JS لكود العميل ، و .NET لكل شيء آخر - وهي مكلفة للغاية من حيث الوقت والموارد.

محرك أمامي بديل لمحرك ASPNET's Razor

Razor هو مجرد محرك قالب في رأيي. في الواقع ، في هذا الرابط ، ذكرت أنه يقول "... أنه يمكنك الاختيار من قائمة طويلة من محركات القوالب الأمامية للترميز."

لقد سمعت بعض التعليقات من MS ضد تراكيب خاصة تشبه C # مثل Razor داخل صفحة HTML ، لصالح الأطر التي تستخدم علامات مخصصة بدلاً من ذلك

راجع للشغل ، هناك أيضًا Bridge.net (http://bridge.net) ومجمعات أخرى من C # إلى Javascript يمكن دمجها مع حلول XAML مثل Fayde

إعادة XAML على HTML5 / JS / إلخ. هناك مشروع مثير للاهتمام Granular والذي يعيد تطبيق WPF. يستخدم Saltarelle للترجمة إلى JS. مثال حي هنا .

هذا الحبيبي رائع جدًا ، @ ethanhs. لم أكن على علم بذلك. نظرًا لأنه اتخذ نفس الأسلوب CSHTML5 و JSIL و Bridge.net (الذي يذكره birbilis ) ، فإنه يعاني من نفس المشكلة المتمثلة في عدم القدرة على مشاركة الكود بين الخادم والعميل من خلال استخدام PCLs ، وهو حقًا الخيار الوحيد القابل للتطبيق طريقة للقيام بذلك في هذه الأيام.

وبقدر ما يبدو هذا المشروع رائعًا ، فإنه يلخص إلى حد كبير المشهد الجليل الذي اضطر مطورو .NET إلى تحمله منذ زوال Silverlight. يقوم هذا العمل وما يقرب من اثني عشر شخصًا آخر بعمل "نوعًا ما" في جعل .NET يعمل في المتصفح ، ولكن ليس تمامًا التجربة الكاملة التي يتوقعها أولئك الذين لديهم تجربة Silverlight.

لا يزال هناك حل واحد موحد يجعل المطورين ينسون Silverlight. لكننا نقترب. آمل ، على الأقل. WebAssembly يبدو واعدًا ولكني لم أر / أسمع أي تطورات مهمة منذ فترة حتى الآن. يبدو أن المنفذ / المبادرة التي يقودها JSIL قد تباطأت إلى حد ما ولم يتم تسجيل وصولها منذ أكتوبر الماضي.

نأمل أن نحقق اختراقًا هنا في المستقبل القريب. أود أن أرى إعلانًا صدر في // بناء العام المقبل ينص على ذلك. : قلب:: +1:

سيكون هذا أحد أفضل الأشياء في السنوات القليلة الماضية التي حدثت لـ XAML.
صوّت هنا !

رائعbbougot. هناك أيضًا تصويت آخر ، حصل - أخيرًا - على بعض الاهتمام ، بعد ما يقرب من 15 شهرًا من الوجود ، دون احتساب ما يقرب من 3 سنوات من عدم التعرف على نظام Xaml الرهيب لتبدأ به (لكنني استطعت!):
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

(على محمل الجد ، 15 شهرًا للاعتراف بالتصويت لأكثر المشاكل وضوحًا؟ ما الذي يفعله فريق UWP هناك ؟؟؟ متى سيتولى فريق Visual Studio أو .NET المسؤولية وتصحيح السفينة ؟؟؟ .. عفوًا ، هذا صحيح ، كنت أستطرد ...)

أيضًا ، لا تنسَ التصويت لصالح هذا الموضوع. إنها تعمل بشكل جيد في 60 حاليًا ، لا سيما بالنظر إلى أن هذه المشكلة بدأت قبل أن يكون لدينا وسائل الراحة الفاخرة مثل GitHub Reactions. :ابتسامة:

Xaml هو الوحيد الذي لديه القدرة على توحيد النظام البيئي للعميل بأكمله!
من فضلك تخلص من DirectX ، يرجى عناق OpenGL ،!
يتم تشغيل UWP على جهاز الكمبيوتر ، على الهاتف ، على موقع الويب!
فيفا Xaml!

لذا ، سؤال مدني هنا terrajobst و harikmenon و karelz (أرى أنك أضفت علامة مؤخرًا ، لذا تهانينا ، سأجذبك إلى هذا!). بدافع الفضول البسيط ، قررت أن أحصل على القليل من المغامرة وتحقق من تصفية GitHub المتقدمة (أو ربما لا) في هذا الريبو. معتبرا أن هناك الكثير من الأصوات وما لم يكن لقضايا مختلفة.

هذا هو عنوان URL الذي أستخدمه:
https://github.com/dotnet/corefx/issues؟q=is٪3Aissue+is٪3Aopen+sort٪3Areactions-٪2B1-desc

يبدو كما لو أن هذه المشكلة بها 82 تصويتًا مؤيدًا حاليًا ، وإذا كنت على صواب ، فإن أقرب عنصر تالي في القائمة هو 17. وهذا يجعل هذه المشكلة إلى حد بعيد هي الأكثر طلبًا / تصويتًا لإصدار هذا الريبو ، أليس كذلك؟

إذا كان الأمر كذلك ، فقد كنت أشعر بالفضول إذا كان لهذا أي تأثير على أولوياتك و / أو تخطيطك. من الواضح أن هذا يبدو أنه سؤال / عنصر شائع جدًا الآن (مرة أخرى ، إذا فهمت بشكل صحيح) ، لذلك أعتقد أنه ربما يكون من الجيد سماع تحديث أو تسجيل وصول فيما يتعلق بإمكانية بدء محادثة نحو التقدم في التقدم هذه المسألة محتمل.

سيكون من الرائع الحصول على أي منظور / سياق هنا ، و / أو إذا كان لدي شيء أسيء فهمه تمامًا فيما يتعلق بطلب العملاء. يحدث ذلك. 😄

يركز مهندسو .NET Core بشكل كبير على .NET Standard 2.0 (أيضًا طلب مرتفع من العملاء) - راجع التفاصيل هنا وهنا . سننظر في المكتبات الأخرى غير الموجودة في تلك القائمة بعد أن نجعل .NET Core يصل إلى أحدث معيار.

شكرا لتوضيح الاستعلام عن التصويتات الايجابية!

شكرا لردكم @ karelz! مقدر جدا. 👍

👼 👼 👼 سأترك هذا هنا في حالة رغبة أي شخص في الإعجاب / إعادة التغريد. 👼 👼 👼
https://twitter.com/MikeEEE76/status/776769805722521600

لقد كنت أعمل مع xaml منذ الإصدار 3 من .net ، وشعرت بتقليص الحجم مع Silverlight وحتى وفاته. أنا شخص يحب التغييرات من أجل التحسين لجعل الأمور أفضل وأكثر فائدة. ولكن الآن مع UWP ، أجد تراجعًا بدلاً من المضي قدمًا. لا تمانع في جميع الميزات الجديدة التي إذا شعرت أنها رائعة ، ولكن في حالة عدم وجود دعم xaml الكامل مثل تطبيق سطح المكتب. كنت أحاول إنشاء تطبيق جديد في UWP ، وتعلمت بالطريقة الصعبة أن كل شيء تعلمته قد تغير مرة أخرى ، لا يمكنني العثور على الكثير من الدعم عبر الإنترنت ، حيث انتقلت مكتبة xaml إليه. على سبيل المثال ، الزينة التي كانت في إطار العمل لم تعد موجودة ، x: ثابت للخصائص التي لا تعمل ، عليك البحث عن ساعات للعثور على مثال أو ما يجب القيام به. لا يوجد رابط لإظهار من xaml القديم إلى UWP الجديد ...

giworking من الواضح أن MS يجب أن تنتبه لتنمية العملاء! كما تم اقتباس Satya Nadella ، فإن azule هو جوهر MS ومستقبله ، وأقوى طاقة لتعزيز azule هي النظام البيئي .net بأكمله. بالمقارنة مع جافا ، فإن جانب العميل هو السلاح الوحيد تقريبًا لإقناع المبرمجين والشركات باحتضان سحابة MS (في الصين ، تعد net حقًا في حالة كارثية ، يتحدث الناس عن جافا ويتفاعلون ، "ما هو f k s t xamarin؟". ....). لذلك ، بصفتي مبرمجًا صينيًا ، عندما أرى xamarin و uwp و typecript و cshtml5 ، فأنا أعلم أنه من الممكن توحيد جانب العميل بالكامل في وضع xaml + C # ، ولكن لماذا لا يرى أصدقاؤنا في MS فرصة للحصول على دعم حصة السوق الصينية مع إذا؟

واو ، لقد تجاوزت هذه المشكلة الآن 100 تصويت مؤيِّد! شكرا جزيلا لكل من أظهر دعمهم لك. إذا كان أي شخص مهتمًا ، فهناك مقال رائع حقًا ( حقًا! ) بقلم terrajobst مع مشاركة مطور العلامات التجارية الهائلة في التعليقات هنا:
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

(على محمل الجد ، يجب على كل موظف في MSFT ينشر مشاركة مدونة قائمة على الشركة أن يتبع توجيه السيد لاندويرث حول كيفية النشر والمتابعة بالتعليقات التي لا مفر منها والتي لا حصر لها والتي لا حصر لها والتي تظهر بعد ذلك. إنه حقًا يتصدر كل شيء ويبدو مثل الكثير من مؤلفي MSFT ، اتركوا منشوراتهم تجف وترك الأسئلة للموت ، وهي بالطبع طريقة مروعة للتعامل مع جمهورك!)

على أي حال ، بالتأكيد تستحق القراءة إذا لم تكن قد فعلت بالفعل ، وخاصة التعليقات. يقودني هذا إلى سبب النشر الآن لأنني سعيد جدًا برؤية هذه المشكلة مذكورة في التعليقات جنبًا إلى جنب مع الشغف / الرغبة في إدخال System.Xaml في .NET Standard / عصر الأنظمة الأساسية. 👍

154 صوتا ايجابيا ... والعدد جارى. 😎 العدد الأعلى التالي هو 25 كمرجع. #عجلة صار

هذا يحتاج إلى القيام به. احصل عليه!

لدينا تطبيق ReactWindows يستهدف WPF ونود استخدام .NET Native عليه لتحسين تجربة التنزيل / التثبيت لأول مرة لعشرات الآلاف من مستخدمي Windows 7. لدينا أيضًا خطط مستقبلية لجلب React Native إلى Linux وربما إعادة استخدام التعليمات البرمجية المشتركة ReactWindows ولكن مع استهداف Xamarin.Forms.

يعد توفر System.Xaml (وأنواع أخرى / أسلوب / تبعيات التجميع لـ WindowsBase و PresentationCore و Xamarin.Forms) في NETCore vNext أمرًا بالغ الأهمية لهذه الإستراتيجية. يمكننا التغلب على هذا النقص من خلال إعادة تأليف وإعادة استهداف التجميعات الموجودة ، أو عن طريق ملء الأنواع / الطرق المفقودة في Mono's System.Xaml وبنائه لـ .NET Core ، ولكننا نفضل حقًا أن تقوم Microsoft بالتقدم وتقديم ما هو ضروري للمنصة .. / ccrozele @ pre10der89

matthargett حظا سعيدا في هذا. لقد تغلبت على هذه المشكلة حتى الموت عندما كنت أبحث في جلب سير العمل إلى .net core. حتى أنه ذهب إلى أبعد من ذلك للوصول إلى فريق xaml. إنهم ليسوا مهتمين حتى عن بعد بفتح System.Xaml. لا أفهم لماذا - بالتأكيد لا يوجد شيء يستحق الحماية هناك.

قد يتم النظر في هذا بعد الإصدار 2.0 في نهاية أبريل.

يا رفاق ، مرة أخرى ، لسنا بحاجة إلى System.XAML لجعل WF يتم نقله إلى netstandard1.x ... هناك بالفعل عمل جيد من dmetzgar حيث جوهر عمل WF. القطعة الرئيسية المفقودة هي المعاملات التي أعتقد أنها ستعود في النهاية في netstandard2.x .

المبدأ التوجيهي الرئيسي من منفذ dmetzgar هو عدم وجود أي نوع من لغة التصميم مرتبطة بالجوهر ولديها بدائل أساسية حتى يتمكن الأشخاص من إجراء تسلسل لسير العمل كما يريدون وبعد ذلك ، إنشاء مصممين فوقه.

بالطبع سيؤدي هذا النهج إلى توافق غير رجعي مع تدفقات العمل الحالية المستندة إلى XAML ، لكن صدقوني ، انقل أي شيء إلى .Net Core هو تغيير جذري كبير ، لذلك يحتاج الناس إلى فهم ذلك.

يوجد OminiSharp حول ذلك يمكن الاستفادة منه لمصممي XAML ولكن مرة أخرى ، التصميم / التسلسل هو جزء من جوهر WF. يجب أن يكون نحيفًا مثل أي شيء آخر مع .Net Core.

أود أن أقول إن هذه المشكلة صُنعت وبصوت عالٍ أن الناس يريدون نقل WF إلى .Net Core ، أعتقد فقط أن الشكوى من فريق System.XAML إلى OSS ، لا تكون منتجة. فريق XAML لديه أولويات أخرى وهو أمر أساسي لأعمال Windows / UWP / Xamarin لذا لا تتوقع الحصول على OSSed قريبًا. بدلاً من ذلك ، أود أن أطلب من dmetzgar الإعلان رسميًا عن WF repo under .Net Foundation ، وتوجيه المجتمع للحصول عليه وتشغيله دون تحديد أي جدول زمني أو وعود عند إنجاز إصدار netstandard2.x . سيكون عملاً مستمرًا مدفوعًا من قبل فريقه ، ويساعده في الغالب المجتمع الذي يرغب بوضوح في المساعدة وإخراجها.

انظر إلى مدى سرعة تطور الأشياء في مشروع أورليانز ... لقد كان أحد أبحاث Microsoft التي حصلت على OSSed العام الماضي وهو أحد أكبر المستودعات وأكثرها نشاطًا على .Net Foundation وهو مدفوع في الغالب بجهود المجتمع (لا يزال لديه فريق MSFT يعمل بدوام كامل فيه).

على أي حال ، IMHO ، أعتقد أننا بحاجة إلى التوقف عن الصراخ والبدء في فعل شيء ما. من الواضح أن فريق dmetzgar ليس لديه نطاق ترددي للعمل على ذلك لأن اهتماماتهم الرئيسية هي دعم المستخدمين الرئيسيين لـ WF ، والتي هي في الأساس عمليات نشر Sharepoint كبيرة ليس لديها خطط للوصول إلى .net core على الإطلاق. لذلك يجب أن يكون المجتمع مدفوعًا بجهد (تحت إشراف فريق dmetzgar ).

يا رفاق ، مرة أخرى ، لسنا بحاجة إلى System.XAML لجعل WF يتم نقله إلى netstandard1.x ...

galvesribeiro قد يكون هذا صحيحًا ، ولكن هذه المشكلة هي نقل System.Xaml إلى .NET Core ، والتي تعد إلى حد بعيد الميزة الأكثر طلبًا في الريبو حيث يطلب فريق .NET الحصول على تعليقات. إذا لم تستمع إلى ملاحظاتك ، فلماذا تطلبها؟ على أي حال ، WF هو ببساطة _ أحد السيناريوهات التي يرضيها منفذ System.Xaml. كما تعلم (أو ينبغي!) System.Xaml قادر على أكثر من ذلك بكثير.

فريق XAML لديه أولويات أخرى وهو أمر أساسي لأعمال Windows / UWP / Xamarin لذا لا تتوقع الحصول على OSSed قريبًا.

نعم ، هذا نوع من المشكلة هنا وما نطلب تغييره. :) أيضًا ، لست متأكدًا من وجود "فريق Xaml" هذه الأيام ، هل هناك ؟! إنه يشعر حقًا أن هذه التكنولوجيا قد تم إغلاقها وأننا بدأنا في الحصول عليها.

على أي حال ، IMHO ، أعتقد أننا بحاجة إلى التوقف عن الصراخ والبدء في فعل شيء ما.

أتفق بنسبة 100. FWIW ، SuperJMN أصدر مؤخرًا OmniXamlv2.0 ، لذلك هناك بعض الجهود المجتمعية الجارية التي يمكن الاستفادة منها بينما تعطي MSFT الأولوية لطاقاتها وجهودها حول هذه المشكلة (والتي ، بالمناسبة ، مستمرة منذ حوالي 11 شهرًا - وما زالت مستمرة).

بالحديث عن ذلك ، إليك سلسلة رسائل لطيفة حول ذلك بالضبط (أي عدم نشاط MSFT في هذا الشأن) ، مع اقتباس من terrajobst :

لأكون واضحًا ، أنا لا أقول أن System.Xaml لا يمكن أو لا ينبغي أن يكون عبر الأنظمة الأساسية. ما أقوله هو أن System.Xaml ليس مفيدًا جدًا خارج WPF و WF ، و NuGet هو مقياس وكيل معقول لهذا البيان. بالطبع ، يمكن جعل System.Xaml مفيدًا خارج نطاق واجهة المستخدم ، ولكن هذه خطوة ثانوية. أفضل استخدام مواردنا الآن لجعل الأجزاء الأساسية تعمل بشكل جيد وكامل. علاوة على ذلك ، من خلال وجود قاعدة متقاربة ، يصبح نقل المكونات ذات المستوى الأعلى ، مثل System.Xaml أسهل بكثير أيضًا.

لذا فهي ليست عبارة إما - أو ؛ إنه بيان بأمر التنفيذ.

بغض النظر عن العبارة غير الصحيحة تمامًا حول System.Xaml ليست مفيدة خارج WPF / WF ، فإن كل هذه الأصوات لمدير المشروع - glish بالنسبة لي ، مع عدم وجود نية للالتفاف على هذه المشكلة على الإطلاق. هدفي ليس أن أكون حاسمة في هذا البيان لأنني أؤيد بالكامل Immo والعمل الرائع الذي يقوم به هنا. ومع ذلك ، فقد كنت حول الكتلة بما يكفي للسماح لهذا النوع من اللغة بإعطائي وقفة ووضعني في موقف الانتظار والترقب (أو بالأحرى "صدق ذلك عندما أراه" LOL!) فيما يتعلق بهذه المشكلة.

في غضون ذلك ، أؤيد الجهود الحالية في .NET Standard 2.0 وأتطلع إلى ما سينتج عن ذلك. ربما قد يكون أفضل مما كان متوقعا. على أقل تقدير ، يبدو أننا سنتمكن من استعادة System.Xaml لمشاريع .NET Core التي تعمل على أنظمة تشغيل Windows ، وهي بداية جيدة بما يكفي بالنسبة لي. 👍

@ Mike-EEE أولاً وقبل كل شيء ، أنا آسف ... على الرغم من أنني كنت أرد على هذا https://github.com/dotnet/corefx/issues/2394 oO تم ربط هاتين المسألتين عدة مرات لدرجة أنني شعرت بالارتباك.

ثانيًا ، لا أقول بأي حال من الأحوال أن XAML مفيد فقط لواجهة المستخدم. لقد استخدمته لسنوات عديدة على بنيات TFS ، WF نفسه ومؤخرًا لواجهة المستخدم. هناك مجموعة من DSLs مثل Azure ML ، وأخرى يمكنها الاستفادة من XAML.

ما قصدته هو أنني لا أرى XAML يتم نقله قريبًا إلى .Net Core. كما قال Immo ، فهم بحاجة إلى تصحيح الأمر أولاً مع الأنظمة الأساسية الحالية. لا يوجد لدى .Net Core أي مكتبات أصلية لمعالجة الصور على الإطلاق.

هناك العديد من تطبيقات XAML التي تتراوح من WPF كامل الميزات إلى الضعيفة وتفتقر إلى الكثير من الميزات في UWP. يجب توحيدها واستقرارها قبل أن يحصل هذا الشيء على OSS. أنا لا أتحدث من قبل الفرق العاملة فيه. أعتقد فقط أنني لن أختلف عنهم إذا اضطررت إلى تحديد أولويات مواردي.

فيما يتعلق بـ WF ، آسف مرة أخرى ، لكن تعليقي السابق كان مستهدفًا في الغالب لأولئك الذين يأملون في أن تكون هذه المشكلة هي السبب في أن منفذ WF إلى النواة لا يحدث بهذه السرعة ، وهذا ليس صحيحًا .

تم ربط هاتين المسألتين مرات عديدة لدرجة أنني كنت في حيرة من أمري.

Hahagalvesribeiro لا أستطيع إخبارك (أو أخشى الاعتراف) كم مرة تعرضت للعض أيضًا. لا تقلق حيال ذلك. أنا شخصيا أقدر المدخلات بغض النظر!

FWIW ، يبدو أيضًا أن cwensley يواصل القيام بعمل رائع على @ Portable.Xaml أيضًا ، بعد أن قام مؤخرًا بإجراء تحسينات في الأداء على تكيفه الأحادي مع System.Xaml مما يجعله أسرع من الإصدار الأصلي. يبدو تقريبًا أن هذا يمكن أن يكون نقطة انطلاق جيدة للجهد هنا ، لأنه ربما يكون الأقرب إلى تجربة System.Xaml الأصلية لجميع النكهات / الخيارات الموجودة هناك. فقط سنتان بسبب الكافيين في الصباح.

يرجى نقل System.Xaml إلى .NetCore

FWIW ، أكثر من 200 صوت لهذه القضية ، ويوجد الآن عند 202. ثاني أعلى إصدار هو dotnet / corefx # 13526 جالسًا عند 47. حسنًا ، WAS 47 ... الآن 48 بعد تصويتي. :) (اذهب وأظهر له بعض الحب ، إنها فكرة جيدة.) # عجلة السرعة

شكرا للتذكير @ Mike-EEE ؛-). لتحديد التوقعات: ما زلنا غير مستعدين بعد لبدء البحث فيها بعمق - أتمنى شخصيًا أن نتمكن بحلول شهر مارس من التعليق أكثر على خطواتنا الرسمية التالية ، حتى لو كانت مرة أخرى "ليس لدينا خطط بعد" (إخلاء المسؤولية: أحاول التعبير عن أفضل تخميني الشخصي ، من فضلك لا تعامله على أنه وعد رسمي من الفريق!).

عندما ناقشنا هذه المشكلة قليلاً في المرة الأخيرة ، كان السؤال الرئيسي الذي طرح هو تحديد أي من أكثر من 200 صوت يتعلق حقًا فقط System.Xaml مقابل WPF. الافتراض هو أن العديد من الناس لا يميزون بين الاثنين. أي اقتراح أفضل السبل للقيام بذلك؟ (على سبيل المثال ، إنشاء مشكلتين محددتين ومطالبة الأشخاص بالتصويت لصالح WPF مقابل "Pure Xaml ، وليس WPF")

كما أنه من المفيد الحصول على قائمة موجزة من السيناريوهات لـ System.Xaml مع بعض تقديرات الأولوية (وهي الآن مبعثرة عبر مناقشة طويلة). @ Mike-EEE هل يمكن أن تساعدنا في تجميعه من فضلك؟ (كما يبدو أن لديك اهتمامًا قويًا ومعرفة عميقة بالمنطقة)

بالتأكيد System.Xaml هو ما يريده الناسkarelz. إذا كان شخص ما يفكر في WPF هنا فهو ليس المكان المناسب IMHO. هناك مجموعة من الأطر الأخرى التي تستفيد من XAML مثل WF و TFS Build وما إلى ذلك والتي لا تزال تستخدم System.Xaml وهذا من شأنه أن يمنحنا يدًا كبيرة.

karelz أقدر حقًا ردك هنا. شكرا لك على الوقت للقيام بذلك. كما يذكر galvesribeiro ، يعد System.Xaml أكثر من مجرد واجهة مستخدم ، والذي يبدو أنه فهم رئيسي يفتقده الكثير من MSFT ، للأسف. إنه نموذج تسلسل قوي يضعه فوق أي حل تسلسل آخر موجود ، لا سيما عندما يتعلق الأمر بوصف التطبيقات ، وهو أفضل ما يمكن فعله (الحرف "A" في لقبه ، بعد كل شيء). لسوء الحظ ، تم الخلط بين "التطبيق" و "واجهة المستخدم" وبالتالي الاحتكاك هنا.

كان التغاضي عن هذا الجانب بمثابة فشل رئيسي لـ UWP وهو جزء من سبب عدم إعجاب أحد حقًا بالعمل معه. على العكس من ذلك ، يبدو أن Xamarin قد فهمت هذا الجانب الرئيسي في نكهة Xaml ، لكنه داخلي ولا يتم الكشف عنه باعتباره عرضًا موثوقًا من الدرجة الأولى (وهو إلى حد كبير ما هذه المشكلة بعد هنا).

يبدو أن منفذ TBH ، cwensley لـ System.Xaml في Portable.Xaml هو الأوفر حظًا في الوقت الحالي. لم يقتصر الأمر على نقل نظام System.Xaml الخاص بمونو (مع الحفاظ على واجهة برمجة التطبيقات المألوفة بشكل عام) ، ولكنه أضاف ميزات جديدة وحسّن أداءه بالفعل ليكون _أفضل_ من System.Xaml.

من وجهة نظري ، يمكن أن تكون هذه المشكلة بسيطة مثل العمل مع cwensley لجعل ما حصل عليه في مكتبة Xaml الموثوقة عبر الأنظمة الأساسية لاستخدامها في المستقبل.

خارج هذا ، حيث يصبح الأمر صعبًا وقد يضيف إلى نظرتك المعقدة (بشكل مفهوم) لهذه المشكلة. نظرًا لأن System.Xaml يوفر لغة معبرة وقوية لوصف التطبيقات (مرة أخرى ، ليس فقط واجهات المستخدم) ، فإنه يحتوي أيضًا على بعض دعم الأدوات الرائع المخبوز في Visual Studio (وبالطبع Blend). من الناحية المثالية ، سيكون من الرائع الاستمرار في نفس التجربة الرائعة والحفاظ بطريقة ما على تجربة مصمم Xaml بطريقة متعددة المنصات ، ولكن هذا شخصيًا يتطلب كرزًا فوق كعكة رائعة نناقشها هنا. :)

أيضًا ، للتكرار هنا ، كان وعد Xaml (والتسليم) أيضًا تحسينًا لسير عمل التطوير بين المصمم والمطور. أود أن أعتقد أنه يمكننا في النهاية اتخاذ هذه الخطوة إلى الأمام وتحسين العملية بين التطوير و _devops_. وهذا يعني أنني أرغب في رؤية عالم يعمل فيه devops في محررات تكوين التطبيقات المصممة بشكل جميل (مدعومة من Xaml) لإدارة التطبيقات المنشورة وصيانتها.

_تتمثل الفكرة بأكملها هنا في تقليل التكلفة الإجمالية في تطوير التطبيقات من الترميز إلى النشر. يعد العمل مع محررين ومصممين رائعين أرخص (من منظور الموارد) من الاضطرار إلى البحث عن شخص ما وتوظيفه ليضع أيديهم في التعليمات البرمجية (و / أو البرامج النصية) لتحقيق السحر.

أشارك هذا معك من منظور الرؤية ، فقط حتى تكون على دراية. ومع ذلك ، لست متأكدًا من مدى اهتمامك بسماع ذلك. 😉 لذا ، إذا كان هذا مجرد "ما الذي يتطلبه الأمر لإغلاق هذه المشكلة وإبعادك؟" أود أن أقترح استكشاف إمكانية العمل مع السيد وينسلي ومعرفة ما إذا كان بإمكاننا الاستفادة من عمله الرائع حتى الآن (أو حتى إذا كان منفتحًا على القيام بذلك). إذا كانت هناك طريقة لضبط هذا الأمر بحيث يمكن أن يكون حزمة Xaml الموثوقة عبر الأنظمة الأساسية لإصدار .NET Core Wave 2 (في مايو أو نحو ذلك؟) فهو أفضل. :)

شكرا للمعلومات ، أنا مهتم بالتأكيد. أشعر أيضًا أن سؤالي (أسئالي) السابق لم يتم طرحه كما كنت أنوي ، لذا دعني أحاول أن أشير إلى بعض الأشياء:

نعم ، أنا بالتأكيد مهتم بالتفاصيل. لا أعتقد أن أي شخص يتعارض مع Xaml! = WPF من جانب MSFT. أنا بالتأكيد لم أحاول القيام بذلك. أنا أعرف فقط ما لا أفهمه تمامًا ، وأحاول سد الثغرات - أي الفهم الكامل للدوافع والحاجة لسيناريوهات "Xaml الخالص".
(راجع للشغل: أنا لا أفهم تمامًا سيناريو devops الخاص بك وكيف أن Xaml هو الشيء الوحيد / الأفضل للمساعدة هناك؟ أو كيف يتم استخدامه فعليًا في السيناريو على الإطلاق؟)

أنا لست هنا لمحاولة إغلاق هذه المسألة. لو سمحت! هذا حتى لم يخطر ببالي. أنا هنا لمساعدة المجتمع في تلخيص الطلب ، بحيث يمكن مناقشته مع الأشخاص المناسبين (فكر في المديرين في هذه الحالة). نعم ، جزء منه يعني أنني (و / أو فريقان آخران من MSFTs) يجب أن أفهم تمامًا طلب تمثيلها على مستوى أعلى - ومن هنا أسئلتي.

أعترف ، أنا مثال جيد لشخص لم يميز بين Xaml و WPF قبل أن يرى هذه المشكلة. من الدردشات العشوائية مع الآخرين في فريق .NET ، يعرف الكثير أن Xaml! = WPF ، لكنهم لا يرون "القيمة الضخمة" لامتلاك Xaml النقي الذي يتم طرحه هنا - لذلك أسئلتي أعلاه حول السيناريوهات. ستساعدني السيناريوهات / تساعدنا على فهم الدافع بشكل أفضل وإخبار / بيع القصة بشكل أفضل. (آمل ألا يكون مفاجئًا أنه في حالة عدم وجود قصة واضحة ، لا يشعر أحد بالحرص على تمويلها :) - القصة شرط أساسي للحصول على التمويل)
لذلك دعونا نتوصل إلى فكرة المصعد لتحريكها للأمام.

فيما يتعلق بعملcwensley - من الرائع أن نسمع أنه قد يكون هناك بعض الحلول ليست باهظة الثمن. ولكن مرة أخرى ، من المفيد حقًا أن نفهم أولاً الخلفية ولماذا ، قبل أن ننتقل إلى الحل. آمل أنه من المنطقي. (لا أحاول أن أكون رافضًا أو أي شيء - فقط أكرر أنه من الأسهل المضي قدمًا عندما يتم فهم السبب والاتفاق عليه)

galvesribeiro إذا كان شخص ما يفكر في WPF هنا فهو ليس المكان المناسب IMHO

أنا لا أشاركك في ثقتك بأن جميع الأشخاص الذين يزيد عددهم عن 200 شخص الذين صوتوا يفهمون حقًا Xaml! = WPF لمثل هذه التفاصيل. أعتقد أيضًا أنه على الأقل القليل من إلقاء نظرة عليه - نعم ، دعنا نحصل على Xaml أولاً ، سيكون من الأسهل بعد ذلك طلب WPF. لذا فإن السيناريو الخاص بهم دائمًا هو WPF ، في حين أن "Pure Xaml" هو مجرد خطوة أولى نحو ذلك.
وربما أكون مخطئًا (رغم أنني على الأقل لست الشخص الوحيد في فريق .NET الذي لديه هذه الشكوك) ...
قد تكون هناك زاوية أخرى لتقسيم "Xaml الخالص" إلى قائمة من السيناريوهات (WPF ، devops أعلاه ، ربما أكثر من ذلك؟) ثم مطالبة الأشخاص بالتصويت لهم - أي منهم يهم حقًا أولئك الذين صوتوا هنا؟ ماذا يريدون حقا؟
(هذه ليست تكتيكات تأخير ، أو أي شيء شرير ، فأنا أحاول فهم "العميل" هنا. وآمل أن يكون ذلك منطقيًا - إذا كان لديك اقتراحات أفضل حول كيفية الوصول إلى هذه البيانات ، فتحدث ، فأنا منفتح على طرق بديلة )

تحرير: كالعادة ، إذا كنت تعتقد أنني لا أقترب من المشكلة بالطريقة الصحيحة ، من فضلك قل ذلك. أحاول بذل قصارى جهدي هنا للمساعدة - بأحسن النوايا. لا أعاني من وهم معرفة كل شيء ، أو التفكير في أنني أذكى من أي شخص آخر.

karelz هناك مجموعة من أطر عمل واجهة المستخدم التي تعيد اختراع العجلة وكتابة لغات الترميز الخاصة بها لمجرد أن XAML ليس متقاطعًا حتى لو لم يعجبهم WPF على الإطلاق. أفالونيا هي واحدة من أفضلها. يستخدمون Omnisharp عندما يمكنهم الاستفادة من XAML الأصلي بدلاً من ذلك.

Workflow Foundation هو مستخدم / عميل كبير لـ XAML ويسأل الأشخاص الموجودون على Port WF إلى .Net Core thread دائمًا عن ذلك.

لذا ، نعم ، أنا أتفق معك في أنه يجب علينا تحديد التوقعات أو رسم مجموعة ميزات أولية على ما هو متوقع من اللوح المتقاطع System.Xaml مع الاستخدامات المرغوبة مثل UI و WF على سبيل المثال.

تضمين التغريدة

أعتقد أيضًا أنه على الأقل القليل من إلقاء نظرة عليه - نعم ، دعنا نحصل على Xaml أولاً ، سيكون من الأسهل بعد ذلك طلب WPF. لذا فإن السيناريو الخاص بهم دائمًا هو WPF ، في حين أن "Pure Xaml" هو مجرد خطوة أولى نحو ذلك.
وربما أكون مخطئًا (رغم أنني على الأقل لست الشخص الوحيد في فريق .NET الذي لديه هذه الشكوك) ...

إذن ... ما هي المشكلة في ذلك؟ يمكن أن يكون حل النظام الأساسي الذي يشبه WPF أمرًا جيدًا. لا يستطيع Xamarin عمل واجهة المستخدم الرسومية لسطح المكتب عبر الأنظمة الأساسية.

@ jnm2 ليس سيئًا - ولكن إذا كان هذا هو السيناريو الرئيسي (90٪ +) ، فيجب أن نخطط للقيام بالأمرين معًا. إن امتلاك Xaml بدون WPF لن يساعد في مثل هذه الحالة (على الأقل ليس كثيرًا). وقد يخلق (يحتمل) وهمًا غير صالح بأن WPF ملتزم وسيأتي بعد فترة وجيزة.

سيكون الحصول على WPF / GUI في .NET Core خطوة كبيرة لـ .NET Core ، والذي يستهدف بشكل أساسي سيناريوهات الخادم وتطبيقات وحدة التحكم الآن.

@ jnm2 وجود System.Xaml سيساعد بشكل كبير الأشخاص (مثلي) الذين _ يحاولون_ إحضار شيء مثل WPF إلى منصات أخرى (https://github.com/AvaloniaUI/Avalonia).

grokys هذا يبدو وكأنه سيناريو معقول - هل يمكنك توضيحه أكثر قليلاً؟ ما مدى ضخامة المساعدة؟ ما هو التحدي بدونه؟

أنا أيضًا أستخدم Xaml لإطار عمل واجهة مستخدم سطح المكتب عبر النظام الأساسي (بخلاف WPF) ، Eto.Forms . هذا هو السبب في أنني أنشأت مشروع Portable.Xaml في البداية ، وقد كان يعمل بشكل جيد بالنسبة لي ومستخدمي حتى الآن.

أنا لا أعارض المساعدة في جعل هذا تطبيقًا "موثوقًا" عبر الأنظمة الأساسية لـ xaml (كما يقول @ Mike-EEE). ومع ذلك ، ضع في اعتبارك أنني أعمل على هذا فقط في أوقات فراغي (؛

تضمين التغريدة
ليس فقط أطر عمل واجهة المستخدم ، بل يمكن استخدامها في العديد من المشاهد مثل XAML إلى HTML

Kation هل يمكنك مشاركة المزيد من التفاصيل ماذا تقصد بالضبط؟

راجع للشغل: لقد بدأت في تلخيص السيناريوهات في المنشور العلوي - إذا لم يكن السيناريو الخاص بك موجودًا ، يرجى وصفه وبمجرد فهمه ، سأضيفه هناك.

تضمين التغريدة
باستخدام محرر XAML القوي في الاستوديو المرئي ، يمكننا إنشاء محتوى مكونات مخصصة بسرعة.
بعد ذلك ، أعتقد أنه يمكننا استخدام XAML لإنشاء محتويات HTML في بعض السيناريوهات الخاصة ، وحتى المزيد من محتويات SVG.
هذا هو إطار عمل XAML إلى XML شبه نهائي لـ .Net 4.5. https://github.com/Kation/WebPresentation

لا أفهم سبب رغبتك في إنشاء HTML أو SVG من XAML. ما هي قيمة XAML هنا؟
هل قيمة أنه يحتوي على محرر VS لطيف؟ هناك أيضًا محررات HTML ، فلماذا لا تستخدمها بشكل مباشر؟
أم أنني أفتقد النقطة تمامًا؟

تضمين التغريدة
لأنني أرغب في إنشاء محتويات مثل WPF باستخدام قالب ونمط في بعض المشاريع.

@ karelz شكرا مرة أخرى على الحوار. أنا شخصيا أقدر ذلك كثيرا.

لا أعاني من وهم معرفة كل شيء ، أو التفكير في أنني أذكى من أي شخص آخر.

أوه ، أنا أحسد. 😉

لذا فإن السيناريو الخاص بهم دائمًا هو WPF ، في حين أن "Pure Xaml" هو مجرد خطوة أولى نحو ذلك.

نعم ، هذا هو الخلط الذي ذكرته مرة أخرى. Xaml هو نموذج تسلسل ، خالص وبسيط. يمكنك تعريف ووصف تطبيق - ومكوناته - فيه. لتبدأ ، فيما يلي مثال على _تطبيق وحدة التحكم_ الموصوف في Xaml:
https://github.com/DevelopersWin/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

يمكنك أن ترى أن هناك أوامر موصوفة في Xaml توفر إرشادات حول ما يجب تقديمه للمستخدم من خلال استخدام مدخلات ومخرجات وحدة التحكم. هذا لا علاقة له بـ WPF أو "UI" (على الرغم من أن هذه من الناحية الفنية هي واجهة المستخدم بمعنى أن CLI هي واجهة المستخدم ، ولكن نأمل أن تتمكن من تحديد الفرق). بالإضافة إلى ذلك ، يمكنك أن ترى أنني أستفيد من امتدادات العلامات وإعلانات الأعضاء الثابتة مباشرة في الملف. هذا شيء لم أره في JSON أو أي تنسيق بيانات آخر. هذه حقًا قوة Xaml ، IMO.

كمثال آخر لسيناريو "Pure Xaml" ، إليك الملف الذي أقترحه من أجل MSBuild جديد لا يعرف التنسيق:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Processor.xaml

(إذا صعدت إلى مستوى ما ، يمكنك رؤية التنسيقات الأخرى التي تفعل الشيء نفسه ، وهذا يحدث فقط ليكون إصدار Xaml)

هذا هو ملف المعالج الذي هو مرة أخرى مجموعة من الأوامر ( System.Windows.Input.ICommand ) التي تصف الخطوات التي يجب اتخاذها في عملية البناء النظرية. مرة أخرى ، لا يوجد WPF أو UI ، ولكن يمكنك أن ترى أنه يرسل رسائل إلى وحدة التحكم.

إحدى الميزات التي أود الإشارة إليها هنا والتي ذكرتها سابقًا هي الأدوات المضمنة في Visual Studio التي أحصل عليها من هذا الملف:

بدون القيام بأي عمل أو تحديد أي مخطط خارجي ، فإن Visual Studio ببساطة "يضيء" ويوفر محررات خاصية كاملة مع القوائم المنسدلة وواجهة مصمم أخرى بناءً على مخطط فئة الملف الذي أعمل معه (نأمل أن يجعل هذا سيناريو devops أسهل لفهم).

بالإضافة إلى ملف المعالج ، إليك المشروع النظري أو ملف الإدخال الذي يمكن استخدامه لإرساله إلى المعالج:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Project.xaml

هنا أحاول الوصول إلى النقطة الرئيسية باستخدام _امتدادات markup_ تستخدم لتوفير إصدار (يمكن تصوره من ملف خارجي) وأيضًا استخدام استعلام لتوفير الملفات التي تم تجميعها للبناء (لاحظ أنه ربما لا ترغب في القيام بذلك في الواقع في نظام البناء النهائي ، لكنني أردت إثبات إمكانية ذلك).

راجع للشغل ، رمز المثال هذا يعمل بكامل طاقته ، لذا يجب أن تكون قادرًا على الحصول على SLN من هذا الريبو وتشغيل إصدار Xaml ، يجب أن تبدو النتائج كما يلي:

(ملاحظة: يعمل على " جهازي" لذا قد يختلف عدد الأميال الخاصة بك. 😄)

راجع للشغل: أنا لا أفهم تمامًا سيناريو devops الخاص بك وكيف أن Xaml هو الشيء الوحيد / الأفضل للمساعدة هناك؟ أو كيف يتم استخدامه بالفعل في السيناريو على الإطلاق؟

نعم ، لقد ناقشت ما إذا كنت سأدخل في ذلك ، حيث شعرت أن رسالتي تطول قليلاً. نأمل الآن أن يساعد مكون المصمم المرئي أعلاه في توضيح ما أقوم به هنا.

يرجى العلم والملاحظة أن هذه هي اللعبة النهائية النهائية بالنسبة لي ولماذا أنا غاضب جدًا حول كل هذا. _ السبب في ذلك هو أنه ينتهي به الأمر إلى تقليل التكلفة الإجمالية لملكية أحد التطبيقات على مدار حياته ._

إذن ، في الجوهر هنا ، ما نتحدث عنه هنا هو التطوير القائم على POCO ، حيث يحدث التحرير والتصميم على POCO المستخدمة في عملية التطبيق. كما نعلم ، سيعمل المطور والمصمم على ملف Xaml الذي يصف عناصر POCO التي تتعامل مع مجال UI (هنا هو "WPF" التقليدي لـ "Xaml" إذا صح التعبير).

في عالمي ، أود أن أرى هذه العملية ممتدة بحيث يسلم التطوير ملفات Xaml للمطورين لاستخدامها لإدارة / صيانة التطبيقات التي تم نشرها في بيئة حية.

يمكنك التفكير في هذا كملفات تكوين حية. يجب تسوية كيفية تحميلها ، ولكن النتيجة النهائية ستكون شيئًا مثل ما تراه في لقطة الشاشة أعلاه في Visual Studio. بدلاً من إجبار المستخدم النهائي (devops) على وضع أيديهم في التعليمات البرمجية (أو بالأحرى ، إجبار منظمة على توظيف المواهب / مجموعة المهارات باهظة الثمن المطلوبة على هذا النحو) ، فإنهم بدلاً من ذلك يعملون مع ضوابط التحرير المرئي المقيدة والمصادق عليها لتكوين و الحفاظ على التطبيق.

_تكمن الفكرة هنا في أنه نظرًا للجهد (والمهارة) المطلوبين للقيام بذلك بدلاً من مطالبتك بمعرفة وفهم الكود ، فإن تكلفة صيانة التطبيق بعد النشر تنخفض بشكل كبير ._

أحد الجوانب التي لم أذكرها حول هذا هو أن عناصر التحكم هذه قابلة للتخصيص بالفعل. يحتوي Visual Studio على واجهة برمجة تطبيقات واسعة النطاق (وإن كانت متقادمة) لتحديد المحررات المرئية المرتبطة بخصائص POCO هذه:
https://msdn.microsoft.com/en-us/library/microsoft.windows.design.model.designmodevalueprovider(v=vs.90).aspx

كل هذا متاح الآن في Visual Studio دون أي عمل إضافي أو جهد أو جهد. لذا فإن الفكرة النهائية هنا هي إنشاء مجموعة من المحررين والمصممين الأقوياء للمساعدة ليس فقط في عملية التطوير ، ولكن في النهاية عملية التطوير.

مرة أخرى ، هذا كله رؤى وبدون أي أساس واقعي فعلي (حتى الآن). من المؤكد أن هذه ليست فكرتي تمامًا ولكنها مستوحاة من مجموعة الأنماط والممارسات باستخدام محرر التكوين المستند إلى نماذج Windows . لقد اتخذت هذا المصاصة خطوة أخرى إلى الأمام ورأيت استخدام ذلك من خلال قوة Xaml.

يُرجى إعلامي إذا كان لديك أي أسئلة إضافية حول هذاkarelz. مرة أخرى أقدر الحوار. لا يوفر فقط الفرصة للمشاركة ، ولكنه يمنح أيضًا فرصة للتحقق من أفكاري ومعتقداتي. ومع العودة إلى فكرة معرفة كل شيء (نعم ، أنا مذنب 👼) ، أحاول أن أبقى متفتحًا على الأشياء وأدرك أنني لا أملك كل الإجابات. هذه بالتأكيد عملية أحاول باستمرار تحسين أدائها. شكرا لك مرة أخرى!

karelz - تستخدم Avalonia حاليًا OmniXaml كمحرك XAML الخاص بها ، وبينما يعمل هذا بشكل جيد ، لا تزال هناك أخطاء وميزات مفقودة. مثل Portable.Xaml ، يتم صيانة OmniXaml بواسطة متطوع ليس لديه دائمًا الكثير من الوقت للعمل عليه.

إذا قررت في الواقع عدم فتح System.Xaml ، فربما يكون إصدار مجموعة الاختبار الخاصة بك بمثابة حل وسط جيد - على الأقل بهذه الطريقة يمكننا ضمان أن تطبيقات الطرف الثالث مثل OmniXaml و Portable.Xaml كانت متوافقة قدر الإمكان.

أعتقد أن ما يحتاجه النظام البيئي .net هو تنسيق تسلسل افتراضي قابل للقراءة من قبل الإنسان - شيء مثل JSON في عالم Javascript. يجب أن يستخدم هذا التنسيق أنواع بيانات donet ويستخدم مباشرة POCOs كمخطط. ثم يمكن استخدام هذا التنسيق لوصف كائنات POCO. هذه الأوصاف مكتوبة بقوة وثابتة. والتي يمكن أن تكون تخطيط واجهة المستخدم أو تكوين تطبيق وقت التشغيل أو وصف سير العمل / المشروع أو حتى للاتصال بين برنامجين. net. وحتى التواصل مع الأنظمة البيئية الأخرى (مثل الويب / جافا سكريبت) ممكن أيضًا ، نظرًا لأنها تنفذ التنسيق. ولكن يجب أن يتم تصميمه حول النظام البيئي .net. هذا هو السبب في أن JSON / BOND / Protobuf / XML ليس كافيًا.

من الناحية التاريخية ، كان XAML يفي بالمسؤولية إلى حد ما. السؤال الآن ، ما مدى جودة هذا الدور. إذا كان جيدًا بما فيه الكفاية ، فأعتقد أن XAML يجب أن يتحول إلى معيار الشبكة ثم تطبيقات .net. ولكن ، إذا أمكن ، يجب أيضًا أخذ التنسيقات الأخرى في الاعتبار. أعتقد أنه في الأسبوع الماضي ، خرج http://www.ammyui.com/ . تنسيق وصف واجهة المستخدم يركز على البساطة ولكنه يُترجم إلى XAML. لأن XAML لم يكن بسيطًا بما يكفي. لقد اقترحت بنفسي تنسيقًا واحدًا في roslyn repo- dotnet / roslyn # 16648 استنادًا إلى عوامل التهيئة (الكائن والتجميع والفهرس). وقد تم أخذ اقتراحي بالفعل (ثم تم تعديله بشكل طفيف) من منشور المدونة هذا بواسطة bricelam من فريق إطار عمل Entity. يحتوي كل من مشاركته وخيط اقتراحي على بعض الأمثلة.

وجهة نظري هي أنه يجب أن يكون هناك تنسيق افتراضي لـ .net ، سواء كان XAML أو أي شيء آخر.

grokys لقد أردت أن أذكر OmniXaml ، ودعوت SuperJMN للمحادثة هنا ، لكن لا يبدو أنه يريد المشاركة أبدًا. لست متأكدًا مما إذا كانت الإعدادات أم ماذا (لقد قمت أيضًا بمحاولة في gitter أيضًا - نظرًا لأنك تعمل معه ، ربما يمكنك الحصول على حظ أفضل بسحبه إلى هنا 😄). OmniXaml بالطبع موضع ترحيب في هذه المحادثة أيضًا.

@ gulshan + 💯 👏 👏! ها ها. جزء من الجزء المربك من كل هذا هو أن Xaml هو تنسيق وتقنية MSFT. مع كل الاستثمارات والأدوات المبنية حولها - سواء مع MSFT أو في الشركات ، فمن غير المفهوم حقًا سبب وجود فجوة في ضمان استمراريتها بحيث يمكن زيادة الجهود والاستثمارات الحالية.

بعد قولي هذا ، أحب ما أراه مع إيمي وما زلت أتفتح عقلًا بشأن هذا الأمر. أو محاولة الحصول على واحد. 👼

أعتقد أنه من المهم أن نكرر سبب إزعاجنا لملفات البيانات لتبدأ بها ، فالقيمة الأساسية في استخدام تنسيقات البيانات هي:

• حيادي اللغة الحتمية . استخدام الملفات لا يتطلب منك معرفة لغة البرمجة.
• مصمم / ودية الأدوات. _ يؤدي استخدام المصمم المرئي و / أو تمكين تجربة المصمم المرئي مع منتجك إلى انخفاض التكلفة الإجمالية للملكية _.

بعد قولي هذا ، ما يهمني شخصيًا هو:

• سير عمل متكامل للمطور / المصمم
• تجربة المصمم المرئي لتحرير الملفات يدويًا.
  
  
  
  • PropertyGrid (نافذة الخصائص) مع واجهة برمجة تطبيقات محرر قابلة للتوسيع كما تمت مناقشته أعلاه.
  
  
• امتدادات الترميز
• Cherry-on-the-Cake of awesome: القدرة على الاستفادة من كل ما سبق ضمن سيناريوهات خارج التطوير (مثال devops أعلاه).

إذا تم استيفاء كل هذه الأمور ، فسأكون على استعداد للنظر في "تنسيق .NET آخر" ولكن من الواضح أنني أفضل الاحتفاظ بـ Xaml وتوسيعه بهذا الشكل. إنها تقنية MSFT وبالتالي ملكية فكرية ، بعد كل شيء.

@ Mike-EEE إذا كان من الممكن إلغاء تسلسل تنسيق إلى POCO ، فيجب أن تعمل كل هذه الميزات ، تظهر نافذة الخصائص في VS لسيناريوهات غير XAML أيضًا. لكن الشيء الوحيد الذي يثير قلقي هو سهولة القراءة دون أي دعم محرر. في بعض الحالات ، يجب عليك تحرير ملف التكوين في خادم بعيد ، ولا يكون لديك سوى ملف vim. بالمقارنة مع JSON و XML (و XAML) ليست كبيرة في هذا الصدد ، IMHO.

لكن XAML يحتوي على بعض الأشياء الفريدة (في الواقع ميزات غير XML) مثل الخصائص المرفقة ، والتي يصعب تقليدها في تنسيق تسلسل بسيط.

سأصوت لـ WPF أولاً (لذا يمكنني أخيرًا أن أقول وداعًا لـ xamarin.froms) ، ثم xaml

تظهر نافذة الخصائص في VS للسيناريوهات بخلاف XAML أيضًا

صحيح ، لكنه ليس "مضاءً" تقريبًا كما هو الحال في Xaml ، مع عناصر تحكم قابلة للتخصيص بالكامل ، إلخ. صححني إذا كنت مخطئًا هنا. لا يمكنك ببساطة وضع المؤشر على خاصية في هذه التنسيقات والحصول على عرض قائمة منسدلة لحقل التعداد (على سبيل المثال). هذه التجربة هي في الأساس الشكل والإصدار التالي من WinForms ، وهو جزء من سبب كونها لطيفة جدًا (لا تزال WinForms شائعة!).

بالمقارنة مع JSON و XML (و XAML) ليست كبيرة في هذا الصدد ، IMHO.

نعم أوافق ، Xaml ليس مقتضبًا تمامًا ، وستسمع شكاوى حول مدى طوله. هذا هو المكان الذي تضع فيه OmniXaml بصمتها من خلال توفير تحسينات حول التنسيق. أنت أيضًا تنافس أمثال التنسيقات الأخرى تمامًا مثل TOML و YAML وما شابه.

ميزات غير XML) مثل الخصائص المرفقة ...

وامتدادات الترميز. هذه ملامح رؤيتها.

ما (أعتقد) أنك تخدش هنا gulshan هو في الأساس "بيانات AST (شجرة بناء جملة مجردة)". إذا كنا نتحدث عن تحسين Xaml (أو تنسيق بيانات .NET) بجدية ، فهذه هي الطريقة التي يجب اتباعها. يمكن أن يكون مدعومًا من قبل Roslyn ، حتى. في الواقع ، لدي تصويت لصالح هذه الفكرة بالذات (جنبًا إلى جنب مع مشاركة مدونة مقابلة ). لسوء الحظ ، لا تحظى بشعبية كبيرة حيث يصعب شرحها ، هاها. بشكل أساسي لديك شجرة AST (بيانات) يمكن كتابتها بأي عدد من التنسيقات. بهذه الطريقة يمكن للمطورين (والأدوات) العمل معها وفقًا لأي تنسيق يكون أكثر منطقية (جمالياً أو غير ذلك) بالنسبة لهم.

لذلك يمكنني أن أقول وداعًا لـ xamarin.froms أخيرًا

بالاتفاق معك على هذا الجانبgroege. 😎

لم يقم @ Mike-EEE بفحص اقتراح Data AST الخاص بك مسبقًا. نعم ، إنه مشابه من الناحية المفاهيمية لاقتراح التسلسل الافتراضي / ترميز الكائن لـ .net. الفكرة صعبة الفهم بسبب تجريدها. 😄

فيما يتعلق بـ XAML ، فإن تنسيق تسلسل البيانات المكتوب بقوة. net سوف يخفف الحاجة إلى العديد من امتدادات ترميز XAML. ومع ذلك ، سيبقى هناك البعض ، الذي لا يمكن تهيئته بواسطة تعبير ما (بدون منشئات). أتمنى أن تكون بعض إمكانات امتدادات الترميز هذه جزءًا من C # نفسها.

حسنًا ، لم أتلق أي رد من karelz ، لذا لا يمكنني إلا أن أفترض أنه جلس أمام شاشة العرض الخاصة به على هذا النحو عندما تعلم أنه يمكنك تحديد تطبيق وحدة التحكم في Xaml:

ضع النكات (السيئة) جانبًا ، واسمحوا لي أن أعرف إذا كان لديك أي أسئلة إضافية.

أيضًا ، من This Week in .NET ، يبدو وكأنه محرك رائع جدًا يتم تخميره في .NET Core . التعليق الأول على هذا المنشور يقول كل شيء . :)

@ Mike-EEE أعلم أنني مدين لك بالإجابة (تم وضع علامة عليها كمهمة في صندوق الوارد الخاص بي وفتحها في المتصفح).
حتى الآن تمكنت فقط من تصفح الردود (شكرًا جزيلاً للجميع على كل التفاصيل والأفكار!) ، لكن لم أحصل على الوقت لتثقيف نفسي حول Xaml (كما أشرت) وقراءة جميع الردود جيدًا قادر على الإجابة ... آسف ، الكثير من الحرائق والارتفاعات مستمرة الآن :( ، سأصل إليها لاحقًا ، أعدك!

كل خير karelz! نقدر كثيرا جهودك والحوار هنا.

إليك تصويت على مصدر مفتوح WPF ، كل إصدار آخر من XAML غير مهم بالمقارنة. وعلى محمل الجد يا رفاق ، أكمل الحلقة حول هذا ، لديهم .net core / XAML STORE لنظامي التشغيل unix و MacOS.

@ Mike-EEE آسف جدًا ، ما زلت لم أحصل على الوقت للعودة إلى هذه المشكلة :(

يا رجل لا تقلق بشأن ذلك ، @ Karelz أعلم أن الجميع مشغولون الآن. أنا أقدر المحادثة أكثر من أي شيء آخر. حصلت على الكثير من رأسي. من الجيد رؤيته هناك والتفكير فيه على هذا النحو. إلى جانب ذلك ، لقد وضعنا بالفعل عامًا + ننتظر حتى الآن ... ما هي الأشهر القليلة الأخرى أو نحو ذلك؟ :)

يجب أن يفتحوا مصدر silverlight 5 .. منذ تحركهم html5 ، تحرك win8 / winrt ... والآن uwp & win10 و xamarin .... COMMON !! مثير للشفقة فقدت في لا لا لاند مثل هوليوود أو ماذا ...

كيف يمكن للمرء أن ينتقل من سيلفر لايت 5 إلى كل تلك الفضلات؟ كيف؟ كيف يمكنك أن تقول أنك تحترم المستخدمين عندما تقوم دائمًا بفك واجهات التجميع .. حتى أنك تعيد تسمية حزمة nuget الخاصة بك ولا تعطي طريقة تلقائية للانتقال من القديمة إلى الجديدة في nuget .. إنه مثل ما زلت تستخدم الجميع على أنهم لانهائيون اختبار بيتا لأنك غبي جدًا بحيث لا يمكنك التفكير بوضوح قبل إنشاء الأفكار وترميزها.

أنت بحاجة إلى إزالة الحاجة إلى مشاريع ios / android / uwp بأشكال xamarin .. اعتقد أن هناك طرقًا أفضل بكثير لدعم الأنظمة المتعددة من وجود مشروع لكل منصة.

الآن أحضر كل شيء تحت f. إطار العمل الذي تقوم بمسحه (أوصي بتغطية wpf / silverlight ولغة xaml ولكن تحقق مما إذا كنت تريد إحضار كل شيء إلى xamarin ولكن من فضلك هل يمكنك إضافة أنواع بيانات على النمط / القوالب .. إغفال غريب مثل الكثير وتأكد من عمل nucrapget A1 لمرة واحدة .. لماذا سأحتاج إلى تثبيت حزمة nuget في جميع التجميعات التابعة؟ نفس الشيء مع dll المشار إليه ..؟ ليس لديك رؤية ... لا شيء ... capout ... كل هذا الوقت عالق في حماقة ms .. كان بإمكاني بناء أجهزة SD الخاصة بي من الطراز العالمي ..

لا أستطيع قضاء يوم دون أن يلقي MS غائط في طريقي .. أنا أفكر بجدية في scala-js أو مجرد السرعة .. حان الوقت لمغادرة المنزل! لقد سئمت

حسنًا ، لقد استغرق الأمر ما يقرب من عامين ، ولكن UWP تحدد أخيرًا امتدادات الترميز لنموذج Xaml الخاص بهم:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

وتجدر الإشارة أيضًا إلى أن Noesis أطلقت منتجها v2.0 الأسبوع الماضي ، ويبدو مثيرًا للإعجاب. يتميز نظام Xaml الخاص به بالفعل بامتدادات الترميز (في C ++ ، مع C # في الطريق) ، ولم يستغرق الأمر سبع سنوات للوصول إلى المواصفات. إنه مجاني أيضًا للمطورين المستقلين الآن. بمجرد أن تأخذ في الاعتبار دعم AmmyUI الخاص به ، يجب أن أقول إن هذا في أعلى قائمتي فيما يتعلق بنماذج Xaml التي تستخدم أجهزة الصراف الآلي:

http://www.noesisengine.com/

مرحبًا karelz ، ربما يمكنك التعليق على هذا. ولكن هل تعرف ما إذا كانت "مواصفات" UWP Xaml التي تحدث الآن لها أي علاقة بهذه المشكلة؟ إذا لم يكن كذلك ، هل تعرف ما إذا كان يمكن؟ فكرة مجنونة هنا ، ولكن قد يكون من الجيد حل مشكلتين بسعر واحدة إذا كان من الممكن مساعدتها. لقد تركت أيضًا رسالة هناك بشأن تصويت UWP أيضًا ، لكنني اعتقدت أنني سأقوم باختبار الاتصال هنا أيضًا.

@ Mike-EEE UWP من المحتمل أن تكون "المواصفات" مدفوعة بمؤسسة أخرى (على ما أظن في Windows) - ربما يكون طلب تفاصيل حول صوت المستخدم هو أفضل قناة.

نعم ، كنت خائفة من ذلك. 😛 لقد تلقيت ردًا هناك ، لكن يجب أن أكون صريحًا ، فليس الأمر منطقيًا بالنسبة لي.

مما يمكنني أن أفهمه ، يبدو أنهم سيستمرون في اتباع نهج الباب المغلق في عملية المواصفات الخاصة بهم. هذا مقلق لأنه يبدو أن هذا سيؤدي إلى نفس النتائج كما في المرة الأخيرة ، تنتهي بواجهة برمجة تطبيقات لا يريد أحد استخدامها أو اعتمادها.

ربما يستمتعون سرًا بالمطورين الذين يشكون من عملهم. :)

على أي حال ، إذا كنت تقرأ هذا وكنت مؤيدًا للتعاون والتطوير الشفاف والمفتوح المصدر ، واستمتعت بكونك جزءًا من نجاح مبادرة asp / .NET Core في هذا المجال ، فيرجى أخذ ثانية للتوجه إلى WPDev UserVoice وأرسل لهم ملاحظة تشجعهم على فعل الشيء نفسه. تم ذكر الرابط سابقًا ولكن هنا مرة أخرى لأولئك الذين يقرؤون هذا من البريد الإلكتروني:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

لا بد لي من استدعاء birbilis وأشكره على مساهمته السابقة هناك. أي كلمات إضافية لطيفة من الثقة يمكن لأي شخص أن يقدمها لتعزيز العملية التي نستخدمها جميعًا هنا ستكون موضع تقدير كبير. 👍

تنهد ... تمامًا مثل أصواتنا ، يمكنك حث الناس على التصويت للأشياء وفي النهاية حتى لو كانت شائعة لا تفعل أي شيء حيال ذلك!

تحديث:
https://github.com/microsoft/xaml-standard

أنا متأكد من أن @ Mike-EEE سيكون سعيدًا جدًا مع هذا ؛ P

هذه حركة عظيمة شكرا للمشاركة @ RichiCoder1

لسوء الحظ ، إنه واجهة مستخدم فقط. من المحتمل أن تكون الاستخدامات الأخرى لـ XAML مثل Sharepoint و WF غير موجودة.

لكن نعم ، على الأقل سيساعد ذلك في توحيد XAML عبر جميع الأنظمة الأساسية المدعومة.

حركة جيدة!

آمل أن يقسموها إلى طبقات

على سبيل المثال ، بصرف النظر عن طبقة XAML الأساسية غير التابعة لواجهة المستخدم ، أود رؤية طبقة XAML ثلاثية الأبعاد

galvesribeiro يبدو أن شخصًا ما تسبب في مشكلة: https://github.com/Microsoft/xaml-standard/issues/23 كنت أقوم بإجراء +1 لها ، ولا يوجد سبب لعدم تقسيم المعيار النهائي.

أنا متأكد من أن @ Mike-EEE سيكون سعيدًا جدًا مع هذا ؛ P

هاها وأنت على حق ، @ RichiCoder1! كل شيء خاطئ ومكسر ولا مكان حيث يجب أن يكون ، لكنها البداية. ؛) شكرا لك لإخبارنا. 👍

ويسعدني جدًا رؤية شخص ما يقوم بإنشاء https://github.com/Microsoft/xaml-standard/issues/23 حتى لا أضطر إلى ذلك. ؛) ؛) ؛)

Plesase ، ضع في اعتبارك تضمين WF (Workflow Foundation) في XAML Standard !!.

Suriman الرجاء التصويت!
https://github.com/Microsoft/xaml-standard/issues/23

لذلك أكره أن أسأل - وأنا أفعل ذلك من أجل أن أكون مواطنًا جيدًا في إعادة الشراء / المشكلة ، ولكن هل هذه المشكلة ضرورية بعد الآن؟ أعني ، أن هذا الريبو يعمل بالفعل على تسجيل أكثر من 50 مشكلة تتطرق إلى تفاصيل أكثر مما يمكن أن تفعله هذه المشكلة على الإطلاق. يبدو أن لديها بالفعل حياة خاصة بها!

هل هناك سبب لإبقاء هذه القضية مفتوحة هنا؟ ما لم أكن أفهم شيئًا تمامًا (ممكن تمامًا) ، أعتقد أننا حققنا الهدف هنا مع معيار Xaml. إنها مدفوعة بالمجتمع وكل شيء ، وهو الأهم بالنسبة لي شخصيًا. :)

@ Mike-EEE هناك فرق دقيق بين المسألتين. يبدو أن أحدهما يدور حول توحيد واجهات برمجة التطبيقات المتاحة داخل XAML نفسه (بشكل صارم في XAML نفسه) ، والآخر يتعلق بدعم XAML كمكوِّن .NET Standard مشابه لـ System.Xaml.

lokitoth منفتح بالتأكيد للمحادثة حول هذا ، لأنني ما زلت أحاول تذوق كل القطع الجديدة. أفترض أنه من الأفضل البدء باقتراح مشاهدة مقطع فيديو terrajobst الممتاز والمفيد الذي يوضح رمز "العمل فقط" مع .NET Standard2.0 الجديد. أنا شخصياً لم ألتف حول كيفية تأثير هذا على System.Xaml. كان تفكيري أنه يجب أن "يعمل فقط" ولكن ربما بدأت أعتقد أنني مخطئ الآن هنا (حسنًا جدًا لدرجة يصعب تصديقها).

ولكي أكون صادقًا ، بعد قراءة عدد قليل من هذه الخيوط في Xaml Standard repo ، كنت أركل نفسي نوعًا ما لاقتراحي السابق (☕️ القهوة جعلتني أفعل ذلك ، أقسم! ☕️). من مظهرها ، من الأفضل تسمية "Xaml Standard" باسم "MSFT UX / UI Standard" لأن هذا هو ما تتم مناقشته بشكل أساسي في هذا الريبو. كما هو الحال ، لا يتم تقديم / عرض / إبراز Xaml كتقنية تسلسل قوية على الإطلاق (خارج الأصوات الشجاعة القليلة التي بذلت الجهود هناك) ، مما يؤدي أيضًا إلى بعض الانفصال / الارتباك أيضًا.

أنا شخصياً لم ألتف حول كيفية تأثير هذا على System.Xaml.

سنحتاج إلى فحص التجميع لمعرفة ما إذا كانت شجرة التبعية قابلة للتحميل في سياق .NET Standard 2.0. إذا كان .NET خالصًا ، فمن المحتمل أن يعمل (على الرغم من وجود مجموعة كاملة من وقت التجميع من العناصر ، مثل BAML والموارد المضمنة وما إلى ذلك ، والتي سيتم إحضارها إلى سلسلة أدوات .NET Core)

من مظهرها ، من الأفضل تسمية "Xaml Standard" باسم "MSFT UX / UI Standard" لأن هذا هو ما تتم مناقشته بشكل أساسي في هذا الريبو.

هذا ، على ما أعتقد ، هو أكثر من وظيفة الإعلان عنها في سياق UWP / Xamarin.Forms ، مما يعني أن المطورين الذين يركزون على هاتين المنصتين - الذين ربما لم يكونوا قد تعرضوا لـ "BigXaml" - هم المساهمون بشكل أساسي. على الرغم من أنك ترى عددًا قليلاً من مشكلات "إحضار كل لهجة WPF XAML" المفتوحة.

نظرًا لوجود الكثير من عمليات التنظيف التي يتعين على الفريق القيام بها ، وأن معدل المشكلات الجديدة في الوقت الحالي مرتفع نسبيًا بالنسبة إلى عدد الأشخاص المساهمين ، فسأمنحه مزيدًا من الوقت لمعرفة أين سيأخذها الفريق.

تضمين التغريدة _
لقد أنشأت مشكلة في Xaml Standard.
https://github.com/Microsoft/xaml-standard/issues/57

شكرًا على التنبيه والمساهمة في المحادثة ،juepiezhongren!

حسنًا lokitoth ، أنا سعيد لأننا أبقينا هذه المشكلة كما هي حيث تقرر https://github.com/Microsoft/xaml-standard/issues/23 أنها غير مناسبة لضوء النهار.

ومع ذلك ، فقد قمت بإنشاء مشكلة جديدة أشعر أنها تقوم بعمل أفضل لوصف المشكلة المطروحة وسيكون من الرائع إضافة تصويتك و / أو مساهماتك هنا: https://github.com/Microsoft/xaml-standard / القضايا / 145

للتوضيح ، ما تبحث عنه سيكون في الواقع _JavaScript_ + HTML5 + CSS3 المشغولات التي تم إنشاؤها. TypeScript هو في الواقع transpiler لـ JS. بدلاً من إنشاء محول .NET لإنتاج JS متوافق مع المعايير والذي من شأنه أن ينفذ بشكل فعال في تصفح (مثل JSIL ) ، قررت MSFT قضاء الوقت الثمين لمنشئ C # لصنع شيء من شأنه أن ينافسه بشكل فعال وفي نهاية المطاف.

أود أن أقول لا تجعلني أبدأ في هذا ، لكنني لا أعتقد أنني توقفت أبدًا. 😛

أيضًا ، هناك نقطة أخرى وهي أن CSHTML5 قريب جدًا مما تبحث عنه weitzhandler ، لكنه لا يسمح بمشاركة التعليمات البرمجية بين تجميعات العميل / الخادم (مثل PCLs ، إلخ). لذلك لا يزال يتعين عليك الحفاظ على قاعدتي رمز منفصلتين وغير متوافقين ، مما يؤدي إلى نفس مشكلة التكلفة / الأعمال بين .NET و JS (أو TypeScript 😉) التي ، على سبيل المثال ، غير موجودة في حل NodeJS بشكل صارم.

حلمي هو استخدام أسلوب كتابات android xml ui لتطبيقات سطح المكتب مع dot net core! نعم حقا!!

أنا على استعداد للتطوع بأي جهد لنقل XAML إلى .NET core.

في التعديلات التي أجريتها على CoreWf (WorkflowFoundation on net standard 2.0) ، أرى أن System.Xaml أو تطبيق Portable.Xaml الأكثر توافقًا سيكون مطلوبًا على الأرجح للسماح بتحميل DynamicActivity من Xaml . لديّ CoreWf يعمل على إطار عمل .net مع تحميل DynamicActivity الأساسي باستخدام System.Xaml ، ولكن لا يزال هناك فشل بسبب حالة التحليل غير الصالحة على .net core مع Portable.Xaml.

سؤال واحد هو لماذا لم تتم إضافة الكود إلى System.Xaml إلى ريبو المصدر المرجعي المرخص لـ Mit؟ هل هناك ترخيص أو براءة اختراع أو مسألة أخرى؟ إذا لم تكن هناك مشكلة ، فإن إضافة هذا الكود إلى مصدر مرجعي سيسمح لنا ، للمجتمع ، بالقيام بالنقل الضروري لدعم CoreWf. لا يلزم الريبو الخاص بالمصدر المرجعي Microsoft بدعم System.Xaml. هل يجب إضافة مشكلة هناك تطلب فتح System.Xaml؟

إذا لم يتم فتح System.Xaml ، فهل يمكننا الحصول على مستند (بخلاف مواصفات Xaml) أو دعم في شكل اختبارات تصف الخطوات الصحيحة لتحليل رمز Xaml وترميز رمز Xaml لـ WorkflowFoundation؟

مرحبًا FWIW @ Karelz ، لقد وضعت بعض الأفكار في سيناريو DevOps هنا:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

بناءً على بعض الأحداث الرائعة في Visual Studio Xaml Designer:
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

اعتقدت أنني سأذكرها هنا ، بينما كنت في ذلك. 👍 إلى جانب ذلك ، هذا الخيط قد فات موعده لنتوء. 😆

weitzhandler u بحاجة إلى التحديث ، نظرًا لأن mono-wasm في طريق ألفا ، فقد حان الوقت تقريبًا لبدء نسيان js.

مطلوبweitzhandler 2 أو 3 سنوات r ، ولكنها ليست مجرد حزمة كاملة ، إنها مكدس عالمي لـ .net.

CoreRT موجود أيضًا على متن الطائرة - https://github.com/dotnet/corert/pull/4480 . أملا في إنتاج HTML + CSS + C # combo جاهز العام المقبل.

تتضمن حزمة توافق .net المقترحة System.Xaml بحالة ربما ومرتبطة بهذه المشكلة.

على ما يبدو تم ربط هذه المشكلة بالحزمة المتوافقة 2.1؟ هل يستطيع أحد أن يؤكد؟ أرى أنه قد تم وضع علامة netfx-signature-pack عليه ، ولكن ليس بإصدار. ومع ذلك ، سآخذ ذلك على عاتق أي شيء حدث حتى الآن. 😄

أكره أن يخيب أملك ولكني أعتقد أنني قمت بطريق الخطأ بتمييز هذا كـ 2.1 عندما كنت أقوم بتحديث مشكلات حزمة comapt بشكل مجمّع. لقد انتقلت إلى Future لأعكس حالة ربما في الاقتراح.

@ Mike-EEE يبدو أن xamarin.wasm سيصل.
https://github.com/mono/mono/pull/5924#issuecomment -343551464

شكرا على التحديث أيها السادة. أقدر تفكيرك بي. :) terrajobst هذا أمر مخيب للآمال حقًا ، لكنني أقدر لك الوقت الذي تستغرقه في تسجيل الوصول والتحديث. لم أكن متأكدًا مما إذا كنت لا تزال مشتركًا في سلسلة الرسائل هذه أم لا. 👼

نظرًا لأننا نأخذ وقتًا في توصيل المشاريع بلا خجل (وأنه سيكون هناك بعض الوقت قبل أن نحصل على إصلاح Xaml الرسمي) ، سأستغرق ثانية لأذكر أنني أمضيت العام الماضي في المساعدة في الإصدار 2 من ExtendedXmlSerializer ، الذي تم إصداره مؤخرًا. يتميز بالدعم التجريبي لملحقات الترميز والخصائص المرفقة (التي تعمل على POCO ، ولا يلزم وجود DependencyObject ) ، وأيضًا تسلسل معلمات بأسلوب protobuf .

إذا كنت تبحث عن (أو تضيف) وظيفة Xaml-ish أثناء انتظار وصول System.Xaml ، فلا تتردد في التحقق من ذلك ، أو تقديم ملاحظات ، أو (الأفضل من ذلك) إرسال العلاقات العامة في الريبو. 👍

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

danmosemsft هل سيتم دعم Workflow Foundation xaml في مشاريع SDK كجزء من مبادرة سطح المكتب 3.0؟

lokki لا أعرف الخطط. تضمين التغريدة

تضمين التغريدة
لماذا لا توجد مشكلة تقول "توفير إطار عمل لواجهة المستخدم كجزء من .NET Core"؟

لا تتحدث هذه المشكلة تحديدًا عن عدم وجود إطار عمل لواجهة المستخدم ، ولا يبدو أن الأشخاص هنا يدركون ذلك.
انظر هذا: https://github.com/Microsoft/xaml-standard/issues/232

weitzhandler هذه المشكلة تجعلني الآن أكثر منطقية. شكرا على التوضيح.

أستطيع أن أرى أن تضمين System.Xaml في .NET Standard أمر مفيد ، لا سيما بجانب معيار XAML.

إذا فهمت "مبادرة سطح المكتب" بشكل صحيح ، فيجب أن تكون قادرًا على استخدام مكتبات .NET التي يمكنك استخدامها في الماضي ، طالما أنك تستهدف Windows فقط (لست متأكدًا مما إذا كان تطبيقك قادرًا على التكيف ديناميكيًا مع البيئة التي يستخدمها يعمل ، إذا لم يكن التطبيق الرئيسي قادرًا على القيام بذلك [على سبيل المثال ، لن يتم تشغيله إذا لم يعثر على نظام التشغيل Windows على سبيل المثال] ، فربما يمكنك القيام بذلك عن طريق إنشاء تجميعات NET Core متعددة تستدعي أشياء خاصة بالنظام الأساسي وتحميلها عند الطلب اعتمادًا على النظام الأساسي الذي يكتشف التطبيق أنه يعمل عليه)

birbilis لا يكفي. يجب أن يتم عرض نفس XAML بالتساوي في جميع الأنظمة الأساسية.

لا تتعلق مبادرة سطح المكتب بـ XAML ، بل تتعلق بأن NET Core ليس صومعة قاسم مشترك على الأقل ، ولكن بدلاً من ذلك تسمح للتطبيقات التي يمكن أن تستهدف منصات معينة (أو بشكل مثالي أيضًا تتكيف ديناميكيًا مع النظام الأساسي الذي يتم تشغيله عليها) وجعل أفضل استخدام للخروج منها ، والقيام بعمليات تكامل خاصة بالنظام الأساسي وما إلى ذلك. يمكن للمرء إنشاء واجهات برمجة تطبيقات قائمة على الإمكانات فوق هذه الوظيفة بحيث يمكن كتابة التطبيقات التي تستفسر فقط عن مدى توفر قدرة معينة. يمكن أيضًا بناء واجهات برمجة التطبيقات للتلخيص / التوافق بناءً على ذلك ، والتثبيت في تطبيقات مختلفة لكل منصة يهتم مؤلفو واجهة برمجة التطبيقات بدعمها.

في الوقت الحالي ، أعتقد أن Portable.Xaml قريب جدًا من System.Xaml الآن. إذا وجدت أي مشكلة يرجى إعطاء ملاحظاتك.

أعلن فريق WPF (@ dotnet / wpf-developer) للتو عن المصدر المفتوح لـ WPF لـ .NET Core 3.0. كجزء من هذا ، تحتوي معاينة .NET Core 3.0 الآن على System.Xaml ، والمصادر المقابلة متاحة على https://www.github.com/dotnet/wpf.

بالمناسبة