On Dec 15, 2006, at 12:21 PM, Ean Schuessler wrote:
On Friday 15 December 2006 09:32, Tim Ruppert wrote:
And btw, the old cart, used JavaScript all the time. Why is this
just coming up now? Why don't we figure out a parallel solution for
other people who want to turn of JavaScript - instead of holding
everyone back?
I tend to agree with you here. Trying to get parity on
Javascript/Non-javascript interface implementations is going to get
very,
very daunting as the libraries keep getting more and more
sophisticated.
Eventually, trying to write a server side widget component that
matches what
you can do in the browser is going to be a ridiculous joke.
Still, its nice to have a simple interface that demonstrates how to
handle
situations like a cell phone interface. Maybe what we need is a next
generation shopping application. In my opinion the one that rolls
out with
OFBiz borders on being unusable for a customer deployment without
extensive
modification.
BTW, I'm replying to Ean's message because it is the latest in this
thread, not necessarily because of anything said here, and these
thoughts are also based on previous messages not completely
represented here...
What Ean is mentioning here is the real problem. The ecommerce
component has seen a pretty anemic level of contributions over the
years and in recent history as well. There are really lots of
problems in the current stuff that have been there for years and have
never been fixed.
Some ideas like a sandbox that is somehow maintained and yet never
considered by anyone as a "supported" part of OFBiz and having lots
of parallel code and such are interesting, but require a level of
resources that I would shocked near to death to see. Realistically it
just hasn't happened before, ever.
In general the ecommerce webapp is meant to be a good starting point
and contributions should be meant to make it a better starting point.
If someone wants to use ecommerce OOTB then that should be possible,
but if there is a decision between making it easier to customize for
what people want to do, and easier to use OOTB, the first one wins
(easier to customize).
So, in my opinion this checkout stuff should go in somehow. I haven't
reviewed it but in its current state it may not be a good generic
replacement for the current anonymous, quick, or multi-step checkout
processes as many sites will want to use something more similar to
one of those. However, it is a nice example of an alternative and can
go in along with others. This is yet another example of something
that is a little ugly OOTB, but easy to remove and that makes it
easier to customize it to the "ultimate" checkout process according
to whatever your current client is imagining.
I have no problem with effort going into making things downgrade
elegantly to not require JS and other stuff, but so far I've seen
approximately 0 resources invested in action in that, and nothing
happens in OFBiz through discussion: it happens through action.
-David
