So I am trying to generate repeating groups in a FIX message, but I need a method to determine which fields are required for each repeating group so I don't have to hard code everything. For some reason, the quickfix DataDictionary class's method
isRequiredField((java.lang.String msgType, int field)
does not work for required fields within repeating groups. For example
isRequiredField("V", 269)
gives false, even thought it is required. The Fix 4.2 XML also has it as required so why does the isRequiredField method return false?
I think you need getGroup(java.lang.String msg, int field), where field is the tag for the group's counter field.
That will give you a DataDictionary.GroupInfo object, and on that you can call getDataDictionary().isRequiredField(msgType,field) (use the same message type).
I think that'll work, anyway. The docs aren't explicitly clear on this.
But why are you doing this?
To be honest, I'm not sure why you think you need to do this. There's simply no need to dynamically query which fields are required. When receiving, the engine checks the required/not-required for you. When you're sending, you have to set values to all the required fields anyway (you can't dynamically do that!).
Unless you are writing some kind of DD-analysis tool, I think you're spending your time investigating a red herring.
Related
I´m pretty new in quickfix, but according to official doc, even in the case you are typing (in the way of assigning a type) the message you want to send. You have to know in advance which are the available fields. I was expecting to find something more programming friendly. Creating a new OrderCancelRequest, would create an instance where you have a pack of acknowledged variables-properties and IDE would help you to know what field must be provided.
In fact
Type Safe Messages And Fields
void sendOrderCancelRequest()
{
FIX41::OrderCancelRequest message(
FIX::OrigClOrdID("123"),
FIX::ClOrdID("321"),
FIX::Symbol("LNUX"),
FIX::Side(FIX::Side_BUY));
message.set(FIX::Text("Cancel My Order!"));
FIX::Session::sendToTarget(message, SenderCompID("TW"), TargetCompID("TARGET"));
}
and Type Safe Field Only
void sendOrderCancelRequest()
{
FIX::Message message;
FIX::Header header& = message.getHeader();
header.setField(FIX::BeginString("FIX.4.2"));
header.setField(FIX::SenderCompID(TW));
header.setField(FIX::TargetCompID("TARGET"));
header.setField(FIX::MsgType(FIX::MsgType_OrderCancelRequest));
message.setField(FIX::OrigClOrdID("123"));
message.setField(FIX::ClOrdID("321"));
message.setField(FIX::Symbol("LNUX"));
message.setField(FIX::Side(FIX::Side_BUY));
message.setField(FIX::Text("Cancel My Order!"));
FIX::Session::sendToTarget(message);
}
Shows not too much difference. In both cases you have to know which are valid tags to be provided. Maybe, in the second example, the compiler allows you to provide wrong fields, not sure. But at the end, you have to consult which are the available fields to kind of message you want to send (it´s similar to receive, cracking does not help too much, in onMessage you have to know which are the available fields)
So, summarizing. Is it possible to find any smarter way to work with quickfix in order to have more help from the IDE-context? I was thinking about a kind of direct message-class maping.
Thanks a lot for your help. Maybe it´s due to I´m new with quickfix, but I have the feeling that using it oblies you to know messages available fields at the end.
I will need to create a Custom Button "convert lead" that will perform the same functionality as Standard Button "Convert" when the button is clicked.
What is the best approach to do it..?
That's a very broad question. What exactly you need, what have you tried so far? Do you really need just a button that opens the conversion page or something more?
If you want to somehow recreate it with Apex... Core of the coded solution would be the Database.convertLead method. You don't pass to it whole leads (like to Database.insert for example) but instead just their IDs + bunch of control flags to make it do exactly what you need. Read up about LeadConvert object. And similarly you can get Account/Contact/Opportunity ID from the result object if it succeeded.
I don't think there's programmatic way to access field names & mappings defined by administrator for lead conversion. Maybe you'd need to store this info somehow (in helper object? custom metadata?). So then you'd query the field names from metadata, then query the lead fields and finally display table of fields & mappings to the user.
As the document says, MediaResponse contains mediaObjects property, and mediaObjects is array of mediaObject, but when I tried to put multiple mediaObjects, I got this error:
MalformedResponse at
expected_inputs[0].input_prompt.rich_initial_prompt.items1.media_response:
Only 1 media_object is allowed. First media_object will be used while
rest will be filtered.
Then what is the point of having an array of mediaObject?
There are several places in the protocol that contain an array where only one object is permitted in the array. One assumes that the designers wanted to make it expandable in the future without having to add special casing.
In this case, it sorta makes sense - right now we can only send one media object as part of the reply. It might be reasonable that, in the future, we could send one or more without having to come back to our webhook.
Which method is better?:
add(new Label("label", new PropertyModel<String>(cat, "name")));
or
add(new Label("label", cat.getName()));
I tried to find any information about comparison.. but couldn't find anything
How I understand the first method is for read/write logic and the second for read only logic, (if I am not right please write me). But for read only logic which better is?
They're functionally different.
The first one says: whenever this component is re-rendered, refresh the value. The second one says: display the value as it was at the time of creation.
Which one do you need? If you want a dynamically refreshing label, you have no choice, it's PropertyModel or CompoundPropertyModel (see later).
If you want it to stay the same, even if the underlying object changes, you can't use PropertyModels.
However, if you are absolutely sure that cat.getName() is never going to change, and therefore the two versions behave the same way, I personally wouldn't use PropertyModel for three reasons:
It breaks encapsulation: in the absence of a getter, it will try to access the private field itself.
As #Jesse pointed it out, it's "magic". If you refactor your class and rename your fields, your PropertyModel will break.
It's not easier to read or maintain. Granted, it's not that much harder either but why add any unnecessary complexity when you're not getting anything out of it? If you put cat.getName() there, you can "click through" in your IDE, your label will show up in a search for all invocations of the getName() method and so on.
If you have many components referring to fields of the same object, you can consider using CompoundPropertyModels, which, although still suffer from problems 1 and 2, make your code look a lot cleaner.
If you have three or fewer components like this though and you don't need a dynamic model, just use the modelless format.
This version is the better of the two options you gave:
add(new Label("label", new PropertyModel(cat, "name")));
It allows the value rendered on the page to update if the page is repainted later after the cat's name has changed.
The second option will only ever display the cat's name as it was at the time that the Label was created. It will never change if the cat's name changes.
There is something to be said for the dangers of using PropertyModel. It is "strings" programming. You compiler is not helping you verify the correctness of the property name "name". If you later refactor your code and change the name of the property to something like "firstName", then you will have to manually find all the places where you reference the old property name and change them by hand.
I have a custom node type for which I want to have a field that uses a special combobox based on list_text. When one chooses the type list_text it is normally possible to enter a static list of selectable texts, however, I want this list to be dynamic, i.e. based on the results of a db_query. What is the best way to do this using Drupal 7?
A simple example for clarification: A node of this custom type X contains a field that points to another node, so whenever a node of type X is created I want a combobox that contains all other nodes.
(Best solution would be to only display the combobox during node creation, and no longer during edit. But I could also live with it if the combobox was shown during the edit as well.)
I have tried to customize options_select by defining my own data type and implementing hook_options_list accordingly. The combobox was displayed during creation with the correct values, however, I could not save it.. I have no idea what went wrong there, but on the first submit it would change to a different theme, and when I tried again I got an internal server error. Am I on the right track at all with defining a completely new data type for the field? there surely must be a simpler way?
You're right in that you don't need a new datatype. Here's a good tutorial on how to do this. It's not specifically for D7 but I didn't see much that wasn't still applicable. There may be a better way to do it in D7 specifically but I would love to know it too if so :)
The tutorial linked by allegroconmolto sent me on the right way. Thanks for that.
Here's the simpler way of doing it: tutorial
Basically, it is, as I assumed, a common problem and hence a simple solution for it was included in the webform module by now. It provides a hook_webform_select_options_info which can be used to register a callback method. The callback method is then called each time a corresponding option select of a webform is shown, so that you can easily fill it with the results of a dbquery or anything else. Works like a charm and takes next to no time to implement.