Руслан

Question

HTML
+3 ещё

Ширина html страницы на мобильных устройствах?

19 подписчиков
более трёх лет назад
31760 просмотров

3

ответа

Answer 1 · 2012-03-04 21:17:56

Руслан @Razbezhkin Автор вопроса

программист, преподаватель

Большое вам спасибо!
как собиру нужную мне схему, отпишусь, что получилось.

Ответ написан более трёх лет назад

2 комментария

Answer 2 · 2019-10-02 16:39:10

В ходе разных экспериментов я пришел к такому выводу:
Если мы хотим сделать страницу (компонент|view) чтобы соблюдались такие условия:
- у компонента есть параметры, влияющие на его отображение (например, номер страницы списка и/или фильтры)
- мы хотим чтобы в url отражались эти параметры и можно было сохранить ссылку на компонент в таком виде
- чтобы при открытии страницы по ссылке внешний вид компонента восстанавливался.
- если мы ходим вперед/назад в браузере, то восстанавливается состояние, соответствующее истории браузера.

То нам следует писать компонент следующим образом:
1. Все параметры, которые мы хотим иметь в url необходимо изменять через маршрутизацию при помощи элемента "router-link", или атрибутов "to" некоторых элементов, или при помощи this.$routes.push. При этом ссылка должна быть такой, чтобы все параметры, кроме изменяемого были такими же.

Например, у нас есть номер страницы, размер страницы и категория, которые должны быть в url, чтобы пользователь мог пересылать ссылку на определенную страницу определенной категории. Таким образом, ссылки пагинатора должны иметь вид:
/goods?page=1&ps=20&catid=10, /goods?page=2&ps=20&catid=10, /goods?page=3&ps=20&catid=10
соответственно, если у нас будет 50 параметров, которые мы должны отражать, то нам нужно будет организовать адреса переходов для 50 параметров, причем для всех компонентов, которые меняют эти параметры, для этого, наверное, нужно написать какой-нибудь велосипед, который берет текущие параметры урлов, меняет (или добавляет) в них какой-то один и генерирует новый адрес перехода.

2. нужно написать в компоненте метод инициализации, который при помощи параметров в url восстанавливает состояние компонента.

3. в хуке жизненного цикла mounted и в watch'ере маршрутизатора ($route) вызывать метод инициализации из п.2.

4. (это п.1 наоборот) нельзя напрямик (без перехода через маршрутизатор) менять состояние при изменении любого параметра влияющего на состояние, т.е. пагинатор не должен просто менять переменную, отвечающую за номер страницы и обновлять массив загруженных товаров - это не изменит url, и следовательно не позволит получить правильную ссылку.

Насколько это нормальное решение? есть ли у кого-то более изящное? как делаете вы?
Спасибо.

Answer 3 · 2022-02-03 15:56:14

В общем, не все так просто как казалось.
Пришлось скачать исходники opentelemetry https://github.com/open-telemetry/opentelemetry-dotnet и посмотреть, как устроено распространение трассировочной информации в инструментарии AspNetCore.

Сохранение, передача и восстановление TraceID (и доп информации) называется Propogation.
В пакете OpenTelemetry Есть специальный класс:
OpenTelemetry.Context.Propagation.Propagators
Который возвращает этих пропогаторов с помощью которых производиться внедрение и извлечение контекстной информации (информации о трассировке).

Чтобы куда-нибудь внедрить данные о трассировке, можно использовать примерно такой код:

//достаем текстового распространителя
var textMapPropagator = Propagators.DefaultTextMapPropagator;
//формируем контекст распространения
var propContext = new OpenTelemetry.Context.Propagation.PropagationContext(Activity.Current.Context, Baggage.Current);
//этот метод вызывает для каждого необходимого значения их контекста распространения ваш же метод, который сохраняет пару ключ-значения для последующего восстановления
textMapPropagator.Inject(propContext,context, (ctx, name, val) =>
{
    ctx.Headers.Set(name,val);
});

На другой стороне нужно контекст трассировки восстановить. код примерно такой:

//извлекаем из среды распространяемую трейс-информацию
        var propagator = Propagators.DefaultTextMapPropagator;
        PropagationContext propagationContext = propagator.Extract(default, context,
            (ctx, name) => { return new string[] { ctx.Headers.Get<string>(name) }; });

        if (propagationContext.ActivityContext.IsValid())
        {
            //формируем новый спан.
            newOne = new Activity("Consumer");
            newOne.SetParentId(propagationContext.ActivityContext.TraceId,
                propagationContext.ActivityContext.SpanId,
                propagationContext.ActivityContext.TraceFlags);
            newOne.TraceStateString = propagationContext.ActivityContext.TraceState;
            newOne.Start();
            newOne.IsAllDataRequested = false;

            Baggage.Current = propagationContext.Baggage;
        }

в результате контекст трассировки восстанавливается и в Jaeger попадает в связанном виде.
Единственная проблема в том, что именно этот Span не сохраняется (хотя все последующие в цепочке - да) и появляется Warning вида: "invalid parent span IDs=b3f757a84de75eda; skipping clock skew adjustment"
Что с ним делать - пока не знаю. чего-то все такие не хватает

Answer 4 · 2019-07-20 13:31:24

Я провел эксперимент: в решении два проекта, первый проект (.net standard 2.0) ссылается на nuget пакет, второй проект (.net framework 4.7.2) ссылается на первый. Построение решения происходит успешно, но при запуске второго проекта возникает ошибка: не удалось загрузить сборку из nuget пакета. от сюда вывод - при построении зависимости из nuget пакетов, которые непосредственно не содержатся в проекте не копируются в выходную папку.

Еще я нашел статью: https://terryaney.wordpress.com/2018/05/06/msbuild... в которой это подтверждается и решение заключается в использовании MSBuild со своей конфигурацией. А вот подключать nuget пакеты ко всем проектам - подход не самый лучший (хотя самый простой).

Я продолжил экспериментировать:
Создал нулевой проект (.net standard 2.0) на который ссылается только первый проект. При построении и запуске второго проекта все зависимости были разрешены, приложение запустилось без проблем.

И еще один эксперимент:
Я создал четвертое приложение, но уже .net core 2.1, которое ссылается только на проект 1, и к моему удивление при его сборке и запуске все зависимости, включая nuget пакет были разрешены, запуск произошел успешно.

Видимо, .net standard и .net core проекты строятся не так, как это делают .net framework проекты.