Сборки и пакеты

Вопросы специалистов

Песочница

Вопросы клиентов

Галерея в стиле Вконтакте или Яндекс.Картинок

Организация хранения данных об изображениях галереи

галерея на “prettyPhoto” вопрос

странности с выводом галлерей

Несколько изображений у товара

Не могу разобраться с Gallery. Дерево альбомов

Обычно эти галереи работают с уже имеющимися ссылками. И различные группы картинок идентифицируют по какому-нибудь параметру (тот же rel используют). То есть на странице не надо обязательно миниатюры иметь, достаточно просто ссылок с адресами на картинки и идентификатором для галереи. Кликнув одно фото, можно будет листать эти фотки. То есть миниатюры — одна фотка из галереи, а остальное — просто ссылки, разбитые по блокам галерей.

Добрый день. Обычно эти галереи работают с уже имеющимися ссылками. И различные группы картинок идентифицируют по какому-нибудь параметру (тот же rel используют). То есть на странице не надо обязательно миниатюры иметь, достаточно просто ссылок с адресами на картинки и идентификатором для галереи. Кликнув одно фото, можно будет листать эти фотки. То есть миниатюры — одна фотка из галереи, а остальное — просто ссылки, разбитые по блокам галерей.

Добрый день. Обычно эти галереи работают с уже име

мысль была выводить на одной странице миниатюры всех альбомов, а при клике на миниатюру подружалась бы галерея этого альбома без перезагрузки страницы. я так понимаю это невозможно на данный момент?
 хотя нашел вот такой пример:
 demo.freesoft.portonvictor.org/prettyPhoto-AJAX-test.html#prettyPhoto
 вроде как раз то, но для меня это совсем сложно

мысль была выводить на одной странице миниатюры вс

мысль была выводить на одной странице миниатюры всех альбомов, а при клике на миниатюру подружалась бы галерея этого альбома без перезагрузки страницы.

Я вообще-то и объяснил, как это делается. Неясно выразился? Значит вы еще не изучили как вообще эти галереи работают. Это следует сделать прежде, чем пытаться их вывести.

мысль была выводить на одной странице миниатюры всех альбомов, а при клике на миниатюру подружалась бы галерея этого альбома без перезагрузки страницы. Я вообще-то и объяснил, как это делается. Неясно выразился? Значит вы еще не изучили как вообще эти галереи работают. Это следует сделать прежде, чем пытаться их вывести.

Вдумался, стало понятно))) спасибо!!! оказывается все так просто…
 

 <a href="http://components/focus/images/gallery2/gallery-02.jpg" rel="prettyPhoto[gallery2]" title="title 2"></a>
 <a href="http://components/focus/images/gallery2/gallery-03.jpg" rel="prettyPhoto[gallery2]" title="title 2"></a>
… и т.д.


Вдумался, стало понятно))) спасибо!!! оказывается все так просто… просто добавил ниже <a href="http://components/focus/images/gallery2/gallery-02.jpg" rel="prettyPhoto[gallery2]" title="title 2"></a>
 <a href="http://components/focus/images/gallery2/gallery-03.jpg" rel="prettyPhoto[gallery2]" title="title 2"></a>
… и т.д.

Вдумался, стало понятно))) спасибо!!! оказывается 

Вот именно

можно еще тогда вопрос: если планирую много галерей, от 20 и выше и в каждой хотя бы по 50 фоток. каким образом, быстрее набивать эти ссылки? каким инструментом лучше воспользоваться, так чтоб не по одной фото загружать, а допустим по фтп скинул и все…
 p.s. нельзя ли яндекс диск для хранения всего этого использовать или что либо подобное? или это пока не реализовать?

можно еще тогда вопрос: если планирую много галере

Готов поделиться своим решением, в ходе установки объяснить, как оно работает, что делает, как можно модифицировать и как использовать.
 

Естественно, не бесплатно…

Готов поделиться своим решением, в ходе установки объяснить, как оно работает, что делает, как можно модифицировать и как использовать. Естественно, не бесплатно…

Готов поделиться своим решением, в ходе установки 

каким инструментом лучше воспользоваться, так чтоб не по одной фото загружать, а допустим по фтп скинул и все…

Если речь именно о наполнении галереи, то там есть такое дело как «Пакетная загрузка». Жмете ее, он сообщает о директории, где он будет искать фотки (можно изменить), и все. Грузите туда фотки, он все это скопирует в этот альбом. (каждый альбом придется так же создавать в ручную).
 Есть еще там загрузка zip-архивом.
 Это все в том случае, если используете именно Gallery.
 

