Consider I have one submit button. On clicking submit, it should call both handleAddData() and handleInsertData().
Yes, we can call multiple handlers on single submit, using a component atg.search.formhandlers.MultipleSubmitHelper,
we have to configure - MultipleSubmitHelper component by setting its queryFormHandlers property to an array
Example- queryFormHandlers=/atg/search/formhandlers/QueryFormHandler1,
/atg/search/formhandlers/QueryFormHandler2
A <dsp:input> tag can only be bound to a single element in ATG. That said, you can have 3 handle methods, one which calls both the others (eg. handleCallAddInsertData) and bind your tag to this, still leaving you with the original handleAddData and handleInsertData. Alternatively you can submit your form via Javascript which will in turn call both handle methods.
If, however you need to call them 'both' you probably have a flaw in your design.
Related
Can we define our own skip and submit button instead of using the predefined one? Especially when we only have 1 task per task suit? I just want to change it because in my case there is more preferable variant
Unfortunately, there is no function like this. The Toloka control elements (such as the "send", "quit" buttons, etc.) cannot be changed, but you can modify the task interface.
I have two input fields which i would like to sync with each other.
Unfortunately, when I add a ChangeListener to each of the TextFields they will trigger each other,
and so create an andless loop.
Ofcourse I could unregister the Listeners, on every change and them put them back,
but is there any Java native approach?
Maybe something with bindings?
From general reasoning (i.e. not knowing swt or java): you can add a boolean flag (probably your class member) m_enteredChangeListener, temporary setting it to true in one of your handlers (not both), making the same handler do nothing if it's reentered recursively.
I've got a MATLAB GUI that has different aspects of functionality, each with their own panel of uicontrols. When one panel is selected, the other one is set to invisible, and vice-versa. However, they share some of the same inputs in the form of a popup menu. Can I include a 'clone' instance of the menu on the second panel somehow? I'd like to avoid as many redundant callbacks and uicontrols as possible.
I guess if the uicontrol was a direct child of the figure, you may be able to put it in front of everything.
A much simpler solution is to use the same callback for multiple uicontrols. In the property editor, you can modify the callback name and set it to a common callback function. Additionally, you can create a field (e.g. myPopupH) in the OpeningFcn of the GUI, in which you store the handles of the popups that should behave the same way. Then, in the callback, you'd use hObject, i.e. the first input argument, for all the get calls (to access the modified state of the popup-menu), but you'd use handles.myPopupH in all the set calls, so that you can ensure that both popups always have the same state. Thus, the ui-object may be redundant, but all the code (which is much more critical) only exists in a single copy.
One place where I routinely use a single callback for multiple ui elements is the close request function which is accessed from the "Cancel"-button as well as from the "X" that closes the figure, and possibly from one of the "File"-menu items.
While developing a web app using ZF, I had an haha! moment regarding the _forward method in Zend_Controller_Action. As stated in the Programmer's Reference Guide, when calling the _forward method inside an action, the requested action will not be executed until the current action completes. This begs the question:
When would you use the _forward action to intentionally make sure your current action completes before starting another, aside from form processing (although you would probably place the _forward request at the end of the action anyway)? What are some clear cut examples of this? Any pitfalls or advantages to using this approach as apposed to an ActionStack?
_forward() just replaces module/controller/action parameters in Request object.
It just allows to change your mind on the go (without another request).
This has different consequences, depending on which dispatch loop state it is called. Some time setDispatched() is needed to execute.
Consider those scenarios:
First:
$this->_forward('some')
Second:
return $this->_forward('some');
Third:
$this->someAction();
// ececuted?
Fourth:
return $this->someAction();
// executed?
I really only use _forward for two reasons:
I want to redirect but don't want the user's URL to change.
I want to pass some (non-string) object to another action.
$this->_forward('index', null, null, array('create_task_form' => $form));
In each case, the target action can stand by itself, without the originator, and usually just marshals up the display.
When would you use the _forward action to intentionally make sure your current action completes before starting another
I don't think it's used to let the current action complete before _forward() is used. That looks more like a call to your domain logic (model, service, something like that) than handling a request which is what an action is for.
yourAction
if(conditionsAreNotMet()) {
return _forward(anotherAction);
}
I think _forward() is provided to have an early exit point in your action (which logic is all focused on one thing, for example presenting news); without the need of performing another request (like _redirect()) and thus putting more load on the web server.
I run into this regularly, and am just looking for best practice/approach. I have a database / datamodule-containing app, and want to fire up the database/datasets on startup w/o having "active at runtime" set to true at design time (database location varies). Also run a web "check for updates" routine when the app starts up.
Given TForm event sequences, and results from various trial and error, I'm currently using this approach:
I use a "Globals" record set up in the main form to store all global vars, have one element of that called Globals.AppInitialized (boolean), and set it to False in the Initialization section of the main form.
At the main form's OnShow event (all forms are created by then), I test Globals.AppInitialized; if it's false, I run my "Initialization" stuff, and then finish by setting Globals.AppInitialized := True.
This seems to work pretty well, but is it the best approach? Looking for insight from others' experience, ideas and opinions. TIA..
I generally always turn off auto creation of all forms EXCEPT for the main form and possibly the primary datamodule.
One trick that I learned you can do, is add your datamodule to your project, allow it to auto-create and create BEFORE your main form. Then, when your main form is created, the onCreate for the datamodule will have already been run.
If your application has some code to say, set the focus of a control (something you can't do on creation, since its "not visible yet") then create a user message and post it to the form in your oncreate. The message SHOULD (no guarantee) be processed as soon as the forms message loop is processed. For example:
const
wm_AppStarted = wm_User + 101;
type
Form1 = class(tForm)
:
procedure wmAppStarted(var Msg:tMessage); message wm_AppStarted;
end;
// in your oncreate event add the following, which should result in your wmAppStarted event firing.
PostMessage(handle,wm_AppStarted,0,0);
I can't think of a single time that this message was never processed, but the nature of the call is that it is added to the message queue, and if the queue is full then it is "dropped". Just be aware that edge case exists.
You may want to directly interfere with the project source (.dpr file) after the form creation calls and before the Application.Run. (Or even earlier in case.)
This is how I usually handle such initialization stuff:
...
Application.CreateForm(TMainForm, MainForm);
...
MainForm.ApplicationLoaded; // loads options, etc..
Application.Run;
...
I don't know if this is helpful, but some of my applications don't have any form auto created, i.e. they have no mainform in the IDE.
The first form created with the Application object as its owner will automatically become the mainform. Thus I only autocreate one datamodule as a loader and let this one decide which datamodules to create when and which forms to create in what order. This datamodule has a StartUp and ShutDown method, which are called as "brackets" around Application.Run in the dpr. The ShutDown method gives a little more control over the shutdown process.
This can be useful when you have designed different "mainforms" for different use cases of your application or you can use some configuration files to select different mainforms.
There actually isn't such a concept as a "global variable" in Delphi. All variables are scoped to the unit they are in and other units that use that unit.
Just make the AppInitialized and Initialization stuff as part of your data module. Basically have one class (or datamodule) to rule all your non-UI stuff (kind of like the One-Ring, except not all evil and such.)
Alternatively you can:
Call it from your splash screen.
Do it during log in
Run the "check for update" in a background thread - don't force them to update right now. Do it kind of like Firefox does.
I'm not sure I understand why you need the global variables? Nowadays I write ALL my Delphi apps without a single global variable. Even when I did use them, I never had more than a couple per application.
So maybe you need to first think why you actually need them.
I use a primary Data Module to check if the DB connection is OK and if it doesn't, show a custom component form to setup the db connection and then loads the main form:
Application.CreateForm(TDmMain, DmMain);
if DmMain.isDBConnected then
begin
Application.CreateForm(TDmVisualUtils, DmVisualUtils);
Application.CreateForm(TfrmMain, frmMain);
end;
Application.Run;
One trick I use is to place a TTimer on the main form, set the time to something like 300ms, and perform any initialization (db login, network file copies, etc). Starting the application brings up the main form immediately and allows any initialization 'stuff' to happen. Users don't startup multiple instances thinking "Oh..I didn't dbl-click...I'll do it again.."