Recommend Me


Dimanche 6 juillet 2008

Plugins

Classé dans : Camping, Projets, Ruby, bivouac — greg @ 21:45

J’ai mis en ligne, hier, une nouvelle version des plugins iUI’s tent et Tooltip. J’ai également publié le nouveau plugin Reflection’s tent. Ce dernier utilise reflection.js.

Ces trois plugins fonctionnement avec les versions 0.2.x et la future version 0.3.0 de Bivouac.

• • •

Vendredi 4 juillet 2008

Rakefile toujours…

Classé dans : Camping, Projets, Ruby, bivouac — greg @ 19:07

J’ai fait quelques corrections dans les taches Rake pour les applications Bivouac. Cela fonctionne plutôt pas mal, et je vais donc pouvoir penser à passer cette version en phase de tests. Pour cela je vais me pencher sur la réécriture des exemples. De plus, comme Camping à l’air de dormir un peu dans son repository, il semble que j’ai un peu de temps que je vais mettre à profit pour travailler sur la documentation et le site.

En attendant, les dernières modifications sont dans le SVN. Pour ceux qui se demandent encore quelle est la meilleure façon pour faire l’installation depuis les sources, voici la démarche que je vous conseil :

$ svn checkout http://bivouac.rubyforge.org/svn/trunk/bivouac/

$ cd bivouac
$ rake gem

$ sudo gem install pkg/bivouac-0.3.0.gem
• • •

Jeudi 3 juillet 2008

Taches Rake pour Bivouac

Classé dans : Camping, Projets, Ruby, bivouac — greg @ 22:43

Guillaume, qui test a fond Bivouac, m’a fait prendre conscience que migrer une application de la version N-1 à la version N de Bivouac, n’est pas facile, ou tout au moins que cela n’est pas sans danger.

En effet, jusqu’à maintenant cette opération ne pouvait se faire qu’en régénérant l’application sur elle-même, au risque d’écraser certains fichiers.

Pour palier ce problème, je viens d’ajouter 6 taches dans le Rakefile des applications :

  • bivouac:update:app, pour mettre à jour le fichier de l’application, le postamble et le fichier de chargement des helpers
  • bivouac:update:configs, pour mettre à jour le fichier de configuration (environment.rb)
  • bivouac:update:public, pour mettre à jour les fichiers publics (js et css)
  • bivouac:update:scripts, pour mettre à jour les scripts
  • bivouac:update, qui revient à appeler successivement les taches bivouac:update:scripts, bivouac:update:public et bivouac:update:configs
  • bivouac:update:all, qui revient à appeler bivouac:update et bivouac:update:app

Ces modifications font partie de la future version 0.3.0.

• • •

Mercredi 2 juillet 2008

before_filter dans Bivouac

Classé dans : Camping, Projets, Ruby, bivouac — greg @ 19:13

Le développement de la version 0.3.0 de Bivouac avance…

Pour le moment, j’ai modifié le script plugin afin de permettre de récupérer les plugins sur une machine n’ayant pas de client SVN installé. Pour cela j’ai mis en place une méthode de récupération via HTTP.

J’ai également corrigé le générateur qui plaçait le fichier de configuration console.rc au mauvais endroit.

Enfin, j’ai ajouté before_filter. Voici un petit exemple d’utilisation avec la mise en place d’un système d’authentification.

Commençons pas créer une nouvelle application :

$ bivouac test

Ajoutons un modèle User

$ ruby script/generate model User login:string password_salt:string password_hash:string
        create /Users/greg/temp/test_filters/app/models/user.rb
        create /Users/greg/temp/test_filters/db/migrate/001_user.rb
        create /Users/greg/temp/test_filters/db/create.rb

Modifions le fichier app/models/user.rb comme ceci :

require ‘digest/sha2′

module TestFilter::Models
  class User < Base
    def password=(pass)
      salt = [Array.new(6){rand(256).chr}.join].pack("m").chomp
      self.password_salt, self.password_hash = salt, Digest::SHA256.hexdigest( pass + salt )
    end
   
    def self.authenticate( login, password )
      user = User.find_by_login( login )
      if user.blank? || Digest::SHA256.hexdigest( password + user.password_salt ) != user.password_hash
        return nil
      end
      user
    end
  end
