Salut,
on m’a demandé d’ajouter dans mon tuto le rôle de chaque dossier créer
dans
un appli ruby comme par exemple vendor
Quelqu’un aurait un francais ou anglais.
merci
Je pense que
http://www.ilovejackdaniels.com/ruby-on-rails/ruby-on-rails-cheat-sheet/
et
http://www.slash7.com/cheats/rails_files_cheatsheet.pdf peuvent t’aider.
Voila HTH.
Merci, j’ai regardé mais ca n’explique pas tout alors
je vais essayer de le faire et tu vas dire si je me trompe
– app ( la ou il y a les fichiers pour l’appli)
– component ou se trouve tous les composant
– config (??)
Рdb (la ou il la base de donn̩es)
– doc (la doc ? mais quel doc ?)
– lib (che pas )
– public ( ce que vois les utilisateurs
– test (‘lendroit de test’)
– vendor (???)
Dans app, il y a 4 dossiers
Le sous-répertoire controllers : Les classes controlleurs
Le sous-répertoire views contient les patrons d’affichage (templates)
pour
saisir les données
de notre application , les convertir en HTML, et les renvoyer vers le
navigateur
l’utilisateur.
Le sous-répertoire models contient les classes qui modélisent et
encapsulent
les données
enregistrées dans la base de données de notre application. Dans la
plupart
des frameworks,
cette partie de l’applications devient facilement fouillis, pénible,
verbeuse et susceptible
d’erreurs. Rails la rend simple comme bonjour !
Le sous-répertoire helpers contient toutes les classes auxiliaires
servant Ã
assister les
modèle (model), vue (view), et contrôleur (controller). Cette séparation
aide à maintenir
code des classes modèle, vue, et contrôleur centré sur leurs vocations
et
dépouillé.
2006/4/19, Guillaume G. [email protected]:
Un sheet cheat plus complète:
–
Benjamin F.
Ah oui 
Dommage elle était bien 
Le 19 avr. 06 à 16:55, Bolo M. a écrit :
Merci, j’ai regardé mais ca n’explique pas tout alors
je vais essayer de le faire et tu vas dire si je me trompe
– app ( la ou il y a les fichiers pour l’appli)
C’est le lieu ou reside les 3 parties essentielle de l’appli : MVC ou
Model, Vue , Controller.
– component ou se trouve tous les composant
– config (??)
La ou se trouve les fichiers configurations de l’application, entre
autre on y trouve databases.yml qui permet de configurer les base de
données (nom, login, password).
Contient aussi la configuration des environnement : développement,
test et production
Et important aussi les routes de ton appli. C’est en fait un
équivalent de mod_rewrite mais en ruby pure pour simplifier.
Normalement on n’y intervient que pour configurer les base de données.
Рdb (la ou il la base de donn̩es)
Pas que ca. On y retrouve les scripts de migration (dans un sous
repertoire migrate). Anisi que le schéma général de la base de données.
– doc (la doc ? mais quel doc ?)
La doc de ton application si tu en a ecrit. Elle est generé au format
RDOC a partir des différents classes de ton appli.
– lib (che pas )
Pas sur mais il me semble qu’il contient les librairies que tu ecrit
toi meme. Si tu utilise capistrano, il contient aussi les taches de
capistrano.
– public ( ce que vois les utilisateurs)
Plus précisément c’est l’equivalent d’un dossier public_html ou du
dossier root d’un serveur web, c’est la parties accessible au serveur
web.
– test (‘lendroit de test’)
Contient tout le nécessaire pour realiser les diffèrent tests de
l’application. Entre autre parmi les plus importants :
- fixtures : garnitures de test (données servant pour les test)
- units : les test unitaire (test des modèles)
- functionnals: test des controllers
- integrations : les test d’intégration (test toutes l’appli des
modèles aux controllers en passant par les routes)
– vendor (???)
L’endroit ou l’on met les librairie externe (c.a.d fourni par
quelqu’un d’autre que toi) nécessaire a l’application. On y trouve
aussi les plugins.
On y trouve aussi une install rails complete si tu as “freezer” ton
apli. Si c’est le cas c’est cette dernier qui sera utilisé en lieu et
place de celle installé sur le serveur qui heberge l’appli.
Dans app, il y a 4 dossiers
Attention dans certains cas , il y a un dossier api qui contient
l’api destiné aux web services. Mais je croit que avec la 1.1 est les
versions futur on ne l’utilisera pas trop.
enregistrées dans la base de données de notre application. Dans la
vocations et dépouillé.
Voila HTH
2006/4/26, Bolo [email protected]:
Qqn ne l’a pas ? Ca me ferra une base pour la reprendre en francais
Salut,
En fait, si on regarde bien, ya pas grand chose à expliquer,
exemple :
app/
controllers/
helpers/
models/
views/
Dans app/controllers, il y a les contrôleurs.
Dans app/helpers, il y a les helpers pour les vues.
Dans app/models, il y a les modèles
Dans app/views, il y a les vues.
Dans doc/ il y a la doc, dans config/ il y a la configuration,
dans test, il y a les tests (dans test/unit, il y a les tests…
unitaires, dans functional, il y a les tests… fonctionnels, etc.)
Dans log/, il y a… les logs
Dans tmp/, il y a les fichiers temporaires.
Dans tmp/sockets… il y a les sockets (pour MySQL par ex)
Dans tmp/sessions, il y a … euh, les sessions si on ne les
met pas dans la base ?
Dans vendor/plugins… il y a… les plugins
Dans components/ il y a euh… les composants ?
Etc, etc.
C’est l’habitude ou je sais pas quoi, mais je la trouve limpide,
l’arbo…
-- Jean-François.
Salut,
J’ai fait un article d’introduction à Ruby et Rails sur cuk.ch. J’y
décris succinctement les dossiers de rails :
http://cuk.ch/articles.php?unique=980&categorie_rech=humeur
NP
Le 26 avr. 06 à 16:48, Jean-François a écrit :
Merci,
il est super bien ton article tres complet
Le 26/04/06, Nicolas P. [email protected] a écrit :
Merci !
NP
Qqn ne l’a pas ? Ca me ferra une base pour la reprendre en francais
Le 26/04/06, Benjamin F. [email protected]
a
écrit :
Bonjour Nicolas,
Le 26/04/06, Nicolas P.[email protected] a écrit :
J’ai fait un article d’introduction à Ruby et Rails sur cuk.ch. J’y
décris succinctement les dossiers de rails :
http://cuk.ch/articles.php?unique=980&categorie_rech=humeur
On peut faire des remarques ? Quitte à faire mon chipoteur (voire
le chieur de service 
Exemple : au début “Dans Ruby tout est un objet.”
Ouais, moi aussi, ça m’est arrivé d’utiliser ce raccourci, mais bon
c’est
un peu inexact… (pour ne pas dire faux :-))
J’ai trouvé d’autres chipotages de ce genre en lisant (rapidement)
ton article.
-- Jean-François.
Ah ?
Je serai bien curieux de savoir ce qui n’est pas objet en Ruby.
Je pensais que c’était le cas.
Quelqu’un pourrait-il éclairer ma lanterne ?
–
Guillaume “Zifro” DESRAT
http://…/
– Aah Jeez…I Wish You Could See This…Lights Coming Up…I’ve
Never Seen A Painting That Captures The Beauty Of The Ocean…I’m
Gonna Make You Rich, Bud Fox…Rich Enough You Can Afford A Girl Like
Darien…This Is Your Wake-Up Call, Pall…Go To Work…DROP IT!!!
(3 Steps Ahead - Drop It)
Le mercredi 26 avril 2006 Ã 22:24 +0200, Guillaume “Zifro” DESRAT a
écrit :
Ah ?
Je serai bien curieux de savoir ce qui n’est pas objet en Ruby.
Les méthodes, qui ne sont pas objet par nature (même si tu peux les
encapsuler dans des objets).
Ceci dit bon, le full objet ou pas c’est un joli argument mais quand le
langage est bien fait ce n’est franchement pas le critère important.
Salut,
Je serai bien curieux de savoir ce qui n’est pas objet en Ruby.
Je pensais que c’était le cas.Quelqu’un pourrait-il éclairer ma lanterne ?
Et bien par exemple, les variables. Une variable est une référence
à un objet mais pas un objet en lui-même, il n’y a pas d’ailleurs,
de classe Variable. Si tu fais a = Array.new, a.class te retourne la
classe de l’objet pointé mais pas la classe de a proprement dite.
De même, les constantes. Ou les structures de contrôle (if…)
(ça l’est, je crois bien en Smalltalk).
Tout ceci n’est pas gênant, comme le dit Eric. Mais si on cherche
à établir une sorte d’échelle de gradation objet, Ruby l’est
plus que le C ( ), plus que le Perl, plus que Python, moins que
Smalltalk…
-- Jean-François.Tout ceci n’est pas gênant, comme le dit Eric. Mais si on cherche
à établir une sorte d’échelle de gradation objet, Ruby l’est
plus que le C (
Smalltalk…
Puis-je ajouter, sans froisser personne, que Ruby est beaucoup plus
OO que Java qui l’est plus que C++ qui l’est plus que C qui ne l’est
pas du tout ?
Smalltalk est, d’après tout ce que j’ai pu entendre, un sacré langage !
Si je devais apprendre d’autres langages je serais tenté par
Smalltalk et Lisp (ok c’est pas très utile tout ça, et alors ?). Et
puis le japonnais, le mandarin, l’arabe et le russe…
Et vous ?
NP
On peut faire des remarques ?
Bien sûr !
Exemple : au début “Dans Ruby tout est un objet.”
Ouais, moi aussi, ça m’est arrivé d’utiliser ce raccourci, mais bon
c’est
un peu inexact… (pour ne pas dire faux :-))
héhé ! Effectivement ! Tout n’est pas un objet !
Tu l’auras bien compris, c’était une introduction à Ruby et Rails
( Cuk est un site d’informatique généraliste - certes pro mac, mais
pas outre mesure - mais qui ne traite pas tous les jours de
programmation car les lecteurs ne sont pas tous, loin de là ,
programmeurs). Dire que tout est un objet en ruby était simpliste.
Dans la plupart des introduction à Ruby, on dit ça (cf. from Java to
Ruby de je ne sais plus qui et très récemment (hier ?) une
introduction au Ruby pour les railistes => si ça intéresse qlqun je
peux retrouver l’article).
Après, on peut rentrer dans les détails et toute personne souhaitant
connaître davantage le langage est (plus ou moins) obligé de lire
Programming Ruby où cette vérité abusive est contre-dite. J’espère
que ceux qui m’auront cru et auraient porté tout leur espoir sur le
fait que tout est un objet en Ruby ne m’en voudrons pas alors de leur
avoir (un peu) menti.
Aussi en déclarant que tout est un objet, je mets Ruby dans la case
des langages Orientés Objet dès leur création et qui offrent ainsi,
notamment, un fort niveau d’abstraction et une manipulation
particulière et relativement libre des types.
J’ai trouvé d’autres chipotages de ce genre en lisant (rapidement)
ton article.
Vraiment n’hésite pas ! Je n’ai pas eu énormément de retours sur les
défaults techniques de mon article. Il y en a évidemment : des
approximations, des petites simplifications… N’hésite pas à me dire
où ça ne va pas. La prochaine fois que je ferais un article de ce
genre, je tiendrais compte de vos remarques !
à bientôt
NP
Le 27/04/06, Nicolas P.[email protected] a écrit :
Tout ceci n’est pas gênant, comme le dit Eric. Mais si on cherche
à établir une sorte d’échelle de gradation objet, Ruby l’est
plus que le C (
Smalltalk…Puis-je ajouter, sans froisser personne, que Ruby est beaucoup plus
OO que Java
J’ai pas mis Java dans la liste, car j’étais pas sûr, les entiers
sont des objets en Java ?
qui l’est plus que C++ qui l’est plus que C qui ne l’est
pas du tout ?
En même temps on peut faire de l’objet en C
On encapsule tout ça dans des structures avec des pointeurs
de fonctions et zou
ça me fait penser aussi à un autre point sur lequel j’ai tiqué
dans ton article dont je ferai les remarques plus tard, car il est
tard, le C++ comme un patch du C, ouais, c’est un point de vue…
Au départ, c’était pas une lib en C ? c’est plus propre qu’un patch
Smalltalk est, d’après tout ce que j’ai pu entendre, un sacré langage !
C’est intéressant de voir comment il a grandement influencé Ruby.
Les blocs de code, ça vient (je crois) de là . Les histoires de
“tout objet”, de métaclasse (mais il y a des différences). Le fait
qu’un objet soit un receveur à qui l’on envoie des messages.
Les messages cascadés (les appels de méthode en chaîne).
nil vient du lisp ou de Smalltalk ? Les symboles. Les opérations
sur les collections (énumérables) : each, collect, detect…
Ruby a un côté : Smalltalk mais en plus lisible et plus “naturel”.
(expression)
ifTrue: [ … ]
ifFalse: [ … ].
est qd même moins clair que :
if (expression)
…
else
…
end
C’est vrai que la machine virtuelle, le garbage collector, ça
existait déjà avec ST, bien avant Java…
Si je devais apprendre d’autres langages je serais tenté par
Smalltalk et Lisp (ok c’est pas très utile tout ça, et alors ?).
ça dépend si tu utilises emacs…
A mon avis, il faut connaître à la fois la programmation procédurale,
orientée objet et fonctionnelle.
Sinon, je me mettrais bien plus sérieusement à Erlang et
Haskell (mais le gros morceau je pense c’est de digérer la notion
de Monades)
Et puis le japonnais, le mandarin, l’arabe et le russe…
On peut pas complètement comparer les langages de programmation
et les langues. Rien que pour le vocabulaire par exemple, ya qu’Ã voir
le nombre de mots réservés existant en Ruby…
-- Jean-François.
PS : on est en train de dévier du sujet initial, il serait peut-être
temps de choisir un autre Subject: d’autant plus que celui-ci
souffre d’un problème de pluralisation
Le 27 avr. 06 à 02:38, Jean-François a écrit :
sont des objets en Java ?
Je considéré, peut-être à tord, qu’il y a non seulement des capacités
à faire de l’OO mais aussi des questions de niveau de programmation
OO et l’entendu des possibilité OO que propose un langage. Là je peux
me tromper je ne suis pas une star de Java (ni Ruby à vrai dire) mais
il me semble que Ruby est OO de partout (pas d’implémentation
explicite d’une couche OO) ; ruby est OO à haut et bas niveau ; et
Ruby offre des possibilité OO poussées avec les blocks (d’où viennent
les each(), collect()…), les enchaînements de méthodes, les
symboles, nil , tout ce que tu décris plus bas.
Après y a-t-il un expert Ruby dans la salle pour nous en dire plus ?
qui l’est plus que C++ qui l’est plus que C qui ne l’est
pas du tout ?En même temps on peut faire de l’objet en C
On encapsule tout ça dans des structures avec des pointeurs
de fonctions et zou
Certes. C peut être OO mais ne l’est pas par nature.
ça me fait penser aussi à un autre point sur lequel j’ai tiqué
dans ton article dont je ferai les remarques plus tard, car il est
tard, le C++ comme un patch du C, ouais, c’est un point de vue…
Au départ, c’était pas une lib en C ? c’est plus propre qu’un patch
héhé, désolé, c’était un peu un raccourci d’énonciation. Ce n’est un
patch mais C++ dérive de C. J’ai mis ça en image par le patch. Ca ne
fait pas de C++ un mauvais langage OO mais il est incontestablement
plus lourd à utiliser que quelque chose comme Ruby. C’est ce que j’ai
voulu exprimer, sans vouloir amoindrir C++, même si ça n’était pas
juste.
else
…
endC’est vrai que la machine virtuelle, le garbage collector, ça
existait déjà avec ST, bien avant Java…
Haskell (mais le gros morceau je pense c’est de digérer la notion
de Monades)
Ouais emacs, ça paraît un peu chaud, je ne suis pas programmeur à
temps complet, alors faire de la programmation sous lisp paraît
difficile. Mais je serai curieux d’apprendre les fondement de Lisp et
Smalltalk sans programmer dans ces langages.
Erlang et Haskell, je suis infoutu de dire quoi que ce soit là
dessus. Ca m’intéresse vivement ! J’ai commencé un peu de
programmation il y 6 ou 8 ans avec du C++ et du Java. J’ai alors été
assez dégoûté par ces langages. Je suis passé par du PHP et pas mal
de programmation de page web (xhtml/css…) Je n’ai été reconquit à
la vrai programmation qu’avec ruby (et rails), récemment. Et je me
rend compte adorer ça. Je vais me renseigner sur ces 2 langages !
Et alors les Monades… connaît encore moins !
Et puis le japonnais, le mandarin, l’arabe et le russe…
On peut pas complètement comparer les langages de programmation
et les langues. Rien que pour le vocabulaire par exemple, ya qu’à voir
le nombre de mots réservés existant en Ruby…
C’était une blague… Mais ayant fait des études littéraires
(toujours en licence de lettre d’ailleurs), j’ai été étonné de voir
dans mes cours de linguistique l’importance de l’aspect mécanique de
la langue.
-- Jean-François.PS : on est en train de dévier du sujet initial, il serait peut-être
temps de choisir un autre Subject: d’autant plus que celui-ci
souffre d’un problème de pluralisation
J’arrête sur ce sujet, je promets !
NP
P.S. : Problème de pluralisation
réglée_______________________________________________
Railsfrance mailing list
[email protected]
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance