[OpenAjaxIDE] OAA IDE WG Minutes 2007-08-23

Jon Ferraiolo jferrai at us.ibm.com
Sun Sep 2 15:19:23 PDT 2007


Hi Manos,
I have been on vacation this past week and am now catching up on some of my
email. It appears no one has responded to you, so I will do my best.
Responses are prefixed by [JON].

Hello all,

Short introduction: I'm with Abiss.gr, our focus here is to keep Sarissa
[1] as compatible with your efforts as possible.

My comments/questions must be rather basic or even naive since i have
missed all the effort spent here, but any answers would be really
helpful in keeping up with you :-)

A) Suppose my library has a function that provides an AJAX route for an
(X)HTML form submission (if all required features are available), how
do i describe that for an IDE?

[JON] I am not quite sure about what you mean by "AJAX route for ... form
submission", but I think I can answer anyway. It looks to me like our
requirements are primarily focused on low-level client-side things such as
JavaScript methods (e.g., arguments and return values) and pre-built UI
controls (e.g., list of properties that show up in an inspector palette). I
don't remember any requirements having to do with Ajax requests at all, let
alone particular types of Ajax requests. This is probably because the
workflows which we are focused on in the IDE group tend to make use of
direct calls to XMLHttpRequest or invoke an Ajax library that has a thin
layer on top of XMLHttpRequest, with some of the IDEs offering
XMLHttpRequest monitor palettes where the developer can see what was sent
up and what was sent back down.

[JON] So, in a best attempt to answer to your question "how do I describe
that for an IDE", the answer is that you would describe your JavaScript
function within the XML metadata file, where the XML specifies the
arguments and return values and includes a textual description of what the
function does.

B) Similarly, how do i make a content replacement function known to an
IDE?

[JON] Ditto: your XML metadata file would specify the arguments and return
values and includes a textual description of what the function does.

C) Sarissa is client side only. Is there a way to describe server side
requirements for HTTP request handlers, so that AJAX and fall back
non-AJAX requests can be handled as appropriate by different server
side implementations?

[JON] I think this is out of scope for the current IDE effort. We probably
would need a "Server Working Group" to address this requirement. So far, we
don't have such a Server Working Group.

[JON] But putting aside OpenAjax Alliance process concerns, my instant
reaction is that it will prove difficult to get the server world (a mixture
of Java (JSF, Struts, ...), .NET, PHP, Ruby, Perl, Python, CGI, and others)
to adopt the same fallback strategy. However, maybe you have something in
mind that you want to propose. If you think it might be interesting and
appropriate for the face-to-face meeting on Sept. 27, let's talk offline
about how we might discuss this at the face-to-face meeting.

D) Sorry if I'm out of line here but could the IDE effort actually be
useful/applied, besides IDEs, on server side technologies such as JSF
or whatnot?

[JON] We actually have a couple of requirements about leveraging the IDE
effort for server-side issues. See
http://www.openajax.org/member/wiki/IDE/requirements#Server_framework_integration.
 We have talked of various occasions about attempting to allow leverage for
server-side scenarios, but we concluded that we need to start making
progress on the spec before we could take a step back and evaluate our work
against server requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20070902/2dd77259/attachment.html 


More information about the IDE mailing list