|
From: <st...@te...> - 2006-11-08 17:02:54
|
Hi Alvin, I understand and I tend to agree. However, I'd like to hear Oren's comments on these issues. The core QFJ API is based on the QF API and it's our goal to keep them compatible when moving from QF to QFJ. That said, one of the features being planned for a post 1.1.0 release is to completely decouple the session protocol engine from the generated message/field code. This will give increased flexibility for packaging and using custom message representations although they must still be based on quickfix.Message. For example, we intend to provide a message representation that uses BigDecimal for prices and other values that need precise representations. My long term vision is to redesign the parsing engine to allow mapping of FIX messages directly to POJOs that aren't required to inherit from quickfix.Message at all. I'm not sure when I'll have time to do that since QFJ is a spare time project for me. ;-) Steve > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > I understand that the classes are generated automatically from XML. But I > feel it may be better to have some optimization and abstractions. This > will > greatly improve code reusibility and flexibility, for example codes > handling different order messages and even different FIX versions. How to > easily maintain the code base when we need to handle different versions of > FIX is always our concern by using QF or QF/J. Right now, the message > classes are bounded with FIX version. Any insights? > > Just my 2 cents > > > > > "Steve Bate" > <steve@technoetic > .com> To > Sent by: <qui...@li.... > quickfixj-users-b net> > ou...@li... cc > ceforge.net > Subject > Re: [Quickfixj-users] repeating > 11/07/2006 08:28 group problem > PM > > > Please respond to > quickfixj-users@l > ists.sourceforge. > net > > > > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ >> The reason I do not want to use NewOrderSingle.NoPartyIDs is that my > order >> object can be either a NewOrderSingle or NewOrderMultileg. Not sure if I >> can add a NewOrderSingle.NoPartyIDs object to a NewOrderMultileg >> object? >> Could you clarify? Just wonder why there is not an abstract class >> sitting >> on the top like GeneralOrder which can enclose some common fields or >> classes like NoPartyIDs? > > The messages correspond directly to the FIX specification. > > You don't necessarily need a new build. Have you tried using the > Group(int field, int delim, int[] order) constructor in 1.0.4? > The only change I made was to make Group(field, delim) call > Group(field, delim, new int[] { delim }). Better yet, you'll > be safer if you include all the tags in the integer array in > the correct order. However, like Oren said, many FIX engines > will not enforce the order of the non-delimeter tags. > > Steve > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > > > > ******************************************************************************* > This e-mail message is intended solely for the use of the addressee. > The message may contain information that is privileged and > confidential. > Disclosure to anyone other than the intended recipient is prohibited. > If you are not the intended recipient, please do not disseminate, > distribute or copy this communication, by e-mail or otherwise. Instead, > please notify us immediately by return e-mail(including the original > message with your reply) and then delete and discard all copies of the > message. We have taken precautions to minimize the risk of transmitting > software viruses but nevertheless advise you to carry out your own > virus checks on any attachment to this message. We accept > no liability for any loss or damage caused by software viruses. > ******************************************************************************* > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |