Я использую onBeforeShow
в моих целевых представлениях для этого.
onBeforeShow : function(evt) {
// gets called everytime the user
// navigates to this view
},
Это функция, которая запускается NavContainer для своих детей в случае навигации. Это описано в NavContainerChild .
Python имеет целый ряд Rails-подобных фреймворков. Их так много, что шутят, что во время типичного выступления на PyCon свет увидит по крайней мере один веб-фреймворк.
Аргумент, что метапрограммирование Rubys сделало бы его более подходящим, неверен ИМО. Для подобных фреймворков метапрограммирование не требуется.
Итак, я думаю, мы можем сделать вывод, что Ruby не лучше (и, вероятно, не хуже), чем Python в этом отношении.
Лично , Я считаю, что Ruby превосходит python во многих отношениях, включая то, что я бы назвал «последовательной выразительностью». Например, в ruby join - это метод объекта массива, который выводит строку, поэтому вы получите что-то вроде этого:
numlist = [1,2,3,4]
#=> [1, 2, 3, 4]
numlist.join(',')
#=> "1,2,3,4"
В python join - это метод объекта строки, но который выдает ошибку, если вы передаете ему что-то кроме строки в качестве объекта, к которому нужно присоединиться, поэтому та же самая конструкция выглядит примерно так:
numlist = [1,2,3,4]
numlist
#=> [1, 2, 3, 4]
",".join([str(i) for i in numlist])
#=> '1,2,3,4'
Есть много таких небольших различий, которые складываются со временем.
Кроме того, я не могу придумать лучшего способа для вносить невидимые логические ошибки, чем делать пробелы значимыми.
Вероятно, есть два основных отличия:
Rails использует их для хорошего эффекта. Вот пример:
class WeblogController < ActionController::Base
def index
@posts = Post.find :all
respond_to do |format|
format.html
format.xml { render :xml => @posts.to_xml }
format.rss { render :action => "feed.rxml" }
end
end
end
Анонимные замыкания / лямбда-выражения упрощают эмуляцию новых языковых функций, которые принимают блоки. В Python замыкания существуют, но они должны иметь имя, чтобы их можно было использовать. Таким образом, вместо возможности использовать замыкания для имитации новых языковых функций, вы вынуждены четко указывать, что вы используете замыкание.
Это используется широко используется в Rails, прежде всего из-за простоты его использования. Чтобы быть конкретным, в Ruby вы можете выполнять произвольный код в контексте класса. Следующие ниже фрагменты эквивалентны:
class Foo
def self.make_hello_method
class_eval do
def hello
puts "HELLO"
end
end
end
end
class Bar < Foo # snippet 1
make_hello_method
end
class Bar < Foo; end # snippet 2
Bar.make_hello_method
В обоих случаях вы можете сделать:
Bar.new.hello
, который выведет «HELLO». Метод class_eval
также принимает String, поэтому можно создавать методы "на лету" по мере создания класса, которые имеют разную семантику на основе передаваемых параметров.
Это так, на самом деле, такое метапрограммирование возможно в Python (и других языках тоже), но у Ruby есть преимущество, потому что метапрограммирование не является особым стилем программирования. Это вытекает из того факта, что в Ruby все является объектом, и все строки кода выполняются напрямую. В результате Class
es сами являются объектами, тела классов имеют self
, указывающие на Class, и вы можете вызывать методы класса по мере его создания.
Это в значительной степени отвечает за степень декларативности, возможную в Rails,
Все это ПОЛНОСТЬЮ "ИМХО"
В Ruby есть ОДИН фреймворк для веб-приложений, так что это единственный фреймворк, который рекламируется для этого языка.
У Python с самого начала было несколько фреймворков, и это лишь некоторые из них: Zope, Twisted , Django, TurboGears (это смесь других компонентов фреймворка), Pylons (своего рода клон фреймворка Rails) и так далее. Ни один из них не поддерживается сообществом Python как «тот, который нужно использовать», поэтому вся «земля» распространяется на несколько проектов.
Rails имеет размер сообщества исключительно, или, по крайней мере, в подавляющем большинстве, благодаря Rails.
И Python, и Ruby вполне способны выполнять эту работу в качестве среды веб-приложений. Используйте то, что нравится ВАМ (и вашей потенциальной команде разработчиков) и с которым можете согласиться.
Некоторые говорят, что тип метапрограммирования, необходимый для реализации ActiveRecord (ключевого компонента рельсов), проще и естественнее выполнять в ruby, чем в python - я еще не знаю python; ), поэтому я не могу лично подтвердить это утверждение.
Я кратко использовал рельсы, и их использование улавливателей / перехватчиков и динамической оценки / внедрения кода действительно позволяет вам работать на гораздо более высоком уровне абстракции, чем в некоторых других фреймворках. (раньше своего времени). У меня мало или совсем нет опыта работы с фреймворком Python, но я слышал, что он не менее эффективен, и что сообщество Python делает огромную работу по поддержке и поощрению питонических усилий.
Я полагаю, нам следует обсуждать не языковые особенности как таковые , а скорее акценты, которые соответствующие сообщества делают на языковых функциях . Например, в Python повторное открытие класса вполне возможно, но редко; в Ruby, однако, повторное открытие класса является чем-то вроде повседневной практики. Отсюда и мой ответ: обычное использование повторного открытия классов.
Сообщество python считает, что делать что-то наиболее простым и понятным способом - это высшая форма элегантности. Сообщество Ruby считает, что умение делать вещи, позволяющие создать крутой код, - это высшая форма элегантности.
Rails - это все о том, что если вы следуете определенным соглашениям, с вами волшебным образом происходит множество других вещей. Это очень хорошо сочетается с рубиновым взглядом на мир, но не соответствует взгляду питона.
Те, кто утверждал, что
безмерный успех Rails фреймворк действительно имеет много делать с языком, на котором он построен
, ошибочно (ИМО). Этот успех, вероятно, обязан больше умному и устойчивому маркетингу, чем техническому мастерству. Django , возможно, лучше справляется во многих сферах (например, встроенный админка) без необходимости использования каких-либо функций Ruby. Я вовсе не осуждаю Ruby, просто защищаю Python!
Настоящий ответ: ни Python, ни Ruby не являются лучшими / худшими кандидатами для веб-фреймворка. Если вам нужна объективность, вам нужно написать код для обоих и посмотреть, какой из них лучше всего соответствует вашим личным предпочтениям, включая сообщество.
Большинство людей, которые отстаивают тот или иной язык, либо никогда серьезно не использовали другой язык, либо «голосуют» за свои личные предпочтения.
Думаю, большинство людей выбирают, с чем они впервые сталкиваются, потому что это учит их чему-то новому (MVC, тестирование, генераторы и т. Д.) Или делает что-то лучше (плагины, шаблоны и т. Д.). Раньше я работал с PHP и познакомился с RubyOnRails. Если бы я знал о MVC до того, как нашел Rails, я бы, скорее всего, никогда не оставил бы PHP. Но как только я начал использовать Ruby, мне понравился синтаксис, функции и т. Д.
Если бы я сначала нашел Python и одну из его сред MVC, я бы, скорее всего, хвалил бы этот язык!
Если бы я знал о MVC до того, как нашел Rails, я бы, скорее всего, никогда не оставил бы PHP. Но как только я начал использовать Ruby, мне понравился синтаксис, функции и т. Д.Если бы я сначала нашел Python и одну из его сред MVC, я бы, скорее всего, хвалил бы этот язык!
Если бы я знал о MVC до того, как нашел Rails, я бы, скорее всего, никогда не оставил бы PHP. Но как только я начал использовать Ruby, мне понравился синтаксис, функции и т. Д.Если бы я сначала нашел Python и одну из его сред MVC, я бы, скорее всего, хвалил бы этот язык!
Because Rails is developed to take advantage of Rubys feature set.
A similarly gormless question would be "Why is Python more suitable for Django than Ruby is?".
Являются ли эти дебаты новой дискуссией «vim против emacs»?
Я программист на Python / Django и до сих пор не обнаружил в этом языке / фреймворке проблемы, которая могла бы побудить меня перейти на Ruby / Rails .
Я могу представить, что было бы то же самое, если бы я имел опыт работы с Ruby / Rails.
Оба имеют схожую философию и выполняют свою работу быстро и элегантно. Лучший выбор - это то, что вы уже знаете.
Я думаю, что синтаксис чище, а Ruby, по крайней мере, для меня, намного более «приятен» - как бы субъективно это ни было!
Два ответа:
a. Потому что рельсы были написаны для Ruby.
б. По той же причине C больше подходит для Linux, чем Ruby