Reload Page After Submit

rbrahmson

I will test that, but who are we kidding, view without logic but then we add logic in JS? No URL parameter on buttons ever? Why don't we disallow links entirely? I exaggerate to demonstrate that we can't be purists and View always has some logic.

But more interestingly, you are absolutely correct in that pressing the "X" does not re-render the underlying window. Nothing really happens, and that actually may be a problem because the end user may press it after filling in information on the form not realizing that all his/her inputs are lost. A far better approach would be to trigger some postback (to FormB, the subform) and let its logic decide what to do... That is if FormB is allowed to have logic;-)))

rbrahmson

Allow me to add another point -- Assume the child form (FormB) is invoked from the main form without having the Popup pseudoclass. Then there is no problem, the logic works as intended. Wouldn't an ideal solution be one where the coding is the same regardless whether the subform is invoked with or without Popup?

rbrahmson

Last but not least, neither of these options (separately or in combination worked):

$sender->jsonTarget('', '', 'Refresh');
$sender->jsonTarget('example.com', '', 'Redirect'); //trying to get bad url
$sender->jsonTarget('/dashboard/settings/demonstration', '', 'Redirect'); //Redirect to the demo test plugin

So there's probably a different jsontarget approach.

I wonder if we can figure out what is triggered by "$Sender->Render('Blank', 'Utility', 'Dashboard');" because that solves the problem...

And really last but not least, this conversation should probably be moved to the development category...

R_J

@rbrahmson said:
I will test that, but who are we kidding, view without logic but then we add logic in JS? No URL parameter on buttons ever? Why don't we disallow links entirely? I exaggerate to demonstrate that we can't be purists and View always has some logic.

The MVC pattern is not about the interface elements. Those are all part of the View/UI. The Model interacts with the database (no links or JS is involved here) and the Controller acts as an interface between the View and the Model.
There are those who think that your Controller should contain more logic and there are those who think that the Model should contain more logic. But what should be done after a page has been submitted is a classical job for the Controller.

But more interestingly, you are absolutely correct in that pressing the "X" does not re-render the underlying window. Nothing really happens, and that actually may be a problem because the end user may press it after filling in information on the form not realizing that all his/her inputs are lost. A far better approach would be to trigger some postback (to FormB, the subform) and let its logic decide what to do... That is if FormB is allowed to have logic;-)))

I think that an "X" in the upper right corner is a UI element that is widely know. When I'm finished writing this comment I will not close my browser (by pressing the "X" in the upper right corner) before I pressed the "Post Comment" button. If you want to stress the meaning of your submit button, make your action elements in your interface colored, let the submit button be some kind of "primary" action (has it been called like that already at the time before Bootstrap?) and also show a "Cancel" button to stress the meaning of the submit button.

By the way: Vanilla already adds .Primary to its Buttens where appropriate.

@rbrahmson said:
Allow me to add another point -- Assume the child form (FormB) is invoked from the main form without having the Popup pseudoclass. Then there is no problem, the logic works as intended. Wouldn't an ideal solution be one where the coding is the same regardless whether the subform is invoked with or without Popup?

If you click on a link (let's call it "FormB") without .Popup, the link is simply followed and the page FormB opens. After you click the submit button, the you will still be on FormB. That is not what you would like to see if you submit FormB as a popup from Main, nor?

rbrahmson

You splitted this while I was typing my response. I paste here below:

You wrote:

If you click on a link (let's call it "FormB") without .Popup, the link is simply followed and the page FormB opens. After you click the submit button, the you will still be on FormB. That is not what you would like to see if you submit FormB as a popup from Main, nor? >

No. We defined the logic that pressing some specific Button-B on FormMain redirects to another formB which upon some Button-Return pressing returns to Main. So there is an implicit parent-child flow relationship. Clearly, pressing Button-Return gives control to the code that renders FormB. Then that code tries to redirect for the Main, and that's working fine without the Popup but breaks if FormB was in a popup. So again, I think for FormB logic should work identically regardless of the Popup state (in other words, Vanilla should handle it internally upon realizing that a different view is rendered). Here is the ideal FormB logic in pseduocode:

FormB:
   if (postback) 
      If (Button-Return)
         redirect to Main     //Ideally that should work regardless of whether it is in a popup or not
      fi

R_J

By the way: I bet that anybody with some basic form handling knowledge is already laughing at our clumsy explanations

It's getting somewhat too theoretical for me now.

You can define an action target in a form, which would pass that postback action back to the Main method like so:

    public function settingsController_demonstration_create($sender) {
        $sender->permission('Garden.Settings.Manage');

        $sender->addSideMenu('dashboard/settings/plugins');
        $sender->setData('Title', t('Demonstration Settings'));

        $sender->setData('Kokolores', $this->getUserMeta(0, 'Kokolores'));
        if ($sender->Form->authenticatedPostBack()) {
            $this->setUserMeta(0, 'Kokolores', $sender->Form->getFormValue('Kokolores'));
            if ($sender->Form->getFormValue('Kokolores') == "nonsense") {
                // Whatever
            }
            $sender->jsonTarget('', '', 'Refresh');
        }
        $sender->render($sender->fetchViewLocation('settings', '', 'plugins/demonstration'));
    }

    public function settingsController_popupTest_create($sender, $args) {
        $sender->permission('Garden.Settings.Manage');

        $sender->addSideMenu('dashboard/settings/plugins');
        $sender->setData('Title', t('Demonstration Popup'));

        $view = $sender->fetchViewLocation('popuptest', '', 'plugins/demonstration');
        $sender->render($view);
    }

In all my demonstration code setting jsonTarget like shown above yields exactly the result that you are talking about. So if you have a constellation where that is not working, it would be helpful if you could provide code.

rbrahmson

Yea, it is becoming theoretical, and I will check again "$sender->jsonTarget('', '', 'Refresh');".

I am curious, though, what happens when one issues $this->render('blank', 'utility', 'dashboard');

rbrahmson

Branching out to another possibly related question - could jsonTarget be used to show background progress?

Clearly progress info (e.g. progress bar) needs client side update through js, but perhaps there is some Vanilla provided facility that does that (and perhaps it leverages jsontarget).

R_J

No. jsonTarget "happens" at the end of a php method. It decides what happens when a request ends.

Page1 has an element (link, submit button) which calls Page2. Some JavaScript hinders the browser to open the link. That's what Popup or Popin class do, well not the CSS does so but global.js, the main js library of Vanilla changes the default behaviour of links with such a class.

So Page2 isn't opened directly, but instead that request is made as an AJAX call (JavaScript calls that link). With using jsonTarget in the PHP method that is called (the method that Page2 routes to), you can influence the behaviour after the request is finished

Vanilla has the TinyProgress class, you would have to dig some deeper to find out how that works, but I would assume that you could indeed use it quite easily. But the TinyProgress is no progress bar but simply a spinner. It just shows you that something is being done, not giving any real feedback about the progress.
If you use TinyProgress, it might be needed to remove that span.TinyProgress with a jsonTarget command at the end of your "Page2 method"