patch with changes and unit test

Hi Toli,

I think it's a good idea.

I'd potentially use a convenience method which takes a Message instance instead of beginString and msgType. Which actually makes me wonder, can the generated Message classes have a method to create the groups instead?

/**

• Creates the group and adds it to the message
• Example: if you have a Message instance that is a quickfix.fix42.MarketDataRequest and you
• want to create a {@link quickfix.fix42.MarketDataRequest.NoMDEntryTypes}
• you need to call
• createAndAddGroup( {@link quickfix.field.NoMDEntryTypes#FIELD}

  )

• @param fieldIdOfGroup the field Id of the field in the group.
• @return the newly added group
  */
  public Group createAndAddGroup(int fieldIdOfGroup);

Message quoteRequest = messageFactory.create("FIX.4.4", MsgType.QUOTE_REQUEST);
Group noRelatedSym = quoteRequest.createAndAddGroup(NoRelatedSym.FIELD);

Unfortunately you'd need a default implementation for Message which throws some type of error, which may be a good reason not to do it this way.

Additionally/alternatively, each message could have a specific createGroup method for its groups. Eg

QuoteRequest quoteRequest = new QuoteRequest();
Group group = quoteRequest.createAndAddGroupNoRelatedSym();

Not sure if adding as well as creating is a good idea, and of course the method names are horrible but you get the picture.

Cheers,
Brad.

Brad,

What you are suggesting in the first part is a good idea, to have
Message quoteRequest = messageFactory.create("FIX.4.4", MsgType.QUOTE_REQUEST);
Group noRelatedSym = quoteRequest.createAndAddGroup(NoRelatedSym.FIELD);

think that'd be a pretty convenient method.

I'm not sure about having a create function for each specific group - I think it'd be very unwieldy to have all these special-named functions, it'll quickly get cluttered and confusing.

Steve, any thoughts? It'd definitely making generating each individual Message subclass more complicated, it'd have to know about which groups it has, but it's not impossible. and maybe "cleaner" than enumerating all the possible groups in the factory code.

thoughts?

Fix checked in revision 605.
The implementation is the original proposal of having a "create" function that returns a Group:

    /**
     * Creates a group for the specified parent message type and
     * for the fields with the corresponding field ID
     *
     * Example: to create a {@link quickfix.fix42.MarketDataRequest.NoMDEntryTypes}
     * you need to call
     *       create({@link quickfix.field.MsgType#MARKET_DATA_REQUEST, {@link quickfix.field.NoMDEntryTypes#FIELD}) 
     *
     * Function returns null if the group cannot be created.
     * @param beginString
     *            the FIX version (for example, "FIX.4.2")
     * @param msgType   Message type of the enclosing message
     * @param correspondingFieldID  the fieldID of the field in the group
     * @return  group, or null if the group can't be created.
     */
    public Group create(String beginString, String msgType, int correspondingFieldID);