satchmo a la carte

[Leonig Mig]

I want an ecommerce framework I can pick and choose from- is this
approach possible with Satchmo.

Or am I required to instantiate some monolithic knot of code and drink
the kool aid?

I am evaluating satchmo atm so would value any viewpoints.

[Chris Moffitt]

I don't think I'd call Satchmo a "monolothic knot of code" and I definitely don't want people drinking Kool-aid :) but I'm not sure that Satchmo allows you to just pick and choose just the parts you need.

There are some places where you can simply disable an app and not use it and there's no problem. There are also places where you can easily customize your own pieces - like shipping and payment modules. We also try to make it easy to override parts of the template, hook into signals or replace views with your custom views. However, there are other places where the integration may be a bit tighter than you would like - especially when it comes to the product models. We try to loosely couple but it's not that easy for you to plug your custom product model in instead of Satchmo's.

If you can give some more details about what you'd like to pick and choose, we might be able to help you figure out how easy or hard it might be.

-Chris

--

You received this message because you are subscribed to the Google Groups "Satchmo users" group.
To post to this group, send email to satchm...@googlegroups.com.
To unsubscribe from this group, send email to satchmo-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.

[Leonig Mig]

Thanks for your thoughful reply. I've succeeded in installing Satchmo
into my project now and I see what you mean. I like the design you
have chosen - the idea is not to "extend" the core functionality but
embed it as a service and then use the funcationality provided.

I can see the real way to add new and custom functionality would be
via the "signals" mechanism rather than overriding some class or
hacking the underlying code. That's a good decoupled design, I'm
encouraged to continue evaluating satchmo as I think it could be a
nice fit for what I want to do.

My main concern is disabling features I do not need. Three concrete
examples:

1. Subscription stuff.
2. Discount codes.
3. Multisite - I will never need multisite.

Is the core stuff sufficiently abstracted from these "non core feature
bundles" I can just yank them out? And still be able to update to a
newer version of Satchmo with minimal work? Or do I need to just
accept the underlying models will alway reflect them and comment them
out in templates and by manipulating the admin screen? If it is the
latter is there a plan to refactor some of this stuff out into
optional modules?

Many thanks, Jim.

> > satchmo-user...@googlegroups.com<satchmo-users%2Bunsubscribe@goog legroups.com>

[Bruce Kroeze]

On Wed, Dec 23, 2009 at 4:52 AM, Leonig Mig <j.gu...@gmail.com> wrote:

I can see the real way to add new and custom functionality would be
via the "signals" mechanism rather than overriding some class or
hacking the underlying code. That's a good decoupled design, I'm
encouraged to continue evaluating satchmo as I think it could be a
nice fit for what I want to do.

Yes, most of the time you can do everything via signals.  We strongly discourage forking the core Satchmo files via hacks, as it makes upgrading an iffy and difficult proposition.

 

My main concern is disabling features I do not need. Three concrete
examples:

1. Subscription stuff.
2. Discount codes.
3. Multisite - I will never need multisite.

The subscription stuff is disabled by not having the satchmo_ext.newsletter module activated.  All the existing templates work automatically with it removed.

Discount codes.  They are part of the core Product models, but if you want to disable them, just don't refer to them in your templates.  If you don't even want them in your admin, then in one of your admin.py files, do this:

from product.models import Discount

admin.site.unregister(Discount) 

 

Multisite.  Can't really be removed, since "site" is a field on very many core modules.  However, we'd accept a patch similar to what we did to remove translations from the admin screens on single-language sites.  It wasn't that tricky, and it makes the admin interface nicer for people who don't need it.  Basically, flip a setting, and your admin gets simpler.

--
Bruce Kroeze
http://www.ecomsmith.com
It's time to hammer your site into shape.

[Leonig Mig]

> Multisite.  Can't really be removed, since "site" is a field on very many
> core modules.  However, we'd accept a patch similar to what we did to remove
> translations from the admin screens on single-language sites.  It wasn't
> that tricky, and it makes the admin interface nicer for people who don't
> need it.  Basically, flip a setting, and your admin gets simpler.

This sounds interesting, I would have a crack at implementing it, may
help me get my head round the codebase too. Can you link to some
details on the patch which removed translations from single language
sites? Or any other documentation which might assist. My goal would be
to have the site field missing from any admin screen - on the basis
there is only one site.

Thanks, Jim.

[Leonig Mig]

Other things I would like to remove / see made pluggable:

1. The cache framework.
2. Livesettings.
3. Much of the non-core product object model.

In the forthcoming "sprint", or generally, on an architectural basis -
would any thought been given to boiling Satchmo down to a universal
core? And hiving / abstracting everything out to "modules"?

[Jim Robert]

I think the direction you're going is pretty good and safe, but I would strongly advise against tearing out the cache framework.

You're only sacrificing performance with little to gain. Not to mention you'll likely need it for the payment processing anyway.

Regarding livesettings, I'm pretty sure that is not difficult to remove from your site

Jim

--

You received this message because you are subscribed to the Google Groups "Satchmo users" group.
To post to this group, send email to satchm...@googlegroups.com.

To unsubscribe from this group, send email to satchmo-user...@googlegroups.com.

[Bruce Kroeze]

On Tue, Dec 29, 2009 at 1:45 AM, Leonig Mig <j.gu...@gmail.com> wrote:

Other things I would like to remove / see made pluggable:

1. The cache framework.

Immense work to little gain, IMHO.  It is a tiny layer on top of the Django cache.

 

2. Livesettings.

Actually, not that hard. However, it would have to be pluggable.  Also, we are most definitely not interested in removing the "config.py" convention.  I did most of the work needed to support this when I added the support for livesettings configuration via settings.py.

 

3. Much of the non-core product object model.

Agreed.