HTML Writer

kreator

finsoftrz писал(а): ↑21 Апрель 2020, 10:22 Разумеется, это вполне конкретные случаи, когда есть целесообразность в html форме. У меня еще есть некоторые сомнения, как это все будет выглядеть, когда заказ, скажем, на сотню позиций.

Выглядеть может будет и нормально. Но это не документ в полном смысле. Даже распечатать цивилизованно будет проблема. Какие я вижу варианты, с какими сталкивался. 1. Прикрепляют pdf (Билайн, например). 2. В письме ссылка на pdf, который лежит у них на сервере (Сбербанк, по-моему), какое-то время лежит.

finsoftrz

У нас стандартно отправляются xls формы. Это распространенный подход при работе торговых фирм. Вообще, в справочнике контрагентов можно настроить, в каком виде генерить письмо, если стандартный вариант с xls не устраивает. С формой html тоже был вариант, только в виде прикрепляемого файла.
Проблемы, насколько я знаю, у тех получателей, которые смотрят свои заказы на смартфонах.
Pdf имеет свои ограничения. И, насколько я знаю, его формирование из клариона связано с определенными проблемами.

RaFaeL

У меня задачи генерировать в HTML документы и нет. Хотя технически это и будет, видимо, в итоге возможно, так как движок общий. Отчет это не обязательно документ, часто это просто отчет

kreator

Вы же хотите плясать от своего редактора отчёта. Мне представляется, что он никаким боком к html. Будете и его допиливать? Если нет, то получите что-то сходное со стандартным классом SV.

RaFaeL

Наш редактор - универсальный. Он может быть использован и для создания документов (если запускается из окна типа "Form" или т.п.), и для экспорта любой произвольной информации, например можно просто передать туда list и он его напечатает/выгрузит. Просто разные режимы. Внутри редактора все хранится во внутренних независимых структурах данных (либо эти структуры создаются динамически по формату листа). Основной элемент структуры это контрол, имеющий уйму свойств - положение, высота-ширина, границы, шрифты, цвета и т.д. и т.п.. Соответственно, если надо что-то напечатать, то из этих данных/контролов динамически собирается структура типа Report и затем печатается. Если же надо выгрузить куда-то (Excel, RTF), то эти же данные передаются в соответствующий класс экспорта. Сам редактор ничего не знает о форматах выгрузки, он к ним не привязан, как не привязан и к базе данных. При экспорте просто пробегаем по структуре, вызываем методы необходимого в этот момент класса экспорта, передаем данные, класс создает файл.

kreator

У Вас "контрол" имеет свойства "ссылка", "якорь", например?

RaFaeL

kreator писал(а): ↑21 Апрель 2020, 21:35 У Вас "контрол" имеет свойства "ссылка", "якорь", например?

Надо будет- добавим. Для выгрузки в RTF например добавил свойство "выравнивание по ширине", которого раньше не было, так как Report и wmf в такое не умеют. Это все мелочи

kreator

Раз мелочи, пробуйте. Коллега смотрит HTML5. Там очень много появилось разных удобных контролов (или объектов, не знаю как сказать). Например, для просмотра и позиционирования больших текстов, таблиц... К отчётам это никакого отношения не имеет. А вот для письма с большими списками может быть да.

kreator

Можно ещё посмотреть всё-таки стандартный SV класс. Вроде всё там неплохо. Панель навигации просто убрать. Бесконечный список - выставить размер отчёта с запасом (может гоню). Во всяком случае контролы там отрабатываются нормально.

Yufil · Сообщение **Yufil** » 23 Апрель 2020, 10:43

kreator писал(а): ↑22 Апрель 2020, 10:38 Раз мелочи, пробуйте. Коллега смотрит HTML5. Там очень много появилось разных удобных контролов (или объектов, не знаю как сказать). Например, для просмотра и позиционирования больших текстов, таблиц... К отчётам это никакого отношения не имеет. А вот для письма с большими списками может быть да.

HTML5 единообразно ( ну, почти ) поддерживается всеми (ну, почти) браузерами. Если нет потребности работать со старыми версиями браузеров ( до 2010 - 2011 ), лучше делать всё на HTML5.

То же самое касается кодировки. XML/HTML/JS/CSS - только на UTF-8.

kreator

Речь о письмах. Это несколько другое. У меня не фантастический опыт. Но, я так понимаю, некоторые тэги там отсутствуют. В частности кодировка задаётся в другом месте. Поэтому можно обойтись и без UTF-8. Тоже не разбирался насчёт поддержки HTML5 в почтовых клиентах. Пока было без надобности. Насчёт отдельного CSS тоже вопрос. Не говоря уже о JS. Всё-таки письмо это не сайт. Что я и отмечаю. Универсальность - это без сомнения здорово. Но есть нюансы.

finsoftrz

CSS можно внедрить в текст письма. Например, так.

Код: Выделить всё

<html>
 <head>
   <style type="text/css">
     table {
        border: 1px solid black;
     }
     td, th {
        text-align: center;
        padding: 2px;
     }
     .cName  {
        text-align: left;
     }
     .cSum  {
        text-align: right;
     }
     .cKol  {
        text-align: right;
     }
   </style>
 </head>
 <body>
  <h4>МАКЕТ                                         </h4>
  <h2>Подтверждение заказа от 27.01.2020г.          </h1>
  <h4>Чебурков В.М.(Шилово,Тырново)                 </h4>
  <h4>                                              </h4>
  <table border="1">
   <tr>
    <th>п/п</th>
    <th>Наименование</th>
    <th>Код</th>
    <th>Ед</th>
    <th>Затреб</th>
    <th>Кол-во</th>
    <th>Скидка,%</th>
    <th>Цена</th>
    <th>Сумма</th>
   </tr>
  <tr>
    <td>     1 </td>
    <td class="cName">Кетчуп 1кг+кукуруза 410г"ХАЙНЦ"1/6                                                                                                     </td>
    <td> 82049 </td>
    <td>      шт </td>
    <td>       1 </td>
    <td class="cKol">       1 </td>
    <td class="cKol">       - </td>
    <td class="cSum">       97,50 </td>
    <td class="cSum">       97,50 </td>
  </tr>
   <tr>
    <td></td>
    <td></td>
    <td></td>
    <td></td>
    <td></td>
    <td></td>
    <td></td>
    <td style="font-weight:bold">Итого:</td>
    <td class="cSum" style="font-weight:bold">       97,50 </td>
   </tr>
  </table>
  <br>
  <div style="padding-left:20px; font-weight:normal; font-size:14px">      Сумма прописью Девяносто семь рублей 50 копеек                                                                     </div>
 </body>
</html>

kreator

Согласен. Поэтому и говорю - специфика. Для сайта так бы делать никто не стал. Сделали бы отдельным файлом. Есть даже тема - внедрить рисунок в тело. Но это вообще изврат.

Yufil · Сообщение **Yufil** » 23 Апрель 2020, 18:26

kreator писал(а): ↑23 Апрель 2020, 11:51 Речь о письмах. Это несколько другое. У меня не фантастический опыт. Но, я так понимаю, некоторые тэги там отсутствуют. В частности кодировка задаётся в другом месте. Поэтому можно обойтись и без UTF-8. Тоже не разбирался насчёт поддержки HTML5 в почтовых клиентах. Пока было без надобности. Насчёт отдельного CSS тоже вопрос. Не говоря уже о JS. Всё-таки письмо это не сайт. Что я и отмечаю. Универсальность - это без сомнения здорово. Но есть нюансы.

1. Я просто аттачил HTML-файл к письму,а получатель вполне корректно видел HTML в тексте письма, невзирая на кодировку. CSSв письмо не вставлял, прописывал свойства прямо в HTML <table style=".... "> </table> , но это вопрос вкуса.

2. Стандарт HTML5 принят в 2009-2010 году, его все должны отображать.

finsoftrz

kreator писал(а): ↑23 Апрель 2020, 13:11 Согласен. Поэтому и говорю - специфика. Для сайта так бы делать никто не стал. Сделали бы отдельным файлом. Есть даже тема - внедрить рисунок в тело. Но это вообще изврат.

Зависит от сайта. Если простенькая визитка, то вполне уместно обойтись без отдельного css файла. Еще css можно непосредственно в html тэги внедрять. Это удобно, когда используем параметрическую настройку, чтобы не плодить кучу дополнительных стилей.