Розширення шаблонів Django

До початку створення філтру потрібно створити каталог templatetags  з файлом __init__.py який вкаже що це папка для пітона і відповідно файл з фільтрами який має мати говорящу назву, оскільки саме з допомогою назви файлу оприділяються наші фільтри в шаблоні, ось так:

{% load ext_filters %} # де ext_filters - це імя нашого файлу
{{ var|cut:"a" }} # це приклад використання фільтру

Власне і вміст нашого файлу:
from django import template
register = template.Library()

@register.filter(name='cut') # можна не вказувати назву філтра, тоді буде 
def cut(value, arg):            взята назва функції
    return  value.replace(arg, '')

таким чином в нашому файлі може визначатись багато фільтрів. Що до каталогу то він повинен бути розміщений в одному із робочих модулів який підключений в INSTALLED_APPS, або може бути венесеней в окремий модуль що також вимагає підключення.

Роутинг в Django

Старт був тут, а це продовження)

urls.py - забезпечує маршрутизацію. Да-да! Геніально! urls.py - забезпечує маршрутизацію для вашого проекта. Все просто, чи не так?) Як же воно там її забезпечує? - запитаєте ви. А так само просто як і називається файл! - відповім вам я і будь хто інший тоже.

Стартуємо з Django (Консоль)

Це перша із серії заміток по фреймворку Django.
Перше з чим прийдеться стикнутись це консоль, з допомогою якої і створюється новий проект, а також інші команди для полегшення життя. Так створюємо проект:
django-admin.py startproject <name_project> #новий проект


В каталозі який відповідає name_project мали появитись кілька файлів, одним із них є manage.py який досить часто використовується для роботи з нашим проектом з допомогою консолі, ось декілька команд:
python manage.py ...  :

• startapp <name_module> #новий модуль
• shell #шел конкретного проекта
• validate #перевірка валідності моделей
• sqlall <name_module> #вивід запитів створення конкретної моделі
• syncdb #виконати запити моделі до БД
• runserver #запуск тестового сертвера
• createsuperuser #створення суперкористувача

Також в корні проекта є urls.py що призначений забезпечити маршрутизацію і settings.py для конфігурації нашого проекта, про них буде пізніше. Що до команд з консолі їх є набагато більше і можна це побачити прямо в тій же консолі)))

Робота з View в Rails

Використання yield в шаблонах:
- шаблон
<html>
  <head>
        <%= yield :head %>
  </head>
  <body>
        <%= yield %>
  </body>
</html>

- вюха
<% content_for :head do %>
  <title>A simple page</title>   // в yield :head
<% end %>
<p>Hello, Rails!</p>  //  в yield


content_for?(:head) - функція для перевірки чи є щось для :head


Використання пратіалів:
- рендер /view/partial/_menu
<%= render "partial/menu" %>

- рендер /view/<controller>/_menu
<%= render "menu" %>

- з використанням шаблону для партіала _menu в _template
<%= render :partial => "menu", :layout => "template" %> 

- для передачі параметрів у партіал
<%= render :partial => "menu", :locals => { :key => @value } %> 

- змінна буде доступна в партіалі під ім'ям партіала без підкреслювання
<%= render :partial => "customer", :object => @new_customer %> 
скорочений варіант попереднього, @customer - модель, буде використано _customer, і модель буде доступна в партіалі <%= render @customer %>

- для рендеру клекції, обєкт буде доступний по імені партіала без підкреслювання
<%= render :partial => "product", :collection => @colection %> 
скорочений варіант <%= render @colection %> якщо в змінній колекції передати різнорідні моделі то буде викоритовуватись партіал відповідно до імені моделі.

Select, Date, часовий пояс в формах Rails

Це коротка замітка із серії про ті ж форми в Rails. Мова буде іти про формування селектів, часового поясу та дати.
Почнем з селектів(скелетний):

<%= select_tag(:city_id, '<option value="1">Lisbon</option>...') %>

формує select;

<%= options_for_select([['Lisbon', 1], ['Madrid', 2], ...], index) %>

формує options для select де index це ключ елемента який має бути вибраним;

<%= options_from_collection_for_select(City.all, :id, :name) %>

формування options прямо з моделі(бази)

Селект для моделі:

<%= f.select(:city_id,  [['Lisbon', 1], ['Madrid', 2],...]) %>

при використанні form builder

<%= select(:person, :city_id, ...) %>

де person це наша модель і має поле city_id, options формується по попередньму принципу, або використовємо:

Форми в Rails

Що до форм, то тут також багато цікавого оскільки розрізняють два види хелперві для роботи з формами: -скелетні хелпери, - модельні хелпери. Почну я з простішого, скелетної форми, а саме це форма з допомогою "form_tag":
<%= form_tag({controller=>:user, :action => :personal}, :method=>:get, :id=>'clsdd') do %>
    <%= label_tag(:user, 'title for text user ', :id=>'id')%>
    <%= text_field_tag(:user, 'text')%>
    <%= text_area_tag(:message, "Hi, nice site", :size => "24x6") %>
    <%= submit_tag(:go)%>
<% end %>

form_tag - приймає першим параметром урл на який буде відселати форму, якщо ви задаєте його рядком символів то все нормальн, а якщо хешем то потрібно відділити як окремий параметер. Далі предаються інші параметри в вигляді продовження хеша, воним можуть бути і опущені. Все  що знаходиться в середині "form_tag" є хелперами для формування тегів форми.
Назви елементів форми є логічними, а закінчення на "_tag" вказує що це простий елемент, першим параметром зазвичай іде ім'я поля, потім значення, і далі можна вказувати додаткові параметри, значення також можна конкретно задати винісши в ":value=> 'значення'";

Моделі в Rails

      Я був чесно кажучи приємно здивований тим наскільки потужниі засоби роботи з базами представлені в Rails. Створення таблиць оформляється в вигляді міграцій, що надає універсальність при підключенні будь якої БД. Моделі предсталяють з себе дійсно моделі в кращих тонах MVC, після того як ви з ними познайомитесь можна вважати що не пусто вони стоять на першому місці)). Чим мені сподобались моделі в рельсах, та усім мені вони сподобались. Оскільки я в рельсах новенький, тай в рубі тоже, але мова зара про рельси, то хочеться сказати що краса коду і лаконічність немає меж, все чітко і логічно без сучка і задорінки). Моделі в rails вміщують в собі таку штукендорину як валідатори, що не може не радувати, оскільки в цьому випадку звязок відчувається здалека. Ні валідатори можуть знаходитись не тільки в моделях, в моделях вони тільки підключаються для коректного заповнення в базу даних. А ще є таке поняття як колбеки, що є важливим атрибутом для моделі, хоча може і не використовуватись як і валідатори. Що до звязків то тут я був найбільше здивований, оскільки звязки є дуже міцними між моделями і зручно контрольовані і взаємозалежними з БД. Логіка яка закладена в вашій базі при написанні всього кількох рядків просто переносяться в ваш проект і це реально зручно. Про Rails і моделі ви можете багато чого знайти в гуглі, а також і по цьому лінку.