Re: Dojo tree 1.4
+1 jQuery is simpler, more flexible and faster to use (coding is about 50% quicker than Prototype one developer has reported), plus now that its community is really building the number of plugins and scripts are increasing very fast. true indeed. -- Thanks & Regards Atul Vani Enterprise Software Developer HotWax Media Pvt. Ltd. http://www.hotwaxmedia.com/ We are the Global Leaders in Apache OFBiz, Google 'ofbiz' and see for yourself. Sam Hamilton wrote: It would make a number of my developers very happy if we migrated over to jQuery. Its been described to me that Dojo is heavy and Prototype as a library for javascript geeks where as jQuery is simpler, more flexible and faster to use (coding is about 50% quicker than Prototype one developer has reported), plus now that its community is really building the number of plugins and scripts are increasing very fast. Anyway a few links for people interested http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks http://ajaxian.com/archives/prototype-and-jquery-a-code-comparison Really I think it boils down that we pick one framework and then run with it. All three are solid choices so then it really comes down to making coding a pleasure in which case jQuery wins it for me. Sam On 09/06/2010 06:03, Scott Gray wrote: My personal opinion is that adding an additional layer of javascript has more downsides that it does upsides. - More code to maintain - Slightly hackish, multi-parameter strings? - Another API for users to learn - Abstracting basic method calls is one thing but what about the more complex object oriented features of the libraries? Not to mention that I think the reason that people have a javascript library preference in the first place is because they are familiar with the APIs, but if we abstract the API away then they don't really gain that benefit. IMO sometimes trying to be everything to everybody just ends up with us being too complex for anybody and what we really need to do is just pick a javascript library and stick with it. Regards Scott On 9/06/2010, at 4:42 AM, Adrian Crum wrote: I'm not a JavaScript expert, so I don't have any strong opinions on the choice of a library. I have some suggestions, however. I haven't looked at the JavaScript library integration lately, but I recall that it started out with creating "connector code" in selectall.js. In other words, selectall.js was used as a facade so the third-party library can be swapped out without too much effort. That's why JavaScript function arguments are sent as Strings - so the String arguments can be parsed into whatever form the third-party library needs. While this effort is underway, it would be nice if we could have a separate file for the library facade. I think selectall.js was used at the start out of laziness - the file was already there. Now the name of that file doesn't match its contents. -Adrian On 6/8/2010 8:17 AM, Erwan de FERRIERES wrote: Le 08/06/2010 16:12, Sascha Rodekamp a écrit : Hey guys, i started the work to update the Dojo libary to the current version 1.4. And i have to say that it didn't satisfy me to work on every Dojo based JaveScript for a little version update. It will coast a lot of time to test and update all the JavaScript Code. And what we have at the end a new heavy Dojo libary which brings a lot of widget but it's hard to extend :-) So i have another (maybe better idea). Why we didn't set Dojo and Prototype as depricated and starting to use jQuerry. In my optinion jQuerry is a better invest in the future. There are a lot of Widget/ Plugin's too and it's much lighter than Dojo. Instead of spending my time with updating all the Dojo stuff, i could spend my time to migrate all Prototype / Dojo based Code to jQuerry. What do you think? Cheers Hi Sascha, I think we have to make up our minds, and make a choice. Then, go for it. I had the same probleme as you a while ago, when introducing charting. Changing to another library is ok with me, but going from one to another every time is not. Maybe we should raise a vote, and then make with what the communauty has decided ! Cheers,
Re: Dojo tree 1.4
+1 for JQuery, it might be pain to learn newer tech, but as we recently start looking into it, we found It has much more easy ways to handle things. Rishi Solanki Manager, Enterprise Software Development HotWax Media Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxmedia.com On Wed, Jun 9, 2010 at 10:15 AM, Deepak Dixit wrote: > Good idea Sascha, > > Yes jQuery is much better then Dojo and much faster then Prototype. > > > Thanks & Regards > -- > Deepak Dixit > HotWax Media Pvt. Ltd. > > > > > Sascha Rodekamp wrote: > >> Hey guys, >> >> i started the work to update the Dojo libary to the current version 1.4. >> And i have to say that it didn't satisfy me to work on every Dojo based >> JaveScript for a little version update. It will coast a lot of time to >> test >> and update all the JavaScript Code. And what we have at the end a new >> heavy >> Dojo libary which brings a lot of widget but it's hard to extend :-) >> >> So i have another (maybe better idea). Why we didn't set Dojo and >> Prototype >> as depricated >> and starting to use jQuerry. In my optinion jQuerry is a better invest in >> the future. There are a lot of Widget/ Plugin's too and it's much lighter >> than Dojo. >> >> Instead of spending my time with updating all the Dojo stuff, i could >> spend >> my time to migrate all Prototype / Dojo based Code to jQuerry. >> >> What do you think? >> >> Cheers >> Sascha >> >> 2010/6/5 Anil Patel >> >> >> >>> Looks like good plan. Overtime people might choose to replace prototype >>> framework with similar thing from Dojo. >>> >>> Thanks and Regards >>> Anil Patel >>> HotWax Media Inc >>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >>> >>> On Jun 5, 2010, at 1:13 PM, Jacques Le Roux wrote: >>> >>> >>> So far I have mostly used Dojo for its tree in a CMS tool, and some >>> Prototype functions notably for layered lookups. >>> >>> I still see them as complementary (Dojo coming more complete but heavier, >>> Prototype being mostly an API). >>> >>> I does do think it's necessary to make a choice. Jacques From: "Adrian Crum" > >From what I recall, the two libraries were included in the project > with > > the idea that the most popular one would get used. At the >>> >>> time, Dojo was a very heavy library and the first attempts to use it >> >> > resulted in very slow page loads. I used Prototype in some >>> >>> initial Ajax work - mainly because it was pretty easy to use. Today, I >> >> > have no preference for either one. >>> >>> -Adrian > > --- On Sat, 6/5/10, Anil Patel wrote: > > > >> From: Anil Patel >> Subject: Re: Dojo tree 1.4 >> To: dev@ofbiz.apache.org >> Cc: "Anil Patel" >> Date: Saturday, June 5, 2010, 7:00 AM >> I started using Dojo in Ofbiz long >> back and in six months because of issues faced we switched >> to using prototype. At that time there were few others in >> comunity who liked prototype better. But I really don't >> remember the reasons. >> >> Since then new checkout process was added that uses >> prototype for all javascript needs. But did not remove Dojo >> because i did not want to upset anybody in community. >> >> Thanks and Regards >> Anil Patel >> HotWax Media Inc >> Find us on the web at www.hotwaxmedia.com or Google Keyword >> "ofbiz" >> >> On Jun 5, 2010, at 9:47 AM, Jacques Le Roux wrote: >> >> >> >>> I have created a branch >>> http://svn.apache.org/repos/asf/ofbiz/branches/dojo1.4 >>> Nothing else for now >>> >>> Jacques >>> >>> From: "Sascha Rodekamp" >>> >>> Hi Jacques ... jep it's a lot of work but not impossible :) A brunch is a good idea to start working on this >>> project. I think the reason >> >> >>> for Antil was, that he isn't use to Dojo. But that >>> shouldn't be a problem >> >> >>> the syntax isn't complicated. And by the way, if this will work the new Dojo >>> will bring us a big benefit >> >> >>> (in my opinion). Cheers Sascha 2010/6/5 Jacques Le Roux > Sascha, > > We should rather use the dev ML for this > > thread. >> >> >>> Maybe it's the reason why Anil was reluctant > > to use Dojo? >> >> >>> Jacques > > > Jacques Le Roux wrote: > > > >> Sascha Rodekamp wrote: >> >> >> >>> Hey, >>> >>> so i started upgrading to dojo 1.4. >>> The good point is ... Dojo 1.4 has >>> >>> >> many really cool new Features which >> >> >>> can
Re: Dojo tree 1.4
Yes Sascha, i am agree with you , jquery is light & more efficient than all other js frameworks. -- Thanks& Regards: Ankit Jain Enterprise Software Developer Hotwax Media Pvt. Ltd. www.hotwaxmedia.com On Tuesday 08 June 2010 07:42 PM, Sascha Rodekamp wrote: Hey guys, i started the work to update the Dojo libary to the current version 1.4. And i have to say that it didn't satisfy me to work on every Dojo based JaveScript for a little version update. It will coast a lot of time to test and update all the JavaScript Code. And what we have at the end a new heavy Dojo libary which brings a lot of widget but it's hard to extend :-) So i have another (maybe better idea). Why we didn't set Dojo and Prototype as depricated and starting to use jQuerry. In my optinion jQuerry is a better invest in the future. There are a lot of Widget/ Plugin's too and it's much lighter than Dojo. Instead of spending my time with updating all the Dojo stuff, i could spend my time to migrate all Prototype / Dojo based Code to jQuerry. What do you think? Cheers Sascha 2010/6/5 Anil Patel Looks like good plan. Overtime people might choose to replace prototype framework with similar thing from Dojo. Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" On Jun 5, 2010, at 1:13 PM, Jacques Le Roux wrote: So far I have mostly used Dojo for its tree in a CMS tool, and some Prototype functions notably for layered lookups. I still see them as complementary (Dojo coming more complete but heavier, Prototype being mostly an API). I does do think it's necessary to make a choice. Jacques From: "Adrian Crum" > From what I recall, the two libraries were included in the project with the idea that the most popular one would get used. At the time, Dojo was a very heavy library and the first attempts to use it resulted in very slow page loads. I used Prototype in some initial Ajax work - mainly because it was pretty easy to use. Today, I have no preference for either one. -Adrian --- On Sat, 6/5/10, Anil Patel wrote: From: Anil Patel Subject: Re: Dojo tree 1.4 To: dev@ofbiz.apache.org Cc: "Anil Patel" Date: Saturday, June 5, 2010, 7:00 AM I started using Dojo in Ofbiz long back and in six months because of issues faced we switched to using prototype. At that time there were few others in comunity who liked prototype better. But I really don't remember the reasons. Since then new checkout process was added that uses prototype for all javascript needs. But did not remove Dojo because i did not want to upset anybody in community. Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" On Jun 5, 2010, at 9:47 AM, Jacques Le Roux wrote: I have created a branch http://svn.apache.org/repos/asf/ofbiz/branches/dojo1.4 Nothing else for now Jacques From: "Sascha Rodekamp" Hi Jacques ... jep it's a lot of work but not impossible :) A brunch is a good idea to start working on this project. I think the reason for Antil was, that he isn't use to Dojo. But that shouldn't be a problem the syntax isn't complicated. And by the way, if this will work the new Dojo will bring us a big benefit (in my opinion). Cheers Sascha 2010/6/5 Jacques Le Roux Sascha, We should rather use the dev ML for this thread. Maybe it's the reason why Anil was reluctant to use Dojo? Jacques Jacques Le Roux wrote: Sascha Rodekamp wrote: Hey, so i started upgrading to dojo 1.4. The good point is ... Dojo 1.4 has many really cool new Features which can help us to improve the UI. The Bad thing is, some parts of the syntax had changed. That effects many parts in OFBiz (OnePageCheckout, Trees, all Dojo features Scripts :-)). Arg, I did not thought it will be so much trouble :/ So that's a lot of work and i can't do it on my own ... who volunteer to help me ;) ?? I could help First Step is to collect all depending issues and than to fix them step by step. So if we do that we need a branch I guess... Jacques Have a nice day Sascha -- >> http://www.lynx.de
Re: Dojo tree 1.4
Good idea Sascha, Yes jQuery is much better then Dojo and much faster then Prototype. Thanks & Regards -- Deepak Dixit HotWax Media Pvt. Ltd. Sascha Rodekamp wrote: Hey guys, i started the work to update the Dojo libary to the current version 1.4. And i have to say that it didn't satisfy me to work on every Dojo based JaveScript for a little version update. It will coast a lot of time to test and update all the JavaScript Code. And what we have at the end a new heavy Dojo libary which brings a lot of widget but it's hard to extend :-) So i have another (maybe better idea). Why we didn't set Dojo and Prototype as depricated and starting to use jQuerry. In my optinion jQuerry is a better invest in the future. There are a lot of Widget/ Plugin's too and it's much lighter than Dojo. Instead of spending my time with updating all the Dojo stuff, i could spend my time to migrate all Prototype / Dojo based Code to jQuerry. What do you think? Cheers Sascha 2010/6/5 Anil Patel Looks like good plan. Overtime people might choose to replace prototype framework with similar thing from Dojo. Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" On Jun 5, 2010, at 1:13 PM, Jacques Le Roux wrote: So far I have mostly used Dojo for its tree in a CMS tool, and some Prototype functions notably for layered lookups. I still see them as complementary (Dojo coming more complete but heavier, Prototype being mostly an API). I does do think it's necessary to make a choice. Jacques From: "Adrian Crum" >From what I recall, the two libraries were included in the project with the idea that the most popular one would get used. At the time, Dojo was a very heavy library and the first attempts to use it resulted in very slow page loads. I used Prototype in some initial Ajax work - mainly because it was pretty easy to use. Today, I have no preference for either one. -Adrian --- On Sat, 6/5/10, Anil Patel wrote: From: Anil Patel Subject: Re: Dojo tree 1.4 To: dev@ofbiz.apache.org Cc: "Anil Patel" Date: Saturday, June 5, 2010, 7:00 AM I started using Dojo in Ofbiz long back and in six months because of issues faced we switched to using prototype. At that time there were few others in comunity who liked prototype better. But I really don't remember the reasons. Since then new checkout process was added that uses prototype for all javascript needs. But did not remove Dojo because i did not want to upset anybody in community. Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" On Jun 5, 2010, at 9:47 AM, Jacques Le Roux wrote: I have created a branch http://svn.apache.org/repos/asf/ofbiz/branches/dojo1.4 Nothing else for now Jacques From: "Sascha Rodekamp" Hi Jacques ... jep it's a lot of work but not impossible :) A brunch is a good idea to start working on this project. I think the reason for Antil was, that he isn't use to Dojo. But that shouldn't be a problem the syntax isn't complicated. And by the way, if this will work the new Dojo will bring us a big benefit (in my opinion). Cheers Sascha 2010/6/5 Jacques Le Roux Sascha, We should rather use the dev ML for this thread. Maybe it's the reason why Anil was reluctant to use Dojo? Jacques Jacques Le Roux wrote: Sascha Rodekamp wrote: Hey, so i started upgrading to dojo 1.4. The good point is ... Dojo 1.4 has many really cool new Features which can help us to improve the UI. The Bad thing is, some parts of the syntax had changed. That effects many parts in OFBiz (OnePageCheckout, Trees, all Dojo features Scripts :-)). Arg, I did not thought it will be so much trouble :/ So that's a lot of work and i can't do it on my own ... who volunteer to help me ;) ?? I could help First Step is to collect all depending issues and than to fix them step by step. So if we do that we need a branch I guess... Jacques Have a nice day Sascha -- >> http://www.lynx.de
Re: Dojo tree 1.4
Comparision article: http://blog.creonfx.com/javascript/mootools-vs-jquery-vs-prototype-vs-yui-vs-dojo-comparison-revised -- Ashish On Wed, Jun 9, 2010 at 10:01 AM, Tim Ruppert wrote: > +1 - I like Prototype, but mostly because we know it well and JQuery was yet > the framework that it is today. You're exactly right that Dojo is heavey and > Prototype is a library for javascript geeks :) JQuery is likely the best > choice on the market right now. > > Cheers, > Ruppert > > On Jun 8, 2010, at 10:10 PM, Sam Hamilton wrote: > >> It would make a number of my developers very happy if we migrated over >> to jQuery. Its been described to me that Dojo is heavy and Prototype as >> a library for javascript geeks where as jQuery is simpler, more flexible >> and faster to use (coding is about 50% quicker than Prototype one >> developer has reported), plus now that its community is really building >> the number of plugins and scripts are increasing very fast. >> >> Anyway a few links for people interested >> http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks >> http://ajaxian.com/archives/prototype-and-jquery-a-code-comparison >> >> Really I think it boils down that we pick one framework and then run >> with it. All three are solid choices so then it really comes down to >> making coding a pleasure in which case jQuery wins it for me. >> >> Sam >> >> >> >> On 09/06/2010 06:03, Scott Gray wrote: >>> My personal opinion is that adding an additional layer of javascript has >>> more downsides that it does upsides. >>> - More code to maintain >>> - Slightly hackish, multi-parameter strings? >>> - Another API for users to learn >>> - Abstracting basic method calls is one thing but what about the more >>> complex object oriented features of the libraries? >>> >>> Not to mention that I think the reason that people have a javascript >>> library preference in the first place is because they are familiar with the >>> APIs, but if we abstract the API away then they don't really gain that >>> benefit. >>> >>> IMO sometimes trying to be everything to everybody just ends up with us >>> being too complex for anybody and what we really need to do is just pick a >>> javascript library and stick with it. >>> >>> Regards >>> Scott >>> >>> On 9/06/2010, at 4:42 AM, Adrian Crum wrote: >>> I'm not a JavaScript expert, so I don't have any strong opinions on the choice of a library. I have some suggestions, however. I haven't looked at the JavaScript library integration lately, but I recall that it started out with creating "connector code" in selectall.js. In other words, selectall.js was used as a facade so the third-party library can be swapped out without too much effort. That's why JavaScript function arguments are sent as Strings - so the String arguments can be parsed into whatever form the third-party library needs. While this effort is underway, it would be nice if we could have a separate file for the library facade. I think selectall.js was used at the start out of laziness - the file was already there. Now the name of that file doesn't match its contents. -Adrian On 6/8/2010 8:17 AM, Erwan de FERRIERES wrote: > Le 08/06/2010 16:12, Sascha Rodekamp a écrit : >> Hey guys, >> >> i started the work to update the Dojo libary to the current version 1.4. >> And i have to say that it didn't satisfy me to work on every Dojo based >> JaveScript for a little version update. It will coast a lot of time to >> test >> and update all the JavaScript Code. And what we have at the end a new >> heavy >> Dojo libary which brings a lot of widget but it's hard to extend :-) >> >> So i have another (maybe better idea). Why we didn't set Dojo and >> Prototype >> as depricated >> and starting to use jQuerry. In my optinion jQuerry is a better invest in >> the future. There are a lot of Widget/ Plugin's too and it's much lighter >> than Dojo. >> >> Instead of spending my time with updating all the Dojo stuff, i could >> spend >> my time to migrate all Prototype / Dojo based Code to jQuerry. >> >> What do you think? >> >> Cheers > > Hi Sascha, > > I think we have to make up our minds, and make a choice. Then, go for > it. I had the same probleme as you a while ago, when introducing charting. > Changing to another library is ok with me, but going from one to another > every time is not. > Maybe we should raise a vote, and then make with what the communauty has > decided ! > > Cheers, > >>> >> > >
Re: Dojo tree 1.4
+1 - I like Prototype, but mostly because we know it well and JQuery was yet the framework that it is today. You're exactly right that Dojo is heavey and Prototype is a library for javascript geeks :) JQuery is likely the best choice on the market right now. Cheers, Ruppert On Jun 8, 2010, at 10:10 PM, Sam Hamilton wrote: > It would make a number of my developers very happy if we migrated over > to jQuery. Its been described to me that Dojo is heavy and Prototype as > a library for javascript geeks where as jQuery is simpler, more flexible > and faster to use (coding is about 50% quicker than Prototype one > developer has reported), plus now that its community is really building > the number of plugins and scripts are increasing very fast. > > Anyway a few links for people interested > http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks > http://ajaxian.com/archives/prototype-and-jquery-a-code-comparison > > Really I think it boils down that we pick one framework and then run > with it. All three are solid choices so then it really comes down to > making coding a pleasure in which case jQuery wins it for me. > > Sam > > > > On 09/06/2010 06:03, Scott Gray wrote: >> My personal opinion is that adding an additional layer of javascript has >> more downsides that it does upsides. >> - More code to maintain >> - Slightly hackish, multi-parameter strings? >> - Another API for users to learn >> - Abstracting basic method calls is one thing but what about the more >> complex object oriented features of the libraries? >> >> Not to mention that I think the reason that people have a javascript library >> preference in the first place is because they are familiar with the APIs, >> but if we abstract the API away then they don't really gain that benefit. >> >> IMO sometimes trying to be everything to everybody just ends up with us >> being too complex for anybody and what we really need to do is just pick a >> javascript library and stick with it. >> >> Regards >> Scott >> >> On 9/06/2010, at 4:42 AM, Adrian Crum wrote: >> >>> I'm not a JavaScript expert, so I don't have any strong opinions on the >>> choice of a library. I have some suggestions, however. >>> >>> I haven't looked at the JavaScript library integration lately, but I recall >>> that it started out with creating "connector code" in selectall.js. In >>> other words, selectall.js was used as a facade so the third-party library >>> can be swapped out without too much effort. >>> >>> That's why JavaScript function arguments are sent as Strings - so the >>> String arguments can be parsed into whatever form the third-party library >>> needs. >>> >>> While this effort is underway, it would be nice if we could have a separate >>> file for the library facade. I think selectall.js was used at the start out >>> of laziness - the file was already there. Now the name of that file doesn't >>> match its contents. >>> >>> -Adrian >>> >>> On 6/8/2010 8:17 AM, Erwan de FERRIERES wrote: Le 08/06/2010 16:12, Sascha Rodekamp a écrit : > Hey guys, > > i started the work to update the Dojo libary to the current version 1.4. > And i have to say that it didn't satisfy me to work on every Dojo based > JaveScript for a little version update. It will coast a lot of time to > test > and update all the JavaScript Code. And what we have at the end a new > heavy > Dojo libary which brings a lot of widget but it's hard to extend :-) > > So i have another (maybe better idea). Why we didn't set Dojo and > Prototype > as depricated > and starting to use jQuerry. In my optinion jQuerry is a better invest in > the future. There are a lot of Widget/ Plugin's too and it's much lighter > than Dojo. > > Instead of spending my time with updating all the Dojo stuff, i could > spend > my time to migrate all Prototype / Dojo based Code to jQuerry. > > What do you think? > > Cheers Hi Sascha, I think we have to make up our minds, and make a choice. Then, go for it. I had the same probleme as you a while ago, when introducing charting. Changing to another library is ok with me, but going from one to another every time is not. Maybe we should raise a vote, and then make with what the communauty has decided ! Cheers, >> >
Re: Dojo tree 1.4
It would make a number of my developers very happy if we migrated over to jQuery. Its been described to me that Dojo is heavy and Prototype as a library for javascript geeks where as jQuery is simpler, more flexible and faster to use (coding is about 50% quicker than Prototype one developer has reported), plus now that its community is really building the number of plugins and scripts are increasing very fast. Anyway a few links for people interested http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks http://ajaxian.com/archives/prototype-and-jquery-a-code-comparison Really I think it boils down that we pick one framework and then run with it. All three are solid choices so then it really comes down to making coding a pleasure in which case jQuery wins it for me. Sam On 09/06/2010 06:03, Scott Gray wrote: > My personal opinion is that adding an additional layer of javascript has more > downsides that it does upsides. > - More code to maintain > - Slightly hackish, multi-parameter strings? > - Another API for users to learn > - Abstracting basic method calls is one thing but what about the more complex > object oriented features of the libraries? > > Not to mention that I think the reason that people have a javascript library > preference in the first place is because they are familiar with the APIs, but > if we abstract the API away then they don't really gain that benefit. > > IMO sometimes trying to be everything to everybody just ends up with us being > too complex for anybody and what we really need to do is just pick a > javascript library and stick with it. > > Regards > Scott > > On 9/06/2010, at 4:42 AM, Adrian Crum wrote: > >> I'm not a JavaScript expert, so I don't have any strong opinions on the >> choice of a library. I have some suggestions, however. >> >> I haven't looked at the JavaScript library integration lately, but I recall >> that it started out with creating "connector code" in selectall.js. In other >> words, selectall.js was used as a facade so the third-party library can be >> swapped out without too much effort. >> >> That's why JavaScript function arguments are sent as Strings - so the String >> arguments can be parsed into whatever form the third-party library needs. >> >> While this effort is underway, it would be nice if we could have a separate >> file for the library facade. I think selectall.js was used at the start out >> of laziness - the file was already there. Now the name of that file doesn't >> match its contents. >> >> -Adrian >> >> On 6/8/2010 8:17 AM, Erwan de FERRIERES wrote: >>> Le 08/06/2010 16:12, Sascha Rodekamp a écrit : Hey guys, i started the work to update the Dojo libary to the current version 1.4. And i have to say that it didn't satisfy me to work on every Dojo based JaveScript for a little version update. It will coast a lot of time to test and update all the JavaScript Code. And what we have at the end a new heavy Dojo libary which brings a lot of widget but it's hard to extend :-) So i have another (maybe better idea). Why we didn't set Dojo and Prototype as depricated and starting to use jQuerry. In my optinion jQuerry is a better invest in the future. There are a lot of Widget/ Plugin's too and it's much lighter than Dojo. Instead of spending my time with updating all the Dojo stuff, i could spend my time to migrate all Prototype / Dojo based Code to jQuerry. What do you think? Cheers >>> >>> Hi Sascha, >>> >>> I think we have to make up our minds, and make a choice. Then, go for >>> it. I had the same probleme as you a while ago, when introducing charting. >>> Changing to another library is ok with me, but going from one to another >>> every time is not. >>> Maybe we should raise a vote, and then make with what the communauty has >>> decided ! >>> >>> Cheers, >>> >
Re: Dojo tree 1.4
My personal opinion is that adding an additional layer of javascript has more downsides that it does upsides. - More code to maintain - Slightly hackish, multi-parameter strings? - Another API for users to learn - Abstracting basic method calls is one thing but what about the more complex object oriented features of the libraries? Not to mention that I think the reason that people have a javascript library preference in the first place is because they are familiar with the APIs, but if we abstract the API away then they don't really gain that benefit. IMO sometimes trying to be everything to everybody just ends up with us being too complex for anybody and what we really need to do is just pick a javascript library and stick with it. Regards Scott On 9/06/2010, at 4:42 AM, Adrian Crum wrote: > I'm not a JavaScript expert, so I don't have any strong opinions on the > choice of a library. I have some suggestions, however. > > I haven't looked at the JavaScript library integration lately, but I recall > that it started out with creating "connector code" in selectall.js. In other > words, selectall.js was used as a facade so the third-party library can be > swapped out without too much effort. > > That's why JavaScript function arguments are sent as Strings - so the String > arguments can be parsed into whatever form the third-party library needs. > > While this effort is underway, it would be nice if we could have a separate > file for the library facade. I think selectall.js was used at the start out > of laziness - the file was already there. Now the name of that file doesn't > match its contents. > > -Adrian > > On 6/8/2010 8:17 AM, Erwan de FERRIERES wrote: >> Le 08/06/2010 16:12, Sascha Rodekamp a écrit : >>> Hey guys, >>> >>> i started the work to update the Dojo libary to the current version 1.4. >>> And i have to say that it didn't satisfy me to work on every Dojo based >>> JaveScript for a little version update. It will coast a lot of time to >>> test >>> and update all the JavaScript Code. And what we have at the end a new >>> heavy >>> Dojo libary which brings a lot of widget but it's hard to extend :-) >>> >>> So i have another (maybe better idea). Why we didn't set Dojo and >>> Prototype >>> as depricated >>> and starting to use jQuerry. In my optinion jQuerry is a better invest in >>> the future. There are a lot of Widget/ Plugin's too and it's much lighter >>> than Dojo. >>> >>> Instead of spending my time with updating all the Dojo stuff, i could >>> spend >>> my time to migrate all Prototype / Dojo based Code to jQuerry. >>> >>> What do you think? >>> >>> Cheers >> >> Hi Sascha, >> >> I think we have to make up our minds, and make a choice. Then, go for >> it. I had the same probleme as you a while ago, when introducing charting. >> Changing to another library is ok with me, but going from one to another >> every time is not. >> Maybe we should raise a vote, and then make with what the communauty has >> decided ! >> >> Cheers, >> smime.p7s Description: S/MIME cryptographic signature
Re: Dojo tree 1.4
I'm not a JavaScript expert, so I don't have any strong opinions on the choice of a library. I have some suggestions, however. I haven't looked at the JavaScript library integration lately, but I recall that it started out with creating "connector code" in selectall.js. In other words, selectall.js was used as a facade so the third-party library can be swapped out without too much effort. That's why JavaScript function arguments are sent as Strings - so the String arguments can be parsed into whatever form the third-party library needs. While this effort is underway, it would be nice if we could have a separate file for the library facade. I think selectall.js was used at the start out of laziness - the file was already there. Now the name of that file doesn't match its contents. -Adrian On 6/8/2010 8:17 AM, Erwan de FERRIERES wrote: Le 08/06/2010 16:12, Sascha Rodekamp a écrit : Hey guys, i started the work to update the Dojo libary to the current version 1.4. And i have to say that it didn't satisfy me to work on every Dojo based JaveScript for a little version update. It will coast a lot of time to test and update all the JavaScript Code. And what we have at the end a new heavy Dojo libary which brings a lot of widget but it's hard to extend :-) So i have another (maybe better idea). Why we didn't set Dojo and Prototype as depricated and starting to use jQuerry. In my optinion jQuerry is a better invest in the future. There are a lot of Widget/ Plugin's too and it's much lighter than Dojo. Instead of spending my time with updating all the Dojo stuff, i could spend my time to migrate all Prototype / Dojo based Code to jQuerry. What do you think? Cheers Hi Sascha, I think we have to make up our minds, and make a choice. Then, go for it. I had the same probleme as you a while ago, when introducing charting. Changing to another library is ok with me, but going from one to another every time is not. Maybe we should raise a vote, and then make with what the communauty has decided ! Cheers,
Re: Shopping list problem in ecommerce component
Please use rather user ML for such questions, see why here : http://cwiki.apache.org/confluence/display/OFBADMIN/Mailing+Lists#MailingLists-DesignanddevelopmentList:dev@ofbiz.apache.org Thanks Jacques From: "rrhati2010" Hi Ankit, Thanks for the solution. Even if I change the default value, I didn't get a unique Shopping list name inserted into the database on clicking Create new button. I need, whenever I click on create new , a unique shopping list name is inserted into the database. Please help...How to do it?? Thanks in advance... RRH =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you - RRH -- View this message in context: http://ofbiz.135035.n4.nabble.com/Shopping-list-problem-in-ecommerce-component-tp2246871p2247179.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] Commented: (OFBIZ-3575) Union view entity support
[ https://issues.apache.org/jira/browse/OFBIZ-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876702#action_12876702 ] Adam Heath commented on OFBIZ-3575: --- I've started to look at this now. First comment, is that the patch doesn't have consistent formatting(mixed space/tab lines, for one). Second, the test case should test unions across different tables, with differently named columns, but with the same type. Plus, we now support conditions in views, which this patch doesn't support at all. This kind of large change is not something that should be in a single patch. It should be broken up into much smaller chunks. One I see that could be done right off the bat is the refactoring in SqlJdbcUtil to move the view sql generation into a separate method. I see it only supports UNION and UNION ALL. Why not INTERSECT and EXCEPT variants as well? Why don't theta-oracle and theta-mssql support unions? If it's because of the different way conditions are done, then that's not correct. Just create nested tables. I'm willing to take the code inside this patch, and use it as a starting point, for something better, so I'm not asking for your help on any of the restructuring. But I may still have questions about it from time to time. I also can't give a concrete timeframe as to when it will be done. I could make use of this tho in one of our own projects. Do you have any thoughts about how to do dynamic views with unions? > Union view entity support > - > > Key: OFBIZ-3575 > URL: https://issues.apache.org/jira/browse/OFBIZ-3575 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Assignee: Adam Heath > Attachments: OFBIZ-3575_UnionViewEntitySupport.patch > > > As per conversion titled "entity-engine union support" > (http://n4.nabble.com/entity-engine-union-support-td1607240.html#a1607240); > here is the basic union support that we had added into our Ofbiz project. I > have changed a little of the xml schema here ... the premise is that a > "UnionViewEntity" extends the standard "ViewEntity" and contains a list of > union members that it will union together. There should only be changes to > the ModelReader to instantiate the new model object and then in SqlJdbcUtil > to handle generating the new sql for unions. I have included a very small > unit test that executes a findList against a test union. > Here is sample sql that was generated: > SELECT uva.UNION_ID, uva.TESTING_NAME, uva.TESTING_SIZE, uva.TESTING_DATE > FROM ( SELECT T1.TESTING_ID AS UNION_ID, T1.TESTING_NAME AS TESTING_NAME, > T1.TESTING_SIZE AS TESTING_SIZE, T1.TESTING_DATE AS TESTING_DATE FROM TESTING > T1 UNION SELECT T2.TESTING_TYPE_ID AS UNION_ID, T2.TESTING_NAME AS > TESTING_NAME, T2.TESTING_SIZE AS TESTING_SIZE, T2.TESTING_DATE AS > TESTING_DATE FROM TESTING T2 ) uva -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3575) Union view entity support
[ https://issues.apache.org/jira/browse/OFBIZ-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-3575: - Assignee: Adam Heath > Union view entity support > - > > Key: OFBIZ-3575 > URL: https://issues.apache.org/jira/browse/OFBIZ-3575 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Assignee: Adam Heath > Attachments: OFBIZ-3575_UnionViewEntitySupport.patch > > > As per conversion titled "entity-engine union support" > (http://n4.nabble.com/entity-engine-union-support-td1607240.html#a1607240); > here is the basic union support that we had added into our Ofbiz project. I > have changed a little of the xml schema here ... the premise is that a > "UnionViewEntity" extends the standard "ViewEntity" and contains a list of > union members that it will union together. There should only be changes to > the ModelReader to instantiate the new model object and then in SqlJdbcUtil > to handle generating the new sql for unions. I have included a very small > unit test that executes a findList against a test union. > Here is sample sql that was generated: > SELECT uva.UNION_ID, uva.TESTING_NAME, uva.TESTING_SIZE, uva.TESTING_DATE > FROM ( SELECT T1.TESTING_ID AS UNION_ID, T1.TESTING_NAME AS TESTING_NAME, > T1.TESTING_SIZE AS TESTING_SIZE, T1.TESTING_DATE AS TESTING_DATE FROM TESTING > T1 UNION SELECT T2.TESTING_TYPE_ID AS UNION_ID, T2.TESTING_NAME AS > TESTING_NAME, T2.TESTING_SIZE AS TESTING_SIZE, T2.TESTING_DATE AS > TESTING_DATE FROM TESTING T2 ) uva -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Dojo tree 1.4
Le 08/06/2010 16:12, Sascha Rodekamp a écrit : Hey guys, i started the work to update the Dojo libary to the current version 1.4. And i have to say that it didn't satisfy me to work on every Dojo based JaveScript for a little version update. It will coast a lot of time to test and update all the JavaScript Code. And what we have at the end a new heavy Dojo libary which brings a lot of widget but it's hard to extend :-) So i have another (maybe better idea). Why we didn't set Dojo and Prototype as depricated and starting to use jQuerry. In my optinion jQuerry is a better invest in the future. There are a lot of Widget/ Plugin's too and it's much lighter than Dojo. Instead of spending my time with updating all the Dojo stuff, i could spend my time to migrate all Prototype / Dojo based Code to jQuerry. What do you think? Cheers Hi Sascha, I think we have to make up our minds, and make a choice. Then, go for it. I had the same probleme as you a while ago, when introducing charting. Changing to another library is ok with me, but going from one to another every time is not. Maybe we should raise a vote, and then make with what the communauty has decided ! Cheers, -- Erwan de FERRIERES www.nereide.biz
Re: Shopping list problem in ecommerce component
Hi Ankit, Thanks for the solution. Even if I change the default value, I didn't get a unique Shopping list name inserted into the database on clicking Create new button. I need, whenever I click on create new , a unique shopping list name is inserted into the database. Please help...How to do it?? Thanks in advance... RRH =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you - RRH -- View this message in context: http://ofbiz.135035.n4.nabble.com/Shopping-list-problem-in-ecommerce-component-tp2246871p2247179.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Dojo tree 1.4
This is line with I said earlier. We should instead use jquery. And to some extend we need to be ready to help those community to build and maintain tools that help us. I will prefer jquery over dojo. Sent from my iPhone On Jun 8, 2010, at 10:12 AM, Sascha Rodekamp > wrote: Hey guys, i started the work to update the Dojo libary to the current version 1.4. And i have to say that it didn't satisfy me to work on every Dojo based JaveScript for a little version update. It will coast a lot of time to test and update all the JavaScript Code. And what we have at the end a new heavy Dojo libary which brings a lot of widget but it's hard to extend :-) So i have another (maybe better idea). Why we didn't set Dojo and Prototype as depricated and starting to use jQuerry. In my optinion jQuerry is a better invest in the future. There are a lot of Widget/ Plugin's too and it's much lighter than Dojo. Instead of spending my time with updating all the Dojo stuff, i could spend my time to migrate all Prototype / Dojo based Code to jQuerry. What do you think? Cheers Sascha 2010/6/5 Anil Patel Looks like good plan. Overtime people might choose to replace prototype framework with similar thing from Dojo. Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" On Jun 5, 2010, at 1:13 PM, Jacques Le Roux wrote: So far I have mostly used Dojo for its tree in a CMS tool, and some Prototype functions notably for layered lookups. I still see them as complementary (Dojo coming more complete but heavier, Prototype being mostly an API). I does do think it's necessary to make a choice. Jacques From: "Adrian Crum" From what I recall, the two libraries were included in the project with the idea that the most popular one would get used. At the time, Dojo was a very heavy library and the first attempts to use it resulted in very slow page loads. I used Prototype in some initial Ajax work - mainly because it was pretty easy to use. Today, I have no preference for either one. -Adrian --- On Sat, 6/5/10, Anil Patel wrote: From: Anil Patel Subject: Re: Dojo tree 1.4 To: dev@ofbiz.apache.org Cc: "Anil Patel" Date: Saturday, June 5, 2010, 7:00 AM I started using Dojo in Ofbiz long back and in six months because of issues faced we switched to using prototype. At that time there were few others in comunity who liked prototype better. But I really don't remember the reasons. Since then new checkout process was added that uses prototype for all javascript needs. But did not remove Dojo because i did not want to upset anybody in community. Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" On Jun 5, 2010, at 9:47 AM, Jacques Le Roux wrote: I have created a branch http://svn.apache.org/repos/asf/ofbiz/branches/dojo1.4 Nothing else for now Jacques From: "Sascha Rodekamp" Hi Jacques ... jep it's a lot of work but not impossible :) A brunch is a good idea to start working on this project. I think the reason for Antil was, that he isn't use to Dojo. But that shouldn't be a problem the syntax isn't complicated. And by the way, if this will work the new Dojo will bring us a big benefit (in my opinion). Cheers Sascha 2010/6/5 Jacques Le Roux Sascha, We should rather use the dev ML for this thread. Maybe it's the reason why Anil was reluctant to use Dojo? Jacques Jacques Le Roux wrote: Sascha Rodekamp wrote: Hey, so i started upgrading to dojo 1.4. The good point is ... Dojo 1.4 has many really cool new Features which can help us to improve the UI. The Bad thing is, some parts of the syntax had changed. That effects many parts in OFBiz (OnePageCheckout, Trees, all Dojo features Scripts :-)). Arg, I did not thought it will be so much trouble :/ So that's a lot of work and i can't do it on my own ... who volunteer to help me ;) ?? I could help First Step is to collect all depending issues and than to fix them step by step. So if we do that we need a branch I guess... Jacques Have a nice day Sascha -- >> http://www.lynx.de -- http://www.lynx.de
Re: Dojo tree 1.4
> Instead of spending my time with updating all the Dojo stuff, i could spend > my time to migrate all Prototype / Dojo based Code to jQuerry. One sample application(or we can say functionality) would be of great help. Then everyone can see the live functionality and can comment accordingly! -- Ashish On Tue, Jun 8, 2010 at 7:42 PM, Sascha Rodekamp wrote: > Hey guys, > > i started the work to update the Dojo libary to the current version 1.4. > And i have to say that it didn't satisfy me to work on every Dojo based > JaveScript for a little version update. It will coast a lot of time to test > and update all the JavaScript Code. And what we have at the end a new heavy > Dojo libary which brings a lot of widget but it's hard to extend :-) > > So i have another (maybe better idea). Why we didn't set Dojo and Prototype > as depricated > and starting to use jQuerry. In my optinion jQuerry is a better invest in > the future. There are a lot of Widget/ Plugin's too and it's much lighter > than Dojo. > > Instead of spending my time with updating all the Dojo stuff, i could spend > my time to migrate all Prototype / Dojo based Code to jQuerry. > > What do you think? > > Cheers > Sascha > > 2010/6/5 Anil Patel > >> Looks like good plan. Overtime people might choose to replace prototype >> framework with similar thing from Dojo. >> >> Thanks and Regards >> Anil Patel >> HotWax Media Inc >> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >> >> On Jun 5, 2010, at 1:13 PM, Jacques Le Roux wrote: >> >> > So far I have mostly used Dojo for its tree in a CMS tool, and some >> Prototype functions notably for layered lookups. >> > I still see them as complementary (Dojo coming more complete but heavier, >> Prototype being mostly an API). >> > I does do think it's necessary to make a choice. >> > >> > Jacques >> > >> > From: "Adrian Crum" >> >> >From what I recall, the two libraries were included in the project with >> the idea that the most popular one would get used. At the >> >> >time, Dojo was a very heavy library and the first attempts to use it >> resulted in very slow page loads. I used Prototype in some >> >> >initial Ajax work - mainly because it was pretty easy to use. Today, I >> have no preference for either one. >> >> >> >> -Adrian >> >> >> >> --- On Sat, 6/5/10, Anil Patel wrote: >> >> >> >>> From: Anil Patel >> >>> Subject: Re: Dojo tree 1.4 >> >>> To: dev@ofbiz.apache.org >> >>> Cc: "Anil Patel" >> >>> Date: Saturday, June 5, 2010, 7:00 AM >> >>> I started using Dojo in Ofbiz long >> >>> back and in six months because of issues faced we switched >> >>> to using prototype. At that time there were few others in >> >>> comunity who liked prototype better. But I really don't >> >>> remember the reasons. >> >>> >> >>> Since then new checkout process was added that uses >> >>> prototype for all javascript needs. But did not remove Dojo >> >>> because i did not want to upset anybody in community. >> >>> >> >>> Thanks and Regards >> >>> Anil Patel >> >>> HotWax Media Inc >> >>> Find us on the web at www.hotwaxmedia.com or Google Keyword >> >>> "ofbiz" >> >>> >> >>> On Jun 5, 2010, at 9:47 AM, Jacques Le Roux wrote: >> >>> >> >>> > I have created a branch >> >>> > http://svn.apache.org/repos/asf/ofbiz/branches/dojo1.4 >> >>> > Nothing else for now >> >>> > >> >>> > Jacques >> >>> > >> >>> > From: "Sascha Rodekamp" >> >>> >> Hi Jacques ... >> >>> >> jep it's a lot of work but not impossible :) >> >>> >> A brunch is a good idea to start working on this >> >>> project. I think the reason >> >>> >> for Antil was, that he isn't use to Dojo. But that >> >>> shouldn't be a problem >> >>> >> the syntax isn't complicated. >> >>> >> And by the way, if this will work the new Dojo >> >>> will bring us a big benefit >> >>> >> (in my opinion). >> >>> >> Cheers >> >>> >> Sascha >> >>> >> 2010/6/5 Jacques Le Roux >> >>> >>> Sascha, >> >>> >>> >> >>> >>> We should rather use the dev ML for this >> >>> thread. >> >>> >>> >> >>> >>> Maybe it's the reason why Anil was reluctant >> >>> to use Dojo? >> >>> >>> >> >>> >>> Jacques >> >>> >>> >> >>> >>> >> >>> >>> Jacques Le Roux wrote: >> >>> >>> >> >>> Sascha Rodekamp wrote: >> >>> >> >>> > Hey, >> >>> > >> >>> > so i started upgrading to dojo 1.4. >> >>> > The good point is ... Dojo 1.4 has >> >>> many really cool new Features which >> >>> > can >> >>> > help us to improve the UI. >> >>> > The Bad thing is, some parts of the >> >>> syntax had changed. That effects many >> >>> > parts in OFBiz (OnePageCheckout, >> >>> Trees, all Dojo features Scripts :-)). >> >>> > >> >>> >> >>> Arg, I did not thought it will be so much >> >>> trouble :/ >> >>> >> >>> So that's a lot of work and i can't do it >> >>> on my own ... who volunteer to >> >>> > help me ;) ?? >> >>> > >> >>> >> >>> I could help >> >>> >> >>> First Step is to collect all depending >> >>> issues and than to fi
Re: Dojo tree 1.4
Hey guys, i started the work to update the Dojo libary to the current version 1.4. And i have to say that it didn't satisfy me to work on every Dojo based JaveScript for a little version update. It will coast a lot of time to test and update all the JavaScript Code. And what we have at the end a new heavy Dojo libary which brings a lot of widget but it's hard to extend :-) So i have another (maybe better idea). Why we didn't set Dojo and Prototype as depricated and starting to use jQuerry. In my optinion jQuerry is a better invest in the future. There are a lot of Widget/ Plugin's too and it's much lighter than Dojo. Instead of spending my time with updating all the Dojo stuff, i could spend my time to migrate all Prototype / Dojo based Code to jQuerry. What do you think? Cheers Sascha 2010/6/5 Anil Patel > Looks like good plan. Overtime people might choose to replace prototype > framework with similar thing from Dojo. > > Thanks and Regards > Anil Patel > HotWax Media Inc > Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" > > On Jun 5, 2010, at 1:13 PM, Jacques Le Roux wrote: > > > So far I have mostly used Dojo for its tree in a CMS tool, and some > Prototype functions notably for layered lookups. > > I still see them as complementary (Dojo coming more complete but heavier, > Prototype being mostly an API). > > I does do think it's necessary to make a choice. > > > > Jacques > > > > From: "Adrian Crum" > >> >From what I recall, the two libraries were included in the project with > the idea that the most popular one would get used. At the > >> >time, Dojo was a very heavy library and the first attempts to use it > resulted in very slow page loads. I used Prototype in some > >> >initial Ajax work - mainly because it was pretty easy to use. Today, I > have no preference for either one. > >> > >> -Adrian > >> > >> --- On Sat, 6/5/10, Anil Patel wrote: > >> > >>> From: Anil Patel > >>> Subject: Re: Dojo tree 1.4 > >>> To: dev@ofbiz.apache.org > >>> Cc: "Anil Patel" > >>> Date: Saturday, June 5, 2010, 7:00 AM > >>> I started using Dojo in Ofbiz long > >>> back and in six months because of issues faced we switched > >>> to using prototype. At that time there were few others in > >>> comunity who liked prototype better. But I really don't > >>> remember the reasons. > >>> > >>> Since then new checkout process was added that uses > >>> prototype for all javascript needs. But did not remove Dojo > >>> because i did not want to upset anybody in community. > >>> > >>> Thanks and Regards > >>> Anil Patel > >>> HotWax Media Inc > >>> Find us on the web at www.hotwaxmedia.com or Google Keyword > >>> "ofbiz" > >>> > >>> On Jun 5, 2010, at 9:47 AM, Jacques Le Roux wrote: > >>> > >>> > I have created a branch > >>> > http://svn.apache.org/repos/asf/ofbiz/branches/dojo1.4 > >>> > Nothing else for now > >>> > > >>> > Jacques > >>> > > >>> > From: "Sascha Rodekamp" > >>> >> Hi Jacques ... > >>> >> jep it's a lot of work but not impossible :) > >>> >> A brunch is a good idea to start working on this > >>> project. I think the reason > >>> >> for Antil was, that he isn't use to Dojo. But that > >>> shouldn't be a problem > >>> >> the syntax isn't complicated. > >>> >> And by the way, if this will work the new Dojo > >>> will bring us a big benefit > >>> >> (in my opinion). > >>> >> Cheers > >>> >> Sascha > >>> >> 2010/6/5 Jacques Le Roux > >>> >>> Sascha, > >>> >>> > >>> >>> We should rather use the dev ML for this > >>> thread. > >>> >>> > >>> >>> Maybe it's the reason why Anil was reluctant > >>> to use Dojo? > >>> >>> > >>> >>> Jacques > >>> >>> > >>> >>> > >>> >>> Jacques Le Roux wrote: > >>> >>> > >>> Sascha Rodekamp wrote: > >>> > >>> > Hey, > >>> > > >>> > so i started upgrading to dojo 1.4. > >>> > The good point is ... Dojo 1.4 has > >>> many really cool new Features which > >>> > can > >>> > help us to improve the UI. > >>> > The Bad thing is, some parts of the > >>> syntax had changed. That effects many > >>> > parts in OFBiz (OnePageCheckout, > >>> Trees, all Dojo features Scripts :-)). > >>> > > >>> > >>> Arg, I did not thought it will be so much > >>> trouble :/ > >>> > >>> So that's a lot of work and i can't do it > >>> on my own ... who volunteer to > >>> > help me ;) ?? > >>> > > >>> > >>> I could help > >>> > >>> First Step is to collect all depending > >>> issues and than to fix them step > >>> > by > >>> > step. > >>> > > >>> > >>> So if we do that we need a branch I > >>> guess... > >>> > >>> Jacques > >>> > >>> Have a nice day > >>> > Sascha > >>> > > >>> > >>> >>> > >>> >> -- >> http://www.lynx.de > >>> >> > >>> > > >>> > >>> > >> > >> > >> > >> > > > > > > -- http://www.lynx.de
[jira] Commented: (OFBIZ-3798) Add generic service to call xml-rpc request
[ https://issues.apache.org/jira/browse/OFBIZ-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876670#action_12876670 ] Nicolas Malin commented on OFBIZ-3798: -- Hi Scott, I already analyse XmlRpcClient to understand how xml-rpc works in OFBiz. To support Https by service definition is in a second step, the first is how make the authentification :). My problem is where I store connexion information ? In service definition, properties by services or service group, in service attribute ? I have a preference for configuration associate to a service group that can do to define a global information for a service list that call the same extern server > Add generic service to call xml-rpc request > --- > > Key: OFBIZ-3798 > URL: https://issues.apache.org/jira/browse/OFBIZ-3798 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Nicolas Malin >Priority: Minor > Fix For: SVN trunk > > Attachments: xml-rpc.diff, XmlRpcEngine.patch > > > I add a generic service to call xml-rpc server. The goal is to have a > technical interface to make calls directly from mini-lang. > The first patch it's my draft. I don't know where I do the service > definition. I add a servicedef in framework/webapp, I move service on > framework/common ? any suggest are welcom ;) > Nicolas -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3798) Add generic service to call xml-rpc request
[ https://issues.apache.org/jira/browse/OFBIZ-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876604#action_12876604 ] Scott Gray commented on OFBIZ-3798: --- It might not hurt to take a look at the existing XmlRpcClient class in OFBiz and see if it helps with https configuration. > Add generic service to call xml-rpc request > --- > > Key: OFBIZ-3798 > URL: https://issues.apache.org/jira/browse/OFBIZ-3798 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Nicolas Malin >Priority: Minor > Fix For: SVN trunk > > Attachments: xml-rpc.diff, XmlRpcEngine.patch > > > I add a generic service to call xml-rpc server. The goal is to have a > technical interface to make calls directly from mini-lang. > The first patch it's my draft. I don't know where I do the service > definition. I add a servicedef in framework/webapp, I move service on > framework/common ? any suggest are welcom ;) > Nicolas -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Shopping list problem in ecommerce component
Hi, The name "New Shopping List" is default name and it is set in "createShoppingList" service in ShoppingListServices.xml check here you see that the value is coming from orderUiLabels.xml if you want to avoid it or want to give your choice name , then just remove the resource & property attribute from the above & set the value you want in the default="abc" attribute. And please ask these types of questions on user mailing list. -- Thanks& Regards: Ankit Jain Enterprise Software Developer Hotwax Media Pvt. Ltd. www.hotwaxmedia.com On Tuesday 08 June 2010 10:43 AM, rrhati2010 wrote: Hi, When I create a new shopping list , every time i click on create new button it creates a new shopping list with same nameHow can I avoid creating shopping list with same name??... Please help. - RRH
[jira] Commented: (OFBIZ-2882) EntityList cache clearing issues when removing generic entity via DelegatorImpl
[ https://issues.apache.org/jira/browse/OFBIZ-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876588#action_12876588 ] Jacques Le Roux commented on OFBIZ-2882: Thanks Bob, Hopefully Adam will get a chance to had a look, else I will try to review at least... > EntityList cache clearing issues when removing generic entity via > DelegatorImpl > --- > > Key: OFBIZ-2882 > URL: https://issues.apache.org/jira/browse/OFBIZ-2882 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Assignee: Adam Heath >Priority: Critical > Attachments: OFBIZ-2882_EntityCacheListFix.patch, > OFBIZ-2882_EntityCacheListFix_V2.patch, OFBIZ-2882_EntityCacheListTest.patch, > OFBIZ-2882_EntityCacheListTest_V2.patch > > > For more information refer to > http://www.nabble.com/EntityList-cache-issues-...-to25179637.html > Ran into some trouble when we turned out caching and started to dependent on > the EntityList cache. The two problems were: > 1) When attempting to storeHook to the entityListCache or entityObjectCache > via the Cache.remove method, the NEW entity was being passed into the OLD > entity. This caused condition matching (in the list cache) to sometimes fail > if a matched entity no longer matches do to it being modified. > 2) During the matching logic the EntityJoinOperator was incorrectly short > circuiting. It was always checking if the lhs/rhs condition was true and if > so returning the short-circuit value. A concrete example is as such -- (A is > funny) && (B is funny). The short-circuit value for this expression is > "FALSE" which means that if the first expression is FALSE we short-circuit > and return FALSE. What was happening was "if (A is funny) then return FALSE" > rather then "if (A is funny == FALSE) then return FALSE". > I have a patch in the works for both of these issues and will include a unit > tester that illustrates the problems (pre-patch) and passes successfully > (post-patch). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3786) First Visit is never been called
[
https://issues.apache.org/jira/browse/OFBIZ-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876569#action_12876569
]
Sascha Rodekamp commented on OFBIZ-3786:
Hi Jacques i'll try to explain what's in my mind
controller.xml specialpurpose/ecommerce
{code:xml}
{code}
The Code in firstVisit is never used, because of the wrong if-statement in the
RequestHandler.
{code}
if (this.trackVisit(request) && session.getAttribute("visit") == null) {
...
}
{code}
session.getAttribute("visit") is never null. It is set in the ControlServlet
before. (VisitHandler.getVisitId(session); )
> First Visit is never been called
>
>
> Key: OFBIZ-3786
> URL: https://issues.apache.org/jira/browse/OFBIZ-3786
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Sascha Rodekamp
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3786_RequestHandler.java.patch
>
>
> I noticed that the first visist element in a controller.xml is never been
> called.
> Here is a proposal patch to solve this issue.
> Now everytime when a session is created, the first visit element will be
> called.
> I don't now if this is the best solution, but maybe we can discuss
> So long
> Sascha
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
