Skip to content
This repository has been archived by the owner on Nov 30, 2017. It is now read-only.

Implementation of PromotionBundle is unclear #276

Open
rvanlaak opened this issue Apr 16, 2015 · 5 comments
Open

Implementation of PromotionBundle is unclear #276

rvanlaak opened this issue Apr 16, 2015 · 5 comments

Comments

@rvanlaak
Copy link

While implementing the PromotionBundle separately we encounter a couple of problems of which it is unclear how to solve them

  • The PromotionType.actions field does result in an error about the fixed_discount service being missing. Uncommenting the actions field does allow the form to render. Do I first need to implement some actions myself before the form will render? Do we need to override the base Actions in the config?
  • How can we (re)use UX of how Rule and Action collections work the PromotionType? The resource bundle has form-collection.js and the promotion bundle has sylius-promotion.js but that does not seems to work. Should an extra data attribute be added to the type?
->add('rules', 'sylius_promotion_rule_collection', array(
        'label' => 'sylius.form.promotion.rules',
        'button_add_label' => 'sylius.promotion.add_rule',
        'attr' => array(
              'data-form-type' => 'collection',
         )
    ))
@rvanlaak
Copy link
Author

For now I've removed the rules and actions fields of the PromotionType by overriding the form.

// ...
class PromotionType extends BasePromotionType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        parent::buildForm($builder, $options);
        $builder->remove('rules');
        $builder->remove('actions');
        }
// ...

So, probably we will make separate actions for that. Is this the best solution? What approach is best to follow?

@rvanlaak
Copy link
Author

Did found quite some nifty features, like the Twig configuration() macro, and other view-related functions are located in the WebBundle. We understand that the backend-agnostic Twig templates are located in such bundle.

It would be great if macros and Extensions that don't rely on the backend could be moved to the PromotionBundle, now we have to copy all those to our own application 👍

@rvanlaak
Copy link
Author

It seems to me that the section about coupons only is related to the backend scenarios for generating coupons. http://docs.sylius.org/en/latest/bundles/SyliusPromotionBundle/coupon_based.html

What about a section about the services to use when checking the validity in the frontend sales process? Did dig through all services, but can't find the one to easily check all promotions in my own shopping cart.

Maybe some extra details about the PromotionCouponAwareSubjectInterface at the models chapter would also help.

Sylius-standard makes use of the AdjustableInterface, but given it is not included in the PromotionBundle a short note about the way to go otherwise would be nice. Maybe an extra dry-run for PromotionProcessor->process() could solve this.

@rvanlaak
Copy link
Author

We're using Annotations in our project. When we try to override the Promotion model by extending the base model, and add the Resources/doctrine/Promotion.orm.xml file all other entities also seem to be read using XML.

How can people that use Annotations extend the models? We only want to add the many-to-many fields to the model so we can show the Orders associated with the Promotion or Coupon in our backend.

http://docs.sylius.org/en/latest/bundles/general/overriding_models.html

@rvanlaak
Copy link
Author

ping @Arn0d

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant