json + prototype + ajax?
Locked
123
123
 
|
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? My 2cents On Dec 15, 2006, at 8:27 AM, Tim Ruppert wrote: > Chris, JavaScript is ingrained in just about anything that submits > forms anymore. I could understand saying something like this about > Flash - however my mind is changing on that as well - but saying > that you have to be able to manage something as complicated as the > feature set that OFBiz employs without JavaScript is almost like > saying - not everyone is off of Netscape 4.x and we need to set the > bar _that_ low for our CSS/HTML standardization. > > My vote for this is to move forward, not hang back. JavaScript, as > much as I'm not a huge fan, is a reality in todays world - and the > use of of DOES NOT make the code bug filled. > > Cheers, > Tim > -- > Tim Ruppert > HotWax Media > http://www.hotwaxmedia.com > > o:801.649.6594 > f:801.649.6594 > > > On Dec 15, 2006, at 8:07 AM, Chris Howe wrote: > >> Tim, >> >> To your post >> http://issues.apache.org/jira/browse/OFBIZ-510#action_12458496 >> >> I would want to see it degrade. The fact that SVN >> OFBiz does not degrade should not be support to >> introduce more code that follows a poor pattern. The >> current state of OFBiz not being able to add to cart >> when JS is turned off needs to be reported as a bug >> and fixed. >> >> Wanting to see this degrade should especially be true >> for a functionality of "Anonymous" checkout. This >> means you're wanting to sell product to random people. >> So, if you're wanting to sell to random people, you >> would want to lower the barriers as far as possible >> for them to use your site. Good web surfing practice >> is to white list JS for sites that you trust. This is >> especially true in corporate environments. >> >> So to summarize, my two cents would be to report the >> add to cart bug to JIRA, fix OFBiz's SVN of this >> pattern and degrade the JS in the anonymous checkout >> patch. But to quickly see this kind of functionality >> into OFBiz, I would prefer to see it added to a >> sandbox so that others could help work out these >> peculiarities. >> >> >> --- Tim Ruppert <[hidden email]> wrote: >> >>> I would certainly love to see the highly useful >>> Anonymous Checkout >>> Process example used in OFBiz - at least until >>> someone else comes up >>> with a good reason to remove Dojo and go to a >>> different front end >>> framewok. Does anyone have any real objections to >>> doing this in >>> light of the fact that no one has another example >>> _and_ that the >>> checkout process is unnecessarily tedious? >>> >>> Cheers, >>> Tim >>> -- >>> Tim Ruppert >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> o:801.649.6594 >>> f:801.649.6594 >>> >>> >>> On Dec 15, 2006, at 12:07 AM, Jacopo Cappellato >>> wrote: >>> >>>> Here are my two cents about this interesting >>> thread: >>>> >>>> 1) the Ajax toolkit's license must be fully >>> compatible with the >>>> OFBiz license >>>> 2) even if it's a good thing to try to find one >>> official Ajax >>>> toolkit for OFBiz now and finally get this ball >>> running, I think we >>>> should do this but also review the decision (and >>> the results we'll >>>> get with the adopted framework) in 2-4 months from >>> now and possibly >>>> return on it; I mean that we should keep an >>> open-minded approach >>>> and also consider new solutions (or criticism to >>> the adopted >>>> toolkit) since I think that in the Ajax world the >>> effects of the >>>> 'software darwinism' >>> (http://www.apache.org/foundation/ >>>> glossary.html#SoftwareDarwinism) still are not >>> mature >>>> >>>> Jacopo >>>> >>>> A. Zeneski wrote: >>>>> I'll let this thread run a little while longer >>> before we say to >>>>> have a >>>>> full official vote. As of right now, it appears >>> most people are >>>>> looking >>>>> at Dojo, and that is fine with me. >>>>> It seems that most of these toolkits do the same >>> thing, so to me its >>>>> just a matter of making a decision so I can push >>> forward with my >>>>> work. >>>>> As for being more active on the lists, sorry I >>> have been MIA for so >>>>> long. I've been involved in a lot of custom (non >>> open source) work >>>>> as of >>>>> late and apologize for not being around. I will >>> do my best to be >>>>> here as >>>>> much as possible. Thanks! >>>>> Andrew >>> >>> > |
Re: json + prototype + ajax?
|
|
Interesting read to develop ajax based application components using Dojo +
JSON. http://today.java.net/pub/a/today/2006/04/27/building-ajax-with-dojo-and-json.html On 12/15/06, Tim Ruppert <[hidden email]> 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? > > My 2cents > > > -- Regards Ashish Vijaywargiya Aditisoft Technology Laboratory |
Administrator
|
In reply to this post by Tim Ruppert
In theory I should agree with Chris, in practise I agree with Tim !
Indeed there are much more places where JS is used than cart, isn'it ? On the other hand we should be aware that using JS everywhere and often should not be a best practice to adopt (OK it's already done :( Perhaps using it *only* thru an Ajax Framework maybe a solution in future ? Jacques ----- Original Message ----- From: "Tim Ruppert" <[hidden email]> To: <[hidden email]> Sent: Friday, December 15, 2006 4:32 PM Subject: Re: json + prototype + ajax? > 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? > > My 2cents > > On Dec 15, 2006, at 8:27 AM, Tim Ruppert wrote: > > > Chris, JavaScript is ingrained in just about anything that submits > > forms anymore. I could understand saying something like this about > > Flash - however my mind is changing on that as well - but saying > > that you have to be able to manage something as complicated as the > > feature set that OFBiz employs without JavaScript is almost like > > saying - not everyone is off of Netscape 4.x and we need to set the > > bar _that_ low for our CSS/HTML standardization. > > > > My vote for this is to move forward, not hang back. JavaScript, as > > much as I'm not a huge fan, is a reality in todays world - and the > > use of of DOES NOT make the code bug filled. > > > > Cheers, > > Tim > > -- > > Tim Ruppert > > HotWax Media > > http://www.hotwaxmedia.com > > > > o:801.649.6594 > > f:801.649.6594 > > > > > > On Dec 15, 2006, at 8:07 AM, Chris Howe wrote: > > > >> Tim, > >> > >> To your post > >> http://issues.apache.org/jira/browse/OFBIZ-510#action_12458496 > >> > >> I would want to see it degrade. The fact that SVN > >> OFBiz does not degrade should not be support to > >> introduce more code that follows a poor pattern. The > >> current state of OFBiz not being able to add to cart > >> when JS is turned off needs to be reported as a bug > >> and fixed. > >> > >> Wanting to see this degrade should especially be true > >> for a functionality of "Anonymous" checkout. This > >> means you're wanting to sell product to random people. > >> So, if you're wanting to sell to random people, you > >> would want to lower the barriers as far as possible > >> for them to use your site. Good web surfing practice > >> is to white list JS for sites that you trust. This is > >> especially true in corporate environments. > >> > >> So to summarize, my two cents would be to report the > >> add to cart bug to JIRA, fix OFBiz's SVN of this > >> pattern and degrade the JS in the anonymous checkout > >> patch. But to quickly see this kind of functionality > >> into OFBiz, I would prefer to see it added to a > >> sandbox so that others could help work out these > >> peculiarities. > >> > >> > >> --- Tim Ruppert <[hidden email]> wrote: > >> > >>> I would certainly love to see the highly useful > >>> Anonymous Checkout > >>> Process example used in OFBiz - at least until > >>> someone else comes up > >>> with a good reason to remove Dojo and go to a > >>> different front end > >>> framewok. Does anyone have any real objections to > >>> doing this in > >>> light of the fact that no one has another example > >>> _and_ that the > >>> checkout process is unnecessarily tedious? > >>> > >>> Cheers, > >>> Tim > >>> -- > >>> Tim Ruppert > >>> HotWax Media > >>> http://www.hotwaxmedia.com > >>> > >>> o:801.649.6594 > >>> f:801.649.6594 > >>> > >>> > >>> On Dec 15, 2006, at 12:07 AM, Jacopo Cappellato > >>> wrote: > >>> > >>>> Here are my two cents about this interesting > >>> thread: > >>>> > >>>> 1) the Ajax toolkit's license must be fully > >>> compatible with the > >>>> OFBiz license > >>>> 2) even if it's a good thing to try to find one > >>> official Ajax > >>>> toolkit for OFBiz now and finally get this ball > >>> running, I think we > >>>> should do this but also review the decision (and > >>> the results we'll > >>>> get with the adopted framework) in 2-4 months from > >>> now and possibly > >>>> return on it; I mean that we should keep an > >>> open-minded approach > >>>> and also consider new solutions (or criticism to > >>> the adopted > >>>> toolkit) since I think that in the Ajax world the > >>> effects of the > >>>> 'software darwinism' > >>> (http://www.apache.org/foundation/ > >>>> glossary.html#SoftwareDarwinism) still are not > >>> mature > >>>> > >>>> Jacopo > >>>> > >>>> A. Zeneski wrote: > >>>>> I'll let this thread run a little while longer > >>> before we say to > >>>>> have a > >>>>> full official vote. As of right now, it appears > >>> most people are > >>>>> looking > >>>>> at Dojo, and that is fine with me. > >>>>> It seems that most of these toolkits do the same > >>> thing, so to me its > >>>>> just a matter of making a decision so I can push > >>> forward with my > >>>>> work. > >>>>> As for being more active on the lists, sorry I > >>> have been MIA for so > >>>>> long. I've been involved in a lot of custom (non > >>> open source) work > >>>>> as of > >>>>> late and apologize for not being around. I will > >>> do my best to be > >>>>> here as > >>>>> much as possible. Thanks! > >>>>> Andrew > >>> > >>> > > > > |
|
|
In reply to this post by Tim Ruppert
Tim,
Please don't construe my concerns as personal criticisms. I very much want to see your ajax contribution available in the code base, thus my suggestion of the sandbox. Using a sandbox alongside the approach in FAQ 21 on the old wiki allows the core business application to remain stable (and improve stability where needed) and allow those who wish to benefit from the added functionality. The NoScript firefox extension is the 5th most popular extension for Firefox. Having websites that work with Javascript turned off is not an approach to appease Luddites. I think this is a fairly normal demand throughout the ecommerce world or else you would see many more sites using Echo2 style frameworks (Echo2 is simply beautiful, hugely functional and easy to relatively easy to develop with and would be even more so with a widget esque style approach, however it renders only an html and body tag, no other html). You don't see Echo2 style sites in abundance because most companies want to be able to reach an audience regardless of their Javascript security preference. This is just coming up now because it would seem no one in the community develops with JS turned off. The same answer applies when you consider that only recently pages in ecommerce have been fixed to render correctly in IE. Just because it's just now being discovered, does not mean we should ignore it. --- Tim Ruppert <[hidden email]> 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? > > My 2cents > > On Dec 15, 2006, at 8:27 AM, Tim Ruppert wrote: > > > Chris, JavaScript is ingrained in just about > anything that submits > > forms anymore. I could understand saying > something like this about > > Flash - however my mind is changing on that as > well - but saying > > that you have to be able to manage something as > complicated as the > > feature set that OFBiz employs without JavaScript > is almost like > > saying - not everyone is off of Netscape 4.x and > we need to set the > > bar _that_ low for our CSS/HTML standardization. > > > > My vote for this is to move forward, not hang > back. JavaScript, as > > much as I'm not a huge fan, is a reality in todays > world - and the > > use of of DOES NOT make the code bug filled. > > > > Cheers, > > Tim > > -- > > Tim Ruppert > > HotWax Media > > http://www.hotwaxmedia.com > > > > o:801.649.6594 > > f:801.649.6594 > > > > > > On Dec 15, 2006, at 8:07 AM, Chris Howe wrote: > > > >> Tim, > >> > >> To your post > >> > > >> > >> I would want to see it degrade. The fact that > SVN > >> OFBiz does not degrade should not be support to > >> introduce more code that follows a poor pattern. > The > >> current state of OFBiz not being able to add to > cart > >> when JS is turned off needs to be reported as a > bug > >> and fixed. > >> > >> Wanting to see this degrade should especially be > true > >> for a functionality of "Anonymous" checkout. > This > >> means you're wanting to sell product to random > people. > >> So, if you're wanting to sell to random people, > you > >> would want to lower the barriers as far as > possible > >> for them to use your site. Good web surfing > practice > >> is to white list JS for sites that you trust. > This is > >> especially true in corporate environments. > >> > >> So to summarize, my two cents would be to report > the > >> add to cart bug to JIRA, fix OFBiz's SVN of this > >> pattern and degrade the JS in the anonymous > checkout > >> patch. But to quickly see this kind of > functionality > >> into OFBiz, I would prefer to see it added to a > >> sandbox so that others could help work out these > >> peculiarities. > >> > >> > >> --- Tim Ruppert <[hidden email]> > wrote: > >> > >>> I would certainly love to see the highly useful > >>> Anonymous Checkout > >>> Process example used in OFBiz - at least until > >>> someone else comes up > >>> with a good reason to remove Dojo and go to a > >>> different front end > >>> framewok. Does anyone have any real objections > to > >>> doing this in > >>> light of the fact that no one has another > example > >>> _and_ that the > >>> checkout process is unnecessarily tedious? > >>> > >>> Cheers, > >>> Tim > >>> -- > >>> Tim Ruppert > >>> HotWax Media > >>> http://www.hotwaxmedia.com > >>> > >>> o:801.649.6594 > >>> f:801.649.6594 > >>> > >>> > >>> On Dec 15, 2006, at 12:07 AM, Jacopo Cappellato > >>> wrote: > >>> > >>>> Here are my two cents about this interesting > >>> thread: > >>>> > >>>> 1) the Ajax toolkit's license must be fully > >>> compatible with the > >>>> OFBiz license > >>>> 2) even if it's a good thing to try to find one > >>> official Ajax > >>>> toolkit for OFBiz now and finally get this ball > >>> running, I think we > >>>> should do this but also review the decision > (and > >>> the results we'll > >>>> get with the adopted framework) in 2-4 months > from > >>> now and possibly > >>>> return on it; I mean that we should keep an > >>> open-minded approach > >>>> and also consider new solutions (or criticism > to > >>> the adopted > >>>> toolkit) since I think that in the Ajax world > the > >>> effects of the > >>>> 'software darwinism' > >>> (http://www.apache.org/foundation/ > >>>> glossary.html#SoftwareDarwinism) still are not > >>> mature > >>>> > >>>> Jacopo > >>>> > >>>> A. Zeneski wrote: > >>>>> I'll let this thread run a little while longer > >>> before we say to > >>>>> have a > >>>>> full official vote. As of right now, it > appears > >>> most people are > >>>>> looking > >>>>> at Dojo, and that is fine with me. > >>>>> It seems that most of these toolkits do the > same > >>> thing, so to me its > >>>>> just a matter of making a decision so I can > push > >>> forward with my > >>>>> work. > >>>>> As for being more active on the lists, sorry I > >>> have been MIA for so > >>>>> long. I've been involved in a lot of custom > (non > >>> open source) work > >>>>> as of > >>>>> late and apologize for not being around. I > will > >>> do my best to be > >>>>> here as > >>>>> much as possible. Thanks! > >>>>> Andrew > >>> > >>> > > > > |
|
|
In reply to this post by Tim Ruppert
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. -- Ean Schuessler, CTO [hidden email] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com |
|
|
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 |
|
|
--- David E Jones <[hidden email]> wrote: > > 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. > These efforts have largely failed in the past because of several reasons, with two in particular. 1) Scope of implementation was too large. If you're referring to the "specialized" components, they were entire applications that didn't really appeal to many deployments. A sandbox is meant to show off a particular feature or approach. Very similar to a JIRA issue except allowed to benefit from an SVN and some structure. When the demonstrated functionality has matured it should be ported back into the main components and removed from the sandbox. Sandbox applications should have a shelf life. 2) There wasn't a critical mass involved in the community that felt they could manipulate OFBiz at will as there are today. I'd be happy to maintain this outside of OFBiz (and will if it won't be maintained in OFBiz), but I think it would have a greater chance of success inside OFBiz being able to benefit from JIRA and the mailing lists. |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |