http://www.webmasterwiki.ru/ПожеланияПользователей History/revisions of Wiki-учебник по веб-технологиям/ПожеланияПользователей en-us http://www.webmasterwiki.ru/PozhelanijaPol'zovatelejj/show?time=2008-02-10+00%3A13%3A04 <div class="pageBefore"><img src="http://www.webmasterwiki.ru/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a name=".pozhelanijapol_zovatelejj" href="http://www.webmasterwiki.ru/PozhelanijaPol'zovatelejj" class="">/Пожелания&nbsp;Пользователей</a> за <a href="http://www.webmasterwiki.ru/PozhelanijaPol'zovatelejj?time=2008-02-10+00%3A13%3A04">2008-02-10 00:13:04</a> и <a href="http://www.webmasterwiki.ru/PozhelanijaPol'zovatelejj">2009-03-22 14:29:33</a></b><br /> <br /> <b>Удалено:</b><br /> <div class="deletions">1. Публикация в&nbsp;рубрики сообществ &ndash; это&nbsp;главное, что&nbsp;мешает при&nbsp;активной<br /> групповой работе. Модель, предложенную Kuso<br /> (<a href="http://www.npj.ru/in/npjdev/by/kuso/335496" target="_blank" title="Внешняя ссылка (откроется в новом окне)" class="outerlink"><img src="http://www.webmasterwiki.ru/themes/canary/icons/web.gif" alt="" border="0" />http://www.npj.ru/in/npjdev/by/kuso/335496</a>) я&nbsp;считаю не&nbsp;очень удачной &ndash; у<br /> автора сообщения и&nbsp;менеджеров сообществ могут быть разные представления по<br /> поводу смысловой структуры журнала. Проблема усугубляется, если делается<br /> кросспостинг.<br /> 2. В&nbsp;панели управления аккаунтом сделать возможность управления подписками.<br /> 3. Админовский интерфейс узла тоже не&nbsp;помешал бы.<br /> 4. Для&nbsp;интенсивной работы над&nbsp;документом была бы&nbsp;полезной такая фича, как<br /> фиксация актуальной версии. Если возникнет необходимость внести изменения<br /> в&nbsp;документ, находящийся в&nbsp;публичном доступе, сейчас нужно или&nbsp;перекрывать<br /> доступ к&nbsp;редактируемому документу, или&nbsp;заводить новый документ-копию для<br /> работы над&nbsp;ним &ndash; иначе простой пользователь будет видет весь процесс<br /> редакторских правок, что&nbsp;не&nbsp;есть хорошо. Неплохо с&nbsp;точки зрения интерфейса<br /> выглядели бы&nbsp;радиокнопки с&nbsp;пометкой &laquo;актуальная версия&raquo; напротив каждой<br /> строки на&nbsp;странице &laquo;версии документа&raquo;. Соответственно, нужно разграничение<br /> прав на&nbsp;управление актуализацией документа.<br /> 5. Для&nbsp;каждой страницы/записи сделать дополнительное поле с&nbsp;набором<br /> ключевых слов (не путать с&nbsp;рубриками!). Единственное их&nbsp;назначение -<br /> дублирование 1:1 в&nbsp;теге meta name="keywords" в&nbsp;результирующем html-коде.<br /> Унифицировать эти&nbsp;ключевые слова с&nbsp;полем &laquo;интересы&raquo; на&nbsp;странице профиля<br /> журнала. Сделать поиск по&nbsp;ключевым словам/интересам.<br /> 6. Сделать возможность создания многоязыкового контента (и, само собой,<br /> интернационализировать сам&nbsp;движок). Для&nbsp;многих сайтов актуальна<br /> возможность размещения материала на&nbsp;нескольких языках. На&nbsp;уровне<br /> интерфейса это&nbsp;видится в&nbsp;виде нескольких закладок при&nbsp;редактировании<br /> документа/записи, на&nbsp;каждой из&nbsp;которых располагался бы&nbsp;контент на&nbsp;каждом<br /> из&nbsp;языков. Интернациализируемыми предлагается сделать поля<br /> &laquo;название/заголовок документа&raquo;, &laquo;ключевые слова&raquo; (см. п.5) и&nbsp;собственно<br /> само содержимое. Крайне полезным было бы&nbsp;наличие разграничения прав<br /> доступа на&nbsp;уровне языков &ndash; на&nbsp;практике, переводчики оригинального контента<br /> должны иметь доступ к&nbsp;правке только своей языковой версии.<br /> 7. (совсем мелочь) Созданный однажды документ может стать рубрикой только<br /> после добавления рубрики при&nbsp;редактировании очередного документа/записи.<br /> Причем название рубрики должно совпасть с&nbsp;названием ранее созданного<br /> документа. Удобным это&nbsp;назвать можно только на&nbsp;весьма нетрезвую голову. В<br /> локальной установке эта&nbsp;проблема решена добавлением чекбокса &laquo;Включить в<br /> список доступных ключевых слов&raquo; в&nbsp;группе &laquo;Опции и&nbsp;настройки&raquo; на&nbsp;странице<br /> редактирования документа. Правке подверглись:<br /> Файл &laquo;npj/messagesets/std_form_RecordEdit.php&raquo;, добавлена строка:<br /> <!--notypo--><div class="code"><code><span style="color: #000000"> "Form.other"&nbsp;=&gt;&nbsp;"Прочее",</span> </code></div><!--/notypo--><br /> файл &laquo;npj/handlers/record/!form_record.php&raquo;, добавлен блок:<br /> <!--notypo--><div class="code"><code><span style="color: #000000"> if&nbsp;($type&nbsp;==&nbsp;RECORD_DOCUMENT)<br />{<br />&nbsp;&nbsp;&nbsp;$other&nbsp;=&nbsp;array(&nbsp;"is_keyword"&nbsp;);<br />&nbsp;&nbsp;&nbsp;$group2[]&nbsp;=&nbsp;&amp;new&nbsp;FieldCheckboxes(&nbsp;&amp;$rh,&nbsp;array(&nbsp;"field"&nbsp;=&gt;&nbsp;"other",<br />"fields"&nbsp;=&gt;&nbsp;$other,&nbsp;"default"&nbsp;=&gt;&nbsp;"1",&nbsp;)&nbsp;);<br />}</span> </code></div><!--/notypo--><br /> Ну&nbsp;и хотелось бы&nbsp;видеть более широкие возможности для&nbsp;форматирования в<br /> виде тегов, дублирующие html-всикй &lt;div&gt; с&nbsp;набором сопутствующих свойств<br /> CSS. Сейчас для&nbsp;красивой страницы не&nbsp;хватает возможности размешения блоков<br /> произвольной ширины (таблицы предполагают колонки одинаковой ширины, а<br /> потому не&nbsp;выход) с&nbsp;произвольной рамкой, отступами, границами, обтеканием и<br /> пр. Это&nbsp;пожелание в&nbsp;самом общем виде, потому как&nbsp;формализовать его&nbsp;в<br /> терминах NPJ&nbsp;я&nbsp;не берусь.<br /> Автор предложений: Евстигнеев Евгений Юрьевич</div></div>