![]() |
#10 |
Участник
|
Цитата:
да, можно передавать строковый тег. но обычно стратегия определяется не menuItem, а datasource: если стоим на одной записи, то делаем одно, если на другой, то делаем другое, если вызываем из другой таблицы, то третье и так далее. а в менюИтемах задаются режимы обработки. Цитата:
собственно, как и раньше, имеем: = эта штука работает на refleaction (со всеми вытекающими последствиями) = вместо конструктора должен быть отдельный класс-запускач (дополнительно к адаптерам, хендлерам, хандлерам, хелперам добавляется еще и strategy) = отдельный класс-запускач ломает систему перекрестных ссылок - теперь понять где что используется и как работает намного сложнее да, в platform update 7 они таки сделали.
Но: = никакой параллельности или асинхронности в фреймворке не предполагается = за уникальностью ключа должен следить сам программист = ключ - строка, с позиционными значениями (почему не аксаптовский контейнер, не xml, не json, не другой сериализуемый объект? почему не использовать имя класса в качестве ключа?) = вся стратегия определения ключа должна находится в одном месте - попытка сделать делегирование принятия решения о ключе приводит к возвращению к иерерхии конструкторов, только в отдельном классе. Другими словами, все равно есть длинный список параметров с заданными позициями. но у них нет дефолтных значений. Та-дам! А весь конструктор должен быть в одном методе. Со всеми пересечениями кода. Та-дам! самое интересное, что эта штука не решает проблему подключения кода от разных производителей. особенно, если разные производители добавлят классы с разными строками-ключами в середину иерархии. или добавят одинаковые ключи для разных классов. мы все еще на уровне "надо сделать атрибут"? да, все уже в курсе. вопрос - какой? как? какова методика добавления класса в иерархию с атрибутами? как добавлять в середину иерахии? как добавлять класс листом в иерархию? кто следит за уникальностью? что должно произойти с методом, который вычисляет ключ после добваления новый классов в иерархию? насколько эта байда проще-легче, чем просто код конструкторов? причем хорошо бы иметь проектик с общей кодовой базой. как предмет для обсуждения. вот-вот! именно! можно. спасибо. только у нас щас должен быть engineering complete. боюсь, что на этой неделе я только урывками во время компиляции. но тема - интересная. в идеале нужен проект на семействе классов с иерархией. спасибо. Цитата:
подумайте еще. для дальнейшего предметного обсуждения: 1. выберите пример с иерархическим семейством, а не плоским. 2. подумайте что будет, если в эту иерархию добавляет новые классы не один программист, а хотя бы два независимых программиста. 3. подумайте как предоставить эту расширенную функциональность пользователями. и главное: а чем получившаяся конструкция по сути отличается от старых добрых конструкторов? (не считая дополнительной трудоемкости и отвалившихся перекрестных ссылок, конечно) Последний раз редактировалось mazzy; 01.06.2017 в 09:01. |
|
Теги |
sysextension framework, sysoperation framework, как правильно, полезное |
|
|