Ticket #37 (new enhancement)

Opened 6 years ago

Last modified 1 month ago

Besoin d'un zoli bureau (voire de PLUSIEURS zolis bureaux)

Reported by: benjamin Assigned to: anonymous
Priority: low Milestone: alternc-2.0
Component: Bureau: ergonomie Version:
Severity: major Keywords:
Cc:

Description

Il semble en effet nécessaire de développer d'autres versions graphiques du bureau d'AlternC, mais basées sur les mêmes scripts php.

2 solutions possibles :

1. Utiliser un systeme de templates

+ Permet de maintenir les codes php sans devoir modifier les différents designs de bureau

  • Lourd à mettre en place

2. Créer un nouveau type de bureau, avec le php dedans

+ Souplesse, permet un design illimité.

  • Nécessite de maintenir le code php de chaque bureau :(

Change History

08/19/02 01:37:35 changed by anonymous

Je serai plutot pour la première solution : systeme de templates Ce serait aussi utile pour les differentes traductions du bureau... (enfin, je crois)

11/17/02 19:11:26 changed by anonymous

Qu'importe pour moi, mais on ne pourrait pas faire cela après la version 1.0

09/08/04 16:18:29 changed by benworld2

Le tout en CSS serait un plus, comme ca tout est personalisable.

10/07/04 23:47:33 changed by Brian

Je veux bien participer au point n°1. Cela fait plus de 4 ans que je réalise des templates en PHP.

03/02/05 21:53:35 changed by denis

  • severity changed from tweak to feature.

04/28/05 07:16:04 changed by anarcat

juste pour noter une pensée que j'ai eu:

dans le concept Model View Controler (http://en.wikipedia.org/wiki/MVC), les fichiers dans bureau/class serait le "model", et le "view controller" seraient dans bureau/admin. Plus précisément, on pourrait dire que les fichiers bureau/admin/*_do* sont les controllers, car ils interprètent les entrées de l'usager et opèrent sur le "modèle" (dans class/).

L'idée serait de:

1- sortir tout le code de contrôle de admin/ et le mettre, par exemple, dans controle/ 2- éliminer le plus possible le code de contrôle de admin (en mettant des générateurs de listes et cie dans les fichiers class/, control/ ou simplement des classes communes, par exemple) 3- dès lors, il devient plus facile de faire des nouvelles "vues"

Sans compter le fait que:

1- mort au frames!!! c'est un des bloquants majeurs, selon moi, à la modification de fond en comble de l'interface d'alternc 2- HTML clean + CSS! tout devrait pouvoir être visuellement modifiable sans nécessairement toucher au code. Voir csszengarden pour des preuves.

05/27/05 17:12:36 changed by arnaud_lb

Je verrais bien le controleur en xml-rpc :)

On déplace tous les controls dans les classes m_*, et le "serveur" xml-rpc serait une couche d'identification et permissions d'utiliser les méthodes.

Le xml-rpc rendrais l'utilisation de ces classes en dehors du bureau plus facile (à partir d'un site, en ligne de commande, etc..).

Tous les languages ayant une lib xml-rpc pouront utiliser ces classes

L'identification peut se faire comme pour le bureau, par l'obtention d'un n° de session.

ça me semble aller complètement dans le sens du MVC.

06/07/05 01:59:52 changed by mickipeos

je peux aussi réaliser quelques chartes graphiques pour le bureau AlternC. Il est clair qu'une réalisation à partir de CSS serait la meilleure solution. Ce serait un plus si elle pouvait s'accomoder avec un template ...

modifié le : 08/06/05 17:35

03/31/06 22:00:44 changed by anarcat

  • type set to defect.
  • milestone set to 2.0.

04/10/08 20:08:30 changed by anarcat

Le commit [2104] standardise le code HTML d'AlternC et permet l'override des styles dans custom.css...

04/13/08 23:44:21 changed by anarcat

  • type changed from defect to enhancement.
  • severity changed from feature to major.

À ce stade-ci, je propose de garder le design actuel (soit des templates PHP), mais en essayant de sortir les admin_do*.php dans des fichiers mieux isolés (bureau/control? comme dans un design MVC.

La plupart des modifications devraient pouvoir se faire par le CSS et beaucoup de travail a été fait dans cette direction déjà par Marc Angles et ont été intégrées dans le [2104].

Donc selon moi la seule chose qui resterait à faire ici serait de se débarrasser du système basé sur les frames pour aller vers des "templates" PHP complets (on a déjà un peu ça, par exemple dans head.php...).

Optionnellement, on pourra éventuellement utiliser un autre système de template, mais ça ne me semble pas être un objectif en soit.