LucasHaines كيف يرتبط هذا بميزات التحقق من صحة الإدخال التي كنت تبحث عنها؟

jevansaks يرتبط هذا ارتباطًا مباشرًا بعمل التحقق من صحة الإدخال الذي أحدده.

باهر. إذا كان لديك أي عناصر معاينة تريد مشاركتها ، يسعدني تجربتها وتقديم التعليقات والأفكار.

هذا هو نوع التحقق المذكور خلال Build 2018

"
x: الاسم = "UserName" Header = "User Name:"
نص = "{x: ربط ViewModel.Person.UserName ،
UpdateSourceTrigger = PropertyChanged ،
الوضع = TwoWay} "/>

x: الاسم = "كلمة المرور" العنوان = "كلمة المرور:"
كلمة المرور = "{x: Bind ViewModel.Person.Password،
UpdateSourceTrigger = LostFocus،
الوضع = TwoWay} "/>
"

thomasclaudiushuber ما مدى أهمية برأيك جعل هذا العمل جزءًا من {Binding}؟ أنا أسأل فقط لأن التحديات التقنية هناك غير تافهة ، فضلاً عن عدم القدرة على العمل في المستوى الأدنى. كانت فكرتنا الأصلية هي دعم x: Bind ، والذي سيتطلب فقط تغييرات في برنامج التحويل البرمجي ، وهو قادر على العمل بالمستوى الأدنى.

أيضًا ، كنا نخطط فقط لدعم نموذج INotifyDataErrorInfo و DataAnnotations. لم نكن عازمين على إضافة شيء مشابه لقواعد Binding.ValidationRules ، وبالتالي لم نشعر أن هناك حاجة كافية لـ ValidatesOnNotifyDataErrors.

يسعدنا الحصول على تعليقاتك بينما نواصل العمل على هذه الميزة حتى يمكن تنفيذها بشكل صحيح!

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

إجابة مختصرة: نعم ، ما تعتقده وما تخطط له يبدو رائعًا. فقط x: الربط جيد ، وفقط INotifyDataErrorInfo جيد أيضًا.

طويل:

فقط س: ربط؟ 👍

في جميع حالات WPF-LOB التي يمكنني التفكير فيها ، كان هناك دائمًا نوع من ViewModel كان معروفًا في وقت الترجمة ، ولا توجد كتابة بطة ، لذا فإن x: Bind جيد. لقد كتبت {Binding} في هذه المشكلة أيضًا حيث اعتقدت أنه يمكنك دعمها للحصول على نفس البنية كما في WPF. ولكن هذا "لطيف أن يكون لديك" أكثر من الأهمية الفائقة. وبما أن {Binding} و x: Bind هما شيئان مختلفان تمامًا وراء الكواليس ، فإن عناصر وقت التشغيل مع {Binding} ليس بالأمر التافه كما ذكرت ، فانسى أمر {Binding}. أعتقد أن امتلاكه لـ x: Bind جيد تمامًا ، وسيعمل مع حالات الاستخدام التي يمكنني التفكير فيها. ومن جميع محادثات المؤتمر التي أجريتها حول UWP و x: Bind ، يمكنني أن أخبرك أن x: Bind هي واحدة من أكثر ميزات UWP المفضلة لجميع مطوري XAML وقد أخبرتهم جميعًا "تفضل x: الربط أكثر من الربط أينما كنت علبة". :) الحصول على أخطاء intellisense و perf و step-in-code و compile-time تجعل x: قم بربط الإعداد الافتراضي الجديد على UWP ، لذا فإن الحصول على دعم التحقق من الصحة أمر جيد وقرار imo جيد.

فقط نموذج INotifyDataErrorInfo و DataAnnotations؟ 👍

