is it possible to have a button that calls two different actions in two different controllers in a cakephp application? For example, let's say that I have a text box on a page and a next button, when I click the next button I want the data entered into the text box to be saved to the database and move to the next page (the moving to another page is another controller action)
Is this possible?
Let me know, thank you
Your concept is totally wrong thought. There are different approaches but your "two buttons" is totally miss-leading. I guess because you did not understand the MVC design pattern, read about it.
When you submit your form from, lets call it /reports/step1 and the data validates simply save it and redirect to /reports/step2.
Different forms that do different things should be always separated. If you start to do multiple things in the same action and view things become messy for sure. Simply go for best practice techniques: If a method is doing two things at once refactor it.
Related
I have an application in which I display a form so a user can search for client records based on last name. After entering search parameters, the record or records (there could be multiple clients with the same last name) are displayed. I then want the user to be able to select a client record, possibly with a radio button, and hit one of two buttons: Display details, or Create Reservation. The Display Details button should cause a new display with details of the selected record. The Create Reservation button should cause a new form, with its own handling, to be displayed.
Now, I know I can set things up according to this login
<?php
if (display button was pressed)
{
php code to retrieve more data and display details
}
else if (create reservation button was pressed)
{
php code to generate and display the reservation form, with appropriate handling
}
?>
display the original form with the search results
The problem is, I end up with really ugly, hard to read code because the php code to generate and display the reservation form is lengthy, and needs its own validation, database interaction, and form handling. The code, to my Java-oriented eye, looks ugly and non-modular. Plus, the code for handling the reservation form is icky, with lots of flag setting to determine if we are in form entry mode or form handling mode. I would like a much cleaner way to do this. So my question is, what is the best practice for handling the situation where there are multiple buttons and the action associated with each button is complex?
I could call a function, obviously, but I still end up with the ugly flags determining which state the script is in (are we displaying the reservation form or handling it?). I could create another php file and include it, but the ugliness persists. Or, I could use header, and pass the client record id in a session variable to the new php script. But that would mean a second, unnecessary retrieve from the database to get the client information again.
All the code examples I see on the web show very simple processing after a form button is pressed. What is the best way to do complex processing and displaying a second form based on a button press?
Have you considered using a framework like Laravel for your site. It would seem to me that you must be doing this "manually". With the complexities you described, having a system with routes and "build-in" functionality (like Eloquent ORM) might serve to simplify things for you.
I would go for using ajax and a rich jQuery plugin (or some other framework) to do what you want.
Basically you will handle lists and the functionality that you mentioned with the php reading data and jQuery scripts to dysplay it. And the information that you have to show would be through ajax. Or when you want to edit.
Here is a cleaner example of what you need:
http://jqueryui.com/dialog/#modal-form
On any given page (It's used site-wide for different purposes) I'd like to call a function getMyForm() or something similar and this would render a several step selection process for a product. We only have this one product but it is quite a complex selection process.
If I wanted to implement this on one page only it would be fairly simple... but I'd like this selection process to be available on different pages, and it seems silly for me to recreate the form for each page used when it's only really the outcome after the selection process that will change for each.
How would I go about achieving this:
Should I have the form on it's own page anyway then link to it at the beginning of the selection process and redirect to the appropriate page after selection depending on the page the user first came from?
Use a service container or similar to render the form on the specific page, then use session attributes/variables to track which step the user is currently on, and refresh the current page after each selection.
Something completely different?
Additional stuff:
I want this to be functional without javascript/jQuery, but this
would be a nice addition in future so I don't want to rule it out if
possible.
The selection process is dependent on what was selected in the
previous step, so I can't just render the whole form in step one, and
some kind of refresh will be required.
First, i'd say you can't completely avoid javascript your selection process, if only for triggering change event on your selectors. Having user to manually trigger page refresh through some button doesn't seem like a good idea.
But if you're so inclined, you need to create a form controller with form builder, there just check a request and render a form accordingly.
For example, if no request is supplied it renders a starting form contains only one select and a submit button, and its action is simple submit to the same page. Main page controller includes a form controller, so form controller gets a request and renders second part and so on...
I have a situation where I have several ways to perform the same activity in my php web app.
There is the "Manage Widgets" section of the app which has a form for creating new widgets and a list of existing widgets.
Then somewhere else in the app there is a button that pops up a dialog to add a new widget.
Then on the home page of the app there is another place where a form is embedded to add a widget (think home page portal).
My question is: What is the best practice for this? In this case all of the forms will be essentially the same. So my first instinct is to use the same code for all three of these scenarios. On the other hand, space on the home page could be smaller and layouts may have to differ between the three.
So even though it would be repetition, is it better to duplicate this form 3 times (there is a proper model layer, so the duplicated code would not include the logic to add/edit the widget)? Or try to force a single view in all of these scenarios? Both seem wrong to me and I am hoping for some ideas to discover some sort of middle ground.
One approach would be to have the markup (not the styles) for the form as a standalone file, which can then be included from anywhere you like.
You can then use AJAX to submit the form to a specific PHP script that handles the form submission and returns a meaningful JSON response. You can then display and style this JSON response on the page in question.
This way you have a single form (that can be styled differently) and a single handler for any view that's required to use the form.
i mean, the best way is compose form from other forms (Dont repeat yourself). You can use different templates for same form to change appearance of final form.
For example/idea you can check forms what is used in Nette Framework (http://doc.nette.org/en/forms)
T.
If you are just changing the styles, not the markup, I think the best approach is to add a specific class to the form element and then use Javascript (not Ajax, justa Javascript) to alternate between these clases as you need.
If your application do not use Ajax at all and you just generate web pages with PHP, is a simple matter of decide which class you form shoud have.
In CSS, you do something like this:
form.main { ... }
/* main form rules */
form.other { ... }
/* other form rules */
Potentially silly question, but I'm looking for the most sensible mechanism by which to maintain and "resubmit" POST variables. Basically the workflow is as follows:
STEP 1) Select charges to pay, and enter payment info
STEP 2) Display confirmation/summary page with option to "PROCEED WITH PAYMENT" or "EDIT INFO"
STEP 3) Return to "edit" form or send data to be processed.
I'm currently using a single page for all actions (just one giant SWITCH based on an "action" var) and submitting the information. The problem I'm having is that between the "confirmation page" and either option, I'm losing my POST data (which I understand). What I need now is a way to preserve that data without duplicating the input fields in each SWITCH section. Below are a few options I've considered. Feel free to comment on the merits or stupidity of each:
1) serialize it to a SESSION var then unserialize it?
2) simply key/value it into a SESSION array?
3) recreate every INPUT for each "form" presented and refill the values
4) put the SWITCH inside a single form and only display relevant portions
5) I would handle it all with Javascript (sort of a faux submission technique), but there is currently processing that occurs between the initial form and the summary and ajaxifying that would be a beast atm.
What's the recommended course of action for the classic INPUT->CONFIRM->PROCESS process? It'd be amazing if I were just missing something über obvious/simple.
FYI: Currently using PHP 5.1.6
Best!
EDIT 1
Clearly using individual pages for the various functionality is desired. The only reason I'm not using separate pages is because other pages are dependent on this one page and management won't allow a clean break at this point in time. It was poorly constructed over 3 years ago and is just now being partially addressed.
At this point I'm using:
foreach($_POST as $key=>$value)
<input type="hidden">.......
...in order to achieve the desired goal.
serialize it to a SESSION var then unserialize it?
simply key/value it into a SESSION array?
Very bad. Clicking "Confirm" should always confirm what is being displayed on the page, not what happens to be in some nebulous session stored on some server somewhere (which may not be the same server that served the previous request if you have a load-balanced cluster).
There are plenty of websites out there which will try to detect when you press the back button and display an error page, probably for related reasons.
recreate every INPUT for each "form" presented and refill the values
You need to do this anyway for the "go back to editing" page.
What's hard about <input type="hidden" ... /> in a loop on the confirmation page?
put the SWITCH inside a single form and only display relevant portions
You mean stick all the inputs in display:none for the confirmation page? That feels ugly too.
Firstly, breaking it up into multiple pages might be a good solution but I don't know your specific needs.
1 and 2 are bad ideas. That being said, I don't know what you gain out of serializing and unserializing to a session variable that you don't get with simple key value pairs in the session. Session management gets pretty hairy if you are running multiple servers behind load balancers
4 Just sounds odd. I don't know what the switch gives you here. If you ever have to use conditional logic to display a completely different functionality to the user, it is probably better of being on a separate page.
5 Faux submission? Just sounds like a kludge. You mean send the data back to the server and return the same data back and display the confirmation div? Why not just use Javascript and manipulate the DOM at that point? Nevertheless bad idea.
Just repost the parameters to the confirmation form and populate the confirmation fields accordingly. (Standard process). I think that is what 3 is but I suggest you use a different page for each step. Just keeps things clean.
I actually ended up using
<?$forward_post_data = base64_encode(serialize($_POST));?>
<input type="hidden" value="<?=$forward_post_data?>"/>
...I then decode it as necessary. It works perfectly.
I have an action (view for example) in a controller that is called from multiple other actions in other controllers. How is the best way to create a "Back" button that will take me back to the page that got me here?
I've used named parameters like "back_controller" and "back_action" and that works fairly well but they get awkward when the page has a form that gets submitted. I have to be sure to pass those parameters as hidden fields or in the form url and then look for them after the form has been processed.
Is there some kind of stack or other solution that anyone else has come up with that handles this situation better? I see this problem in a lot of my projects and I've yet to come up with a good solution.
I don't completely understand your question, but this may be helpful:
If you need to redirect to the referer page you can use:
$this->redirect($this->referer());
http://book.cakephp.org/view/425/redirect
I don't believe in back buttons. That is a feature that the browser does quite well and you would be better off having buttons always taking you to specific destinations rather than back.
If you must have a back button, you could create a history stack in the session. When a page loads you just push that page on the history (you will want to make sure you don't push the same page on the stack multiple times). You could create URL like /back who's sole job is to redirect the user to the last page they were on.
$_SERVER['HTTP_REFERER']