Good point, Derrell. I did some evaluation of the Qooxdoo request code
earlier this week to determine if the parameter list was fixed or
variable, and it looked like the parameters were fixed and predictable.
Your comment gives me comfort that Oracle can handle the set of
parameters in any RPC request without any parameter definition problems.
On a semi-related note, Oracle does provide a method to send variable
argument lists in web requests, but it involves prepending the target
URL with an exclamation "!" character. This causes the web module to
move all request parameters into two arrays for parameter names and
values, which you then define as incoming array parameters in the
request procedure. This provides a work around in Oracle to requests
with unknown parameter lists, and the procedure then needs to parse
through the two arrays to get any parameters as needed. To use this
capability, I could set the Qooxdoo request URL with a leading "!"
character to activate this Oracle modplsql capability, but I don't know
if there are any restrictions against a leading "!" in a Qooxdoo request
URL.
Thanks,
Gene
On Wed, 2009-12-02 at 13:08 -0500, Derrell Lipman wrote:
> On Wed, Dec 2, 2009 at 13:04, Gene Amtower <[email protected]> wrote:
>
> Thanks for the heads-up, Helder.
>
> I do know that the Oracle web interface requires that ALL
> incoming parameters be defined in the procedure spec,
> otherwise it fails to find a matching procedure to
> activate/run. Oracle provides the ability to overload the
> same procedure name with different parameter lists/types, and
> this gets in the way when it can't determine the appropriate
> overloaded procedure based on incoming parameters in the
> request. So, it might have been as easy as making sure the
> no-cache parameter was included in the procedure parameter
> list. Unfortunately, it makes server development a bit
> trickier than PHP coding, where you can define any parameters
> in the request, whether they get used in the PHP code or not.
>
>
>
> This was the reason I proposed recently removing the getParams()
> method as a conformance requirement in RpcExample's test suite. I just
> wrote a Java backend that has exactly the same issue you discovered. I
> wanted to pass the parameters individually to the remote method, and I
> don't know of a way in Java to handle variable argument lists. That
> feature is not necessary for the purposes of generic JSON-RPC, and I
> don't believe it should be mandated by our conformance test suite.
>
> Derrell
>
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________ qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