مجرد دعم نموذج INotifyDataErrorInfo و DataAnnotations يبدو جيدًا بالنسبة لي. لا يلتقط WPF التعليقات التوضيحية للبيانات تلقائيًا ، فأنت بحاجة إلى ربطها يدويًا في تطبيق INotifyDataErrorInfo الخاص بك باستخدام فئة Validator. تقصد هذا عندما تقول "نموذج شروح البيانات" ، أليس كذلك؟ أو هل تخطط لدعم DataAnnotation المدمج الذي يسمح للمطور بوضع تعليق توضيحي للبيانات على خاصية وهذا يعمل فقط؟ مثل ASP.NET Core MVC؟ بينما سيكون ذلك رائعًا ، أعتقد أنه ليس ضروريًا. يعد وجود فئات ValidationContext و Validator و ValidationResult والفئات الأخرى من System.ComponentModel.DataAnnotations أمرًا كافيًا.

إضافة Binding.ValidationRules؟ Noooooo ؛-)

لا ، بالتأكيد لا تضيف ذلك. INotifyDataErrorInfo كافٍ وهو الأفضل. أعتقد أنني لم أستخدم قواعد ValidationRules بعد الآن بعد إضافة دعم IDataErrorInfo إلى WPF (إذا كنت أتذكر بشكل صحيح ، كان هذا في .NET Framework 3.5). وعندما تمت إضافة INotifyDataErrorInfo في .NET Framework 4.5 ، استخدمت أنا وعملائي تلك الواجهة في جميع المشاريع للتحقق من صحة الإدخال. دعم هذه الواجهة فقط جيد.

إضافة ValidatesOnNotifyDataErrors؟ لا ولكن...

نعم ، ليس عليك إضافة هذا. لكن لا علاقة له بقواعد التحقق من الصلاحية الملزمة. ترتبط هذه الخاصية مباشرة بواجهة INotifyDataErrorInfo. في ملحق التوصيف الملزم الخاص بـ WPF ، يكون ValidatesOnNotifyDataErrors بشكل افتراضي صحيحًا ، مما يعني أن {Binding} يلتقط التحقق من صحة INotifyDataErrorInfo المطبق إذا كان الكائن المنضم يطبق تلك الواجهة. إذا قمت بتعيين الخاصية ValidatesOnNotifyDataErrors على امتداد علامة Binding إلى false ، فلن يلتقط ملحق Binding Markup تنفيذ INotifyDataErrorInfo للتحقق من الصحة. لذلك ، ربما لا يكون هذا صعب التنفيذ مع x: Bind ، لكن ربما لسنا بحاجة إليه. لذا ، لا ، لا تفعل ذلك. لا بأس في ترك هذا. لكن اسمحوا لي أن أصف السيناريو الذي كنت بحاجة إليه في الماضي:

تعرض عناصر تحكم WPF افتراضيًا حدًا أحمر يتم تحديده عبر Validation.ErrorTemplate. لنفترض الآن أن لديك تطبيق INotifyDataErrorInfo مع فئة لها خاصية الاسم الأول. إنه مطلوب ، لذلك تقوم بإرجاع خطأ إذا كانت خاصية FirstName فارغة أو فارغة. الآن قمت بربط TextBox بخاصية FirstName. عندما يزيل المستخدم هذا الاسم الأول ، يظهر حد أحمر. عظيم ، بالضبط ما تريده. ولكن ربما لديك في مكان آخر في واجهة المستخدم عنصر تحكم آخر مرتبط بخاصية الاسم الأول أيضًا. على سبيل المثال TextBlock في Tab-Header. سيعرض WPF على TextBlock هذا حدًا أحمر أيضًا عندما يكون هناك خطأ في التحقق من الصحة. لكن قد لا يكون هذا ما تريده. تريد الخطأ فقط في TextBox حيث يمكن للمستخدم تغيير الاسم الأول ، ولكن ليس في TextBlock في رأس Tab. للتخلص من الحد الأحمر على TextBlock ، لا يتعين عليك تحرير قالب ErrorTemplate الخاص بـ TextBlock ، وبدلاً من ذلك تقوم فقط بتشغيل التحقق من صحة INotifyDataErrorInfo على TextBlock-FirstName-Binding عن طريق تعيين الخاصية ValidatesOnNotifyDataErrors على false. هذه هي حالة الاستخدام الوحيدة التي أمتلكها لهذا العقار. :)

آمل أن يساعد هذا.

ملخص

نعم ، أوافق تمامًا ، وجود التحقق من صحة الإدخال في x: الربط مع دعم INotifyDataErrorInfo يعد خطة جيدة.

