Re: [Quickfixj-users] repeating group problem

[Brad H. <Bra...@gb...>]

Hi,

Perhaps part of the problem is that the User Manual has some notes on
type safety and strongly encourages you to use the "Most Type Safe"
method of doing things which relies on the generated classes.  As you
say, to support multiple FIX versions you can't really do that - you
have to use the "More Type Safe" (or lower) method.

This means the message cracker isn't very useful for receiving messages
- if you want common code for each version you'll be casting back to
quickfix.Message anyway.  We don't use the message cracker in our
quickfix/j app, but rather code like this:

	Header header =3D message.getHeader();
	String msgType =3D header.getString(MsgType.FIELD);
	if (MsgType.EXECUTION_REPORT.equals(msgType)) {
		if (message.isSetField(ExecType.FIELD)) {
			String executionType =3D
message.getString(ExecType.FIELD);
      ....

>From memory the message cracker does something similar to switch on
version/message type anyway and then just casts to the appropriate type.


What this doesn't give you is any compile time validation/auto complete
for what fields are in your message, but use of the fields names at
least gives you readability.  Good unit tests on your domain <->
quickfix mapping can help make up for the loss of compile time safety.

Unfortunately you pretty much have to use the generated group classes
for repeating groups.  I think the factory approach discussed earlier
would be a good compromise, and the underlying implementation (inner
classes vs component objects or whatever) wouldn't really matter.=20

Cheers,
Brad.

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of Oren
Miller
Sent: Friday, 10 November 2006 8:40 AM
To: qui...@li...
Subject: Re: [Quickfixj-users] repeating group problem

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Isn't the session code already decoupled from the generated message =20
code?  It has been that way with QuickFIX since the beginning.  Is =20
this different in QuickFIX/J?

The purpose of the generated classes is to allow you to add a certain =20
level of type safety by taking advantage of the compilers type =20
system.  If you are are writing code that supports multiple versions =20
(is there a reason for this?  Are you using the fix messages as your =20
domain objects instead of converting them at the edge of your =20
system?), you do not want type safety.  I'm not sure it really makes =20
sense.  At least in QuickFIX, the Session class is an example of an =20
object that supports multiple versions of fix which does not make use =20
of type safety.  No generated message classes are used anywhere in =20
there.

If you are trying to write code blocks to support multiple versions, =20
you should be working directly with the Message class.  I'm not sure =20
how the generated objects help you at all since type safety is not =20
something you desire in this case.  Is there something I'm missing?

--oren