LK
не пролестать страницу вниз, контент не отрендерился
ну тогда никак, нужно страниццу пролистать и только потом печатать ибо нужен контент
Size: a a a
2019 September 05
DL
ну тогда никак, нужно страниццу пролистать и только потом печатать ибо нужен контент
так отрендерилась юзера
DL
ну тогда никак, нужно страниццу пролистать и только потом печатать ибо нужен контент
окне печати не отрендерилась
LK
LK
DL
я с делла так но у меня есть проблема с этим, в это окно новое нельзя добавить стили а мне надо стилизовать документ
DL
как их добавлять есть предложения?
LK
как их добавлять есть предложения?
там есть ссылка link rel или как ее для стилей
LK
пробуйте подключать стили, это же обчная страница
LK
или inline css
DL
тут как то странно рендерится, svg не показывается
DN
ниукого не сломалось ничего на 76 хроме? у меня сегодня беда и контент прыгает и мигает
DN
поставил нестабильную 78 версию хрома и там все ок(
КТ
Гайз
Нужен совет. Есть самостоятельный (и показывает, и с апи общается) компонент "файл менеджер" для работы с Amazon S3 в рамках моего сайта
Сейчас внедряется новый функционал - синхронизация файлов с мобильным приложением. Для управления файлами нужен компонент типа такого, который описал выше.
Следовательно резонной идеей кажется сделать имеющийся файл менеджер универсальным, чтобы можно было его использовать для разных файловых хранилищ.
Вопрос следующий: как построить архитектуру такого компонента, чтобы он был смарт (общался с апи) и при этом мог бы использоваться для разных хранилищ?
Варики:
1. Говорить ему тип хранилища через аттрибут, инжектить всё возможные сервисы и использовать нужные сервисы исходя из аттрибута — не очень нравится из-за того, что инжектим всё подряд.
2. Пропихивать ему нужный сервис через байндинг-аттрибут и использовать внутри, не зная о том с каким хранилищем работаем — не очень нравится потому что есть необходимость менять интерфейс для разных хранилищ
2. Использовать всякую ангуляровскую магию для конфигурации компонента — потенциально нравится, но не шарю
Нужен совет. Есть самостоятельный (и показывает, и с апи общается) компонент "файл менеджер" для работы с Amazon S3 в рамках моего сайта
Сейчас внедряется новый функционал - синхронизация файлов с мобильным приложением. Для управления файлами нужен компонент типа такого, который описал выше.
Следовательно резонной идеей кажется сделать имеющийся файл менеджер универсальным, чтобы можно было его использовать для разных файловых хранилищ.
Вопрос следующий: как построить архитектуру такого компонента, чтобы он был смарт (общался с апи) и при этом мог бы использоваться для разных хранилищ?
Варики:
1. Говорить ему тип хранилища через аттрибут, инжектить всё возможные сервисы и использовать нужные сервисы исходя из аттрибута — не очень нравится из-за того, что инжектим всё подряд.
2. Пропихивать ему нужный сервис через байндинг-аттрибут и использовать внутри, не зная о том с каким хранилищем работаем — не очень нравится потому что есть необходимость менять интерфейс для разных хранилищ
2. Использовать всякую ангуляровскую магию для конфигурации компонента — потенциально нравится, но не шарю
КТ
На данный момент структура такая:
LK
Гайз
Нужен совет. Есть самостоятельный (и показывает, и с апи общается) компонент "файл менеджер" для работы с Amazon S3 в рамках моего сайта
Сейчас внедряется новый функционал - синхронизация файлов с мобильным приложением. Для управления файлами нужен компонент типа такого, который описал выше.
Следовательно резонной идеей кажется сделать имеющийся файл менеджер универсальным, чтобы можно было его использовать для разных файловых хранилищ.
Вопрос следующий: как построить архитектуру такого компонента, чтобы он был смарт (общался с апи) и при этом мог бы использоваться для разных хранилищ?
Варики:
1. Говорить ему тип хранилища через аттрибут, инжектить всё возможные сервисы и использовать нужные сервисы исходя из аттрибута — не очень нравится из-за того, что инжектим всё подряд.
2. Пропихивать ему нужный сервис через байндинг-аттрибут и использовать внутри, не зная о том с каким хранилищем работаем — не очень нравится потому что есть необходимость менять интерфейс для разных хранилищ
2. Использовать всякую ангуляровскую магию для конфигурации компонента — потенциально нравится, но не шарю
Нужен совет. Есть самостоятельный (и показывает, и с апи общается) компонент "файл менеджер" для работы с Amazon S3 в рамках моего сайта
Сейчас внедряется новый функционал - синхронизация файлов с мобильным приложением. Для управления файлами нужен компонент типа такого, который описал выше.
Следовательно резонной идеей кажется сделать имеющийся файл менеджер универсальным, чтобы можно было его использовать для разных файловых хранилищ.
Вопрос следующий: как построить архитектуру такого компонента, чтобы он был смарт (общался с апи) и при этом мог бы использоваться для разных хранилищ?
Варики:
1. Говорить ему тип хранилища через аттрибут, инжектить всё возможные сервисы и использовать нужные сервисы исходя из аттрибута — не очень нравится из-за того, что инжектим всё подряд.
2. Пропихивать ему нужный сервис через байндинг-аттрибут и использовать внутри, не зная о том с каким хранилищем работаем — не очень нравится потому что есть необходимость менять интерфейс для разных хранилищ
2. Использовать всякую ангуляровскую магию для конфигурации компонента — потенциально нравится, но не шарю
делаешь папку amazon-file-manager
и туда пихать шаблон директиву и сервис
и туда пихать шаблон директиву и сервис
КТ
делаешь папку amazon-file-manager
и туда пихать шаблон директиву и сервис
и туда пихать шаблон директиву и сервис
Так с амазоном он связан не будет напрямую, Амазон — чисто кейс для этого менеджера
2019 September 06
C☭
Привет! может кто уточнить. какую точно надо писать версию для ANDROID_SUPPORT_V4_VERSION при установке cordova плагина???
например
нужно ли мне вписать самую актуальную версию или самую минимальную? на данный момент мы поддерживаем приложение от
ANDROID_SUPPORT_V4_VERSION
например
cordova plugin add cordova-plugin-file-opener2@2.1.4 --shrinkwrap --variable ANDROID_SUPPORT_V4_VERSION="23.+"
cordova plugin add cordova-android-support-gradle-release@2.0.1 --shrinkwrap --variable ANDROID_SUPPORT_VERSION="27.+"
нужно ли мне вписать самую актуальную версию или самую минимальную? на данный момент мы поддерживаем приложение от
android Lollipop@5 API-LVL 21 – 22