لا ، إنها خطة رائعة ، أنا بالفعل متحمس للغاية!

thomasclaudiushuber شكرًا على المتابعة التفصيلية! السيناريوهات الأساسية التي تصفها تتماشى مع ما نعتقد أنه محرك القيمة الحقيقية ، ومن الجيد سماع ذلك. كان التصميم العام لهذه الميزة وواجهة برمجة التطبيقات في حالة تغير مستمر ، ويرجع ذلك في الغالب إلى العمل السابق الذي قام به WPF. كانت هناك بعض الأشياء الرئيسية التي يجب ذكرها هنا:

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

2. تستفيد بعض ميزات / وظائف نظام التحقق من صحة WPF من ميزات WPF الأساسية غير الموجودة في UWP. الأبرز هنا هو طبقة الزينة ، والتي تسمح لأي UIElement في WPF بعرض مرئيات التحقق من الصحة ، وليس فقط عناصر التحكم (عن طريق إضافة جزء من القالب).

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

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

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

تضمين التغريدة لا تزال واجهة المستخدم الحالية التي شاركناها دقيقة. إذا كانت لديك ملاحظات ، فلا تتردد في تقديمها في هذا الموضوع.

LucasHaines واجهة المستخدم تبدو جيدة بالنسبة لي. لكني أتساءل كيف يمكنك ضبط كيفية عرض الأخطاء. لم أجد أي شيء بخصوص هذا ولا أعرف ما إذا كان لديك بالفعل شيء تشاركه في هذا المجال. هل سيكون هناك شيء مشابه مثل خاصية Validation.ErrorTemplate المرفقة من WPF؟

هل هناك جدول زمني لموعد طرح المواصفات / الاقتراح الرسمي لهذا الغرض؟
ما الذي يمكنني فعله للمساعدة في الوصول إلى المنتج عاجلاً؟

أتفق مع mrlacey أعلاه ... يمكنني حقًا استخدام هذا الآن ، لذلك يسعدني تقديم المساعدة حيث يمكنني ذلك.

نحن نعمل على مواصفات مفتوحة وسأخبر الجميع أنها متوفرة في الريبو الخاص بالمواصفات.

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

بدأنا مراجعة المواصفات المفتوحة للتحقق من صحة الإدخال في مستودع المواصفات المفتوح. https://github.com/Microsoft/microsoft-ui-xaml-specs/pull/26

مرحبًا يا رفاق ، كيف نتابع هذا - هل لدينا الوقت المقدر للوصول؟

knightmeister لدينا مواصفات مفتوحة تم إنشاؤها هنا . لا تتردد في المشاركة في المراجعة والمساعدة في تشكيل الميزة. نحن نخطط لشحن هذا كجزء من WinUI 3.0. إذا كنت تريد مزيدًا من المعلومات حول خارطة طريق WinUI 3.0 ، فراجع المشكلة رقم 717.

مرحبًا بالجميع - يرجى إلقاء نظرة على أحدث العينات في المواصفات. أجرىstevenbrix بعض التحديثات الرائعة على العينات وتناول الملاحظات الأخرى.

سؤال واحد: هل ستتدفق معلومات التحقق إلى التسلسل الهرمي للتحكم؟ على سبيل المثال ، هل سيكون من الممكن لعنصر تحكم في الحاوية (مثل TabView أو Pivot) أن يعرف أن هناك عنصر تحكم فرعي في حالة غير صالحة؟

فكر في طريقة عرض معقدة تحتوي على عناصر تحكم متعددة في الحاويات ، حيث تريد تمييز أجزاء العرض التي تتطلب الانتباه ، على سبيل المثال عن طريق تغيير نمط رأس Pivot عندما يكون أي عنصر تحكم فرعي في حالة غير صالحة.

هذه قضية حرجة بالنسبة لي.
يعتمد نظام التحقق من صحة XAML بالكامل على قواعد التحقق من WPF ، ويقرأ الحقل ونموذج الكيان من BindingExpression وينشئ قواعد التحقق وفقًا لسمات التحقق من صحة DA (انظر هذا ).

