Thanks for the comments. I'll summarize my thoughts here: 1. Integrating grapelli into Satchmo. I do like the look and extra features grapelli has. I am very leary of adding yet another dependency to Satchmo. There are some places where it's optional but some of the features do require modifying the admin.py file. I'm not sure if we should do this or not.
2. General API stabilization- documentation and improvements. I'm all for these. 3. General re-design of demo store- I appreciate any effort that folks can devote to this. There seem to be some offers of support so I hope we can coordinate efforts. If someone starts a fork on bitbucket, let's try to coordinate efforts. 4. Ajax updates - Another good idea. I'm receptive to it as long as it degrades gracefully and isn't required for core store functionality. 5. Translation model changes - Once again, I'm not opposed to this but would need to see the implementation details to understand how it could play out. 6. Pinax integration - This recipe here is in place - http://github.com/hbussell/pinax-satchmo-buildout I'm not sure what other "integration" people would like to see. I'm open to the idea and James and I have had very very brief discussions about this in the past but no concrete work yet. -Chris On Thu, Jun 3, 2010 at 7:01 AM, Brian O'Connor <[email protected]> wrote: > I agree with pretty much everything franck mentioned. While pre1.0, > backwards incompatible changes should be avoided when feasible, but it > shouldn't be the end all be all in the decision making process. > > I'd like to see a heavy push to optimize a lot of the SQL inside satchmo. > I know in certain areas the amount of queries are really, really high and > whatever can be done to cut down on that would be great. > > In addition, which I've thought a lot about and close to formalizing a > proposal is greater AJAX support. A few months ago I streamlined some of > the product add / update / delete ajax functions to be the same code as the > regular, with different output depending on the request type. I'd really > like to see that expanded into the other models as well, like Cart display, > product viewing, shipping calculation, etc. As you can see from my previous > posts, I feel strongly that satchmo as a eCommerce framework should provide > the ability for shop makers to calculate shipping and tax costs on the cart > display page via AJAX without making it themselves. It would be easy enough > for us to do once, and everyone else can either include it or remove it (a > perfect candidate for a templatetag, ie {% render_quick_shipping_form %}). > > I think some more formal API specifications need to be made for each > indvidual module - ie, we make it very clear we just call > get_lowest_shipping_cost(), get_shipping_options(), etc. This way if people > need to extend satchmo for their own needs in templatetags, views, etc, it > is very obvious what needs to be done. > > This might be a poor place for this question, but why are we passing > default_view_tax in pretty much every function I've looked at in the satchmo > core? Shouldn't that be made into a context processor, or just taken from > the config values when needed? Or just used in the product model when we > ask for its price? I'd liek to see that done so that future code > improvements can be done and optimizations without worrying about what that > really is. > > My last, but really not important request would be to factor all the > translation models out of the code. I have a loose idea of how to do this > in code, and will release that idea in a separate email to the dev list. I > know for my client, translations aren't on the agenda, and probably never > will be. For him, the translations area is cluttering up the already > confusing admin interface, and there's no way to easily disable that. > > Brian > > On Thu, Jun 3, 2010 at 5:32 AM, franck bret <[email protected]> wrote: > >> 2010/6/3 Chris Moffitt <[email protected]>: >> > Now that 0.9.1 is out the door, I wanted to outline my thoughts for the >> next >> > release. My purpose is to drive some discussion about what we should >> focus >> > on. >> > >> > 1. I would like to get the django csrf updates incorporated into Satchmo >> > trunk so it can use this improved feature. An initial fork has been >> started >> > here - https://bitbucket.org/dhmorgan/satchmo >> > >> > 2. Updates to the admin interface. I would really like to see some >> efforts >> > at making the admin interface a little more streamlined so that it isn't >> as >> > intimidating to a new user. I think some judicious use of jquery could >> > probably make some big steps. I'd also like to see some rudimentary >> > reporting so that the admin interface is more useful to store owner. >> I think a first and simple step is to integrate django-grapelli, wich >> is well designed, coded and eyes catchy. It gives some pretty inline >> admin and can remain optional. >> > >> > 3. Evaluating improvements to the product model to support improved >> product >> > model inheritance. There has been some good discussion here and I'd like >> to >> > see if we can make some of that a reality without massive >> > backwards-incompatible changes. >> Actually I think we need to make more simple and solid the main >> workflow/api when dealing with product. Separating what is really >> required for a product to exist (sku, pricing, title, qty, shipping >> rules), what is qualifying the product inheritance(abstract parent >> reference and variations) and what is needed for displaying a >> product(description, photos, attributes etc...). Well designing this >> part is the key for future elegant webservice api... Also I think >> backward incompatible changes will be unavoidable., but south >> migrations can help... >> The next part is to refactor products templates tags / context >> processors to ensure data processing and html rendering are really >> separated in a way we designers can only works on templates with a >> clear usage definition guide... >> > >> > 4. Figure out why caching-app-plugins does not work with the new caching >> > template loader. >> > >> > Other than those items, I'm sure we'll continue to focus on >> documentation, >> > bug fixes and translations. >> > >> > Some optional items: >> > - Bursar split. I'm still in favor of this but am not sure exactly how >> much >> > work is still needed there. >> Agree for that, payment and shipping must be separated to gain a whole >> of benefits with side projects... >> > - One of my pony requests is an improvement to the overall look and feel >> of >> > the default store. I like that there is minimal cruft that needs to be >> > removed from the default templates but I would prefer that Satchmo out >> of >> > the box looked more presentable to a customer and had some cleaner >> markup. >> > It would be cool if we could get some templates out there to jump start >> that >> > aspect of deploying Satchmo. >> Not sure, cause it's design and design is a subjective and value added >> job in this case... I really prefer to show in early customer meeting >> look what we can do with an exhaustive api/documentation and notes on >> workflow than a "look how does it's pretty"... A standard xhtml / css >> compliant clear and minimal design(white/grey/black + 1 blue color >> link) should do the job. I'll work on that when finding a few hours. >> > >> > Anyway, those are a few thoughts. I'm curious if anyone else has >> anything >> > major they would like to advocate for. Feel free to bring up here. >> A main context processor for cart and shipping in order to have >> contextual dict for displaying on all pages of the website what is the >> cart amount and simulate shipping based on logged or not >> information(get_lowest_shipping_cost). >> > >> > Thanks, >> > Chris >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Satchmo users" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]<satchmo-users%[email protected]> >> . >> > For more options, visit this group at >> > http://groups.google.com/group/satchmo-users?hl=en. >> > >> >> >> >> -- >> Franck Bret >> --------------------- >> 06 03 90 65 98 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Satchmo users" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<satchmo-users%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/satchmo-users?hl=en. >> >> > > > -- > Brian O'Connor > > -- > You received this message because you are subscribed to the Google Groups > "Satchmo users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<satchmo-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/satchmo-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Satchmo users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.
