Forum OpenACS Development: Re: TWiST OpenACS package

Collapse
Posted by Claudio Pasolini on
Hi Tom,

I'm trying to build a TWiST service using the new API that you provided to deal with complex types and I've posted for reference the code at http://demo01.vestasoft.com:8001/twistsample.txt and the responses at http://demo01.vestasoft.com:8001/twistresponses.txt or you can try them live at http://demo01.vestasoft.com:8001/twist/ws/parties

The first operation parties::PartiesQuery mimicks your stock2::Stocks example and returns the complex type parties::OneParty made up of a fiew simple types. Actually, given an input request that specifies a party type, the operation queries a table and returns some attributes for every party of the given type.

With the second operation parties::PartiesQuery2 I'd like to return the complex type parties::Result made up of the simple type parties::partiesNumber, wich holds the number of parties retrieved, and the already existing complex type parties::OneParty.

The response contains only the first party of the list, ignoring the others and I don't understand if this depends from the way I constructed the returnList within the proc or from some other reasons.

I tried several variations, one of wich is parties::PartiesQuery3 where I built the resultList in a
different way, but then the system complains about "Missing value for required Element CreationDate with no default value calling ::namespace inscope
::wsdb::elements::parties::OneParty::CreationDate new".

What I'd like to do next is to create a service that accepts a parties::Parties complex type made up of a sequence of
parties:OneParty and returns a list of party_id after creating them. Do you think that this is possible with TWiST? I tried to define {OneParty:elements::parties::OneParty} as the argument of the proc, but the system complains about not finding the corresponding ::validate proc.

A last question about the automatically generated names of the Request and Response elements: do you think that they could be parameterized?

TIA,
Claudio

Collapse
Posted by Tom Jackson on
Claudio,

You want to return a list, the first element of the list is your first child element partiesNumber, the second element of the list is your list of parties:

    return [list $partiesNumber $partiesList]

Also, on your return type, you have two colons after the name, I haven't checked if this matters or not, or if it should matter or not:

{PartiesNumber::parties::partiesNumber}

About parameterizing the names of the request and response elements: yes this needs to be dealt with. There is a slightly larger problem to fix or clarify in this area, I think the issue is that you can pre-create request/response types if you name them ${procName}Request and ${procName}Response, but by pre-creating them, they are not again created when you use <ws>proc, although you can do things like change the default value from what was specified in the complexType. In tWSDL, you can name simpleTypes, complexTypes, messages, operations, ports, etc. all with the same name without any problem. However, it is sometimes confusing to track down errors if you don't put a trailing chunk of text which helps identify what the name applies to.

Anyway, I had thought of parameterizing these, and I believe I put some namespace variables in the <ws>namespace to use, but then I didn't use them. So I'll look at that to see if it can be quickly fixed.

Collapse
Posted by Tom Jackson on
BTW, after considering the potential complexity handling inputs of greater depth than list_of_lists, or more complex outputs, I think the next addition to TWiST will be <ws>operation. This will allow the developer direct access to writing the 'Invoke' command for the operation, which takes an inputXMLNS (where to find the input document) and fills an outputXMLNS (with the return document), and returns a reference to the documentElement. You could use this, for instance, to send all the data for an invoice and process the different complexTypes involved in a single transaction. (You can do this now by writing a proc and setting a variable pointing to it, but not using the TWiST API.)
Collapse
Posted by Tom Jackson on
Claudio,

The new version of TWiST is 0.9.5, hopefully if you are using the OpenACS wrapper, you can update by changing the version number and restarting OpenACS. The older version will remain in place, and you can switch back if you find a bug.

Here is what the new version adds: with <ws>proc, the ability to use a complexType element name in place of the procArgsList and/or the returnList.

Example (from stockquoter):

# Create input element complexType
<ws>element sequence stock::StocksToQuote {
    {Symbol:stockquoter::symbol {maxOccurs 8 default "MSFT"}}
    {Verbose:stockquoter::verbose {minOccurs 0 default "1"}}
}

# Create output element complexType <ws>element sequence stock::StocksQuoted { {StockResponse:elements::stock::StockResponse {maxOccurs 8}} }

# Use complexType element name in place of lists <ws>proc ::stock::Stocks { StocksToQuote } { set resultList [list] foreach symbol $Symbol { lappend resultList [Stock $symbol $Verbose] } return $resultList } returns StocksQuoted

The result is that the user now has control of the names of the input and output elements.

Collapse
Posted by Claudio Pasolini on
Tom,

the upgrade to version 0.9.5 worked very well and the ability to use an arbitrary complexType element name as input/output of the procs is very useful.

For a number of simple web services this is enough, while as you already pointed out we need something as the announced <ws>operation to deal with more complex cases.