على سبيل المثال ، هل سيكون من الممكن لعنصر تحكم في الحاوية (مثل TabView أو Pivot) أن يعرف أن هناك عنصر تحكم فرعي في حالة غير صالحة؟

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

يعتمد نظام التحقق من صحة XAML بالكامل على قواعد التحقق من WPF ،

weitzhandler لا نخطط حاليًا لإضافة شيء مثل ValidationRule إلى WinUI. هل هناك شيء يمنحك استخدام هذا أكثر من استخدام ValidationAttributes وجعل نموذجك ينفذ INotifyDataErrorInfo ؟ أود أن أرى كيف يبدو نموذجك و XAML للحصول على فهم أفضل لسيناريو الاستخدام الخاص بك.

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

يتطلب منك INDEI تنفيذ جميع الكيانات والكيانات الفرعية الخاصة بك.

هل يمكنك توضيح المزيد عن هذا؟

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

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

FWIW ، نحن نخطط لوجود فئة ValidationBase هذه مباشرة في Toolkit ، لذلك لا يتعين عليك كتابة هذا الرمز المعياري بنفسك.

public class ValidationBase : INotifyPropertyChanged, INotifyDataErrorInfo
{
   public event PropertyChangedEventHandler PropertyChanged;
   public event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;

   protected void SetValue<T>(ref T currentValue, T newValue, [CallerMemberName] string propertyName = "")
   {
       if (!EqualityComparer<T>.Default.Equals(currentValue, newValue))
       {
           currentValue = newValue;
           OnPropertyChanged(propertyName, newValue);
       }
   }

   readonly Dictionary<string, List<ValidationResult>> _errors = new Dictionary<string, List<ValidationResult>>();
   public bool HasErrors
   {
       get
       {
           return _errors.Any();
       }
   }
   public IEnumerable GetErrors(string propertyName)
   {
       return _errors[propertyName];
   }

   private void OnPropertyChanged(string propertyName, object value)
   {
       PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
       Validate(propertyName, value);
   }

   private void AddErrors(string propertyName, IEnumerable<ValidationResult> results)
   {
       if (!_errors.TryGetValue(propertyName, out List<ValidationResult> errors))
       {
           errors = new List<ValidationResult>();
           _errors.Add(propertyName, errors);
       }

       errors.AddRange(results);
       ErrorsChanged?.Invoke(this, new DataErrorsChangedEventArgs(propertyName));
   }

   private void ClearErrors(string propertyName)
   {
       if (_errors.TryGetValue(propertyName, out List<ValidationResult> errors))
       {
           errors.Clear();
           ErrorsChanged?.Invoke(this, new DataErrorsChangedEventArgs(propertyName));
       }
   }

   public void Validate(string memberName, object value)
   {
       ClearErrors(memberName);
       List<ValidationResult> results = new List<ValidationResult>();
       bool result = Validator.TryValidateProperty(
            value,
            new ValidationContext(this, null, null)
            {
                MemberName = memberName
            },
            results
            );

        if (!result)
        {
            AddErrors(memberName, results);
        }
    }
}

سيشتق نموذجك بعد ذلك من تلك الفئة ويظهر بالشكل التالي:

public class Person : ValidationBase
{
    private string name;
    [MinLength(4)]
    [MaxLength(6)]
    public string Name
    {   
        get { return name; }
        set { SetValue(ref name, value); }
    }
}

بافتراض أنه تم تعيين فئة Person # $ 5 $ # $ هذه على خاصية ViewModel على Page ، فإنك تلتزم بذلك ، ويتم التحقق تلقائيًا:

<TextBox Text="{x:Bind ViewModel.Name, Mode=TwoWay}" />

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

أنت على حق ، لكن هذا يتطلب أن تكون كياناتك ليست POCOs.
يجب أن أجربها. قد لا يكون الأمر بهذا السوء عند استخدام فئة EntityBase في تطبيق LoB. أنا معتاد فقط على استخدام POCOs.

UWP ليس لديه * التحقق من الصحة * !!!!!!! لقد بدأت للتو مشروعًا. العودة إلى WPF حتى بضع سنوات.

@ rufw91 أعرف ، أليس كذلك ؟!

