Event xforms-model-construct-done behaviour - forms

In my form I would like to call web service after to form is loaded after publishing. I've created custom XBL control for it, where I have :
<xf:group id="component-group">
<xf:action ev:event="xforms-enabled" ev:target="component-group">
<xf:send ev:event="xforms-enabled" submission="my-submission"/>
</xf:action>
</xf:group>
But it doesn't work as expected : my submission is sent everytime when I add new element in FormBuilder or change a name of some other controls. Generally speaking submission is sent when my form is changing in some way.
Now I want submission to be sent ONLY when I publish my form and someone would open it to fill (and of course when I press "Test" in FormBuilder, but I guess it's the same as filling form after publishing).
I was trying something like this :
<xf:group id="component-group">
<xf:action ev:event="xforms-model-construct-done" ev:target="component-group">
<xf:send ev:event="xforms-model-construct-done" submission="my-submission"/>
</xf:action>
</xf:group>
Unfortunately it's not working, this way submission is not sent at all. Any thoughts ?

This is due to the fact that XBL components are live at design time too. So you need a way to test whether the component is running within Form Builder or not.
There should be a function for this, really, but there isn't (I added this to the list of functions we should add to the API here). You can do:
<xf:group id="component-group">
<xf:var name="fr-params" value="xxf:instance('fr-parameters-instance')"/>
<xf:action
event="xforms-enabled"
target="component-group"
if="not($fr-params/app = 'orbeon' and $fr-params/form = 'builder')">
<xf:send submission="my-submission"/>
</xf:action>
</xf:group>
A few minor comments:
you don't need to (in fact shouldn't) place event attributes on nested actions
you don't even need the ev prefix

Related

How to moving fields in forms of ncurses

I've written a program in C using ncurses and specially forms. I need that a particular field of my form moves as I'm filling the form. I tried move_field, but it doesn't work.
Here is how I wrote it :
if (typact==ADSD && rowc>rowg )
{
move_field(field[ietg],rowg=rowc,colg);
refresh();
}
I'm sure that the move_field is executed (I use xCode for debugging my program). I presume that refresh is not sufficient. I tried also placing move_field between unpost_form and post_form like this:
if (typact==ADSD && rowc>rowg /* && !field_status(field[ietg]) */ )
{ unpost_form(my_form);
move_field(field[ietg],rowg=rowc,colg);
post_form(my_form); refresh();
}
but it doesn't work once again. The form is erased and re-posted without the texts I have written and the field is always in the same place.
How could I use move_field?
The manual page says
The function move_field moves the given field (which must be disconnected) to a specified location on the screen.
You can disconnect a field by retrieving the current list of fields with form_fields (and its length using field_count), removing the field from that list and updating the list using set_form_fields.
When using move_field, you must also (temporarily) unpost the form with unpost_form. Otherwise, move_field returns E_POSTED (The form is already posted). After moving the field, use post_form to get the form-driver to work with the updated form.
The test/move_field.c file in ncurses sources provides an example of these calls.

Remove submitted state in submission handler

I am trying to reset a form so that it appears to Drupal 8 that it hasn't been submitted. So far I have been unable to do this, as I cannot find any available methods (setSubmitted() hardcodes it to TRUE without a FALSE option). The reason is this isn't a full submit, but a submit of one field after which I would like the user to be redirected to another page that has another form, and I would like this secondary form to use the value obtained in the first step.
In the submit handler for the first part I use this to redirect:
$form_state->setRedirect('my.route', [], []);
And this works, but when the form reaches the second form (it seems) that the second form thinks it is a submission. As a result any submit buttons I add to the second form seem to make it auto-submit, and this breaks my user journey.
In the submit for the first part I have tried:
$form_state->setRebuild(TRUE);
$form_state = new FormState();
unset($form_state);
Tried the above in various configurations to no avail. They all prevent/ignore the setRedirect call that I make afterwards. The reason I want/need to do it this way is I want to preserve the POST method used.
Do you want to obtain something similar to what core search module does? It has simple SearchBlockForm that sends data to more complex SearchPageForm.
SearchBlockForm uses GET method (though you may use POST):
$form['#method'] = 'get';
and has no id and token fields:
function search_form_search_block_form_alter(&$form, FormStateInterface $form_state) {
$form['form_build_id']['#access'] = FALSE;
$form['form_token']['#access'] = FALSE;
$form['form_id']['#access'] = FALSE;
}
BTW, the last change allows you to avoid running submit callbacks.
Hope this helps.

