Re: [Quickfix-developers] Component blocks

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

This goes back to the original implementation of QuickFIX.  We looked at 
implementing component blocks in an OO manner when first implementing 
support for them.  The current implementation allowed us to get support 
in with very little work and almost no changes to the code (as well as 
no changes to the java/.net wrappers).  So it won out by getting us 
there quicker without being very invasive.  It certainly would be 
worthwhile revisiting components to make their use better reflect the 
object model defined by the specification.

The easiest first step would be to generate component objects.  That 
would at least give us the ability to pass them around to methods even 
if we have to fill them up manually from the message.  After that we can 
look at generating methods which would set/get the appropriate fields 
for those components with a getComponent/setComponent method.

--oren

Shepheard, Toby (London) wrote:

> I make it look a bit worse than it is - fieldMap.getField can of 
> course take a TransactTime object rather than the base type, which 
> protects it against data dictionary changes and the need to know the 
> base type.
>  
> Still, the question around using component blocks in an OO manner 
> remains :)
>
>     -----Original Message-----
>     *From:* qui...@li...
>     [mailto:qui...@li...] *On
>     Behalf Of *Shepheard, Toby (London)
>     *Sent:* 18 January 2006 14:52
>     *To:* qui...@li...
>     *Subject:* [Quickfix-developers] Component blocks
>
>     Hi all,
>
>     I'm using QuickFIX/J, though I think this may be applicable to the
>     other implementations I'm not sure.
>
>     What I'd like to do is write some helper methods to carry out
>     certain common actions based on component blocks. A typical
>     example would be the Instrument block, which appears in a number
>     of guises:
>
>     QuoteRequest message - here it is part of a repeating group,
>     NoRelatedSym.
>     NewOrderSingle message - here it is part of the main
>     NewOrderSingle message
>
>     I'd love to be able to pass in an "Instrument" object to a method
>     and do my thing with it, but there doesn't seem to be any such
>     object. Indeed, the only way I could find to extract Instrument
>     data from a common base class was to treat is as a FieldMap
>     object, which covers both Group and Message types. This seems to
>     mean using a format such as
>
>     fieldMap.getField(new UtcTimeStampField(TransactTime.FIELD)
>
>     Which is not very type-safe, as I'm just assuming the fieldMap
>     will have the Instrument block's fields, and is liable to break if
>     anything changes in the underlying data-dictionary. Is there a
>     better way to do this that is type-safe and reusable, regardless
>     of the underlying fieldMap type that the instrument block is a
>     part of? I realise component blocks have no "real" meaning, but
>     they do provide a common, logical construct that it seems  shame I
>     can't leverage in a nice OO way, especially considering the data
>     dictionary contains all the required data for generating such
>     objects. If I am missing something, please let me know :)
>
>     Regards,
>     Toby
>
> If you are not an intended recipient of this e-mail, please notify the 
> sender, delete it and do not read, act upon, print, disclose, copy, 
> retain or redistribute it. Click here 
> <http://www.ml.com/email_terms/>for important additional terms 
> relating to this e-mail.     http://www.ml.com/email_terms/