Denis Souza wrote:
for it. My suggestion here is that service parameters each have aI'm fighting that one as I write and although it's a solvable problem, I can't help feeling like it's an unnecesairly complication.
(user-defined) name so you can pass the parameters in whichever order you
want and still be sure you're not breaking anything at the receiving end. It
would also help when integrating to external services that insist on passing
URL parameters with names you have no control over. Eg. An integration with
another web site (such as an online payment system) might call your URL with
a "transaction-id" parameter (and maybe other additional parameters whose
names you can't control).
Basically, every time I need to interface a tapestry app with another application I hit some kind of a wall: the last time the problem was not beeing able to force <input> field names or values so that when the form submits, the non tappestry web app receives the data it expects. Also a solvable problem, but it gives me a feeling of waltzing through a mine field whenever I need to interface with something else. :(
-- Tomislav Nakic-Alfirevic Netgen Ltd. www.netgen.hr Rudeska 172/3 10000 Zagreb, Croatia tel.: +385 1 387 97 22 fax.: +385 1 387 97 24
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
