We are using Hudson now for several months as Continous Integration System. This short article describes how we have configured a hudson project for a symfony 1.4 project. I am assuming that the reader is already used to Hudson and knows how a normal project has to be configured.

PHPUnit is the test framework of our choice (surprise, surprise) and we are using the sfPHPUnit2Plugin for all our projects. If you do not now this plugin you may first read another post where the usage and features are described in detail.

All requirements in short:

* Hudson has to be installed
* Hudson plugin xUnit Plugin has to be installed
* the symfony project needs the sfPHPUnit2Plugin
* PHPUnit has to be installed on your test server

Ok, here the configuration steps of the hudson project:

1. Configure your project

Configure standard settings for a hudson project like source-code management settings or email notifications. Please check the official docs if you do not know how to handle this.

2. Add a shell build step

Building a symfony project in a test environment is pretty easy. With the help of some shell commands the project is completely configured and ready for testing. Those shell commands may be entered in the build step section of the hudson project. Defining the correct commands is the main part during the configuration process.

Our configuration looks like this:

1. cd $WORKSPACE/trunk
2. sh _deployment/install_test.sh
3. php symfony cc
4. php symfony phpunit:test-all –configuration –options=”–log-
5. junit=build/testresult_$BUILD_NUMBER.xml” cd build
6. ln -s -f testresult_$BUILD_NUMBER.xml currentTestResult.xml

1. Jump in the project root of the project
2. Install the project on the test server with the help of a internal shell script. This step includes for example the generation of the databases.yml.
3. Clear the symfony cache (always a good choice)
4. Run all PHPUnit tests including unit and functional tests. The test result is written in a jUnit compatible logfile (needed for the xUnit Plugin).
5. Jump in the build directory, which is internally used by Hudson
6. Symlink the latest testresult

3. Configure Post-Build-Action

After the xUnit Plugin is installed correctly, an additional PHPUnit Pattern field should be displayed in the post build action section. In this field has to be entered:

1 trunk/build/currentTestResult.xml

The options “Fail the build if test results were not updated this run” and “Delete temporary JUnit file” should be both checked.

The xUnit Plugin takes the currentTestResult.xml file, which was previously created with the help of the sfPHPUnit2Plugin and analyzes it. When everything works fine, you should be able to review the created test reports.

Here some screenshots how this result could look like.

Build history:

Trend graph of the test results:

You can find the original post here : http://dev.esl.eu/blog/category/symfony/

Many times when you’re validating forms in symfony you need to do more than what the standard validators allow, and since you’re lazy you don’t feel like creating your own custom validator. sfValidatorCallback to the rescue!

sfValidatorCallback allows you to define your own validation function to be used for a given form field. It also allows you to scrub the data in any way you see fit. We’ll look at both uses.
A Psudo-example

Since you can use the callback validator for literally anything you want, here’s a simple example of how to use a function in your model to validate a field on the form for that model object

In MyObjectForm.class.php:

1.public function configure() {
2. …
3. $this->widgetSchema['some_text_field'] =
4. new sfWidgetFormTextArea(array(‘required’=>false));
5.
6. $this->validatorSchema['some_text_field'] = new sfValidatorCallback(
7. array(‘callback’=>
8. array($this->getObject(), ’someTextFieldValidatorHook’)
9. )
10. );
11. …
12. }

Here we see that we’re setting the validator for some_text_field to our call back. The first parameter to the callback takes our options. For these we need to pass a callback, which takes the same parameters as PHP’s call_user_func. Since we want to call a method in our base model object, we’ll use an array as the first parameter to pass our object and the method we want to call. $this->getObject(); returns the model object of the form, and someTextFieldValidatorHook is what we want to call.

So, in MyObject.php, in your model folder:

1. public function someTextFieldValidatorhook($validator, $value) {
2.
3. //test $value, set $pass if its ok
4.
5. if($pass) {
6. return $value;
7. }
8.
9. else {
10.
11. $message = “I can write whatever I want here based on the results “.
12. “of my test. The point is that this field didn’t validate though”;
13.
14. throw new sfValidatorError($validator, $message);
15.
16. }
17.
18. }

We can see here that the magic is throwing the exception when your test fails. The exception bubbles up and is caught by the form stuff on a higher level to render the error message to the user as you would expect.