p.s. нельзя ли яндекс диск для хранения всего этого использовать или что либо подобное? или это пока не реализовать? 

Я.Диск нет (еще не видел анонса такого пакета, хотя надо бы написать). Но можно облако Amazon3S, соответствующий медиасурс из коробки идет.

каким инструментом лучше воспользоваться, так чтоб не по одной фото загружать, а допустим по фтп скинул и все… Если речь именно о наполнении галереи, то там есть такое дело как «Пакетная загрузка». Жмете ее, он сообщает о директории, где он будет искать фотки (можно изменить), и все. Грузите туда фотки, он все это скопирует в этот альбом. (каждый альбом придется так же создавать в ручную).
 Есть еще там загрузка zip-архивом.
 Это все в том случае, если используете именно Gallery. p.s. нельзя ли яндекс диск для хранения всего этого использовать или что либо подобное? или это пока не реализовать? Я.Диск нет (еще не видел анонса такого пакета, хотя надо бы написать). Но можно облако Amazon3S, соответствующий медиасурс из коробки идет.

каким инструментом лучше воспользоваться, так чтоб

спасибо… с вопросами пока закончено, надо пробовать)

спасибо… с вопросами пока закончено, надо пробоват

Пожалуйста.

в личку черканите пожалуйста, что да как… какие плюсы вашего решения и сколько тенге

в личку черканите пожалуйста, что да как… какие пл

Начал писать в личку, но решил выложить здесь.
 

Вот, небольшой скрипт самописный. На странице вызываю так, например: [[Gal? &galdir=`images/gal/tube`]]
 

Там есть несколько параметров, немножко некрасиво сделал то, что оформление с кодом смешано, но разобраться можно.
 

Сниппет берет все файлы из указанной папки, обходит их циклом, с помощью phpThumbOf генерирует превьюшки и выводит на страницу. Результаты кеширует, чтобы каждый раз в папку не лезть (например, если галерея выводится на нескольких страницах, генерироваться будет только 1 раз). Оттолкнувшись от него можно будет сделать свою галерею.
 

Если скрипт подойдет, но трудно будет разобраться, тогда поговорим о консультациях. Или если будут конкретные вопросы, пишите в клуб)

Начал писать в личку, но решил выложить здесь. Вот, небольшой скрипт самописный. На странице вызываю так, например: [[Gal? &galdir=`images/gal/tube`]] Там есть несколько параметров, немножко некрасиво сделал то, что оформление с кодом смешано, но разобраться можно. Сниппет берет все файлы из указанной папки, обходит их циклом, с помощью phpThumbOf генерирует превьюшки и выводит на страницу. Результаты кеширует, чтобы каждый раз в папку не лезть (например, если галерея выводится на нескольких страницах, генерироваться будет только 1 раз). Оттолкнувшись от него можно будет сделать свою галерею. Если скрипт подойдет, но трудно будет разобраться, тогда поговорим о консультациях. Или если будут конкретные вопросы, пишите в клуб)

Начал писать в личку, но решил выложить здесь. Вот

спасибо огромное, все работает… мне оформление и не надо как бы
 мне достаточно вот такого вывода
 

спасибо огромное, все работает… мне оформление и не надо как бы
 мне достаточно вот такого вывода <a href="images/gallery_N/name.jpg" rel="prettyPhoto[gallery_N]" title="name_Galery_N"></a> и все)))
 спасибо!

спасибо огромное, все работает… мне оформление и н

<?php
$properties = implode("-", $scriptProperties);
$cache_key = "gal".$properties;
$output = $modx->cacheManager->get($cache_key);
if ($output) return $output;
$files = scandir($galdir, 0);
// если директории не существует
if (!$files) return false;
// удаляем . и .. (я думаю редко кто использует)
if ($sort == 0) unset($files[0],$files[1]);
else unset($files[count($files)-1], $files[count($files)-1]);

foreach ($files as $file) {
  if (!$each_href) {$href = $modx->runSnippet('phpthumbof', array("input" => "/$galdir/$file", "options" => "w=1100&h=1100"));} else {$href = $each_href;}
  $output .= $before.'<a href="'.$href.'" '.$class.' rel="prettyPhoto['.$galdir.']">
</a>'.$after."\n";
}
$modx->cacheManager->set($cache_key,$output);
return $output;


выводит то что нужно единственно индификатор это полный путь.
 можно как то обрезать до названия папки?
 ато сейчас он вот в таком виде rel=«prettyPhoto[assets/components/focus/images/gal]»