ما هي قيود وقتك؟ أول تطبيق لهذا موجود في WinUI3 alpha ، ويجب أن يكون لدينا معاينة لسطح مكتب WinUI قريبًا في // Build timeframe. نحن نخطط على RTM'ing بحلول نهاية العام

UWP ليس لديه * التحقق من الصحة * !!!!!!! لقد بدأت للتو مشروعًا. العودة إلى WPF حتى بضع سنوات.

لقد قررت التمسك بـ WPF للسنوات القادمة أيضًا. لقد فعلت كل شيء (WPF ، و SL ، و WP ، و UWP ، وما إلى ذلك) ، في النهاية ، يبدو أن هناك تقنية واحدة فقط قوية ، وهي WPF. ربما يكون من المثير للاهتمام في غضون بضع سنوات التحقق من موقع WinUI ، لكنني سئمت من التحول إلى التكنولوجيا الجديدة وتركي وحدي في الظلام. WPF ناضج ويعمل بشكل رائع. ربما في غضون بضع سنوات ، لن يكون نظام التشغيل Windows مناسبًا على الإطلاق ، لذلك دعونا ننتظر ذلك قبل إجراء أي استثمارات أخرى في النظام الأساسي.

ربما في غضون بضع سنوات ، لن يكون نظام التشغيل Windows مناسبًا على الإطلاق ، لذلك دعونا ننتظر ذلك قبل إجراء أي استثمارات أخرى في النظام الأساسي.

بالنظر إلى أننا تجاوزنا للتو 1 مليار عملية تثبيت لنظام التشغيل Windows 10 ، أجد صعوبة في الاعتقاد بأن هذا سيكون صحيحًا على الإطلاق. لكنني بالتأكيد أشعر بإحباطك ولا ألومك على بقائك في WPF. FWIW ، يمتلك فريقنا شركة WPF الآن ، لذا أخبرني إذا كان هناك أي شيء تريد رؤيتنا نقوم به هناك.

يتطلب منك INDEI تنفيذ جميع الكيانات والكيانات الفرعية الخاصة بك.

هل يمكنك توضيح المزيد عن هذا؟

باستخدام الكود الخاص بي ، يمكن لجميع كيانات POCO أن تظل خالية من تنفيذ تلك الواجهات ، وتبقى بدون فئة أساسية. يتم تنفيذ INPC تلقائيًا باستخدام Fody. أكثر ما أفعله هو تطبيق IValidatableObject عندما يتطلب الأمر مزيدًا من التحقق الدقيق. وهو يعمل على الأنواع الفرعية أيضًا.

FWIW ، نحن نخطط لإنشاء فئة ValidationBase هذه مباشرة في Toolkit ، لذلك لا يتعين عليك كتابة هذا الرمز المعياري بنفسك.

هذا ليس جيدا. ماذا لو كان لدى الكيانات الخاصة بي فئة أساسية بالفعل؟ لهذا السبب أيضًا لست معجبًا كبيرًا بـ INotifyDataErrorInfo . تعد خصائص INPC بمثابة صداع لأنفسهم بالفعل ، خاصة عند التعامل مع تطبيقات البيانات الضخمة مع العديد من الكيانات.

إنه لأمر مروع للغاية أن UWP ليس لديه التحقق المناسب من الصحة حتى الآن. هذه ميزة أساسية مهمة في أي تطبيق تقريبًا ويجب إعطاؤها الأولوية الأولى.

إنه لأمر مروع للغاية أن UWP ليس لديه التحقق المناسب من الصحة حتى الآن. هذه ميزة أساسية مهمة في أي تطبيق تقريبًا ويجب إعطاؤها الأولوية الأولى.

نعم ، لهذا نحن نعمل على ذلك :)

هذا ليس جيدا. ماذا لو كان لدى الكيانات الخاصة بي فئة أساسية بالفعل؟

أنا فقط أحاول فهم استخدامك هنا. ما هي الفئة الأساسية ، وهل يمكن أن تشتق من هذه الفئة؟

نعم ، لهذا نحن نعمل على ذلك :)