How to validate custom ("%CUSTOM%) RulesStringValue in Fiddler?

I have following piece of code in my fiddlerscript:
RulesString("Redirect Foo", true)
RulesStringValue(0, "to the latest version", "latest")
RulesStringValue(1, "to a particular version... (e.g. 1.2.3)", "%CUSTOM%")
public static var foo_redirect: String = null;
It renders as a submenu and clicking Redirect Foo to a particular version... opens a prompt box where you can type something.
Now, I want to validate that the user typed something following a regexp, and not a totally random string, and display a FiddlerObject.alert if he put something non-conformant.
How can I do the validation just after the user inputs the value, but before there's any redirection happening? (I don't want to defer it to OnBeforeRequest since it may display dozens of alerts there, one per each session - Foo is a folder with many JS files).
Fiddler does not offer a mechanism to validate the values of the %CUSTOM% token at the point of entry. If you want to do that, don't use RulesString, instead use FiddlerScript or an extension to add a menu of your own devising.

SAPUI5 bindAggregation complete for a Table

I am binding an aggregation to a table . I couldn't find an event which is triggered after the binding is complete . There is "updateFinished" event for sap.m.List , which is exactly what I am looking for in a Table (and a dropodown). I thought of using attachRequestCompleted() on the model , but the model is used at other places where I do not want this event to trigger.
Is there anyway to trigger a event once the databinding is complete on a Table (and a dropdown)?
Any help is appreciated.
Thanks in advance.
update: There is "updateFinished" event for table extended from ListBase. I am still not sure how I missed it before I posted this question. But, the question is still valid for a dropdown and TableSelectDialog controls.
I also stumbled upon that problem, but in a different Context.
I have a Grid layout in which I dynamically load Panels via an oData Model.
Therefore I have entered the path in my XML Grid-View element.
<l:Grid id="grid" content="{some path...}">...</l:Grid>
Now I wanted to set the grid view busy and when the data is loaded revert this.
Therefore I use the Binding of the grid view.
In the Controllers onInit method I have added:
this._oGrid = this.getView().byId("grid");
this.getRouter().attachRouteMatched(this._onRouteMatch.bind(this));
Please note that the bind method is not available in every browser. You need to apply a polyfill. (See https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Function/bind)
Also Bind has nothing to do with the binding :D
I needed to do this because the Binding is not available in the onInit function.
The _onRouteMatched function:
var oContent = this._oGrid.getBinding("content");
oContent.attachDataReceived(function(oData) {
this._oGrid.setBusy(false);
}.bind(this));
Now when the data is received the busy option is set to false.
If you want to show a 'loading' indicator for your table while the data is still loading (and thus not bound), I think the best approach is the following:
Use a dedicated JSONModel which holds only UI-specific stuff, like toggling enabled/readonly/busy/etc properties of controls.
In your case, something like:
var oUIModelData = {
tableIsBusy : false,
//etc, things like :
btnSubmitEnabled : false,
someControlVisible : true
};
var oUIModel = new sap.ui.model.json.JSONModel();
oUIModel.setData(oUIModelData);
sap.ui.getCore().setModel(oUIModel, "UIModel");
In your table definition, bind the busy property to {UIModel>/tableIsBusy} and set the table's property busyIndicatorDelay to 0 to avoid any delays
Just before you do your OData service call, set the property tableBusy to true. This will immediately show the busy overlay to your table:
sap.ui.getCore().getModel("UIModel").setProperty(tableIsBusy, true);
//here your OData read call
In your OData service's requestCompleted (and if needed, also in requestFailed) event handlers, set the busy property of the UIModel back to false:
sap.ui.getCore().getModel("UIModel").setProperty(tableIsBusy, false);
The big benefit of this approach is (IMHO) instead of relying on each control to check whether the data has been loaded, simply do it during the actual load.
And by binding these UI-related things to a (separate) model saves you from writing lots of extra code ;-)
In general you could solve the problem by using batch processing on the OData service. According to https://sapui5.netweaver.ondemand.com/docs/guide/6c47b2b39db9404582994070ec3d57a2.html:
Use OData model v2.
var oModel = new sap.ui.model.odata.v2.ODataModel(myServiceUrl);
Define a set of deferred batch groups.
oModel.setDeferredBatchGroups(["myGroupId", "myGroupId2"]);
Add the batch group information to the corresponding bindings, e.g:
{
path:"/myEntities",
parameters: {
batchGroupId: "myGroupId"
}
}
All read/query actions on bindings in a certain batch group will be held back until a .submitChanges(.) call on the batch group is made.
oModel.submitChanges({
batchGroupId: "myGroupId",
success: mySuccessHandler,
error: myErrorHandler
});
Use the success/error handlers to execute actions.
This rather generic approach gives you additional control such as trigger actions, grouping and event handling on the OData model.

