Попробуйте это
Controller
public function showPackageItems($id)
{
$package = Package::find($id)
->with('packageItems')
->where('id', $id)
->first();
return view('admin.packages.show', compact('package'));
}
Blade file
{{ $package->id }} //you can access package instance like that.
//for packageItems
@foreach($package->packageItems as $p)
<td>{{ $p->item_id }}</td>
<td>{{ $p->qty }}</td>
@endforeach
Откровенно говоря, это действительно зависит от Вашей базы пользователей. Существуют тонны приложений PHP, которые автоматически не обновляют себя. Их пользователи являются или достаточно техническими для обработки процесса обновления или просто не обновляют.
Я имею целью два шага:
1) Серьезно спросите себя, в чем, вероятно, будут действительно нуждаться Ваши пользователи. Самообновление обеспечит действительно повышение принятия для выравнивания по ширине дополнительной работы? Если Вы уверены, что ответ да, просто сделайте это.
Так как Вы спрашиваете здесь, я предположил бы, что Вы еще не знаете. В этом случае я имею целью шаг 2:
2) Версия выпуска 1.0 без функции. Ожидайте отзывов пользователей. Ваши пользователи могут сразу кричать для более простого процесса обновления, в этом случае необходимо расположить по приоритетам его. Поочередно, можно найти, что пользователи намного более обеспокоены некоторой другой функцией.
Предположение, что Ваши пользователи хотят, не спрашивая их, является хорошим способом потратить впустую много времени разработки на вещах, в которых на самом деле не нуждаются люди.
Я думал об этом в последнее время в отношении изменений схемы базы данных. В данный момент я рою в WordPress, чтобы видеть, как они обработали изменения базы данных между изменениями. Вот то, что я нашел до сих пор:
$wp_db_version
загружается из wp-includes/version.php
. Эта переменная соответствует числу пересмотра Подверсии и обновляется когда wp-admin/includes/schema.php
изменяется. (Возможно через рычаг? Я не уверен.), Когда wp-admin/admin.php
загружается, названная опция WordPress db_version
читается из базы данных. Если это количество не равно $wp_db_version
, wp-admin/upgrade.php
загружается.
wp-admin/includes/upgrade.php
включает вызванную функцию dbDelta()
. dbDelta()
сканирования $wp_queries
(строка SQL-запросов, которые создадут новую схему базы данных с нуля), и сравнивает его со схемой в базе данных, изменяя таблицы по мере необходимости так, чтобы схема была принесена актуальный.
upgrade.php
затем выполняет вызванную функцию upgrade_all()
который работает конкретный upgrade_NNN()
функции, если $wp_db_version
меньше, чем целевые значения. (т.е. upgrade_250()
, WordPress 2.5.0 обновлений, будет выполнен, если версия базы данных будет меньше чем 7 499.) Каждая из этих функций выполняет их собственную миграцию данных и процедуры населения, некоторые из которых называют во время первоначального сценария установки базы данных. Хорошо сокращает дублирующий код.
Так, это - один способ сделать это.
Я предполагаю, что Вы уже исключили это, но Вы могли разместить его как услуга. (Думайте wordpress.com),
Я предложил бы, чтобы Вы упаковали свое приложение с грушей и настроили канал. Ваши пользователи могут затем обновить приложение через стандартный интерфейс (груша). Это не совсем автоматически (если у пользователей нет некоторой автоматизации, работающей сверху груши), но это стандартно, таким образом, любой системный администратор может поддержать его.
Просто мои 2 цента: я рассмотрел бы автоматически сам обновление приложения в моем CMS как дыра в системе безопасности, поэтому если Вы решаете кодировать эту функцию, необходимо рассмотреть для реализации разных уровней этого поведения:
Я думаю, что Вашим наилучшим вариантом является механизм проверки обновления, который предупредит администратора, когда будет обновление (обновления).
Как Вы упоминаете, существует много возможных проблем защиты. Из-за одних, я предложил бы не делать этого. Вместо этого попытайтесь создать довольно умный сценарий обновления.