Re: [Quickfixj-users] repeating group problem

[Oren M. <or...@qu...>]

Yeah, I would recommend adopting the same practice as the C++ engine  
of placing the delimiter first no matter what.  For all practical  
purposes, this is all you really need.  The spec does specify that  
all fields must be in a certain order, but most implementations,  
QuickFIX included, do not care as long as the delimiter is in the  
right place.  Despite this, your recommendation of using the  
generated group is the best way to go.

Dynamically creating groups based on the DataDictionary is an  
interesting idea.  What do you think of flipping it around a little  
and turning the DataDictionary into a kind of factory.  I'm thinking:

Group group = dataDictionary.createGroup( "X", NoPartyIDs.FIELD )

Then you can even add createMessage( "X" ), and createField methods.   
Could be useful for some use cases that require more dynamic  
capabilities.

--oren

On Nov 3, 2006, at 8:49 PM, Steve Bate wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Alvin,
>
> I recommend using the NewOrderSingle.NoPartyIDs rather than the
> generic Group. The C++ code does create an ordering for the delimeter
> field using the constructor you're using and QFJ does not. We can
> change tnat behavior to be consistent with the C++ constructor but
> this usage of the generic Group will be dangerous to use in both C+ 
> + and
> QFJ. The C++ code happens to order the non-delimeter fields in key  
> order,
> which are tag numbers in this case. You are fortunate to have two
> non-delimeter tags where the tag number ordering and the group field
> ordering are the same. In general, you probably wouldn't be so lucky
> since the ordering of the non-delimeter fields is undefined from an
> API perspective when using this Group constructor.
>
> If users want to create a generic Group rather than using the
> message-specific groups we should probably create a constructor that
> takes a group field tag number and a data dictionary and let the
> constructor build the correct ordering criteria and determine the
> delimeter field from the dictionary. It seems safer.
>
> Oren, any comments?
>
> Steve