CMS apphooks for cart and checkout

[rubengrill]

Currently the cart and checkout are implemented via rest ViewSets to handle the server side logic, angular directives on the client side to interact with it and cms plugins to render the cart/checkout forms in a cms page.

Personally, I don't want to use that strategy, because of two reasons:

• I prefer to have minimal effort to get a shop deployed. I don't like when I have to add multiple plugins to get a running cart (container -> row -> column -> cart, proceed button, ...). As I know the markup of my cart, I want to write that in my template exactly once, there should be no possibility for a customer to ever change that (maybe by accident, murphys law...) after the customer approved the design (changes are ok, but >I< want to do that.
• When using django shop, I want to focus on extending django code I am familiar with. In a recent project I always had the feeling that even a simple task could be a risk, because eventually I might also have to dig into angular code (or server side angular integration). While there are some places where angular (ajax in general) makes totally sense (e.g. badge and change cart), for validating/processing the cart/checkout (also login) I prefer having django views/forms there.

In a recent project I created an apphook for both the cart and the checkout, they are just FormViews rendering a template where the complete cart/checkout markup is rendered, without a single cms plugin.

With this issue I would like to start a discussion, if django shop should also provide apphooks as an alternative to plugins with angular integration.

Maybe that would not even be too much effort by having apphooks using the existing ViewSets. The ViewSets could be extended to also support rendering templates.

[rfleschenberg]

IMHO we should move the Angular parts out of django-shop into a separate package. Some developers like Angular, some hate it. I'd prefer to be agnostic in regard to frontend frameworks, so that people can use Angular, jQuery, react, something else, or even no client-side scripting at all.

That doesn't mean that we would maintain all of these solutions, of course. We would likely maintain only one default solution (which might happen to be Angular), but as a separate package to ensure that the dependency doesn't leak into the main django-shop package.

The problem with all of this of course is that somebody has to do it, while providing a good upgrade path for existing deployments :) But yes, I am definitely interested in seeing those apphooks!

In the long run, I would even be interested in having a django-shop package without the dependency on django-cms. While most shops want a CMS, some shops don't. And some shops may want Mezzanine, Wagtail or whatever. But that is probably a topic for another issue.

[jrief]

I fully agree with @rfleschenberg . The reason AngularJS is tight into django-SHOP is mainly, automatic client-side form validation.

Therefore, one might run django-SHOP even without django-CMS and hence without Cascade. I tried to use loose coupling, and that's also the reason why I keep dependencies in separate packages, even if I am the author of them: djangocms-cascade, django-angular, angular-bootstrap-plus (pure Javascript), djangocms-bootstrap3 and django-sass-processor. Authors of other frameworks tend to put everything together, making them very opinionated towards a certain technology stack. This is something I really want to avoid.

However, my main focus was on features, flexibility and extensibility. Therefore I did not invest a lot of time in trying how to run django-SHOP without, say AngularJS or django-CMS or Cascade plugins, even if with some effort, this should be possible.

If someone wants to run django-SHOP without CMS, one major external library would be a flexible category system. If possible, this should use the deferred model framework.

@rubengrill could you please send me your e-main address?