Don't get me wrong, I'm not trying to limit us by any means. However, there are currently a number of efforts going on in which Ajax will be used to enhance or update various pieces of the open source project. I for one would like to see an Ajax based packing screen go in the near future as well.
What I mean by #1 priority, is to decide how we will standardize this [for now] during the first wave of development. If we have a handful of people all using different tools, we'll end up with a mess. To compare, we don't have some screens using Velocity and others using Freemarker, we have a standard for this. Even though Velocity is supported and people can use it in the custom solutions. Freemarker is standard for the open source contributions. Before we start getting patches from people, I think we need standards. This will save a lot of review time in the future. Andrew David E Jones wrote: > > Consistency is good, but I wouldn't say that's our #1 priority. We > definitely want primary and secondary best practices like we do with > other things, but also want to support a variety of technologies on the > framework level. In other words, if people want to do stuff in their own > code bases we don't want to block that, but yes for anything going into > the project it should follow a consistent set of patterns so that people > exploring the code for the first time will have a stream of "okay, okay, > okay, ..." going through their heads instead of a stream of "wtf, wtf, > wtf, ...". > > On an important but less pleasant note: the AJAX stuff we are dealing > with is very new in OFBiz, and outside of OFBiz the "market" is still > maturing quite a lot. I agree we should perhaps vote on a best practice, > though in general I'd rather see X task implemented with DOJO required > so much effort and with Prototype so much effort. What I mean to say is > that we should definitely decide on a best practice now and it sounds > like most of the consensus is around JSON+DOJO, but we shouldn't be > surprised if something much better comes up at some point in the future. > > BTW, as to how I see AJAX stuff fitting into OFBiz there are 2 big parts: > > 1. adding dynamic client side features to the form and screen (and > other) widgets for things like dynamic lookups, expanding tree-browsers, > movable screen-lets, etc. > > 2. special purpose pages that are meant to optimize a certain task, like > the checkout stuff Tim mentioned, but probably even moreso for fancy > back-end stuff > > For #1 replacing an AJAX framework is easy, but doesn't make as big a > different in coding efficiency or anything, whereas for #2 something > better would make coding easier, but require more rewriting... > > -David > > > On Dec 13, 2006, at 4:53 PM, A. Zeneski wrote: > >> I am curious as to the pattern used to make the async calls, what method >> of return is used here? >> >> I see two possible patterns which would be useful: >> >> 1) JSON compressed objects. This will require more processing on the >> front end to pull the data and format the HTML. I like leaving this in >> the front end code personally. This is currently implemented using the >> JSONServiceEventHandler request handler. >> >> 2) Screen Widget based HTML return. The Ajax request makes a simple call >> which returns a HTML fragment (developed using screen widgets). The >> return is then just plugged in by updating the element content >> (innerHTML). >> >> Either of these patterns is fine by me, and I believe that for most >> applications a combination of the two would be necessary. >> >> I am sure there are many other ways to accomplish the same thing, but >> since there is so much effort about to begin around 'Ajaxing' OFBiz >> making sure things are consistent is #1 priority. >> >> I'm curious as to what other 'patterns' people have come up with (if >> any). >> >> Andrew >> >> >> Tim Ruppert wrote: >>> Just to continue the push towards Dojo, I am about to submit a new >>> Anonymous Checkout process for >>> https://issues.apache.org/jira/browse/OFBIZ-510 which is based upon >>> Dojo. You guys will like it - 3 steps and working towards my 2 step >>> process goal. >>> >>> Cheers, >>> Tim >>> --Tim Ruppert >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> o:801.649.6594 >>> f:801.649.6594 >>> >>> >>> On Dec 13, 2006, at 4:36 PM, A. Zeneski wrote: >>> >>>> I used prototype for my initial test and found it very easy to work >>>> with. Dojo on the other hand seemed to have a much broader learning >>>> curve. It too me a while to get everything working, but I think it is >>>> due to the ajax part being more verbose. >>>> >>>> The extra features such as DND and other widgets is very nice as well. >>>> >>>> The fact that DOJO is available under the BSD license is a plus as >>>> well. >>>> I think there should be no license issues with this library. >>>> >>>> Should we just say DOJO is the way to go for future Ajax based tools in >>>> OFBiz or do we need a formal vote? >>>> >>>> Andrew >>>> >>>> Alex D. Fleming wrote: >>>>> Hi, >>>>> >>>>> Ooops Dojo is supported by IBM & AOL ....so I will prefer Dojo. >>>>> >>>>> http://dojotoolkit.org/foundation/ >>>>> >>>>> >>>>> On 12/14/06, A. Zeneski <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> Si (& all), >>>>>> >>>>>> I am in process of doing a lot of custom AJAX stuff for a new >>>>>> client. I >>>>>> intended on using prototype.js but based on conversations with other >>>>>> people decided to go with dojo instead. >>>>>> >>>>>> The main part of what I did was a JSON wrapper around the service >>>>>> event >>>>>> handler. What this does is allows you to define (controller) requests >>>>>> for ajax calls and have the results return in a lightweight (JSON) >>>>>> format. >>>>>> >>>>>> This will work with any front end toolkit (Yahoo, Prototype, Dojo, >>>>>> etc). >>>>>> The main point is to define a standard pattern for AJAX requests in >>>>>> OFBiz. >>>>>> >>>>>> Deciding on a toolkit for the javascript is very important and >>>>>> based on >>>>>> what I have researched and discussed with other people, Dojo seems >>>>>> to be >>>>>> the way to go. >>>>>> >>>>>> Of course, I am open for discussion with this, but we really should >>>>>> decide on a standard for contributions back to OFBiz. The last >>>>>> thing I >>>>>> want to see is several different ways of communication and different >>>>>> toolkits being used. >>>>>> >>>>>> Prototype.js has been removed from SVN for the time being. As soon as >>>>>> there is code which uses one of the toolkits it can be added back in. >>>>>> >>>>>> Let's start a community vote for the default AJAX toolkit to use in >>>>>> OFBiz. Based on the work I did, I have already setup the back end >>>>>> pattern, services using JSON for the return. Now let's decide on a >>>>>> front >>>>>> end toolkit. >>>>>> >>>>>> First lets, define the candidates: >>>>>> >>>>>> 1) Dojo >>>>>> 2) Prototype >>>>>> >>>>>> Andy >>>>>> >>> >>> >
smime.p7s
Description: S/MIME Cryptographic Signature
