Несколько простых вопросов для знающих
Ребят, всем привет, у меня такой вопрос:
1. За что отвечают экшены в папке /pages/ фронтенда приложения Shop?
2. Правильно ли я понимаю, например у сайта есть глобальная маршрутизация и там скажем выбралось какое то приложение(по глобальным настройкам роута).
то после этого, когда выполняется выбранное приложение, внутренняя обработка роутов будет производиться уже в wa-apps/[guestbook]/lib/config/app.php
т.е. именно от этого файла будет зависеть какие контроллеры и экшены будут вызываться?
3. Смотрел приложение "Blog", там по сути всё приложение состоит только из шаблонов, т.е. экшенов и контроллеров я там не увидел. Вопрос в том, это дефолтное поведение фреймворка и в каком то системном базовом классе он такие чудеса творит
или скорее всего где то подключаются отдельные классы, где находятся модели и контроллеры этого приложения, если да, то в каких?
Заранее Спасибо.
15 ответов
3. В папке lib достаточно action'ов не знаю как Вы смотрели
3. Смотрел вот как: есть папка
\wa-apps\blog\themes\vk
т.е. в каждой папке по одной папке и вней ещё папка т.е. такая матрешка и только в самой вложенной папке находятся шаблоны.
пс.
wa-apps\blog тут только одна папка themes т.е. lib и ничего подобного нет, я вот поэтому и хотел уточнить, что вероятно я что то пропустил раз это каким то чудом работает.
Вопрос: не знаю на сколько правильно или не правильно делаю. В продукт(shop_product) хочу затолкать сразу 3 цены(розница, постоянные и опт) и сделать правки с минимальными телодвижениями, чтобы везде шаблоны не править и в случае чего отделаться только добавлением 1-2 строк в контроллер. нашел класс
class shopProductModel extends waModel
По хорошему в нём надо переопределить метод getById(Id) т.к. в файле shopProduct.class.php:
public function __construct($data = array()) // $data - это и есть кеш данных из базы
if (is_array($data)) {
$this->data = $data;
} elseif ($data) {
$this->data = $this->model->getById($data);
}
Но,$data получается из кеша и я не могу отследить, где она изначально проставляется, в идеальном случае должен быть один из методов той же модели, на практике видимо что то иначе.
Я хоть и тыкаюсь в этом направлении, но в памяти ещё держу, что в таблице shop_product_skus могут быть указаны другие параметры и соответственно по 3 цены туда тоже вталкивать надо.
+ моя правка вероятно повлечет костыль, что надо каким то образом определять принадлежность посетителя к группе, что конечно правильнее делать в контроллере.
Заранее спасибо.
2. Как (и, главное, зачем?) вы планируете переопределять стандартные модели магазина с сохранением изменений при установке обновлений?
* А в чём состоит ваш вопрос?
2. Как (и, главное, зачем?) вы планируете переопределять стандартные модели магазина с сохранением изменений при установке обновлений?
* А в чём состоит ваш вопрос?
и попутно уточню вопрос:
class shopProductModel extends waModel
public function __construct($data = array()) // $data - это и есть кеш данных из базы
...
if (is_array($data)) {
$this->data = $data;
} elseif ($data) {
$this->data = $this->model->getById($data);
}
...
-------------
$data - это кеш данных, как понять откуда и где он получается и заполняется?
т.к. по всей видимости кеш получается в обход $this->model->getById($data)
-------------
В этом файле нет информации об обработке запросов.
Если приложению нужно формировать ЧПУ-адреса (во фронтенде) в произвольном формате, то формат таких адресов нужно задать в файле wa-apps/***/lib/config/routing.php. Но ВСЕ адреса, обрабатываемые вашим приложением во фронтенде, должны начинаться с того фрагмента, который был указан в разделе "Структура" приложения Сайт для вашего приложения.
Пример: допустим, вы создали для вашего приложения поселение с маской myapp/*
Это значит, что все запросы, URL, которых в самом начале содержат фрагмент myapp/ (после URL, по которому установлен фреймворк), будут обрабатываться вашим приложением.
Если вас устравают URL вида myapp/?module=some&action=other, то достаточно создать соответствующий модуль и экшен — без файла routing.php. Если такие "некрасивые" адреса во фронтенде вам не нужны и вы хотите вместо них использовать что-то вроде myapp/some/other/, то создавайте файл routing.php, в котором описывайте соответствие нужного вам формата контроллерам/модулям/экшенам вашего приложения.
Есть глобальный роутинг(который правится в админке) его читает
waSystem->dispatch()
затем в нём выбирается какое то приложение в зависимости от конфигов и после этого вызывается dispatch этого конкретного приложения.
waFrontController->dispatch()
waFrontController->execute()
метод dispatch именно в нём значит всё это и происходит.
далее судя по параметрам
$this->execute($plugin, $module, $action);
получается, что можно только один раз плагины подключать? Или это сделано как то чтобы их можно было жестко в ручную запускать?
потому что по доке:
wa()->event('[НАЗВАНИЕ_СОБЫТИЯ]', $params);
http://www.webasyst.ru/developers/docs/plugins/plugin-basics/
Если для плагина определены обработчики для нескольких хуков, то этот плагин обработает их все при получении запроса от пользователя (если при обработке такого запроса приложением задействуются хуки, к которым прикреплён этот плагин) — в том же порядке, в котором задействуются хуки (т. е. генерируются события, соответствующие хукам) в коде приложения. Или вы другое имеете в виду?
Если цены относятся только к артикулу(shop_product_skus), не проще ли бы сделать в системе повсеместно join товара и артикула при получении данных.
Я например сейчас ещё разбираюсь в движке и вижу такую ситуацию, например где списки товаров в одних случаях цена получается из артикула (где их несколько), в других случаях, где товар один ставится цена из товара и артикул игнорируется.
Сейчас например добрался до подтверждения заказа, там итог считается правильно, но в корзине 1 товар с разными артикулами, не увидел намёков на какие либо артикулы т.е. данные берутся из товара непосредственно.
конкретно в файле:
apps\shop\lib\classes\checkout\shopCheckoutConfirmation.class.php
после
$items = $cart->items(false);
идут два метода:
$order['discount'] = shopDiscounts::calculate($order);
и
$taxes = shopTaxes::apply($items, array('shipping' => $shipping_address['data'],
и в шаблон сразу выводится items->price
2. Вот кстати по поводу обновлений это отдельная головная боль.
Я изначально думал как то через git хранить свои правки и в случае чего переписывать поверх.
По идее эта программа должна помочь, но она сейчас слишком сложна для моего понимания.
Сейчас пока так делаю:
public function items($hierarchy = true)
{
$items = $this->model->getByCode($this->code, true, $hierarchy);
return MyFixes::ShopCartIems($items,$hierarchy); // фиксы
}
И будет отдельный отладочный сайт на котором будут проверяться обновления, после чего переноситься в рабочий вариант. Пока это единственный вариант, который вижу. Оказывается даже шаблоны обновляются :)))))
В openCart был интересный механизм с xml-ками т.е. составляется xml файл где только правки т.е. непосредственно в код вносить изменений не надо и после обновлений всё отлично работает.
В корзине заказываю:
товар_1 (артикул_1)
товар_1 (артикул_2)
при этом цена берется только из товар_1 (shop_product)
В то время как итоговая цена считается с учетом артикула, получается 1+2=4 :)
т.е. имеется ввиду что для упрощения есть товар с фиксированной ценой, либо некий мин/мах от артикула, которая показывается при выводе товара в общем списке.
т.е. не совсем понятно почему "compare_price" вынесли в отдельное поле, в то время как можно просто Price использовать.
И в артикулах тоже самое:
shop_product_skus.primary_price, -- сейчас смотрю, именно по ней итог в корзине считается т.е. цена спокойно может отличаться от shop_product_skus.price, так же в создании заказа, видимо так же для итогов.
shop_product_skus.purchase_price, -- в базе она вообще везде по нулям ставится.
shop_product_skus.compare_price,
Сейчас вот смотрю purchase_price: т.е. где то используется, но для чего так сделано не понятно, по идее же это будет вести к лишним ошибкам в расчетах
wa-apps\shop\lib\model\shopOrder.model.php (12 hits)
Line 616: SUM(IF(oi.purchase_price > 0, oi.purchase_price*o.rate, ps.purchase_price*".$this->escape($rate).")*oi.quantity) purchase
Line 665: SUM(IF(oi.purchase_price > 0, oi.purchase_price*o.rate, ps.purchase_price*pcur.rate)*oi.quantity) AS purchase
Line 791: $sql = "SELECT SUM(IF(oi.purchase_price > 0, oi.purchase_price*o.rate, ps.purchase_price*pcur.rate)*oi.quantity) AS purchase
Line 835: SUM(IF(oi.purchase_price > 0, oi.purchase_price*o.rate, ps.purchase_price*".$this->escape($rate).")*oi.quantity) purchase