Now, there are are a few things to keep in mind:

* sfValidatorError can take a message code and error messages as its second and third parameters. However, most of the time you use the call back, you’ll want to generate the error message internally, since its dependant on the test you just wrote. Still, remember that you can respond with canned error messages if you want.
* Your data hasn’t been saved yet, so you really have no notion of what the other fields are unless you grab the request object and look at them.
* You can make your validation method static if you want, but sometimes its helpful to have the old values of your current object, or you may have expanded your model object to do things beyond the standard get/set stuff.

Is This Cool?

Some may argue that this kind of validation doesn’t belong in your model object, and a separate validator object should be created. I can see that point, and I think I mostly agree with it, but there are exceptions to every rule. Sometimes this simple approach is the correct one, and it can streamline your development.

Still, you should keep in mind that your validation function is going to throw a validator exception, so indicate that you’ll need to catch it in your documentation if the test fails, or name the method something to show that it should only be used as a hook to the validator, as I’ve done with someTextFieldValidatorHook.
Scrubbing

One last benefit of the validator is that it gives you a good way to scrub your data before you save it. Since your callback function (someTextFieldValidatorHook in our case) takes the value in to verify it and returns it at the end if the test passed, you can technically change it to whatever you want. Some possible ideas are:

1. Removing HTML
2. Converting text links to actual links (bad example as you should probably do this on output)
3. Formatting Phone Numbers
4. Etc, etc

That’s It

Hope you found this useful. Feel free to share how you’ve used the callback validator in your applications.

You can find the original post here : http://www.pbtg.com/blogs/jim/tag/symfony

One interesting topic on web development is webservice development. There are several techniques to implement a webservice out there, and today I’ll talk about one technique that I worked in the recent past that I really like: SOAP. As per wikipedia:

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on Extensible Markup Language (XML) as its message format and usually relies on other Application Layer protocols, most notably Remote Procedure Call (RPC) and HTTP for message negotiation and transmission. SOAP forms the foundation layer of the web services protocol stack providing a basic messaging framework upon which abstract layers can be built.

The plan for this tutorial is to build a complete set of webservice methods to interact with the citypicker, built in a previous post. For this, I’ll use a great symfony plugin called ckWebService. This plugin enables the developer to expose your actions as a SOAP webservices. Another great functionality is the built-in WSDL generator, that parses module’s doc comment in order to identify which actions should be exposed and it’s input/output parameters.

Let’s start by installing ckWebService plugin in our symfony project. I’ll not install the latest release, instead I’ll checkout from trunk svn, as it contains some nice improvements if compared to latest release:

info@amphee.com [~/symfony/blog]# cd plugins/
barrosws@barros.ws [~/symfony/blog/plugins]# svn co http://svn.symfony-project.com/plugins/ckWebServicePlugin/trunk ckWebServicePlugin

OBSERVATION: Current trunk version has a small bug (actually a wrong variable name) that must be fixed before continuing:

public function getResultProperty()
{
- return $this->resultMember;
+ return $this->resultProperty;
}

Now we need to configure the plugin in order to make it work. The read-me located at plugin page provides a complete guide to configure it. For this project we use a basic configuration:

apps/frontend/config/app.yml:

soap:
enable_soap_parameter: on
ck_web_service_plugin:
wsdl: soap.wsdl
handler: ckSoapHandler
persist: %SOAP_PERSISTENCE_SESSION%
render: off
result_callback: getSoapResult
soap_options:
encoding: utf-8
soap_version: %SOAP_1_2%

apps/frontend/config/filters.yml:

soap_parameter:
class: ckSoapParameterFilter
param:
condition: %APP_ENABLE_SOAP_PARAMETER%

apps/frondend/config/factories.yml:

soap:
controller:
class: ckWebServiceController

Done! That’s all we need to start exposing actions as SOAP webservices. For now on we can expose any of our previously created action by adding a special tag to the doc comment, like this:

/**
* Action description
* @ws-enable
*
* @param string $name
* @return boolean
*/
public function executeSomeAction($request)
{
/* action here */
}

This doc comment will expose the action and instruct the WSDL generator that this action expects a string input parameter, called $name and that it will return a boolean value. An interesting thing about this plugin is that it will place all input parameters in the $request object, so the action can access it as if it was called from a browser, passing name as a query string or a post value:

