Несколько простых вопросов для знающих

Ребят, всем привет, у меня такой вопрос:



1. За что отвечают экшены в папке /pages/ фронтенда приложения Shop?



2. Правильно ли я понимаю, например у сайта есть глобальная маршрутизация и там скажем выбралось какое то приложение(по глобальным настройкам роута).

то после этого, когда выполняется выбранное приложение, внутренняя обработка роутов будет производиться уже в wa-apps/[guestbook]/lib/config/app.php

т.е. именно от этого файла будет зависеть какие контроллеры и экшены будут вызываться?



3. Смотрел приложение "Blog", там по сути всё приложение состоит только из шаблонов, т.е. экшенов и контроллеров я там не увидел. Вопрос в том, это дефолтное поведение фреймворка и в каком то системном базовом классе он такие чудеса творит

или скорее всего где то подключаются отдельные классы, где находятся модели и контроллеры этого приложения, если да, то в каких?



Заранее Спасибо.

3 ответа

  • 1
    Михаил Ушенин Webasyst 23 января 2014 02:50 #
    > внутренняя обработка роутов будет производиться уже в wa-apps/[guestbook]/lib/config/app.php
    В этом файле нет информации об обработке запросов.
    Если приложению нужно формировать ЧПУ-адреса (во фронтенде) в произвольном формате, то формат таких адресов нужно задать в файле wa-apps/***/lib/config/routing.php. Но ВСЕ адреса, обрабатываемые вашим приложением во фронтенде, должны начинаться с того фрагмента, который был указан в разделе "Структура" приложения Сайт для вашего приложения.

    Пример: допустим, вы создали для вашего приложения поселение с маской myapp/*
    Это значит, что все запросы, URL, которых в самом начале содержат фрагмент myapp/ (после URL, по которому установлен фреймворк), будут обрабатываться вашим приложением.

    Если вас устравают URL вида myapp/?module=some&action=other, то достаточно создать соответствующий модуль и экшен — без файла routing.php. Если такие "некрасивые" адреса во фронтенде вам не нужны и вы хотите вместо них использовать что-то вроде myapp/some/other/, то создавайте файл routing.php, в котором описывайте соответствие нужного вам формата контроллерам/модулям/экшенам вашего приложения.
    • 0
      Сергей Сергей 23 января 2014 11:48 #
      Всё мега спасибо, т.е. в итоге получается так:

      Есть глобальный роутинг(который правится в админке) его читает
      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/
      • +1
        Михаил Ушенин Михаил Ушенин Webasyst 24 января 2014 04:05 #
        > получается, что можно только один раз плагины подключать?

        Если для плагина определены обработчики для нескольких хуков, то этот плагин обработает их все при получении запроса от пользователя (если при обработке такого запроса приложением задействуются хуки, к которым прикреплён этот плагин) — в том же порядке, в котором задействуются хуки (т. е. генерируются события, соответствующие хукам) в коде приложения. Или вы другое имеете в виду?
  • 0
    Сергей Варенов 23 января 2014 02:34 #
    1. Я так понимаю за создание страниц товаров(ну и прочие действия с ними), наследует action'ы класса "waPageActions"
    3. В папке lib достаточно action'ов не знаю как Вы смотрели
    • 0
      Сергей Сергей 23 января 2014 11:27 #
      1. Имеется ввиду карточка товара с фотками и ценами и прочей ерундой?
      3. Смотрел вот как: есть папка
      \wa-apps\blog\themes\vk
      т.е. в каждой папке по одной папке и вней ещё папка т.е. такая матрешка и только в самой вложенной папке находятся шаблоны.
      пс.
      wa-apps\blog тут только одна папка themes т.е. lib и ничего подобного нет, я вот поэтому и хотел уточнить, что вероятно я что то пропустил раз это каким то чудом работает.
      • +1
        Михаил Ушенин Михаил Ушенин Webasyst 24 января 2014 05:00 #
        Видимо, вы что-то пропустили... Проверьте тут содержимое директорий: https://github.com/webasyst/webasyst-framework
        • 0
          Сергей Сергей 27 января 2014 14:47 #
          Михаил, обращаюсь к вам, как к эксперту:
          Вопрос: не знаю на сколько правильно или не правильно делаю. В продукт(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 цены туда тоже вталкивать надо.

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

          Заранее спасибо.
          • 0
            Михаил Ушенин Михаил Ушенин Webasyst 30 января 2014 01:34 #
            1. Цена должна относиться к артикулу, а не к товару, потому что в магазине продаются именно артикулы, а товар — это лишь представление артикулов на витрине (даже если у товара всего один артикул). Как вывод отсуда: товаров без артикулов в Shop-Script 5 не бывает (по крайней мере, не должно быть).

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

            * А в чём состоит ваш вопрос?
          • +1
            Михаил Ушенин Михаил Ушенин Webasyst 30 января 2014 01:35 #
            1. Цена должна относиться к артикулу, а не к товару, потому что в магазине продаются именно артикулы, а товар — это лишь представление артикулов на витрине (даже если у товара всего один артикул). Как вывод отсюда: товаров без артикулов в Shop-Script 5 не бывает (по крайней мере, не должно быть).

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

            * А в чём состоит ваш вопрос?
            • 0
              Сергей Сергей 1 февраля 2014 06:57 #
              Немного промахнулся, чуть ниже ответ отписал.

              и попутно уточню вопрос:

              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)
              -------------
  • 0
    Сергей 1 февраля 2014 06:53 #
    1. Ок, огромное спасибо за ответ, кстати в связи с этим - вы разработчик веб-асиста?
    Если цены относятся только к артикулу(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 файл где только правки т.е. непосредственно в код вносить изменений не надо и после обновлений всё отлично работает.
    • 0
      Сергей Сергей 1 февраля 2014 07:02 #
      с товаром уточню:
      В корзине заказываю:
      товар_1 (артикул_1)
      товар_1 (артикул_2)

      при этом цена берется только из товар_1 (shop_product)
      В то время как итоговая цена считается с учетом артикула, получается 1+2=4 :)
    • 0
      Сергей Сергей 1 февраля 2014 07:15 #
      ПС. в этом случае (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
    • 0
      Сергей Сергей 1 февраля 2014 11:14 #
      с primary_price видимо разобрался - это цена в иностранной валюте, из которой идёт пересчет?

Добавить ответ

Чтобы добавить комментарий, зарегистрируйтесь или войдите