<?php
$properties = implode("-", $scriptProperties);
$cache_key = "gal".$properties;
$output = $modx->cacheManager->get($cache_key);
if ($output) return $output;
$files = scandir($galdir, 0);
// если директории не существует
if (!$files) return false;
// удаляем . и .. (я думаю редко кто использует)
if ($sort == 0) unset($files[0],$files[1]);
else unset($files[count($files)-1], $files[count($files)-1]);

foreach ($files as $file) {
  if (!$each_href) {$href = $modx->runSnippet('phpthumbof', array("input" => "/$galdir/$file", "options" => "w=1100&h=1100"));} else {$href = $each_href;}
  $output .= $before.'<a href="'.$href.'" '.$class.' rel="prettyPhoto['.$galdir.']">
</a>'.$after."\n";
}
$modx->cacheManager->set($cache_key,$output);
return $output; выводит то что нужно единственно индификатор это полный путь.
 можно как то обрезать до названия папки?
 ато сейчас он вот в таком виде rel=«prettyPhoto[assets/components/focus/images/gal]»

<?php
$properties = implode("-", $scriptProperties

Извините, но столько много вопросов, касаемых самых основ — это очень плохая тенденция. Во-первых, никто не будет постоянно на них отвечать, сутки не резиновые. Во-вторых, это говорит о том, что вы сами мало пытаетесь искать ответы на свои вопросы. Сталкиваясь даже простейшими вопросами, вы не сидите, и не ломаете над этим голову, а просто идете спрашивать. Так вы ничему и никогда не научитесь. Будет бессмысленный копипастинг.

Извините, но столько много вопросов, касаемых самы

да блин оказывается все просто, надо просто прочитать)))
 

[[!Gal1? &galdir=`assets/components/focus/images/gal` &name=`[[*pagetitle]]` ]]

да блин оказывается все просто, надо просто прочитать))) $name  = $scriptProperties['name']; и вызываю [[!Gal1? &galdir=`assets/components/focus/images/gal` &name=`[[*pagetitle]]` ]]

да блин оказывается все просто, надо просто прочит

не нужна — MODX и сам создает переменные по именам всех параметров, так что можно получить доступ к значению любого параметра двумя способами — написать $name или $scriptProperies['name']
 

Кстати, есть еще одна фишка. Если написать так:
 

то в сниппете значение [[*pagetitle]] будет помещено в переменную $input, а путь — в переменную $options (это сделано для того, чтобы можно было создавать свои модификаторы помимо стандартных, типа [[*longtitle:default=`[[*pagetitle]]`]]).
 

Кстати, сниппет phpthumbof является таким модификатором. И параметры в него можно передавать так:
 

[[phpthumbof? &input=`[[+tv.img]]` &options=`w=50&h=50&zc=1`]]

Теперь можно легко понять, что это за строчка такая в сниппете:
 

$modx->runSnippet('phpthumbof', array("input" => "/$galdir/$file"
                                    , "options" => "w=1100&h=1100"));

В принципе, строка $name  = $scriptProperties['name']; не нужна — MODX и сам создает переменные по именам всех параметров, так что можно получить доступ к значению любого параметра двумя способами — написать $name или $scriptProperies['name'] Кстати, есть еще одна фишка. Если написать так: [[*pagetitle:Gal=`assets/images/gal`]] то в сниппете значение [[*pagetitle]] будет помещено в переменную $input, а путь — в переменную $options (это сделано для того, чтобы можно было создавать свои модификаторы помимо стандартных, типа [[*longtitle:default=`[[*pagetitle]]`]]). Кстати, сниппет phpthumbof является таким модификатором. И параметры в него можно передавать так: [[+tv.img:phpthumbof=`w=50&h=50&zc=1`]] или так: [[phpthumbof? &input=`[[+tv.img]]` &options=`w=50&h=50&zc=1`]] Теперь можно легко понять, что это за строчка такая в сниппете: $modx->runSnippet('phpthumbof', array("input" => "/$galdir/$file"
                                    , "options" => "w=1100&h=1100"));

В принципе, строка $name  = $scriptProperties['nam

т.е. вызывать я и так могу
 

[[!Gal1? &galdir=`assets/components/focus/images/gal` &id=`[[*id]]` &options=`w=1100&h=1100`]]


выкинув ту бесполезную строчку, а options присвою "'.$options.'"
 Спасибо за урок!) очень интересно!

т.е. вызывать я и так могу [[!Gal1? &galdir=`assets/components/focus/images/gal` &id=`[[*id]]` &options=`w=1100&h=1100`]] выкинув ту бесполезную строчку, а options присвою "'.$options.'"
 Спасибо за урок!) очень интересно!