…
$name = $request->getParameter(‘name’);
…

Also, notice that $request parameter was removed from the doc comment. This is necessary because if we keep it, the WSDL generator will add $request as a parameter to the webservice, what is not the case here.

Let’s start the implementation for this project. We have three actions that will be exposed:

* executeIndex: to list users;
* executeEdit: to insert/edit users;
* executeDel: to delete users.

One might think that we will need to add @ws-enable to these actions doc comment… well, yes, that’s the original idea, but I prefer using a different approach. My approach is to create a new module, called soap (or whatever you want) and create wrappers to actual actions. This will reduce the number changes needed to be done in the actual actions (sometimes it won’t require any change at all) and will make it possible for the developer to code the entire system without even caring about webservice, all adjustments can be easily made only when actually implementing the webservice. This is not the best way to achieve this result. The correct way to do this is to create a custom SoapHandler, but this will kill WSDL generator, so I’ll stick to my way by now (trunk version has all the necessary changes to make this possible – it’s not the case with latest release).

So, let’s create our new module:

info@amphee.com [~/symfony/blog]# symfony generate:module frontend soap
>> dir+ /home/amphee/symfony/blog/apps/frontend/modules/soap/templates
>> file+ /home/amphee/symfony/blog/app…soap/templates/indexSuccess.php
>> dir+ /home/amphee/symfony/blog/apps/frontend/modules/soap/actions
>> file+ /home/amphee/symfony/blog/app…/soap/actions/actions.class.php
>> file+ /home/amphee/symfony/blog/tes…al/frontend/soapActionsTest.php
>> tokens /home/amphee/symfony/blog/tes…al/frontend/soapActionsTest.php
>> tokens /home/amphee/symfony/blog/app…soap/templates/indexSuccess.php
>> tokens /home/amphee/symfony/blog/app…/soap/actions/actions.class.php

The first action will expose is executeIndex, that will return a list of all users registered in the system. This is the simplest one and I’ll use to explain some important points:

apps/frontend/modules/soap/actions/actions.class.php:

