Елнур Уразымбетов

NikolayAlb: Лично я считаю, что задача должна быть независимой от коммента или координаты картинки.
Поэтому, предлагаю следующий вариант структуры БД:

Task:
    id
    title
    related_task_id
Image:
    id
    task_id
    path_to_file
    position_x = null
    position_y = null
    width = null
    length = null    
ImageComment:
    id
    image_id
    text
    position_x
    position_y
    width
    height

= null - Означает, что он по умолчанию пустой

Теперь попробую объяснить логику:
Как вы видите. задача - независимая сущность. Но задачу можно связывать к другой задачу. Объясню это чуть ниже.

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

К картинке можно писать комменты. Текст коммента, координаты x, y, ширина и высота. Думаю все понятно.

Теперь внимание. У вас есть два варианта создания задачи. Первое, это когда вы создаете его отдельно.
Второе, когда создаете задачу относящуюся к определенной области картинки (картинка в другой задаче).

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

Думаю, вы поняли...

Для тренировки мозга попробовали сделать вот так:

function process($input, $k, array $prefix = array())
{
    $result = [];

    if ( $k === 1 )
    {
        foreach ($input as $item)
        {
            $result[] = array_merge($prefix, [$item]);
        }
    }
    else
    {
        $n = count($input);
        $m = $n - $k + 1;

        for ( $i = 1; $i <= $m; $i++ )
        {
            $subInput = array_slice($input, $i, $k);
            $subPrefix = array_merge($prefix, [$input[$i-1]]);
            $r = process($subInput, $k-1, $subPrefix);
            $result = array_merge($result, $r);
        }
    }

    return $result;
}


$input = [1, 2, 3, 4, 5];
$k = 3;
$result = process($input, $k);
var_export($result);

Кажется Вы не закрыли фигурной скобкой свою функцию drawTable.

echo "</tr>";
  }
  echo "</table>";
?>

Должно быть:

echo "</tr>";
  }
  echo "</table>";
}
?>

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

Я вижу два варианта:
Первое: Не показывать в роуте категорию.
Например, роут для категории: /store/category/{$category-id}
Роут для продукта: /store/product/{$product-id}
Вместо id Вы можете вставлять транслитерацию названия продукта или категории. Или и id, и транслитерацию

Второе: У каждого продукта должна быть главная связанная категория. Его и показывать в роуте. А другие категории будут просто дополнением внутри сайта и никак не отражаться в роуте

Приветствую! Мне в течение последнего года доводилось делать три похожих проекта документооборота. Хотелось бы поделиться со своим решением, как я организовал структуру таблиц (они же и сущности в доктрин).

Первое:
У моих проектов было несколько маршрутов согласования. Поэтому я хранил их отдельно. И называл их workflow (бизнес процесс)

Workflow: (Маршрут согласования)
    id
    name (Название маршрута согласования)
WorkflowPoint: (Точка согласования)
    id
    title (Название точки. Например "Согласование фин директора")
    workflow_id (Связанный маршрут)
    user_id (Пользователь, который рассматривает документ в этой точке согласования)
    order_id (Порядковый номер точки в маршруте)
    roles (Права пользователя, в данной точке согласования)

Второе:
В моих проектов в одном документе согласования могли храниться несколько файловых вложении. Поэтому Файл и Документ согласования хранились отдельно.

Approval: (Документ согласования)
    id
    title (Название документа)
    author_id (Инициатор)
    state = 0 (Состояние документа. 0 - черновик. 1 - в процессе согласования. 2 - одобрено. 3 - отказано. 4 - архивировано)
    workflow_id (Маршрут, по которому движется данный документ. По умолчанию null, кроме того, когда состояние документа в процессе согласования)
    workflow_point_id (Текущая точка согласования в маршруте. При одобрении, указывается следующая точка)
    approval_user_id (Пользователь, который должен рассмотреть документ в текущий момент. Это поле чисто для удобства в поиске)
Attachment: (Файл-вложение)
    id
    approval_id (Связанный документ)
    file_path (Путь к файлу)
    author_id (Пользователь, который вложил файл)

Я значительно упростил структуру, чтобы просто дать Вам идею для размышления. В реальных проектах было гораздо сложнее

В консоли после этой команды doctrine:generate:entities так же нужно ввести неймспейс, с которой вы работаете. Например:
doctrine:generate:entities App
или
doctrine:generate:entities AppBundle
или
doctrine:generate:entities App\Bundle.

1) На счет ассетов. Взгляните в сторону gulp.js или grunt.js
Они являются сборщиками проектов. Можно собирать css или js файлы в один файл, минимизировать их, работать с sass или less, оптимизировать изображения и много-много чего.

2) Вы можете написать свой сервис "RouteLoader", который добавляет новые роуты в приложение. А сам сервис подключаются автоматически вместе с бандлом.