jobeet第八天:单元测试

*这一系列文章来源于Fabien Potencier,基于Symfony1.4编写的Jobeet Tutirual

Symfony中的测试

Symfony中有两种类型的测试:单元测试功能测试。单元测试是验证每个方法或者函数是否能够按照预期的结果正确运行。每个单元测试应该尽可能不要对其它模块有依赖关系。而功能测试则是验证整个应用程序的行为是否正确。今天我们先来讲解单元测试,而明天我们将会讲解功能测试。 read more »

jobeet第七天:玩转分类页面

*这一系列文章来源于Fabien Potencier,基于Symfony1.4编写的Jobeet Tutirual

今天我们就来完成第二天内容中Category的需求,实现Category的相关页面:

用户能够查看同一Category中的所有Job信息,并且Job信息能按照最近发布时间进行排序,并且每页显示20条Job信息

read more »

jobeet第六天:更多的数据模型

*这一系列文章来源于Fabien Potencier,基于Symfony1.4编写的Jobeet Tutirual

Doctrine查询对象

在第二天的内容中我们定义了这样一个需求(requirements):“在Job首页显示最近发布的和在有效期内的Job信息列表”。我们现在在首页中显示的是数据库中全部的Job数据,而没有考虑到不需要在首页中显示已过期的Job信息。

read more »

jobeet第五天:路由

*这一系列文章来源于Fabien Potencier,基于Symfony1.4编写的Jobeet Tutirual

URLs

如果你在Jobeet的首页中点击任意一条Job信息,你就会发现这些URL看起来会像是这样的:/job/1/show。如果你曾经使用过PHP来进行网站的话,那你可能更加熟悉这样的URL:/job.php?id=1。那么Symfony是怎么样把URL转换成前一种形式的呢?Symfony是如何根据URL来决定调用哪个ControllerAction的呢?为什么showAction($id)中的$id的值就是需要检索出的Job信息的id呢?这些问题我们会在今天的内容中一一解答。 read more »

jobeet第四天:控制器和视图

*这一系列文章来源于Fabien Potencier,基于Symfony1.4编写的Jobeet Tutirual

在昨天的内容中,我们已经生成了JobController控制器,那么我们今天就来对JobController控制器进行自定义操作。Symfony自动生成的JobController控制器已经有了我们所需要的大部分代码了: read more »

jobeet第三天:数据模型

*这一系列文章来源于Fabien Potencier,基于Symfony1.4编写的Jobeet Tutirual

假若你现在极其渴望打开你的文本编辑器来开始写PHP代码的话,那么今天的内容就能满足你的心愿了,我们会开始写一些代码了。我们将会定义Jobeet中需要使用到的数据模型,并使用ORM来和数据库进行交互,并且我们还会为应用创建第一个模块(module)。由于Symfony已经为我们做了很多工作,所以我们基本不用写太多的PHP代码就能拥有一个功能齐全的模块了。 read more »

jobeet第二天:Jobeet是什么

*这一系列文章来源于Fabien Potencier,基于Symfony1.4编写的Jobeet Tutirual

今天我们同样一行代码也不用写,我们在第一天的时候就已经把开发环境搭建起来了,同时我们还新建好了一个空的Symfony项目。 read more »

jobeet第一天:开始你的Jobeet项目

*这一系列文章来源于Fabien Potencier,基于Symfony1.4编写的Jobeet Tutirual

什么是Jobeet?

Jobeet是一个开源的发布求职信息和招聘信息的网站。在这一些列的教程中我们将学会教你怎么样实现它。通过这Jobeet项目实例教程,你将学会使用最新的Web技术—Symfony2.3.2进行网站开发(你还不知道Symfony是什么?Symfony是一个PHP框架)。 read more »

(Security)怎么样去自定义你的登录表单

在symfony认证中使用form login 认证是一种常见的、灵活的方法。几乎每一个方面表单登录都可以定制。下面介绍完整的默认配置。

 

表单登录配置的参考

要查看完整的form login配置,请参阅SecurityBundle Configuration (“security”)。其中一些有趣的配置选项如下。

 

成功后的重定向

你可以选择各种各样的配置去改变登录成功后的跳转页面。默认情况下页面跳转回用户请求的页面(这个页面就是触发登录表单的页面)例如用户请求http://www.example.com/admin/post/18/edit,最终成功登录,页面还会跳转回http://www.example.com/admin/post/18/edit。这些请求的URL都存储在session中。如果没有URL出现在session中(也许是用户直接去登陆页面),然后将用户重定向到默认页面,也就是默认的首页。你可以通过多种方式完成这种行为。

如前所述,默认情况下将用户重定向到最初的页面。有时,也可能导致问题,像:如果一个后台的ajax请求“appears”是上次访问的URL,那么用户会被重定向到那里,这是不对的。有关控制信息请参阅  How to Change the default Target Path Behavior.

 

改变默认页面

首先,这个默认页面能够被设置(也就是说,如果没有前一个页面被存储在session里,用户会被重定向到默认页面)。要将他设置为default_security_target 路由,请看以下配置:

现在,当session里没有URL时,用户将被定向到default_security_target路由。

 

始终重定向到默认页面

你可以不管页面如何请求,都把URL定向到默认页面,你需要设置always_use_default_target_path为true即可:

 

 

使用Referring URL

如果以前没有URL被储存在session,你不妨尝试使用HTTP_REFERER来代替,因为这往往是相同的。你可以设置use_referer为true来实现(它默认时false):

 

从表单内控制重定向的URL

你可以通过增加一个隐藏的_target_path字段来指定重定向。例如,使用以下方式,将重定向URL设置为account路由。

 

未完待续中。。。。。

(Security)在登录表单使用CSRF保护

当使用登录表单时,你应该确保你的应用免受CSRF(跨站请求伪造)攻击。Security组件已经内置了对CSRF的防御支持。在本文中,您将学习如何在登录表单使用它。 read more »