т.е. вызывать я и так могу [[!Gal1? &galdir=`asset

вывожу некешированный ресурс с 60 фотографиями, обрабатывается гдето порядка 6 секунд. Хотел поинтересоваться, а если phpthumbof не обрабатывать фото а просто путь выводить, цикл ведь быстрее будет? Но тут путь как раз и формирует phpthumbof и его просто так не выкинуть да?

вывожу некешированный ресурс с 60 фотографиями, об

А вы попробуйте, и посмотрите, что получится.

я уже пробовал- получаю пусто)

Отключите плагин phpThumbofCacheManager — этот плагин каждый раз удаляет сгенерированные картинки при очистке кеша.

Отключите плагин phpThumbofCacheManager — этот пла

Илья, отличное решение! Зачет!:-)

В новой сборке ShopModxBox будет мультигалерея «из коробки». А пока придется самому докручивать, но это не особая проблема.
 

1. Качаем MIGX и создает для шаблонов товаров TV-поле gallery. В параметрах ввода указываем:
 Тип ввода: migx. 
 Вкладки формы:

2. Обновляем getdata-процессор, дописывая формирование данных галереи, вот ревизия.
 

Все. В получаемых данных из процессора catalog/products/getdata у вас в каждом массиве данных товара будут сформированные данные галереи. Далее уже на свой вкус реализуете вывод в шаблоне.

В новой сборке ShopModxBox будет мультигалерея «из коробки». А пока придется самому докручивать, но это не особая проблема. 1. Качаем MIGX и создает для шаблонов товаров TV-поле gallery. В параметрах ввода указываем:
 Тип ввода: migx. 
 Вкладки формы: [
{"caption":"Info", "fields": [
    {"field":"title","caption":"Название"},
    {"field":"image","caption":"Изображение","inputTVtype":"image"},
    {"field":"description","caption":"Описание","inputTVtype":"richtext"}
]} 
] Разметка колонок: [
{"header": "Название", "width": "160", "sortable": "true", "dataIndex": "title"},
{"header": "Изображение", "width": "50", "sortable": "false", "dataIndex": "image","renderer": "this.renderImage"}
] 2. Обновляем getdata-процессор, дописывая формирование данных галереи, вот ревизия. Все. В получаемых данных из процессора catalog/products/getdata у вас в каждом массиве данных товара будут сформированные данные галереи. Далее уже на свой вкус реализуете вывод в шаблоне.

В новой сборке ShopModxBox будет мультигалерея «из

подскажите кто-нибудь стандартный вывод 
 или на свой вкус)

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

     {foreach $object.gallery as $gallery}
         <img src="{snippet name=phpthumbof params="input=`{$gallery['image']}`&options=`w=250&h=300&far=1&bg=FFFFFF`"}"  title="{$gallery['title']}">
     {/foreach}


{foreach $object.gallery as $gallery}
         <im

а можно реализовать выбор сразу нескольких фото? (типа select multiple)?

а можно реализовать выбор сразу нескольких фото? (

Если речь о migx, то rtfm.modx.com/extras/revo/migx/migx.tutorials/migx.use-resource-specific-media-source-and-multifile-uploader
 А вообще цепляйте любую галерею, которая привязывает картинки к документам. Вроде щас что-то новое уже появилось. Но конечно выводить их нужно будет наверн через сниппет. Хотя мало ли какие варианты возможны.

Если речь о migx, то rtfm.modx.com/extras/revo/mig

Совет только один: смотрите логи. Тут может быть все, что угодно, включая непонятные символы в названии альбома, превышение нагрузки на более чем двух альбомах (да-да, и такое может быть). В общем, только логи.

Совет только один: смотрите логи. Тут может быть в

Почитайте это, может поможет.

Кастомная галерея, дело хорошее, были бы покрепче знания.
 Подобное обращение в galSubAlbumRowTpl мне выдает обложки вложенных альбомов.
 

<div id="catalog">
<p>[[+name]]</p>
</div>
[[!Gallery? &containerTpl=`SiteGalleryItemTpl` ]]

Но как Ваш код переработать/использовать для вывода их содержимого, до меня не доходит.

Кастомная галерея, дело хорошее, были бы покрепче знания.
 Подобное обращение в galSubAlbumRowTpl мне выдает обложки вложенных альбомов. <div id="catalog">
<p>[[+name]]</p>
</div>
[[!Gallery? &containerTpl=`SiteGalleryItemTpl` ]] Но как Ваш код переработать/использовать для вывода их содержимого, до меня не доходит.

Кастомная галерея, дело хорошее, были бы покрепче 

К сожалению, с плейсхолдерами я не помогу. Галерея в этом плане весьма не простая, и не прозрачен механизм появления тех или иных плейсхолдеров. Поэтому придется вам или самим ковырять, или ждать кто подскажет если подскажет, или платный проект объявлять.

К сожалению, с плейсхолдерами я не помогу. Галерея

А если по средством xPDO, не подскажите как сразу к элементам вложенных запрос оформить, а не текущему альбому?

А если по средством xPDO, не подскажите как сразу 

Проблема состояла всего лишь в одном условии сниппета Gallery
 

if ($modx->getOption('checkForRequestAlbumVar',$scriptProperties,true)) {
    if (!empty($_REQUEST[$albumRequestVar])) $scriptProperties['album'] = $_REQUEST[$albumRequestVar];
}

Решилась задача на этом этапе очень некрасиво, но была срочная необходимость, поэтому за грамотностью не гнался:
 

if ($modx->getOption('checkForRequestAlbumVar',$scriptProperties,true)) {
    if($scriptProperties['album']!="") $_REQUEST[$albumRequestVar]=$scriptProperties['album'];
    if (!empty($_REQUEST[$albumRequestVar])) $scriptProperties['album'] = $_REQUEST[$albumRequestVar];
}

Код чанка особо не изменился:
 

<div id="catalog">
<p>[[+name]]</p>
</div>
[[!Gallery? &album=`[[+id]]`]]

А для того, чтобы выводились изображения корневых альбомов, не имеющих вложенных альбомов, немного видоизменил код самой страницы:
 

[[!Gallery? &toPlaceholder=`gallery`]]
[[!GalleryAlbums? &toPlaceholder=`galleries`]]
[[!GalleryAlbums? &rowTpl=`galSubAlbumRowTpl` &parent=`[[+gallery.id]]` &showAll=`0` &showInactive=`1` &toPlaceholder=`subgalleries`]]

<div style="float: right">
<h2>Galleries</h2>
<ul>
[[+galleries]]
</ul>
</div>

[[!If?
   &subject=`[[+subgalleries]]`
   &operator=`empty`
   &then=`[[+gallery]]`
   &else=`[[+subgalleries]]`
]]

Проблема состояла всего лишь в одном условии сниппета Gallery if ($modx->getOption('checkForRequestAlbumVar',$scriptProperties,true)) {
    if (!empty($_REQUEST[$albumRequestVar])) $scriptProperties['album'] = $_REQUEST[$albumRequestVar];
} Решилась задача на этом этапе очень некрасиво, но была срочная необходимость, поэтому за грамотностью не гнался: if ($modx->getOption('checkForRequestAlbumVar',$scriptProperties,true)) {
    if($scriptProperties['album']!="") $_REQUEST[$albumRequestVar]=$scriptProperties['album'];
    if (!empty($_REQUEST[$albumRequestVar])) $scriptProperties['album'] = $_REQUEST[$albumRequestVar];
} Код чанка особо не изменился: <div id="catalog">
<p>[[+name]]</p>
</div>
[[!Gallery? &album=`[[+id]]`]] А для того, чтобы выводились изображения корневых альбомов, не имеющих вложенных альбомов, немного видоизменил код самой страницы: [[!Gallery? &toPlaceholder=`gallery`]]
[[!GalleryAlbums? &toPlaceholder=`galleries`]]
[[!GalleryAlbums? &rowTpl=`galSubAlbumRowTpl` &parent=`[[+gallery.id]]` &showAll=`0` &showInactive=`1` &toPlaceholder=`subgalleries`]]

<div style="float: right">
<h2>Galleries</h2>
<ul>
[[+galleries]]
</ul>
</div>

[[!If?
   &subject=`[[+subgalleries]]`
   &operator=`empty`
   &then=`[[+gallery]]`
   &else=`[[+subgalleries]]`
]]

Проблема состояла всего лишь в одном условии снипп

Как приятно все-таки самому суметь сделать, правда? :)

Как приятно все-таки самому суметь сделать, правда

Согласен, но когда на решение задач есть достаточно времени оно вдвойне приятней.

Согласен, но когда на решение задач есть достаточн

Тоже верно. Но у других так же может не быть времени на то, чтобы разбираться в чужих скриптах.

Тоже верно. Но у других так же может не быть време

Так никто ж насильно и не заставляет в чужом коде копаться. Бывает, что просто сталкивался с подобным и готов с ходу ответить.

Так никто ж насильно и не заставляет в чужом коде 

В любом случае, Спасибо, что дали наводку в сниппетах покапаться.

В любом случае, Спасибо, что дали наводку в сниппе

Не за что!

Возник еще вопрос… Есть ли возможность сортировать изображения по тегам?

Возник еще вопрос… Есть ли возможность сортировать

Фильтровать или сортировать? Но в любом случае, нативно — нет. Писать только свой переопределяющий процессор, чтобы дописать немного построение запроса. Тогда как минимум фильтровать получится. С сортировкой сложнее.

Фильтровать или сортировать? Но в любом случае, на

На гитхабе сниппет AlignImages, а здесь в примере AlignImage ;)

На гитхабе сниппет AlignImages, а здесь в примере 

2.Чуть медленнее будет выполняться фильтрация и сортировка по TV этих изображений. Впрочем это проблема/особенность архитектуры modx (а вернее, т.н. универсальных БД), а никак не проблема выбранного варианта хранения данных изображений

Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/

2.Чуть медленнее будет выполняться фильтрация и сортировка по TV этих изображений. Впрочем это проблема/особенность архитектуры modx (а вернее, т.н. универсальных БД), а никак не проблема выбранного варианта хранения данных изображений Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/

2.Чуть медленнее будет выполняться фильтрация и со

Здравствуйте, Николай. В тему по Вашей ссылке задам вопрос. Недавно реализовывал то, о чём Вы там писали. Возможности значительно расширяются с подобным подходом. БлагоДарю Вас от всей Души! Однако, не удалось обращаться к своим данным из таблицы site_content, как к стандартным, через плейсхолдеры. К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал?
 

P.S.: Немножко дописывал Ваш плагин, который Вы указали на Хабре. Хотел сначало выложить куда-то и скинуть Вам, а потом подумал — зачем Вам нужен мой ГК. :) И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь.

Здравствуйте, Николай. В тему по Вашей ссылке задам вопрос. Недавно реализовывал то, о чём Вы там писали. Возможности значительно расширяются с подобным подходом. БлагоДарю Вас от всей Души! Однако, не удалось обращаться к своим данным из таблицы site_content, как к стандартным, через плейсхолдеры. К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал? P.S.: Немножко дописывал Ваш плагин, который Вы указали на Хабре. Хотел сначало выложить куда-то и скинуть Вам, а потом подумал — зачем Вам нужен мой ГК. :) И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь.

Здравствуйте, Николай. В тему по Вашей ссылке зада

ВАРИАНТ 1. Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами

Пожалейте тех, кому потом придется с такой галереей работать.

ВАРИАНТ 1. Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами Пожалейте тех, кому потом придется с такой галереей работать.

ВАРИАНТ 1. Для каждого графического файла создаётс

К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал?

Так вы в смарти-шаблоне попробуйте прописать {$modx->resource->logo}. Так же getdata-процессоры вернут массивы данных ресурсов, содержащих элемент logo. Собственно, мы плейсхолдеры особо не юзаем.

К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал? Так вы в смарти-шаблоне попробуйте прописать {$modx->resource->logo}. Так же getdata-процессоры вернут массивы данных ресурсов, содержащих элемент logo. Собственно, мы плейсхолдеры особо не юзаем.

К примеру так [[*logo]], пришлось писать сниппет, 

C другой стороны, если «каждый графический файл будет иметь свою собственную страницу на сайте (с описанием, характеристиками, комментариями и пр.)», то разве это галерея? В моем понимании, в галерее создаются изображения, а тут получается, что создаются страницы.

C другой стороны, если «каждый графический файл бу

Вариант хороший. На первый взгляд, даже идеальный:
 а) никакие join'ы не требуются
 б) каждое поле индивидуально типизировано и проиндексировано — как следствие, сортировка и фильтрация будут выполняться максимально быстро и корректно (для строковых значений сравнение строковое, для числовых — числовое)
 в) данные занимают меньше места за счёт индивидуальной типизации (верно, только если оригинальные значения TV-параметров из стандартной таблицы с TV будут удаляться)
 

Но этот вариант не всегда реализуем. Как, например, в моём случае.
 У меня более десяти типов ресурсов, у каждого — по 15-20 TV. Итого — сотни TV. Сортировка и фильтрация выполняется по большинству из них. Да, можно все эти TV (по которым выполняется сортировка и фильтрация) автоматом закинуть в (site_content) и индивидуально типизировать на основе характеристик TV. И сделать всё это программно (имя поля = tv_{id}). В mySQL допускается 4 тысячи полей в таблице. Этого с головой хватит и на текущий, и на будущий функционал. Но проблема в том, что работать с этими полями без индексов не имеет смысла, а максимально допустимое число индексов в таблице mySQL — 64. Вот это ограничение и является определяющим. Даже если для некоторых полей создавать составные индексы, всё равно индексов понадобится более 100. К тому же со временем функционал будет только расширяться, добавляться новые типы ресурсов и новые TV-поля.
 

Сейчас у меня реализован следующий вариант:
 а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV
 б) при фильтрации и сортировках подключаются через JOIN только те TV, которые участвуют в этих фильтрах/сортировках (как правило, их не более 3 за раз, а 3 JOIN'а выполняются вполне себе быстро)
 в) в случаях, когда ресурс имеет большое количество TV, а в конечной выборке необходимо получить 2-3 TV-ки, эти TV join'ятся (так быстрее: на json-декодирование большого числа TV нужно время), в остальных случаях для выборки использую поле (properties) с последующим json-декодированием

Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/ Вариант хороший. На первый взгляд, даже идеальный:
 а) никакие join'ы не требуются
 б) каждое поле индивидуально типизировано и проиндексировано — как следствие, сортировка и фильтрация будут выполняться максимально быстро и корректно (для строковых значений сравнение строковое, для числовых — числовое)
 в) данные занимают меньше места за счёт индивидуальной типизации (верно, только если оригинальные значения TV-параметров из стандартной таблицы с TV будут удаляться) Но этот вариант не всегда реализуем. Как, например, в моём случае.
 У меня более десяти типов ресурсов, у каждого — по 15-20 TV. Итого — сотни TV. Сортировка и фильтрация выполняется по большинству из них. Да, можно все эти TV (по которым выполняется сортировка и фильтрация) автоматом закинуть в (site_content) и индивидуально типизировать на основе характеристик TV. И сделать всё это программно (имя поля = tv_{id}). В mySQL допускается 4 тысячи полей в таблице. Этого с головой хватит и на текущий, и на будущий функционал. Но проблема в том, что работать с этими полями без индексов не имеет смысла, а максимально допустимое число индексов в таблице mySQL — 64. Вот это ограничение и является определяющим. Даже если для некоторых полей создавать составные индексы, всё равно индексов понадобится более 100. К тому же со временем функционал будет только расширяться, добавляться новые типы ресурсов и новые TV-поля. Сейчас у меня реализован следующий вариант:
 а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV
 б) при фильтрации и сортировках подключаются через JOIN только те TV, которые участвуют в этих фильтрах/сортировках (как правило, их не более 3 за раз, а 3 JOIN'а выполняются вполне себе быстро)
 в) в случаях, когда ресурс имеет большое количество TV, а в конечной выборке необходимо получить 2-3 TV-ки, эти TV join'ятся (так быстрее: на json-декодирование большого числа TV нужно время), в остальных случаях для выборки использую поле (properties) с последующим json-декодированием

Если речь о десятках и более тысяч документов, то 

Если вся суть проекта крутится вокруг этой галереи, то такой подход предпочтительней. УРЛы, параметры индексации, ТВ-параметры и все такое.

Если вся суть проекта крутится вокруг этой галереи

И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь.

Чессказать времени совсем нет что-то смотреть. Сорри.

И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь. Чессказать времени совсем нет что-то смотреть. Сорри.

И раз уж пишу тут, всё-таки предложу. Если интерес

в) данные занимают меньше места за счёт индивидуальной типизации (верно, только если оригинальные значения TV-параметров из стандартной таблицы с TV будут удаляться)

В целом по проекту: сочувствую…

в) данные занимают меньше места за счёт индивидуальной типизации (верно, только если оригинальные значения TV-параметров из стандартной таблицы с TV будут удаляться) Они удаляются. В целом по проекту: сочувствую…

в) данные занимают меньше места за счёт индивидуал

Пожалейте тех, кому потом придется с такой галереей работать. 

Например, Василий, я уверен, выбрал бы именно такой вариант (отдельная таблица).
 А что там за проблемы возникнут при работе с такой галереей?

Пожалейте тех, кому потом придется с такой галереей работать. Например, Василий, я уверен, выбрал бы именно такой вариант (отдельная таблица).
 А что там за проблемы возникнут при работе с такой галереей?

Пожалейте тех, кому потом придется с такой галерее

то разве это галерея? В моем понимании, в галерее создаются изображения, а тут получается, что создаются страницы. 

Ну так комментарии к изображению, описание изображения, списки ресурсов, с которыми связано изображение и прочая информация, касающаяся конкретного изображения должна же на какой-то странице отображаться. Можно и для такой страницы создать один специальный ресурс+шаблон и выводить там запрошенное изображение со всей информацией. Но в плане SEO эффективнее будет оформить в виде таких страниц сами ресурсы, отвечающие за изображения. Других вариантов нет. Впрочем, это уже не суть важно, как это всё организовать. Кому как нравится. Важно то, как и где организовать хранение данных об изображениях.

то разве это галерея? В моем понимании, в галерее создаются изображения, а тут получается, что создаются страницы. Ну так комментарии к изображению, описание изображения, списки ресурсов, с которыми связано изображение и прочая информация, касающаяся конкретного изображения должна же на какой-то странице отображаться. Можно и для такой страницы создать один специальный ресурс+шаблон и выводить там запрошенное изображение со всей информацией. Но в плане SEO эффективнее будет оформить в виде таких страниц сами ресурсы, отвечающие за изображения. Других вариантов нет. Впрочем, это уже не суть важно, как это всё организовать. Кому как нравится. Важно то, как и где организовать хранение данных об изображениях.

то разве это галерея? В моем понимании, в галерее 

В смысле, я что-то не то делаю? Или проект на modx труднореализуем?

В целом по проекту: сочувствую… В смысле, я что-то не то делаю? Или проект на modx труднореализуем?

В целом по проекту: сочувствую… В смысле, я что-то

Он просто труднореализуем:) Не важно на чем. Но не безнадежен.

Он просто труднореализуем:) Не важно на чем. Но не

Моя реплика относится к «Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами» — у Василия я кину на страницу 100 файлов и готово, а тут 100 раз «создать ресурс» — «открыть файл-браузер» — «загрузить картинку» — «выбрать картинку» — «сохранить ресурс».
 

У Василия вариант 2 получается, потому что ms2Gallery рассчитана на то, чтобы на странице ресурса вывести много картинок. И я бы тоже выбрал вариант 2, но в вашем случае получается, что отдельная страница на картинку, куча характеристик, комментарии — то есть скорость работы с картинками в ms2Gallery нивелируется скоростью заполнения характеристик для каждой картинки. То есть для пользователя будет почти одинаково, что вариант 1, что вариант 2, зато для вас быстрее будет сделать вариант 1.


Моя реплика относится к «Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами» — у Василия я кину на страницу 100 файлов и готово, а тут 100 раз «создать ресурс» — «открыть файл-браузер» — «загрузить картинку» — «выбрать картинку» — «сохранить ресурс». У Василия вариант 2 получается, потому что ms2Gallery рассчитана на то, чтобы на странице ресурса вывести много картинок. И я бы тоже выбрал вариант 2, но в вашем случае получается, что отдельная страница на картинку, куча характеристик, комментарии — то есть скорость работы с картинками в ms2Gallery нивелируется скоростью заполнения характеристик для каждой картинки. То есть для пользователя будет почти одинаково, что вариант 1, что вариант 2, зато для вас быстрее будет сделать вариант 1.

Моя реплика относится к «Для каждого графического 

а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV

Есть еще вариант дублировать их в отдельную таблицу (:

а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV Есть еще вариант дублировать их в отдельную таблицу (:

а) все TV-поля дублируются в поле (properties) таб

Чем сложнее проект, тем меньше потенциальных конкурентов

Чем сложнее проект, тем меньше потенциальных конку

Есть еще вариант дублировать их в отдельную таблицу (: 

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

Есть еще вариант дублировать их в отдельную таблицу (: Тогда для каждого типа ресурсов придётся свою таблицу создавать с TV (из-за ограничения на число индексов в одной таблице). Ну а коли для каждого типа ресурсов будет своя таблица, то и сами ресурсы логично будет хранить в этих таблицах. А коли ресурсы будут храниться в отдельных таблицах, тогда и modx не нужен.

Есть еще вариант дублировать их в отдельную таблиц

А еще тем выше риски, издержки и т.п., и соответственно ниже профит и больше срок окупаемости. Тут не все так однозначно.

А еще тем выше риски, издержки и т.п., и соответст

В своём проекте я не использую какие-либо сторонние сниппеты и компоненты (кроме компонентов для работы с комментариями), поскольку ни один компонентов не обеспечивает требуемого функционала проекта. Даже элементарно хлебные крошки, пагинация, баннеры, псевдонимы, uri, ajax-подгрузка, редиректы, SEO и многое другое — всё это реализовано собственным кодом с индивидуальной логикой. Соответственно, и сабжевый вопрос подразумевает написание собственного интерфейса для загрузки изображений (но только для загрузки). Именно поэтому, я и не рассматриваю здесь возможность использования сторонних компонентов в качестве критерия выбора. Ну а собственный интерфейс для загрузки изображений будет обеспечивать возможность загрузки и одного изображения, и нескольких одновременно (с указанием характеристик для каждой из них).
