浮起来的验证消息

 

  在我之前的一篇文章《如何制作好一个提交按扭》中,讨论了表单提交相关的事宜,后来又在具体的项目实践中发现还有要完善的地方。关于验证消息的摆放问题。

  如果你的版面够宽,并且客户没有要求,你可以自己设计界面,那还好,不会存在我所碰到的问题。因为你完全可以常规地把用户输入出错时弹出的验证消息放在一块预先留好的空白地带。比如下面这样:

 

  这种方式是很常见用得非常多的方式。

  现在的问题是,客户给了你这样的界面:

 

  当你埋头苦干完成布局后,实际运行时出现这样的情况:

 

  你可以看到,可恶的验证消息把原先活生生的布局给糟蹋成了什么样子。于是我就寻思着,验证消息不能这么放,得另想出路。

 

  三个解决办法。

  一是只给出一条总的验证消息,不为每个输入都设置一条需要显示出来的消息。如非死不可的注册页面那样:

 

 

  这里的汇总验证消息会给出具体哪里出错了,比如上面说的请写出正确的邮件地址,然后很多时候,有些很不负责的开发人员并没有把工作做得像非死不可这样的大公司这样到位,只是在汇总验证消息这里给出一条固定的错误信息,比如“请检查表单中的错误后再提交”,具体是哪里填错了你丫自己找去吧。试想你在填一个拥有向十个条目的表单,系统又不给出更为具体的提示,而只是这样不负责任地叫你自己去找错误,是不是有砸键盘的冲动。当然,这样做的后果是丢失用户。为了争取用户,我们必需要提升用户的体验,用户体验做得越好,就越多人愿意用。

  其实提到用户体验,不止是给出友好的提示信息这块需要注意,很多地方很多细节,都是值得开发人员去细心拿捏的。虽然不一定每个用户都是挑剔的用户,但你拿一个考虑不够全面的产品出来给用户时,哪天用户遇到了一个更加注重细节的产品,这些细节用户是会体会到的,当用户丢失了你到时候来二次返工意义都没有多大了。这里给大家看个小小的细节问题,移动的无线上网业务的客户端产品,G3随e行的登陆界面:

 

 

 

  不知你们发现什么问题没有,当然这里我不说它的网有多破,功能什么的也不讨论,单看这个界面就让人感到有多狗血了,美工就犯了个常识性的错误。‘流量信息’和‘电话簿’的图标,看着是不是很扯,他们的倒影是拿图标图片直接翻转而来的!对于前面两个图标,没问题,但后面两个图标的倒影,稍微相像一下生活中放在桌子上的水杯就可以发现问题,哪有这么坑爹的倒影,看着真心蛋疼!下面我把这个界面倒影的逻辑应用到水杯上, 大家可以看看效果:

 

 

 

  同样的道理,电话簿也是这样的常识错误。虽然不是每个用户会发现或者在意这些东西,管他呢,只要功能没有bug能用就行,但这个真的不该成为开发人员偷懒的借口。如果没有追求完美的萝卜丝,苹果公司也走不到今天。

似乎扯远了,回到本篇文章的主题来。

这种显示验证消息的方式好不好,要说不好,非死不可这样的全球大公司都在用,肯定不能说不好。我猜可能是考虑到排版的问题,上面的输入框也都那么整齐,如果验证消息放在每个框的后面的话,会破坏整个布局的整齐性,放在输入框的下面会把下面的内容往下挤,在没有验证消息时又会把下面的内容抬上来。

 

  二是用弹框,像某著名华人论坛的注册页面那样:

 

 

  这样的方式需要用户点击确定,不是最佳的选择,你每次错误都要点击一下确定,表单内容少还无妨,内容多了错误的地方很多的话,那就点得有点手软了。

 

  最后就是让验证消息处于页面的上层,不跟表单内容在同一层,这样就不会把原来的布局破坏掉了。我更倾向于这种方式来显示表单的验证消息。这种方式不管用在哪里都不会有问题,特别是页面的Grid控件中,根本没有单独的空白来放置验证消息,都是拿来显示数据的区域。

 

  上图就是Kendo UI的Grid控件,这也是为什么它采用了把验证消息浮起来放在上层的原因。

  那,我们要实现这种浮起来的效果也是相当简单的,只需一句CSS代码。真的就只需一句,只要一句。

  我们可以查看一下网页源码,看它是怎么实现的,就可以从中找到答案。

 

 

  经验证,就是那个position属性在起作用,当我把这个CSS属性去掉后,验证消息就跑到Grid里面去了,破坏了原来的布局:

 

 

  所以,在以后的场合中,只需给你的验证消息加上position:absolute这条CSS语句,它就会在显示时浮于页面内容的上方,从而避免了破坏原来的布局。

  最后,我在项目中修改后,问题解决了。当你输入正确,验证消息会消失,不会影响其他操作。

 

 

