Posté le 24/06/2017 12:51
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 77 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 29/04/2018 11:35 | #
Les deux.
Les scripts qui génèrent les pages HTML du forum généreront /forum/14904-v5-histoire-equipe/2. Parce que dans le navigateur on veut avoir le slug (+ référencement).
L'API qui sera accessible par les scripts, par exemple quand on demandera les nouveautés, renverra 14904. Ainsi les scripts, qui n'ont aucune idée du titre, demanderont /forum/14904. Cette URL doit aussi être acceptée.
Citer : Posté le 29/04/2018 11:39 | #
Pour la postérité, j'avais proposé de garder page dans les paramètres GET, e.g. /forum/discussions/14440/la-v5-une-histoire-d-equipe?page=2 (où discussions représente le slug du forum, mais peut être remplacé par genre actualites, projets, etc).
Bon en vrai j'avais aussi proposé de reprendre la notation en objet de ZdS (qui fait /forums/savoirs/ pour les forums et /forums/sujet/ pour les topics) mais finalement j'aime bien l'arborescence. J'avais aussi proposé d'utiliser des IDs pour les forums en eux-mêmes, mais sur un set de données aussi réduit (généralement moins de vingt entrées, ou guère plus), utiliser le nom c'est loin d'être dramatique.
Mais bon, tout ça c'est du bikeshed
Mon blog ⋅ Mes autres projets
Citer : Posté le 29/04/2018 11:42 | #
Donc deux urls possible pour une page.
Les liens dans les pages retourneront par défaut sur quel url? la version longue ou la version courte?
Quelqu'un pourrai-t’il me faire un exemple de ce à quoi doit ressembler la bdd avec les forums et les topics(et si possible faire la migration sur la bdd car j'arrive pas à le faire)
Ajouté le 29/04/2018 à 11:45 :
Je part sur une licence CeCILL 2.1 donc (au format texte, et au format html)
Citer : Posté le 29/04/2018 11:46 | #
Je suis peut-être pas clair, mais j'ai dit au moins 2/3 fois que tous les liens des pages utilisaient la version longue... >_<
Citer : Posté le 29/04/2018 11:46 | #
Tu ne peux pas définir une licence pour un projet sans obtenir l'accord de ceux qui détiennent le code
Sinon, la CeCILL 2.1 me semble un bon choix.
Mon blog ⋅ Mes autres projets
Citer : Posté le 29/04/2018 11:50 | #
J'ai fait un fork donc je met la licence dessus et si ça ne convient pas je l'enlève, et sur ce topic il à déjà été parlé de mettre la CeCILL comme licence, donc je prend les différents messages disant que c'était la licence à mettre comme l'accord des autres membres(c'était pas des membres mais des admins je crois)
Citer : Posté le 29/04/2018 12:15 | #
Même sur ton fork ou sur toute autre copie, les développeurs originaux, sauf s'ils ont explicitement cédé leurs droits, restent propriétaires de leur code. Les licences libres n'auraient aucun intérêt si on pouvait les contourner aussi facilement
Mon blog ⋅ Mes autres projets
Citer : Posté le 05/05/2018 22:07 | #
HELP ME!
J'ai besoin d'avoir le shéma de la bdd, voir même(comme je suis nul en liaison bdd-python) créer le fichier app/models.py faire la migration et faire une pull request sur mon fork de la v5.
PS: Je préfère la deuxième solution car avec la première je risquerais de foutre de la merde.
Ajouté le 23/05/2018 à 12:10 :
J'aimerais créer une bonne architecture pour le projet, au lieu de tout mettre dans 3~4 fichiers.
l'architecture actuelle est la suivante:
.
├── app
│ ├── forms.py
│ ├── __init__.py
│ ├── models.py
│ ├── routes.py
│ ├── static
│ │ ├── css
│ │ │ ├── container.css
│ │ │ ├── footer.css
│ │ │ ├── global.css
│ │ │ ├── header.css
│ │ │ ├── homepage.css
│ │ │ ├── light.css
│ │ │ ├── navbar.css
│ │ │ ├── responsive.css
│ │ │ └── shoutbox.css
│ │ ├── fonts
│ │ │ ├── desktop.ini
│ │ │ ├── noto_sans.ttf
│ │ │ └── raleway_300.ttf
│ │ ├── images
│ │ │ ├── 3864.png
│ │ │ ├── account-circle.svg
│ │ │ ├── calc.png
│ │ │ ├── calcraft.gif
│ │ │ ├── clonelab.gif
│ │ │ ├── courses.png
│ │ │ ├── email.svg
│ │ │ ├── fa_124.png
│ │ │ ├── fruit_ninja.gif
│ │ │ ├── gravity_duck.png
│ │ │ ├── inbox.svg
│ │ │ ├── laptop.png
│ │ │ ├── legolas.gif
│ │ │ ├── logo_noshadow.png
│ │ │ ├── logo.png
│ │ │ └── message-text.svg
│ │ └── scripts
│ │ ├── contact.js
│ │ ├── pc-utils.js
│ │ ├── smartphone_patch.js
│ │ └── trigger_menu.js
│ └── templates
│ ├── base
│ │ ├── alerts.html.j2
│ │ ├── base.html.j2
│ │ ├── container.html.j2
│ │ ├── errors.html.j2
│ │ ├── footer.html.j2
│ │ ├── header.html.j2
│ │ ├── head.html.j2
│ │ ├── navbar
│ │ │ ├── account.html.j2
│ │ │ ├── forum.html.j2
│ │ │ ├── news.html.j2
│ │ │ ├── programs.html.j2
│ │ │ ├── sprites.html.j2
│ │ │ ├── tools.html.j2
│ │ │ └── tutorials.html.j2
│ │ ├── navbar.html.j2
│ │ └── scripts.html.j2
│ ├── forum.html.j2
│ ├── index.html.j2
│ ├── list_forum.html.j2
│ ├── login.html.j2
│ ├── register.html.j2
│ ├── tutoriels.html.j2
│ ├── validation.html.j2
│ ├── view_topic.html.j2
│ └── viewtuto.html.j2
├── app.db
├── config.py
├── CONTRIBUTING.md
├── migrations
│ ├── alembic.ini
│ ├── env.py
│ ├── README
│ ├── script.py.mako
│ └── versions
│ └── 39259e85e0ed_.py
├── package.txt
├── README.md
├── REQUIREMENTS.md
└── V5.py
11 directories, 73 files
un beau bazar n'est-ce pas?
Le fichier des routes contient environ 15 routes toutes en bazar, les templates sont pas organisées...
(ceci est sur ma branche forum_tutos donc c'est encore en dev mais si on continue la v5 sera tout aussi mal faite que la v42)
Citer : Posté le 23/05/2018 12:38 | #
On a séparé les templates pour pouvoir faire des modifications facilement sans se perdre dans ses fichiers et plusieurs millier de ligne
Citer : Posté le 23/05/2018 14:24 | #
Perso, je ferais une sous-app (qui ont chacune des parties) avec chaque partie du site:
> Une app pour les jeux
> Une app pour les tutoriels
> Une app pour le forum
etc...
ça permet de regrouper ce qui va ensemble mais de garder l'interaction (une app peut appeller une autre app)
Citer : Posté le 23/05/2018 14:25 | #
C'est ce qui était prévu, à mon avis. Juste que ça a pas été fait pour le moment…
Citer : Posté le 23/05/2018 18:07 | #
Intelligide un truc comme ça?
> v5.py
> config.py
> README.md
> REQUIREMENTS.md
> app/
> __init__.py
> jeux/
> //toute l'application jeux
> // autre app...
>__pycache__/
> *.pyc
Ajouté le 23/05/2018 à 18:11 :
Sinon une autre demande que j'ai est d'avoir le maximum de réponses de d'avis sur mon code et ce que je fais, car je le voit bien je suis une des personne qui à le plus de temps pour la v5.
Mais j'ai donc besoin d'avoir des demandes précises et des réactions par rapport à ce que je fait(ou que je ne fait pas)
Je ne sais pas si je doit ouvrir un nouveau topic pour ça, est-ce que je doit en ouvrir un nouveau ou pas?
Citer : Posté le 23/05/2018 19:16 | #
Surtout pas pour les apps. En fait, dans la v5, tout est forum.
Je m'explique : que ce soit les topics, les jeux, les tutoriels, et tous les contenus d'une manière générale, ils se présentent à peut près tous pareil. C'est un contenu principal suivi d'un fil de commentaires.
Si on commence à faire des apps pour chaque truc, ça va être un bronx pas possible à maintenir par la suite. À vrai dire la v42 fonctionne sur ce modèle.
L'idée, c'est de faire une classe "content", dont vont descendre les classes "topic", "program", "tutorial", etc.
À ce moment là, un topic c'est une classe content avec des propriétés de topic (à quel forum il est rattaché, savoir si il est privé ou non, en post-it, whatever) suivie d'un fil de commentaires, un programme c'est une classe content avec des propriétés de programmes (fichiers, images, notes, whatever) suivie d'un fil de commentaires, etc. On obtient quelque chose de beaucoup plus modulable et facile à maintenir.
Par exemple, si on veut ajouter un système de like de messages, ben c'est partout pareil, pas besoin de se faire chier à modifier 50 fichiers. Etc.
Tout ça pour dire que (à priori), plusieurs apps je le sens assez mal.
Citer : Posté le 24/05/2018 10:39 | #
Ok... ben du coup il va falloir avoir un très bon idée de ce que doit être l'algo(sa construction exacte) pour que je puisse structurer mon travail au lieu de faire 5000 urls n'importe comment dans tus les sens.
Est-ce que on à déjà l'architecture de la bdd?
Peut-on créer un second pad dans lequel on mettrais l'architecture de la bdd, celle des formulaires, celle des templates et l'architecture idéale des répertoires et des fichiers?
Citer : Posté le 24/05/2018 12:59 | #
Je vais faire un peu mieux que ça ; je vais créer un topic pour reformuler ce qui est un peu en bordel dans le pad pour que tout le monde puisse le lire. Ce sera l'occasion d'y mettre les diagrammes que j'ai faits et mon début de bdd, ainsi que l'ordre dans lequel il faudra implémenter.
La bdd, comme tu le sais sans doute, sera sous la forme de classes Python grâce à l'Object-Relational Mapping (qu'on peut traduire brutalement par "correspondance classes/base de données"). Il faudra qu'on en parle en détail, mais pour ça le forum semble encore un peu limitant. Une conversation vocale serait plus aisée.
Je vais aller le plus vite possible mais ça prendra sans doute quelque jours à tout reprendre. Stay tuned.
Citer : Posté le 24/05/2018 14:53 | #
Ok, ayant déjà commencé à faire une pause sur mon travail de la v5(pas de commit de puis très longtemps, pas beaucoup de code en plus sur mes fichiers non-commitées...) ça ne me pose pas de problèmes d'attendre. Pour avoir une conversation vocale je ne sais pas quand c'est possible.
De plus je serais heureux d'avoir plus de collaborations des membres de PC sur mon travail(mon fork est ouvert à tous, seule la branche master est protégée).
Je me permet de rappeler que la v5 est un projet communautaire et que tout membre de la communauté peu venir aider.
Mon fork comme dit plus haut est ouvert a toutes les collaborations(dans les limites du GitLab), voici son lien) pour ceux qui en passant voudraient venir voir le code ou nous donner un coup de main.
Je propose donc que mon fork soit un lieu ou toutes les idées soient balancées avant d'être validées(ou pas) par les membres développeurs officiels de PCv5(Développeurs mandatés de Planète Casio)
Citer : Posté le 24/05/2018 14:59 | #
Nope, si on a une idée de feature, le mieux c'est de soit 1) demander sur le forum ou 2) Créer une issue. Ensuite, de proposer une implémentation et d'ensuite de demander avec une merge request via gitlab. C'est vachement plus organisé
Citer : Posté le 24/05/2018 15:01 | #
Il a raison !
Citer : Posté le 24/05/2018 15:02 | #
Effectivement mais doit-on pour autant tout faire sur le repo principal(sachant que personne, excepté les développeurs mandatées, y ont accès)?
Je ne peux, en aucuns cas, créer de branche sur le repo principal, ni même faire un push, je peux uniquement créer des merge requests et des issues.
Ajouté le 24/05/2018 à 15:03 :
C'est aussi pour ces raisons que mon fork existe, je ne pouvais pas participer sur le repo principal.
Citer : Posté le 24/05/2018 15:03 | #
Ben, tu fork, tu dévellopes sur ton fork et tu demandes à merger depuis ton fork
Citer : Posté le 24/05/2018 15:04 | #
Ben ouais, c'est le but. Tu forkes, tu codes, tu merges request. Pis les devs mandatés, qui sont responsables et compétents, acceptent ou pas.