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.
