在页面之间维护/重新提交 POST 变量的最明智的机制是什么？
可能是愚蠢的问题，但我正在寻找最明智的机制来维护和“重新提交”POST 变量。基本上，工作流程如下：
步骤 1) 选择要支付的费用，然后输入付款信息
步骤 2) 显示确认/摘要页面，其中包含“继续付款”或“编辑信息”选项
步骤 3) 返回“编辑”表单或发送要处理的数据。
我目前正在使用一个页面来执行所有操作（只有一个基于“操作”变量的巨型开关）并提交信息。我遇到的问题是，在“确认页面”和任一选项之间，我丢失了我的 POST 数据（我理解）。我现在需要的是一种保留该数据的方法，而无需复制每个 SWITCH 部分中的输入字段。以下是我考虑过的一些选择。请随意评论每个的优点或愚蠢之处：
1）将其序列化为 SESSION var，然后反序列化它？
2）简单地将其键/值放入SESSION数组中？
3）为呈现的每个“表单”重新创建每个输入并重新填充值
4）将SWITCH放入单个表单中并仅显示相关部分
5）我将使用Javascript（有点像虚假提交技术）来处理这一切，但是有目前正在处理初始表单和摘要之间发生的情况，并且 ajaxifying 这将是一个野兽 atm。
对于经典的“输入”->“确认”->“处理”流程，建议采取什么行动？如果我只是错过了一些非常明显/简单的东西，那就太棒了。
仅供参考：目前使用 PHP 5.1.6
最好！
编辑 1 显然需要使用单独的页面来实现各种功能。我不使用单独页面的唯一原因是其他页面依赖于这一页面，而管理层此时不允许彻底中断。三年多前，该问题的建造质量很差，现在刚刚得到部分解决。
此时我正在使用：
foreach($_POST as $key=>$value)
<input type="hidden">.......
...为了达到预期的目标。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
只需将其键/值写入 SESSION 数组？
非常糟糕。点击“确认”应该总是确认页面上显示的内容，而不是在某个服务器上存储的模糊会话中发生的内容（如果您有负载平衡集群，则这可能不是为先前请求提供服务的同一台服务器）。
有很多网站会尝试检测您何时按下后退按钮并显示错误页面，可能是出于相关原因。
为呈现的每个“表单”重新创建每个输入并重新填写值
无论如何，您都需要对“返回编辑”页面执行此操作。
在确认页面上循环
有什么困难？将 SWITCH 放入单个表单中并仅显示相关部分
您的意思是在确认页面中将所有输入粘贴在
display:none中？这也感觉很丑。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:nonefor the confirmation page? That feels ugly too.首先，将其分成多个页面可能是一个很好的解决方案，但我不知道您的具体需求。
1和2是坏主意。话虽这么说，我不知道通过序列化和反序列化会话变量可以获得什么好处，而会话变量是通过会话中的简单键值对无法获得的。如果您在负载均衡器后面运行多个服务器，会话管理就会变得非常棘手
4 听起来很奇怪。我不知道这个开关给你带来了什么。如果您必须使用条件逻辑向用户显示完全不同的功能，那么最好位于单独的页面上。
5 假提交？听起来就像是一个拼凑。您的意思是将数据发送回服务器并返回相同的数据并显示确认div？那为什么不直接使用 Javascript 并操作 DOM 呢？尽管如此，还是个坏主意。
只需将参数重新发布到确认表单并相应地填充确认字段即可。 （标准流程）。我认为这就是 3，但我建议您为每个步骤使用不同的页面。只是保持东西干净。
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
...I then decode it as necessary. It works perfectly.