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].
For more options, visit this group at
http://groups.google.com/group/satchmo-users?hl=en.
