Leon, check out https://issues.apache.org/jira/browse/OFBIZ-510 -
there's a VERY useful implementation up there and ready for review.
This piece makes the anonymous checkout process usable - in my opinion.
We don't actually need this piece for what we're doing at the moment
since our customer only accepts credit cards for payment, but since
I'm not in habit of just breaking other people's stuff and I don't
really want to maintain tons of mods (other than straight custom
work) outside of the OFBiz trunk, we took the time to do this.
Please everyone take a look at this and let's get this initial AJAX
direction decided upon sometime soon. We are building tons of apps
based on a JSON / Dojo approach right now and would love for this to
be adopted or know a good reason to change direction to something
else. We're happy to do that if that's what we all decide.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6594
On Dec 13, 2006, at 8:39 PM, 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.