相关连接

如何制作好一个提交按扭---我是个爱折腾的人

http://www.cnblogs.com/Wayou/archive/2012/09/19/how_to_make_a_nice_submit.html

<think>好的,我现在需要帮助用户解决调用支付宝接口时遇到的isv.app-call-limited错误码的问题。首先,我要仔细理解用户的问题描述。用户提到在调用支付宝发送消息时遇到了这个错误,并希望找到解决方法。 根据用户提供的引用内容,特别是引用[2],里面提到子错误码以"isp."开头的错误通常由服务端异常引起,但用户遇到的错误码是isv.app-call-limited,看起来属于引用[2]中提到的错误码小于100的平台级错误。在引用[2]的错误码列表中,错误码9对应的是“App Call Limited应用调用次数超限,包含调用频率超限”,解决方案是调整调用频率,等待限频时间过后再调用。此外,淘客的调用频率由系统根据上月交易额自动调整,修改后的频率会在官方论坛公告。因此,我需要确认isv.app-call-limited是否对应错误码9,或者是否有其他相关信息。 接下来,我需要整理解决步骤。首先,错误码isv.app-call-limited表示应用调用次数或频率超过限制。可能的原因包括短时间内频繁调用API、超过每日调用限额,或者应用权限不足。解决方案方面,应该包括检查调用频率、分批处理请求、查看官方公告、优化代码、联系技术支持等。 还需要考虑用户可能的操作环境,比如是否在高峰期调用,是否有异常的调用量激增。此外,用户可能需要检查他们的API调用日志,确认是否有不必要的重复请求,或者是否可以缓存结果以减少调用次数。 另外,参考引用[4]中的钉钉发送消息工具类代码,虽然不直接相关,但可能提示用户在处理消息发送时是否有类似的限流机制,或者是否有代码层面的优化空间,比如使用队列控制发送频率,或者增加重试机制。 需要确保用户理解错误码的具体含义,并按照支付宝的官方建议处理。同时,提醒用户关注官方公告,因为限流策略可能会调整,尤其是在促销活动期间可能会有临时限制。 最后,总结解决步骤,确保用户能够逐步排查问题,并采取相应的措施来避免再次触发限流。同时,建议用户如果自行无法解决,及时联系支付宝技术支持获取帮助。</think>### 解答:如何解决调用支付宝接口出现`isv.app-call-limited`错误? #### 1. 错误原因分析 `isv.app-call-limited`表示**应用调用次数或频率超过支付宝接口限制**,具体可能由以下原因引起: - **调用频率过高**:短时间内频繁调用接口(如每秒多次请求)[^2]。 - **调用总量超限**:当日或当月累计调用次数达到上限[^2]。 - **权限或配额不足**:应用未申请相关接口权限,或接口配额未开通/已耗尽[^3]。 #### 2. 解决方案步骤 ##### 步骤1:**检查调用频率** - **降低请求频率**:通过代码增加请求间隔(例如从每秒多次改为每秒1次),或使用队列控制并发量。 - **分批处理请求**:若需批量操作,分拆为多个小批次发送,避免单次触发限流。 ##### 步骤2:**确认调用配额** - **查看接口文档**:登录[支付宝开放平台](https://open.alipay.com/),检查目标接口的默认调用频率和总量限制。 - **申请配额提升**:若业务需求较大,通过商户账号提交工单申请提高配额。 ##### 步骤3:**优化代码逻辑** - **避免重复调用**:在客户端或服务端增加缓存机制,减少不必要的重复请求。 - **异步处理失败请求**:对因限流失败的请求,记录日志并加入重试队列,延迟后重新发送。 ##### 步骤4:**监控与告警** - **接入监控工具**:使用支付宝的[运营中心](https://openhome.alipay.com/platform/healthCheck.htm)或第三方工具(如Prometheus)监控接口调用情况。 - **设置阈值告警**:当调用量接近限流阈值时触发告警,及时调整策略。 ##### 步骤5:**联系技术支持** 若上述方法无效,通过开放平台提交工单,提供以下信息: - 接口名称(如`alipay.wap.trade.create.direct`) - 错误发生的具体时间、请求参数(脱敏后) - 应用AppID及商户ID #### 3. 示例代码优化(限流控制) ```python import time from ratelimit import limits, sleep_and_retry # 限制每秒最多调用1次(根据支付宝接口配额调整) @sleep_and_retry @limits(calls=1, period=1) def call_alipay_api(params): # 调用支付宝接口的具体实现 response = alipay_client.execute(request) return response ``` #### 4. 预防措施 - **阅读官方文档**:关注接口的[错误码列表](https://opendocs.alipay.com/common/02km9f)和限流规则。 - **压力测试**:上线前模拟高并发场景,验证接口稳定性。 - **灰度发布**:新功能分阶段发布,逐步增加调用量。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值