Использование Sinatra для больших проектов с помощью нескольких файлов



кажется, что в Sinatra все обработчики маршрутов записываются в один файл, если я правильно понимаю он действует как один большой/маленький контроллер. Есть ли способ разделить его на отдельные независимые файлы, поэтому, когда, скажем, кто - то вызывает " / " - выполняется одно действие, и если получено что-то вроде "/posts/2", то другая логика, аналогичная логике, которая применяется в PHP?

599   8  

8 ответов:

вот базовый шаблон для приложений Sinatra, которые я использую. (У моих больших приложений есть 200 + файлов, разбитых таким образом, не считая драгоценных камней поставщика, охватывающих 75-100 явных маршрутов. Некоторые из этих маршрутов являются маршрутами регулярных выражений, охватывающими дополнительные 50 + шаблонов маршрутов.) При использовании Thin вы запускаете такое приложение, используя:
thin -R config.ru start

Edit: теперь я поддерживаю свой собственный монах каркас на основе ниже называется Riblits. Чтобы использовать его для копирования моего шаблона в качестве основы для ваших собственных проектов:

# Before creating your project
monk add riblits git://github.com/Phrogz/riblits.git

# Inside your empty project directory
monk init -s riblits

абсолютно. Чтобы увидеть пример этого, я рекомендую загрузить Monk gem, описанный здесь:

https://github.com/monkrb/monk

вы можете 'драгоценный камень установить' его через rubygems.org. после того, как у вас есть драгоценный камень, создать образец приложения, используя инструкции, связанные выше.

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

Это довольно просто, если вы посмотрите, как Monk обрабатывает его, в основном вопрос о необходимости файлов в отдельных каталогах, что-то вроде (вам нужно будет определить root_path):

Dir[root_path("app/**/*.rb")].each do |file|
    require file
end

выполните поиск Google для "Sinatra boilerplate", чтобы получить некоторые идеи о том, как другие выкладывают свои приложения Sinatra. От этого вы можете, вероятно, найти тот, который соответствует вашим потребностям или просто сделать свой собственный. Это не так уж трудно сделать. По мере разработки новых приложений Sinatra вы можете добавлять их в свой шаблон.

вот что я сделал и использую для всех моих проектов:

https://github.com/rziehl/sinatra-boilerplate

Я знаю, это старый запрос, но я до сих пор не могу поверить, что никто не упомянул Падрино Вы можете использовать его в качестве основы на верхнее Синатры, или по частям, добавляя только камни, которые вас интересуют. Он пинает десять прикладов задницы!

мой подход к размещению различных проектов на одном сайте заключается в использовании sinatra/namespace таким образом:

сервер.РБ

require "sinatra"
require "sinatra/namespace"

if [ENV["LOGNAME"], ENV["USER"]] == [nil, "naki"]
    require "sinatra/reloader"
    register Sinatra::Reloader
    set :port, 8719
else
    set :environment, :production
end

for server in Dir.glob "server_*.rb"
    require_relative server
end

get "/" do
    "this route is useless"
end

server_someproject.РБ

module SomeProject
    def self.foo bar
       ...
    end
    ...
end

namespace "/someproject" do
    set :views, settings.root
    get "" do
        redirect request.env["REQUEST_PATH"] + "/"
    end
    get "/" do
        haml :view_someproject
    end
    post "/foo" do
        ...
        SomeProject.foo ...
    end
end

view_someproject.Haml на

!!!
%html
    ...

еще одна деталь о подпроектах, которые я использовал, состояла в том, чтобы добавить их имена, описание и маршруты к какой-то глобальной переменной, которая используется "/" чтобы сделать домашнюю страницу руководства, но у меня нет фрагмента прямо сейчас.

чтение документов здесь:

Синатра Расширения

похоже, что Sinatra позволяет вам разложить ваше приложение на модули Ruby, которые могут быть втянуты через метод Sinatra "register" или методы "helpers", например:

помощников.РБ

require 'sinatra/base'

module Sinatra
  module Sample
    module Helpers

      def require_logged_in()
        redirect('/login') unless session[:authenticated]
      end

    end
  end
end

routing / foos.РБ

require 'sinatra/base'

module Sinatra
  module Sample
    module Routing
      module Foos

        def self.registered(app)           
          app.get '/foos/:id' do
            # invoke a helper
            require_logged_in

            # load a foo, or whatever
            erb :foos_view, :locals => { :foo => some_loaded_foo }
          end   
        end  

      end
    end     
  end
end

приложение.РБ

#!/usr/bin/env ruby

require 'sinatra'

require_relative 'routing/foos'

class SampleApp < Sinatra::Base

  helpers Sinatra::Sample::Helpers

  register Sinatra::Sample::Routing::Foos

end

когда Монк не работал на меня, я начал работать над шаблонами сам.

Если вы думаете об этом, нет ничего особенного связывая набор файлов. Философия монаха была объяснена мне в начале 2011 года во время RedDotRubyConf, и они специально сказали мне, что это действительно необязательно использовать его, особенно сейчас, когда он вряд ли поддерживается.

Это хорошее начало для тех, кто хочет использовать ActiveRecord:

простой Sinatra MVC

https://github.com/katgironpe/simple-sinatra-mvc

ключом к модульности на Sinatra для более крупных проектов является обучение использованию базовых инструментов.

SitePoint имеет очень хороший учебник откуда вы можете увидеть модульные приложения и помощники Sinatra. Однако следует обратить особое внимание на одну важную деталь. Вы держите несколько приложений Синатра и горы их с Rackup. Как только вы знаете, как написать базовое приложение, посмотрите на config.ru файл этого учебника и наблюдать, как они монтируются независимые приложения Синатры.

Как только вы научитесь запускать Sinatra со стойкой, откроется целый новый мир стратегий модульности. Это, очевидно, приглашает попробовать что-то действительно полезное: теперь вы можете рассчитывать на наличие отдельных драгоценных камней для каждого sub application, что может позволить вам легко версировать свои модули.

Не стоит недооценивать силу использования gem-модулей для вашего приложения. Вы можете легко проверить экспериментальные изменения в хорошо разграниченной среде и легко развернуть их. Так же легко вернуться назад, если что-то пойдет не так.

есть тысяча способов организовать свой код, поэтому не помешало бы попытаться получить макет, похожий на Rails. Однако есть и некоторые большие должности о том, как настроить свою собственную структуру. Этот пост охватывает другие частые потребности большинства веб-разработчиков.

Если у вас есть время, я рекомендую вам узнать больше о Rack, общей основе для любого веб-приложения на основе Ruby. Это может иметь гораздо меньшее влияние на то, как вы выполняете свою работу, но всегда есть определенные задачи, которые большинство людей выполняют в своих приложениях, которые лучше подходят в качестве промежуточного программного обеспечения стойки.

Comments

    Ничего не найдено.