При разработке каталогов и интернет-магазинов часто требуеться иметь под рукой таблицы следующего содержания:

Спасибо добрым людям , разместили у себя и позволяют бесплатно пользоваться этими данными.

На таких людей не жалко и ссылочку поставить:
Canberra

Не всем сайтам необходимо иметь сложные и длинные пароли. Поэтому минимальная длина пароля установленная в ядре kohana 3.2 размером 8 символов иногда требует корректировки в меньшую сторону, например – 3 символа.
Сделать такие изменения можно переопределив метод get_password_validation в нашей модели ‘user’:

 public static function get_password_validation($values)
{
  return Validation::factory($values)
   ->rule('password', 'min_length', array(':value', 3))
   ->rule('password_confirm', 'matches',
           array(':validation', ':field', 'password'));
	}

При регистрации на различных ресурсах мы, как правило, получаем на email ссылку с кодом для подтверждения регистрации. При подверждении регистрации, просить пользователя снова вводить логин и пароль не всегда оправдано (чего ведь не сделаешь для наших любимых пользователей). Поэтому для того, чтобы пользователь автоматически залогинился, перейдя по ссылке с кодом, нам нужен будет метод:

Auth::instance()->force_login($username)

Например, у нас есть некий action confirm в который мы попадаем по ссылке http://sitename/confirm/312ecvfv13E213, где “312ecvfv13E213” – код подтверждения регистрации:

public function action_confirm()
{
//Получаем код регистрации из нашего роута
$code =  $this->request->param('code');

//Проверяем есть ли пользователь с таким кодом (например в таблицу users
//добавим поле 'code', куда предварительно будем записывать
//сгенерированный код подтверждения)

//содаем объект user
$users = ORM::factory('user');

//находим пользователя с наши кодом подтверждения
$user = $users->where('code', '=', $code)->find();

//Если пользователь существует, то, например, добавляем ему
//роль login (а в случае, когда он еще не подтвердил регистрацию,
//то давать ему роль prelogin или не давать вообще никакой роли)

if ($user->id)
{
//например роль 'login' имеет id=1
$user->add('roles', 1);

//И напоследок - автоматически логиним его на нашем сайте
Auth::instance()->force_login($user->username);

//И можем еще перебросить его на "главную"
$this->request->redirect();

}

В форме прописываем checkbox:

id="show<?=id?>"

Вот вариант получения состояния конкретного checkbox:

function showhide(id) {

//Проверяем наш checkbox на :checked
if($("#show"+id).is(":checked"))
{
checked = 1;
}
else checked = 0;
//Записываем состояние checkbox в БД
$.post('/pages/ajax', {
'id': page_id ,
'checked': checked
});
}

В своем проекте использую jQuery для работы с элементами форм и передачи запросов в БД при помощи $.post().
Браузеры по разному обрабатывают и выполняют код js скриптов.
В частности firefox 6 и выше выполняет следующий код:

function chagedata (id) 
{
  $.post('/order/changedata', {
        'id': id
        });
  $.ajax({  
            url: "/shop/cart.html",  
            cache: false,
            success: function(html){  
                $("#cart").html(html);  
         });
}

последовательно, т.е. сначала отрабатывает post, после этого ajax получает данные и мы выводим их на экран.
Другие браузеры, к примеру, Opera 11 выполняет скрипты независимо от их порядка, а по мере поступления отклика от них. В данном случае, post еще не записал данные в БД, а ajax уже вывел html код…
Для того, чтобы все происходило в соответствии с нашим планом, необходимо записать код следующим образом:

$.post('/order/changedata', {
        'id': id
    })
    .done(function() {
        $.ajax({  
            url: "/shop/cart.html",  
            cache: false,
            success: function(html){  
                $("#cart").html(html);  
            } 
        });

т.е. пока не выполнится post, ajax не станет выводить данные.

Часто в таблицах мы храним данные в виде bool значений, например, флаг наличия товаров магазине.
Таблица products:

id name price instock
1 Ботинки 100 1
2 Сапоги 200 1
3 Тапочки 50 0

где instock – флаг наличия товара на складе, 0 – нет товара, 1 – есть.
Из админ панели магазина мы меняем состояние наличия того или иного товара на складе, например, нажатием кнопки “В наличии”.
В нашем скрипте мы выполняем следующий запрос к БД:

UPDATE `products` SET `instock` = IF (`instock` = 0, 1, 0)

таким образом при значении в поле равном “0” мы устанавливаем значение поля равное “1” и наоборот, при равном “1” устанавливаем – “0”.

Posted in SQL.

На Github есть модуль captcha https://github.com/kolanos/kohana-captcha, но для kohana 3.2 в нем надо сделать некоторые изменения. В частности изменить вызовы конфигурационного файла с

$config = Kohana::config('captcha')

на

$config = Kohana::$config->load('captcha')

и заменить старый вариант вызова request:

Request::instance()->headers['Content-Type'] = 'image/'.$this->image_type;
Request::instance()->headers['Cache-Control'] = 'no-store, no-cache,
must-revalidate, post-check=0, pre-check=0';
Request::instance()->headers['Pragma'] = 'no-cache';
Request::instance()->headers['Connection'] = 'close';

на новый:

Request::current()->headers('Content-Type', 'image/'.$this->image_type);
Request::current()->headers('Cache-Control', 'no-store, no-cache,
must-revalidate, post-check=0, pre-check=0');
Request::current()->headers('Pragma', 'no-cache');
Request::current()->headers('Connection', 'close');

Continue reading

В kohana есть замечательный модуль ORM, он значительно облегчает жизнь разработчикам.
Хотя как известно “бесплатный сыр бывает только в мышеловке”.

Используя ORM мы получаем простой и удобный доступ к базе данных, как к обычному объекту, но при этом в конечном итоге kohana все же создает обычные SQL запросы.

Таблица пользователей ‘users’
id role_id name
1 2 Вася
2 3 Петя
3 1 Степа
Таблица ролей пользователей ‘roles’
id role_name
1 root
2 admin
3 manager

Допустим мы создали 2 модели к вышеописанным таблицам:

  • user.php
  • role.php

Continue reading