Recommend Me


Friday 4 July 2008

Rakefile toujours…

Filed under: bivouac, Camping, Projets, Ruby — 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
• • •

Hash-ment mieux…

Filed under: Ruby — greg @ 18:10
class Hash
  def <<(h);h.each{|k,v|self[k]=v};end
  alias :to_str :to_s
  def to_s;"{"+self.map{|k,v|k.inspect+" => "+v.inspect}.join(‘, ‘)+"}";end
end
• • •

Thursday 3 July 2008

Taches Rake pour Bivouac

Filed under: bivouac, Camping, Projets, Ruby — 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.

• • •

Wednesday 2 July 2008

Ingrid Betancourt a été libérée…

Filed under: Important, libre — greg @ 22:18

Source : AFP

L’armée colombienne a libéré mercredi dans le sud-est de la Colombie l’otage franco-colombienne Ingrid Betancourt, trois Américains et onze militaires colombiens détenus par la guérilla des Farc, lors d’une opération d’infiltration soigneusement planifiée.

Lire la suire »

• • •

before_filter dans Bivouac

Filed under: bivouac, Camping, Projets, Ruby — 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.

• • •

Flash facile…

Filed under: Web — greg @ 7:54

www.effectgenerator.com vous propose de réaliser en ligne, de façon hyper simple, vos propres animations flash :

• • •

Sunday 29 June 2008

Bivouac 0.2.5

Filed under: bivouac, Camping, Projets, Ruby — 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.

• • •

Thursday 26 June 2008

Gravatar dans les commentaires

Filed under: RubyFR, Friend, Tout et rien — greg @ 18:58

Bien qu’il n’y en ait pas des tonnes, j’ai ajouté la présence de gravatar dans les commentaires. Et tout cela sans utiliser de plugin.

• • •

Thursday 19 June 2008

Distribuer des applications Shoes

Filed under: Shoes, Ruby — greg @ 18:57

Why The Lucky Stiff propose, avec la dernière version de Shoes, une solution absolument géniale pour distribuer ses applications Shoes. Le principe est simple, vous pouvez fabriquer un exécutable Windows et/ou Linux et/ou Mac avec votre application :

shoes-package.png

Pour cela, démarrez Shoes avec l’option -p ou –package sous Windows et Linux. Sous Mac, lancez Shoes et faite un ⌘-x.

Indiquez ensuite le type d’exécutable que vous voulez générer et précisez si vous souhaitez inclure Shoes dans votre exe ou si vous voulez qu’il soit téléchargé depuis internet s’il n’est pas présent sur la machine.

Il ne reste plus qu’a cliquer sur “OK” pour vous retrouver avec un EXE Windows, un DMG Mac et un je ne sais pas* Linux.

* cela ne fonctionne pas sur mon Mac ?!

• • •

Wednesday 18 June 2008

periodically_call_remote

Filed under: bivouac, Camping, Projets, Ruby — 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…

• • •
Next Page »
Powered by: WordPress • Template adapted from the Simple Green' Wench theme - RSS