Tim Ansell pisze: >> The difference between these two branches is that they represent the same >> thing using different means: the former uses an expression parseable by >> regular expressions, the latter uses XML structures, which is more >> consistent with the rest of the document (but much more verbose). > > Can you please explain the XML structures format? I would definitely > prefer to keep it as XML as possible.
I thought so :)
I'm a little bit rusty, but here goes...
The DTD says:
<!ELEMENT useparameters (name, longname, description?, typefield, typeframe?) >
<!--
useparameters/typefield and useparameters/typeframe
are used to describe how to get parameter ids from
an "indirect" frame; lack of typeframe means that the
parameter is embedded directly and no extra frame is
necessary.
-->
<!ATTLIST useparameters ref IDREF #REQUIRED >
<!ELEMENT typefield (#PCDATA) >
<!ELEMENT typeframe ((getfield | getlist)) >
<!ATTLIST typeframe name IDREF #REQUIRED idfield CDATA #REQUIRED >
<!ELEMENT getfield ((getfield | getlist)?) >
<!ATTLIST getfield name CDATA #REQUIRED >
<!ELEMENT getlist ((getfield | getlist)?) >
<!ATTLIST getlist name CDATA #REQUIRED >
I added two subelements to useparameters: typefield (mandatory) and
typeframe (optional). The presence of typeframe element determines if the
parameter's data can be extracted directly from the frame or another frame
is needed.
If the parameter ID is "local", the field pointed to by typefield element
contains the parameter ID and decoding of the frame is straightforward: just
use the ID to decode the parameter. I modified Object frame in protocol3.xml
to use "parameters" for object types:
<packet base="Response" name="Object" id="7">
...
<structure>
...
<integer type="unsigned" size="32">
<name>otype</name>
<longname>Object Type</longname>
<description>The type of the object.</description>
<subtype />
</integer>
...
<useparameters ref="ObjectParams">
<name>object</name>
<longname>the objet's data</longname>
<typefield>otype</typefield>
</useparameters>
</structure>
...
</packet>
This gets turned to something like this:
//direct: just read this sucker
this.object=ObjectParams.create(this.otype, in);
If the parameters are "indirect", that is the parameter descriptions are
contained in another frame, the useparameters element must describe how to
get the actual parameter ID. The field pointed to by typefield element
contains the parameter description ID. The getfield and getlist elements
describe the frame traversal:
<packet id="11" base="Response" name="Order">
...
<structure>
...
<integer type="unsigned" size="32">
<name>otype</name>
<longname>Order Type ID</longname>
<subtype />
</integer>
...
<useparameters ref="OrderParams">
<name>orderparams</name>
<longname>the order's parameter</longname>
<!-- parameter description ID -->
<typefield>otype</typefield>
<!-- the indirect frame name and its
description ID field -->
<typeframe name="OrderDesc" idfield="id">
<getlist name="parameters">
<getfield name="type"/>
</getlist>
</typeframe>
</useparameters>
</structure>
...
</packet>
While decoding a frame, the parameters' data are stored in a byte array.
This data are actually decoded in the getter, with some user's help:
// you have to pass the OrderDesc frame object decoded separately
public List<OrderParams> getOrderparams(OrderDesc template)
{
// <typefield>otype</typefield> and
// <typeframe name="OrderDesc" idfield="id"> :
if (template.getId() != getOtype())
throw new TPException(...);
TPDataInput in=new TPInputStream(
new java.io.ByteArrayInputStream(
this.orderparams));
List<OrderParams> ret=new ArrayList<OrderParams>();
// <getlist name="parameters"> :
for (OrderDesc.ParametersType template0 : template.getParameters())
{
// <getfield name="type"/> :
ret.add(OrderParams.create(template0.getType(), in));
}
return ret;
}
I hope that's the way to do that :)
> I've been looking at the thread where you explain the regex parsable
> bits and I think I'm beginning to understand what it does (I'm still a
> little fuzzy).
>
> Basically, the problem you are trying to solve is how to map the
> describable bits to the things they describe? This is a little bit
> complicated because there are two levels of indirection (the objects are
> described by object descriptions which are made up of the stuff describe
> in the XML).
Yes... Actually only parameters :)
--
Ecce Jezuch
"I'm the scum of the Earth, I'm the scum of the Earth,
I am the cancer, I am humanity" - R. Patrick
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
