json + prototype + ajax?
Locked
123
123
Re: json + prototype + ajax?
 
|
Re: json + prototype + ajax?
|
|
Re: json + prototype + ajax?
|
|
Re: json + prototype + ajax?
|
|
In reply to this post by Anil Patel-2
Nice, I like...
Anil Patel wrote: > 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). > > I have used this pattern with screen/ftl for generating html on demand. > > Regards > > > On 12/13/06, A. Zeneski <[hidden email]> 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 <[hidden email]> 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 (4K)
Re: json + prototype + ajax?
|
|
In reply to this post by David E Jones-2
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 <[hidden email]> 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 >>>>>> >>> >>> > |
Re: json + prototype + ajax?
|
|
In reply to this post by Ean Schuessler
Ean,
When I implemented a test case using the new JSON service event handler I found that the requests behaved just like any other HTTP request. The security part is transparent, you require auth (but not HTTPS) for events which will be Ajax-Enabled. This uses the user login object found in the session (due to the fact that the url for the Ajax request is wrapped around <@ofbizUrl> tags) and the service engine handles the security. For screen based (non-JSON) responses, I think the security handling should be up to the page returned, just like any other page in OFBiz. Thoughts? Andrew Ean Schuessler wrote: > On Wednesday 13 December 2006 19:21, David E Jones wrote: >> 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... > > We've had a few discussions going on over here about how to handle AJAX > integration while still keeping security in mind. It seems like providing a > limited dispatcher that only allows certain groups of services to be invoked > is a good thing. Lots of services are already userLogin and Role protected, > which is a good headstart. Maybe a specific AJAX dispatcher that has only > services which are already vetted exposed through it? > > It would also be nice to have a high level facility for invoking those > services and then triggering their results to something like the Dojo event > framework when they return. With something like Comet these events could even > be initiated by the server as if you had made a call on the client and then > the delivery events occured. > |
Re: json + prototype + ajax?
|
|
Re: json + prototype + ajax?
|
|
Re: json + prototype + ajax?
|
|
In reply to this post by Leon Torres-2
Leon,
The JSON wrapper is for one purpose, to return service results in a lightweight compressed format for use by the Ajax javascript toolkit. This rather than XML is faster and more efficient as well as supported by all the toolkits I have see so far. This is only useful when you are looking to get specific values from a service call; and allows you to call existing services in your Ajax front end. One really nice way to use this would be for a simple upload widget. Call the service directly through a request event and have the results returned in an object ready for javascript to work with. This also uses the internal service security methods for authentication and validation. I think its a real clean way to integrate. I will try to put together a simple example and check it into one of the components, I will let you know when it is there. The other side is pulling in pre-formatted HTML. When doing this the HTML fragments should be configurable at least as much as the current templates are configurable. I like the idea of using screen definitions and FTL to generate this. Actually, this can be used for most things; but why when all you need to get back is an ID or some raw data. I think using a combination of these two methods (with any Ajax toolkit) is a great start. Andrew Leon Torres wrote: > I'd like to request before any votes go out that we see an actual > implementation of something useful in JSON and Dojo. I'm concerned that > this approach is not lightweight enough for certain needs. > > First, it needs to support functionality that have a high rate of > requests, such as autocomplete. This is critical. > > Second, the OFBiz AJAX system needs to be shallow and malleable. By > shallow, I mean it should not have too many layers of complexity, > abstraction or indirection. By malleable, I mean it should be easy to > customize and build new effects or features for. Without these traits, > it becomes difficult to develop and debug custom Ajax features. > > The reason I went with prototype was because of how easy it was to > implement autocomplete in the form widget: It takes just two dozen > lines of Javascript, some standard HTML form elements, and a standard > Servlet method to process the autocomplete. And the requests are very > fast, using the "ftl" handler. No special magic was required, just to > load the required .js libraries. > > But this talk about having to write a JSON service event handler > concerns me. If someone could demonstrate that it will be just as simple > and straightforward, that would be great. > > - Leon > > > > A. Zeneski wrote: >> Ean, >> >> When I implemented a test case using the new JSON service event handler >> I found that the requests behaved just like any other HTTP request. The >> security part is transparent, you require auth (but not HTTPS) for >> events which will be Ajax-Enabled. This uses the user login object found >> in the session (due to the fact that the url for the Ajax request is >> wrapped around <@ofbizUrl> tags) and the service engine handles the >> security. >> >> For screen based (non-JSON) responses, I think the security handling >> should be up to the page returned, just like any other page in OFBiz. >> >> Thoughts? >> >> Andrew >> >> Ean Schuessler wrote: >>> On Wednesday 13 December 2006 19:21, David E Jones wrote: >>>> 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... >>> We've had a few discussions going on over here about how to handle >>> AJAX integration while still keeping security in mind. It seems like >>> providing a limited dispatcher that only allows certain groups of >>> services to be invoked is a good thing. Lots of services are already >>> userLogin and Role protected, which is a good headstart. Maybe a >>> specific AJAX dispatcher that has only services which are already >>> vetted exposed through it? >>> >>> It would also be nice to have a high level facility for invoking >>> those services and then triggering their results to something like >>> the Dojo event framework when they return. With something like Comet >>> these events could even be initiated by the server as if you had made >>> a call on the client and then the delivery events occured. >>> |
Re: json + prototype + ajax?
|
|
Re: json + prototype + ajax?
Administrator
|
Re: json + prototype + ajax?
|
|
Re: json + prototype + ajax?
|
|
Re: json + prototype + ajax?
|
Administrator
|
Re: json + prototype + ajax?
|
Administrator
|
Re: json + prototype + ajax?
|
|
Re: json + prototype + ajax?
|
Administrator
|
Re: json + prototype + ajax?
|
|
Re: json + prototype + ajax?
|
|
Re: json + prototype + ajax?
|
|
| Free forum by Nabble | Edit this page |