Zend Framework / Form Element is rendering as a text box rather than a dropdown box

I have the following in a config.ini file: (Zend_Form_Element)
site_status.name = "site_status"
site_status.type = "select"
site_status.label = "Status"
site_status.options.multiOptions.active.key = "Active"
site_status.options.multiOptions.active.value = "Active"
site_status.options.multiOptions.active.key = "Inactive"
site_status.options.multiOptions.active.value = "Inactive"
As you can see this is supposed to be a dropdown (select) box, however it is being rendered as a standard text box. What am I doing wrong?
--> Edit
Rather than tying the elements to a form, I am trying to tie them to a database: In my code it would look something like this:
[{tablename}] // the table name would represent a section in the ini
{column}.name = "{column_name/form_field_id}";
{column}.type = "{form_element_type}"
{column}.label = "{form_element_label}"
...
From there I would pull in the database table(s) that the form would represent data for (one or more tables as necessary). As far as the reasoning for this approach is that (down the road), I want to define (either by ini or some other storage method), a configuration file that would be a list of fields/elements that belong to a specific form (that a non-programmer type could easily edit), that the 'generic' form class would read, pull in the element info, and create the form on the fly.
I do realize however this poses another problem which I haven't yet figured out, and that is how to use table lookups for select elements (without coding the database retrieval of the lookup into the form, so that a non-user could easily just define it without any programming, purely configuration, but that is a whole other topic not part of my question here. (and I think I have viable ideas/solutions to that part of the problem anyhow) -- extra config entries and a generic routine pretty much.
I hope that clarifies my thought process and reason why I am doing it the way I am in the example above.
I have not yet played with using a Zend_Config to construct an instance of Zend_Form.
But a look at the code suggests that Zend_Form::addElement() doesn't directly take a Zend_Config instance as a param. Rather, it looks like you need pass your Zend_Config instance to the form constructor. It also seems that the config format needs to be a little deeper in order to map config keys to setXXX() calls.
In path/to/config/myForm.ini:
[myForm]
myForm.elements.site_status.name = "site_status"
myForm.elements.site_status.type = "select"
myForm.elements.site_status.label = "Status"
myForm.elements.site_status.options.multiOptions.active.key = "Active"
myForm.elements.site_status.options.multiOptions.active.value = "Active"
myForm.elements.site_status.options.multiOptions.inactive.key = "Inactive"
myForm.elements.site_status.options.multiOptions.inactive.value = "Inactive"
Then instantiating:
$formConfig = new Zend_Config_Ini('path/to/config/myForm.ini', 'myForm');
$form = new Zend_Form($formConfig);
Not tested, but looking at this example:
Using Zend_Form with Zend_Config - Andrew Vayanis
it feels like it should go something like the above.
Update
In view of the comments/feedback from #Aaron, two more approaches.
We could extend Zend_Form, implementing a method called something like addElementByConfig in which we would pass the shallow Zend_Config instance that describes the element itself. In fact, we could even just override addElement(), taking a recursive approach: if the first param is an instance of Zend_Config, then call addElement() using the component data.
If the atomicity and re-usability are the primary benefits we seek in using Zend_Config to describe an element, then perhaps we just make a custom element extending Zend_Form_Element. Then we could use these elements in any forms we wish.