end

Nous pouvons dès à présent ajouter un utilisateur dans notre base via la console :

$ ruby script/console  
>> u = User.new
=> #<TestFilter::Models::User id: nil, login: nil, password_salt: nil, password_hash: nil>
>> u.login = "greg"
=> "greg"
>> u.password = "motdepasse"
=> "glatvd"
>> u.save
=> true
>> u = User.find( :all )
=> [#<TestFilter::Models::User id: 1, login: "greg", password_salt: "K6cXb1Om", password_hash: "25233354623a362a303091683a9d4229a72b0a7906293da388b...">]
=> ^D

Ajoutons un controller Admin avec trois actions (login, logout et home) :

$ ruby script/generate controller admin login logout home
        create /Users/greg/temp/test_filters/app/views/admin
        create /Users/greg/temp/test_filters/app/controllers/admin.rb
        create /Users/greg/temp/test_filters/app/views/admin/login.rb
        create /Users/greg/temp/test_filters/app/views/admin/logout.rb
        create /Users/greg/temp/test_filters/app/views/admin/home.rb
        create /Users/greg/temp/test_filters/test/test_admin.rb

Dans la vue app/views/admin/login.rb nous devons mettre en place un formulaire pour la saisie du login et du mot de passe :

module TestFilter::Views
  def admin_login
    unless @error.nil?
      div do
        b @error
      end
    end
     
    form_tag R(AdminLogin) do
      p do
        text "Identifiant : "; br; input :type => "text", :name => "login"
      end
      p do
        text "Mot de passe : "; br; input :type => "password", :name => "password"
      end
      p { input :type => "submit", :value => "Entrer" }
    end
  end
end

La vue app/views/admin/home.rb sera notre page d’administration principale. Nous n’allons rien y mettre de pertinent pour cet exemple à par un lien vers la page de déconnexion :

a "Logout", :href => R(AdminLogout)

Nous n’avons pas besoin de la vue app/views/admin/logout.rb. En effet, quand l’utilisateur demande à se déconnecter il est immédiatement redirigé vers la page de login.

Passons à ma modification du contoller app/controllers/admin.rb. Les parties login, logout et home sont “classiques” :

module TestFilter::Controllers
  class AdminLogin < R ‘/admin/login’
    def get
      if @state[:user].blank?
        @error = nil
        render :admin_login
      else
        redirect R(AdminHome)
      end
    end
    def post
      user = User.authenticate( input.login, input.password )
      if user.nil?
        @error = "Login ou mot de passe incorrect…"
        render :admin_login
      else
        @state[:user] = user.id
        if @state[:redirect].blank?
          redirect R(AdminHome)
        else
          redirect @state[:redirect]
        end
      end      
    end
  end
 
  class AdminLogout < R ‘/admin/logout’
    def get
      @state[:user] = nil
      redirect AdminLogin
    end
   
    alias :post :get
  end
 
  class AdminHome < R ‘/admin/home’
    def get
      render :admin_home
    end
    def post
      render :admin_home
    end
  end
end

Comme vous pouvez le voir, nous stockons dans la session un paramètre :user qui, s’il existe, contient l’ID de l’utilisateur authentifié.

Ce qui nous manque ici, c’est un filtre pour détecter que l’utilisateur est bien identifié quand il arrive sur . Et c’est là que nous utilisons le fameux before_filter.

La première chose que nous allons faire c’est donc de rajouter un filtre dans notre controller :

module TestFilter::Controllers

  # …

  class AdminCheckLogin
    def self.filter( state )
      if state[:user].blank?
        return AdminLogin
      else
        return nil
      end
    end
  end
end

La classe AdminCheckLogin contient notre filtre déclaré via la méthode de classe filter. Cette méthode prend un paramètre correspondant aux données de sessions. Nous vérifions s’il y a bien un user pour la session courante, ci c’est le cas nous renvoyons nil sinon nous renvoyons le classe du controller vers laquelle rediriger l’utilisateur (ici AdminLogin).

Il ne reste plus qu’a déclarer ce filtre. Pour cela nous ajoutons la ligne suivante après la déclaration de la classe AdminCheckLogin :

before_filter AdminCheckLogin, :only => [AdminHome]

Comme vous pouvez le voir, before_filter prend en premier paramètre le nom de la classe de filter et en second un hashage précisant les conditions d’application du filtre.

Faites bien attention. Contrairement à Rails, before_filter utilise des noms de classes et non des symboles. Il est donc important de placer ses filtres en fin de controller avec le before_filter en dernière ligne.

Si vous voulez bénéficier de ces amélioration tout de suite, vous pouvez récupérer les sources.

• • •

Dimanche 29 juin 2008

Bivouac 0.2.5

Classé dans : Camping, Projets, Ruby, bivouac — greg @ 17:49

La version 0.2.5 de Bivouac est en ligne. Au programme, quelques corrections de bug, et la possibilité de forcer l’utilisation d’un server dans le fichier de configuration.

Un grand merci à Guillaume pour ses tests et ses retours…

Pour la prochaine version (0.3.0), je vais travailler sur la possibilité d’envoyer des mails, à la ActionMailer. De plus, la version 2.0 de Camping semblant imminente, je vais travailler sur la compatibilité avec la version 1.9.

• • •

Mercredi 18 juin 2008

periodically_call_remote

Classé dans : Camping, Projets, Ruby, bivouac — greg @ 23:50

Voici un petit exemple d’utilisation de periodically_call_remote avec Bivouac.

Commencez par créer un nouveau projet :

bivouac test

Ajouter ensuite un controller et une action associée :

cd test
ruby script/generate controller periodically call

Modifiez la vue app/views/periodically/call.rb de la façon à obtenir le code suivant :

module Test::Views
  def periodically_call
    h1 "periodically_call_remote"

    div( :id => "refresh-me", :style => "background-color: #eee;") do; end

    periodically_call_remote( :update => ‘refresh-me’, :url => R(PeriodicallyCall), :frequency => 2 )
  end
end

Dans cette vue, nous demandons, via le helper periodically_call_remote, à ce que le div d’id refresh-me (:update => ‘refresh-me’) soit mis à jour toutes les 2 secondes (:frequency => 2) par le contenu renvoyé par PeriodicallyCall (:url => R(PeriodicallyCall))

Ce qu’il faut savoir, c’est que periodically_call_remote utilise un appel de type POST. Donc dans app/controllers/periodically.rb nous gérerons via le GET l’accès à la vue app/views/periodically/call.rb et via le POST nous renverrons le contenu à mettre à jour :

module Test::Controllers
  class PeriodicallyCall < R ‘/periodically/call’
    def get
      render :periodically_call
    end
    def post
      Time.now
    end
  end
end

Vous remarquerez qu’il n’existe pas de render :text => “Bla bla bla” avec Bivouac. Il suffit de renvoyer directement le texte.

Avant de terminer, il ne faut pas oublier de charger les librairies JavaScript (prototype et script.aculo.us). Pour cela, ajoutez la ligne javascript_include_tag :defaults dans le head du layout app/views/layouts/default_layout.rb.

Voila, démarrez le server et connectez-vous sur http://localhost:3301/periodically/call, vous devriez voir une page avec la date, rafraîchie toute les 2 secondes…

• • •

Samedi 7 juin 2008

Bivouac 0.2.4, iUI’s Tent 0.0.3, Scaffold’s Tent 2.0.0

Classé dans : Camping, Projets, Ruby, bivouac — greg @ 0:40

La version 0.2.4 de bivouac, que je viens de mettre en ligne, aurait bien mérité d’être numéroté 0.3.0, tant les modifications sont importantes.

  • Le script console fonctionne enfin correctement. Il gagne également un fichier de configuration (script/console.rc).
  • Le générateur view est deprecated
  • … en contrepartie le générateur controller supporte maintenant les vues :
    ruby script/generate controller my_controller my_action_one my_action_two …
    Cette commande aura pour effet de créer un seul contrôleur (app/controllers/my_controller.rb) et deux vues (app/views/my_controller/my_action_one.rb et app/views/my_controller/my_action_two.rb) correspondantes aux deux actions du contrôleur.
  • Ajout du support des migrations de type RemoveColumnsFromTable.
  • Amélioration du support des layouts. Il y a maintenant un helper, pour les contrôleurs, qui permet d’utiliser la syntaxe layout :my_layout au lieu de @layout = “my_layout”. Pour ne pas utiliser de layout il suffit de passer :none au helper layout.
  • Les layouts sont maintenant placés dans le répertoire app/views/layouts.
  • L’aide des générateurs a été corrigée.
  • cookies_sessions.rb a été déplacé.

Ces changements ont impliqué une mise à jour des plugins Scaffold’s Tent et iUI’s Tent. Ce dernier profite de cette mise à niveau pour recevoir quelques améliorations :

  • iphone_input_text et iphone_input_password ont été modifiés afin d’accepter les options :autocorrect, :autocapitalize, …
  • Le générateur iphone_view est deprecated. Le générateur iphone_controller est rebaptisé iphone.

Sachez enfin que la documentation des plugins est disponible sur le site du projet.

• • •

Mardi 3 juin 2008

Bivouac 0.2.3

Classé dans : Camping, Ruby, bivouac — greg @ 19:34

Je viens de mettre en ligne la version 0.2.3 de bivouac.

Au programme :

  • La configuration de la base de données se fait maintenant via un fichier YAML.
  • Les erreurs de type 404 sont gérées via le controleur et la vue not_found .
  • Ajout du helper FormView#editable_content. Voir http://bivouac.rubyforge.org/svn/trunk/bivouac/examples/bivouac_sample/ pour un exemple.
  • Lors de la génération de modèle et de migration, il est maintenant possible de spécifier et colonnes et leur type :
    ruby script/generate model user name:string mail:string
  • Ajout du support des layouts multiples (Voir http://rubyforge.org/pipermail/camping-list/2008-May/000729.html)
  • Thin n’est plus le serveur utilisé par défaut… Mongrel revient en force ;)
  • Ajout des sessions via un cookie. Vous pouvez préciser, lors de la création d’un projet, si vous voulez utiliser des sessions en base de données ou en cookie (option -S)

Notez qu’il se prépare de grandes choses pour la sortie de la version 2.0 de camping et que bivouac ne passera pas en version 1.0 avant que camping ne sorte en version 2.

• • •

Samedi 24 mai 2008

Camping 2.0

Classé dans : Camping, Ruby, bivouac — greg @ 10:58

La mailling liste camping est active en ce moment et l’on y discute beaucoup de la future version 2.0. C’est pourquoi j’ai mis en stand-by le développement de Bivouac dont je prévoyais la version 1.0 pour bientôt !

• • •

Jeudi 10 avril 2008

Bivouac 0.2.2 et Backpack 0.1.0

Classé dans : Camping, Projets, Ruby, bivouac — greg @ 0:46

La version 0.2.2 de bivouac est disponible. C’est au tour du postamble d’avoir été totalement réécrit. Grâce à cela il est maintenant possible de choisir le serveur à utiliser (WEBRick, Mongrel ou Thin). De plus, vous pouvez binder le serveur sur le port et l’IP de votre choix lors du lancement :

$ ruby script/server -h
Usage: server [thin|mongrel|webrick] [option]
  -p port                : Runs Bivouac on the specified port (default 3301)
  -b ip                  : Binds Bivouac to the specified ip (default 0.0.0.0)
  -d start|stop|restart  : Make server run as a Daemon.

Enfin, Bivouac::Template#copyTemplate et Bivouac::Template#template ont été modifiés afin de permettre leur utilisation par backpack.

Backpack, justement, fait son apparition. Il vous permet de générer simplement le squelette d’un plugin pour bivouac.

$ backpack –help
Usage: backpack [options] plugin_name
backpack is a plugin generator for bivouac

Specific options:
    -g, –generator NAME:TYPE,…    Generator list. TYPE must be ‘view’ or ‘controller’
    -c, –no-controller-helpers      Do not create controller helper
    -v, –no-view-helpers            Do not create view helper

Common options:
    -?, –help                       Show this message
    -V, –version                    Show version

C’est un sous-projet non inclu dans bivouac, a installer donc :

sudo gem install backpack
• • •
« Page précédentePage suivante »
Powered by: WordPress • Template adapted from the Simple Green' Wench theme - RSS