/**
* Get users
*
* @ws-enable
*
* @return SoapUser[]
*/
public function executeGetUsers($request)
{
// call actual action
$this->getController()->forward(‘citypicker’,'index’);

// set result
$actionInstance = $this->getLastActionInstance();
$actionInstance->result = $actionInstance->users;
}

As I said before, we will create wrappers to actual actions. For this action, we don’t have any input parameter, so we don’t need any extra processing. First thing the action does is a forward to actual action. Note that I use the forward method from the controller instead of forward method from sfAction. This is necessary because we need continue our execution flow AFTER actual action returns (sfAction’s forward won’t return control to us). Return value is expected to be located in the deepest action instance, in our case, citypicker/index action, in a property called result (in our case, we store the result of a UserPeer::doSelect() call – made in citypicker/index action and stored in users property). In order to do this we need to get this action’s instance and that’s what getLastActionInstance method do:

apps/frontend/modules/soap/actions/actions.class.php:

/**
* Get last action instance
*
* @return sfActionInstance
*/
private function getLastActionInstance()
{
return $this->getController()->getActionStack()->getLastEntry()->getActionInstance();
}

This method will simply return last actions instance from the action stack, and we will use it in all of our wrappers. If you look at doc comments, you will notice return value is declared as an array of SoapUser objects. SoapUser class is defined as follows:

lib/soap/SoapUser.class.php

class SoapUser
{
/**
* User name
*
* @var string
*/
public $name;

/**
* Country ID
*
* @var integer
*/
public $country_id;

/**
* State ID
*
* @var integer
*/
public $state_id;

/**
* City ID
*
* @var integer
*/
public $city_id;
}
?>

Doc comments are REQUIRED here too, because WSDL generator will use it to build the object definition. When sending result back, our result (array of User objects) will be converted into SoapUser objects, making these properties available.

Our first method is complete. In order to start using it, we need to generate the WSDL definition, using the built-in WSDL generator. The generator will also create the frontend dispatcher, in web/ directory:

info@amphee.com [~/symfony/blog]# symfony webservice:generate-wsdl frontend soap http://blog.barros.ws/symfony
>> file- /home/amphee/symfony/blog/web/soap.php
>> file+ /home/amphee/symfony/blog/web/soap.php
>> tokens /home/amphee/symfony/blog/web/soap.php
>> file+ /home/amphee/symfony/blog/web/soap.wsdl

In order to test it we can use a nice piece of software called SoapUI. This software will read soap.wsdl and build the request, all using a nice GUI. I recommend downloading the trial of PRO version, as it is capable of generating forms (web like) where you can input parameters:

executeDel actions is similar to executeIndex:

apps/frontend/modules/soap/actions/actions.class.php:

/**
* Deletes an user
*
* @ws-enable
* @param integer $id
*
* @return boolean
*/
public function executeDelUser($request)
{
// call actual action
$this->getController()->forward(‘citypicker’,'del’);

// set result
$actionInstance = $this->getLastActionInstance();
$actionInstance->result = true;
}

Now, executeEdit (executeNewUser in our wrapper) is a bit trickier:

apps/frontend/modules/soap/actions/actions.class.php:

/**
* Creates a new user in the system
*
* @ws-enable
* @param SoapUser $user
*
* @return boolean
*/
public function executeNewUser($request)
{
// convert input param from OBJECT to ARRAY
$request->setParameter(‘user’,get_object_vars($request->getParameter(‘user’)));

// call actual action
$this->getController()->forward(‘citypicker’,'edit’);

// check errors
$actionInstance = $this->getLastActionInstance();
if(!$actionInstance->form->isValid()) $this->throwSoapFormException($actionInstance->form);

$actionInstance->result = true;
}

First difference we can note is the fact this action requires one input parameters. In doc comment we declare that this action expects an SoapUser object as input, but the actual action expects an simple array. The first step then is to convert received object into an array. For this we use get_object_vars and after conversion, we set it back to the $request object. Finally we call actual action, that will act as if the user had submitted the form. Next difference is that we need to check if there was any error processing input data. We do this by checking if form, in actual action instance, is valid, and if not return an error message. In order to throw an exception with detailed errors, I created an small method called throwSoapFormException, that will iterate through all errors in the form and build single string, with one error per line:

apps/frontend/modules/soap/actions/actions.class.php:

/**
* Throw a SoapFault error based on form errors
*
* @param sfForm $form
*/
public function throwSoapFormException($form)
{
foreach($form->getFormFieldSchema()->getError() as $e)
$errors[] = $e;

throw new SoapFault(‘ERROR’,implode(“n”,$errors));
}

And that’s it, we can now create new users using the new SOAP interface:

Well, actually one small thing is missing to make it really work… Did u notice that I didn’t touch actual actions yet? Sometimes we don’t need to touch it, but that’s not our case. If you look at citypicker post you will notice that both “del” and “edit” actions redirect the user back to index page on success. We can’t do this when running on soap mode, or we will lose control and we won’t be able to send correct result back to the client. To fix this, we just need to make an small change:

if(!$this->isSoapRequest()) return $this->redirect(‘citypicker/index’);

isSoapRequest is a new method added by ckWebservicePlugin and it will return true when executing the actions via SOAP. Adding this check we just perform the redirect when NOT in SOAP mode.

That’s all we need to talk about how to expose your actions via SOAP, but in order to complete our example, we need to create some methods to fetch countries/states/cities informations. For this we create 6 new actions:

/**
* Get countries list
* @ws-enable
*
* @return SoapGeo[]
*/
public function executeGetCountries($request)
{
$this->result = CountryPeer::doSelect(new Criteria());
}

/**
* Get a country
*
* @ws-enable
* @param integer $id
*
* @return SoapGeo
*/
public function executeGetCountry($request)
{
$this->result = CountryPeer::retrieveByPK($request->getParameter(‘id’));
}

/**
* Get states list
*
* @ws-enable
* @param integer $country_id
*
* @return SoapGeo[]
*/
public function executeGetStates($request)
{
$country = CountryPeer::retrieveByPK($request->getParameter(‘country_id’));
if(!$country) throw new SoapFault(‘ERROR’,'Invalid country’);

$this->result = $country->getStates();
}

/**
* Get a state
*
* @ws-enable
* @param integer $id
*
* @return SoapGeo
*/
public function executeGetState($request)
{
$this->result = StatePeer::retrieveByPK($request->getParameter(‘id’));
}

/**
* Get cities list
*
* @ws-enable
* @param integer $state_id
*
* @return SoapGeo[]
*/
public function executeGetCities($request)
{
$state = StatePeer::retrieveByPK($request->getParameter(’state_id’));
if(!$state) throw new SoapFault(‘ERROR’,'Invalid state’);

$this->result = $state->getCitys();
}

/**
* Get a city
*
* @ws-enable
* @param integer $id
*
* @return SoapGeo
*/
public function executeGetCity($request)
{
$this->result = CityPeer::retrieveByPK($request->getParameter(‘id’));
}

And to finish, we need to create the SoapGeo class, that will store country name and id:

lib/soap/SoapGeo.class.php:

class SoapGeo
{
/**
* ID
*
* @var integer
*/
public $id;

/**
* Name
*
* @var string
*/
public $name;
}

And we’re done. With this we can now build an external app to create/edit/delete users in the database. I spent several days working with the plugin before coming up with this solution and I hope this will save other developers some time dealing with SOAP implementations.

You can find original post here : http://blog.barros.ws/2008/11/16/soap-webservice-in-symfony/

With the amount of plugins published in the symfony site, many great plugins get lost in the maze. With this series of posts, we would like to bring some attention to plugins we use every day or that we think are essential for any symfony developer.

sfSyncContentPlugin

Deploying symfony applications is always a key part of developing and maintaining websites that run on symfony. It is always a recommended practice to do development on a local environment or dedicated development server. It is also recommended to have a QA/staging server that is as close as possible to your production server. Using this well proven method you can spot problems and bugs before everybody else sees or experiences them, you know, those bugs that “only” happen in production, don’t tell me that it never happened to you, I won’t believe you.

Anyway, making changes in a live site is not only not recommended, it should never be done!

When developing and testing symfony applications, a lot of times you need to have a copy of the live data. Or you may have a staging server where you make changes before pushing them to a live site in a production server. symfony already provides a way to deploy code changes to a remote server, but what about uploaded and data files? And database content?

Since we discovered and started using it, we can’t live without thesfSyncContentPlugin plugin by Tom Boutell and Alex Gilbert, also developers ofApostrophe CMS. This plugin helps with all the tasks and needs described above. Using it is quite simple. All you need to do is define your servers in config/properties.ini like this:

[qa]
  host=qa.example.com
  port=22
  user=user
  dir=/var/www/mysite

[prod]
  host=www.example.com
  port=22
  user=user
  dir=/var/www/mysite

[staging]
  host=staging.example.com
  port=22
  user=user
  dir=/var/www/mysite

Make sure to use SSH keys to authenticate to your remote servers, so you don’t get asked again and again for passwords. Then just run the following symfony tasks:

# Migrate files and DB from development to qa
./symfony project:sync-content frontend dev to qa@qa

# Migrate files and DB to production (always make a backup of production before doing this!)
./symfony project:sync-content frontend dev to prod@prod

# Migrate files and DB from QA into development
./symfony project:sync-content frontend dev from prod@prod

Files and DB content are copied accordingly, almost magically. It saves so much time, but please make sure you understand and check the order that you apply in the symfony task. With the power this plugin provides, is very easy, by mistake, to overwrite production data, so again, always make a backup!

Symfony Components are stand alone php libraries that can be handy in the development of php. Those are earlier coupled with the symfony and now available separately from the symfony package.

Just have look at those
YAML : PHP library that speaks yaml. YAML framework is the php library which take yaml as string and convert in to php array. All in all it is great product if you want to use it in any of your php project.
it is open source and available at YAML Component of Symfony

Templating : Which is templating engine, that you can use in any of your php project. It is the templating tool which you can use in any kind of templating system. Available at Templating System

And some other components available like EVENT DISPATCHER, DEPENDENCY INJECTION

And Request Handler The flexible micro-kernel for fast frameworks is coming sooner. have a look at
Symfony Components

All in all if you are now interested in symfony’s some of the features to implement only. THIS IS THE BEST OF COMPONENTS YOU CAN TRUST. AND YET NOT REQUIRED TO USE THE SYMFONY. It shows the robustness of symfony projects.

Here are some of the advantages of SYMFONY Framework..

* Compatible with as many environments as possible
* Easy to install and configure
* Simple to learn
* Enterprise ready
* Convention rather than configuration, supporting fallback calls
* Simple in most cases, but still flexible enough to adapt to complex cases
* Most common web features included
* Compliant with most of the web “bests pratices” and with web “design patterns”
* Very readable code with easy maintenance
* Open-Source

Check it out the new Alpha Symfony 1.3 with new features… SYMFONY 1.3

• WHAT’S NEW IN SYMFONY 1.3

This alpha version will be the next stable release, is not suitable for production use. You can follow its development use by having a look at the Whats new in Symfony 1.3 even if you are willing to explore the .pdf then please click here.

• Upgrading projects from Symfony 1.2 to Symfony 1.3

To upgrade your 1.2 project to a newer version of Symfony 1.3, you will find all the steps and other information through this.. please   Click here This document describes the changes made in symfony 1.3 and what need to be done to upgrade your symfony 1.2 projects. And If you want more detailed information on what has been changed/added in symfony 1.3, you can read the What’s new? tutorial.

• Deprecations and removals in 1.3

Here are some of the deprecations and removals in newer version of symfony 1.3.To find the lists of all settings, classes, methods, functions, and tasks that have been deprecated or removed in symfony 1.3 please Click here

You can find the installation for the symfony 1.3 here Installation

And for the first time user don’t bother here you can have basic installation Getting Started

Here are some of the important links through which you can direct download the source for Symfony 1.3

• sf_sandbox_1_3.tgz
• sf_sandbox_1_3.zip

hi, we all knows tht symfony 1.2 is released . today i want to write about some symfony 1.2 features.

Features
The admin generator will be rewritten from scratch to leverage the new form framework. The main goal is to provide a more customizable and a more flexible admin generator.

The Propel plugin and the Doctrine plugin will be bundled with symfony 1.2. So, as of symfony 1.2, the core team will officially support Doctrine as a first class citizen.

The development of secure applications has always been quite easy with symfony thanks to the use of the ORM, the output escaper, and the CSRF protection. Symfony 1.2 will go one step further by providing native input filtering. We will base this feature on the new filter extension bundled with PHP 5.2.

The framework must simplify the life of the developer on repetitive and boring activities. As most applications send emails, the Swift library, one of the most feature-full and flexible solution for sending emails in PHP, will be integrated into the core.

The JavaScript world evolves very quickly, with lot of great frameworks available (prototype, jQuery, Dojo, mootools, and YUI). all the JavaScript stuff available into a plugin.
The project:deploy task was just a proof of concept. So, it is time to start a discussion on the features we need for a proper deployment task.

The routing is now cached, so you can expect a significant performance boost when you got plenty of routes in your app. Also, the routing class is no more a singleton so you can now extend and reference it easily to fit your needs,

you can download symfony 1.1 from below given  links .

sf_sandbox_1_1.tgz

sf_sandbox_1_1.zip

you can upgrade your existing symfony project into symfony1.2.

Last week, the NetBeans team announced that the next version of their IDE (6.8) will have native support for symfony! That’s a great news for all of us. They have a dedicated page in their Wiki about symfony support in NetBeans, and the NetBeans 6.8 nightly builds already have some basic support for symfony, like the ability to run a task. To learn more, read Tomas Mysik’s blog post about what is already available. That’s exiting, and I think we need to help them building a great IDE for symfony. I highly encourage you to download a 6.8 build, test it with your own projects, and give them feedback.

content from.. http://www.symfony-project.org/blog/2009/07/08/symfony-support-in-netbeans-6-8

You can vote! With over 47,000 nominations, the community has chosen 85 finalists in 12 categories. Take a look at our finalists and pick your favorites, or maybe even discover something useful you hadn’t heard of before. we are going to vote for symfony .

why we are going to vote for SYMFONY ?

chk this link if you want to know about symfony http://www.symfony-project.org/

it show why we r going to vote symfony a best web development tool ever .

Vote For Symfony. go to this link.
http://sourceforge.net/community/cca09/vote/?f=392

from,

jasmin patel

hello readers,

today i w’ll tell you about symfony 2.0  upcoming version of symfony after sucess of symfony 1.0 and 1.2,

One thing is very intersting in symfony 2.0 is it’s  more faster then old versions.

also many features updated and change in controlorrs and many more …

if you want to  know more about symfony 2.0 then  click here

enjoy,

kiran