شكرا، اقدر ذلك كثيرا. هذا وبقية عملك.
ماذا تعني التسمية يحتاج وينوي 3 ؟

أنا فقط أحاول فهم استخدامك هنا. ما هي الفئة الأساسية ، وهل يمكن أن تشتق من هذه الفئة؟

أنا أستخدم OData Connected Service للحصول على كيانات يتم إنشاؤها على عميلي.
الكائنات التي تم إنشاؤها من هذا النمط:

c# public abstract partial class ContactBase : Microsoft.OData.Client.BaseEntityType, INotifyPropertyChanged

ماذا تعني التسمية يحتاج وينوي 3؟

تضمين التغريدة
هذا يعني أن التحقق من صحة الإدخال سيأتي مع WinUI 3. (3.0 كما هو مخطط حاليًا). ربما لن يأتي إلى WinUI 2 لأن ذلك سيتطلب تغييرات في رمز OS XAML الذي هو في وضع الصيانة الآن.

أنا أستخدم UWP في تطبيق Uno Platform. نأمل أن يتم تغطية WinUI عند صدوره.
شكرا على التحديث مع ذلك!

أنا فقط أحاول فهم استخدامك هنا. ما هي الفئة الأساسية ، وهل يمكن أن تشتق من هذه الفئة؟

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

غالبًا ما يكون وجود فئة أساسية أمرًا مطلوبًا من قِبل جهة خارجية ، على سبيل المثال إطار عمل المثابرة الذي تستخدمه. إن مطالبة UWP / WinUI أيضًا بفئة أساسية للتحقق من الصحة ليس خيارًا. يجب أن تكون واجهة مفيدة ، فلا يمكن لأي من تطبيقاتنا الاستفادة من فئة أساسية.

دعنا نعود قليلا. أعتقد أن التعليقات القليلة الأخيرة التي أدليت بها تسببت في بعض الارتباك ، وهو أمر سيئ بالنسبة لي.

كل ما يحتاجه النموذج هو تنفيذ System.ComponentModel.INotifyDataErrorInfo (أو Windows.UI.Xaml.Data.INotifyDataErrorInfo لـ C ++). سيقوم المترجم بإنشاء الكود بشكل صحيح لربط ذلك مع العرض الخاص بك عند استخدام {x:Bind} .

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

شكرا للتوضيح الخاص بكstevenbrix.

ماذا عن سمات التحقق و IValidatableObject ، هل سيتم احترامها في وقت تشغيل UWP؟

ماذا عن السمات الأخرى ، مثل السمة MaxLength التي ذكرتها سابقًا ، هل سيتم تعيين الحد الأقصى لطول TextBox تلقائيًا كما هو الحال في ASP.NET؟
نفس الشيء مع DataTypeAttribute ، EditableAttribute .
أيضًا DisplayAttribute لتوليد رؤوس الحقول.
بقدر ما أتذكر ، تم دعمهم جميعًا في Silverlight.

(انظر هذا ).

ماذا عن سمات التحقق من الصحة و IValidatableObject ، هل سيتم احترامها في وقت تشغيل UWP؟

لذلك سنوفر حاليًا دعمًا للسمة Required . ستضع بعض عناصر التحكم تلقائيًا علامة نجمية صغيرة بجوار نص الرأس عند استخدامها. نحن منفتحون على دعم المزيد في المستقبل إذا كنت تريد ذلك. الرجاء فتح مشكلة منفصلة إذا كنت ترغب في رؤية المزيد ، ولمجرد تحديد التوقعات ، فمن غير المرجح أن يؤدي أي دعم إضافي للسمات إلى إصدار WinUI3 الأولي.

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

ربما كطريقة بديلة عن ValidationBase الذي اقترحته ، يجب أن تكون هناك مجموعة من طرق الامتداد ، والتي تقوم بتشغيل عملية التحقق باستخدام Validator.TryValidateObject ، وتقوم بحقن نتائج التحقق في الكيان ، وإخطار التغييرات ؟
بهذه الطريقة ، يمكن تحقيق ذلك بسهولة بمجرد تنفيذ INotifyDataErrorInfo . يمكن أن يكون لدينا أيضًا واجهة ترث من INotifyDataErrorInfo تضيف خاصية تحتوي على مجموعة الأخطاء ، بحيث يمكن التعرف على وقت تشغيل UWP أو مجموعة الأدوات ككيان آلي قابل للتحقق بدلاً من ذلك ، وتعيين الخاصية تلقائيًا إذا تم تنفيذها.

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

