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. >>>
smime.p7s
Description: S/MIME Cryptographic Signature