هذا هو فكرة عظيمة :)

هل تتساءل عما إذا كانت نماذج مولد المصدر الجديد يمكن أن تساعد هنا أيضًا؟

نعم @ michael-hawker ، أحب أفكارك!

كانت لدي نفس الأفكار منذ فترة عندما قرأت لأول مرة عن إمكانيات مولد المصدر الجديد.

أعتقد أنه باستخدام نماذج منشئ المصدر الجديد ، يمكننا بناء / إنشاء الكثير من الأشياء خلف الكواليس لـ INotifyDataErrorInfo و INotifyPropertyChanged.

لدي دورة WPF حول Pluralsight التي تفعل ذلك بالضبط مع T4 و INotifyPropertyChanged و INotifyDataErrorInfo ، بما في ذلك التعليقات التوضيحية للبيانات للتحقق من الصحة: https://www.pluralsight.com/courses/wpf-mvvm-advanced-model-treatment
تستخدم الدورة أيضًا الخصائص المرفقة المخصصة لربط الأشياء.
الهدف من هذه الدورة هو إظهار كيف يمكنك إنشاء تطبيق MVVM WPF يظهر في كل حقل إدخال إذا تم تغييره وما هي القيمة الأصلية.

لذلك ، بالتأكيد ، فإن إنشاء الأشياء وربما ينتهي الأمر بمكتبة (ربما كجزء من WCT) سيكون أمرًا رائعًا. وأود إعادة هذه الدورة التدريبية لـ WinUI. :)

@ rufw91 أعرف ، أليس كذلك ؟!

ما هي قيود وقتك؟ أول تطبيق لهذا موجود في WinUI3 alpha ، ويجب أن يكون لدينا معاينة لسطح مكتب WinUI قريبًا في // Build timeframe. نحن نخطط على RTM'ing بحلول نهاية العام

stevenbrix ، آمل ذلك ، اضطررت للعودة إلى WPF ، لقد انتهيت بالفعل الآن.

فتحت هذا .

لمتابعة هذا الأمر ، بعد محادثة مع stevenbrix على Twitter ، قمت بدمج التنفيذ الأساسي INotifyDataErrorInfo الذي قدمه هنا في فئة ObservableValidator الجديدة التي يتم تضمينها في مجموعة أدوات MVVM الجديدة (ال مكتبة Microsoft.Toolkit.Mvvm ) ، والتي تستخدم أيضًا INotifyPropertyChanged و INotifyPropertyChanging 😄

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

هل يمكن أن تعطينا تحديثًا لهذا الأمر؟ من الغريب أن UWP 10.0 18362 يدعم INotifyDataErrorInfo . وفقًا لصفحة الوثائق التالية ، https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo؟view=netcore-3.1 INotifyDataErrorInfo "ينطبق" على UWP 10.0. ومع ذلك ، مع تثبيت UWP 10.0 18362 واستهدافه ، لا تعرض مربعات النص عمليات التحقق من صحة INotifyDataErrorInfo . يتم وصف مربعات النص في XAML على النحو التالي:

<TextBox Text="{x:Bind ViewModel.Username, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />

ونستخدم هنا تطبيق ReactiveValidationObject كـ INotifyDataErrorInfo .

worldbeater هذا متاح فقط في أحدث معاينات WinUI3 ، هل تستخدم ذلك؟

شكرا لكstevenbrix! ذاهب لتجربة WinUI3. يسعدني سماع أن INotifyDataErrorInfo و UWP يصادقون ، أخيرًا ✨

worldbeater ، لا يزال قيد المعاينة ، لذلك نود الحصول على تعليقاتك عليه! 💪

worldbeater بالمناسبة ، تقول المستندات إنها متوفرة على UWP 10.0 ، لكن هذا لا يعني أنها مدعومة من قبلها. التوثيق ليس واضحًا بدرجة كافية.