Fork me on GitHub




« 1 2 3 4 (5) 6 »


Re: Redesign Interface d'Administration
Régulier
Inscrit: 06/01/2006 23:55
Messages: 379
Citation :

Burning a écrit:

Citation :
Pour moi le look des admins des modules ne doit pas etre gere par les dev des modules, mais par le noyau de xoops.


Il faudrait alors que les développeurs de modules existants fasse un gros boulot pour mettre à jour cette standardisation ? Certains modules risquent de rester sur le carreau, non ?... en même temps, PHP5 puis PHP6 pourraient bien faire du darwinisme...

Oui s'ils veulent en beneficier... sinon on peut le faire en gardant la compatibilite avec le system actuel sans aucun pb.
C'est un plus qu'on peut fournir, une façon de travailler et une classe d'affichage que l'on peut utiliser ou pas.

Citation :

Burning a écrit:

Je donne mon avis sur la question de l'admin (au risque de me répéter mais j'ai l'impression que cela va dans le même sens que celui indiqué par Garrath).

-> si une part des modules et notamment l'affichage de leurs rubriques / onglets est prise en charge par xoops on pourrait alors envisager de masquer / afficher certaines rubriques selon les groupes.
oui mais bon en meme temps c des gens qui accedent a l'admin deja non?

Citation :

Burning a écrit:

-> Autrement dit si on souhaite que les contributeurs du site aient un accès limité à l'ajout d'articles (pour un module comme News), à l'ajout de clichés (pour un module comme eXtGallery), etc. sans que l'autorisation de créer de nouvelles catégories ne leur soit accordée :

- fonctionnellement tout va bien car les modules (les mieux conçus) refoulent le contributeur qui clique sur le lien de création des catégories

- du point de vue de l'ergonomie ce n'est pas optimum : le mieux serait de ne pas afficher les accès interdits. Donc organiser un affichage des rubriques d'administration des module conditionné par les permissions de groupes


Outre la logique, les avantages seraient très importants de mon point de vue :

- simplifier la tâche des contributeurs qui ne sont pas forcément initiés au maniement de xoops (ni parfois du web)

- faire de xoops un outil plus "pro" dans le sens où la séparation des rôles webmaster / contributeurs serait directement prévue par le code : le prestataire = le webmaster et le client (en espérant ne pas dire des gros-mots ) = le contributeur.

@+
Dsl, je dois avouer que j'ai pas tout compris

Posté le : 11/10/2007 20:07
Partager Twitter Partagez cette article sur GG+
Re: Redesign Interface d'Administration
Guest_
Re',

@Garrath : vi je comprends que tu ne comprennes pas ! J'ai retrouvé un vieux post ici avec des images dedans qui raconte à peu près la même chose !

@+

Posté le : 11/10/2007 20:33
Partager Twitter Partagez cette article sur GG+
Re: Redesign Interface d'Administration
Semi pro
Inscrit: 05/06/2004 14:25
Messages: 750
Encore une fois, Burning, ton idée de divers niveaux d'accès dans les options, c'est une bonne idée!


Si on essaie de formaliser tout ça (pour pouvoir ensuite gérer l'affichage comme on veut) il faudrait classer tout ce qui se passe dans l'administration.

L'objet de base serait "une opération administrative", ça resterait une entité relativement vague(concrètement, ça serait un jeu de fonctions, voir même de classe, je ne maitrise vraiment pas assez l'OO pour voir ce qui serait mieux). Un exemple: Pour le module news, il y aurait entre autre : valider un article, créer une nouvelle catégorie, modifier un article , modifier une catégorie.

Actuellement on voit que les opérations du même type sont présentées ensemble dans un même onglet.

L'idée serait donc que chaque opération fasse parti d'un ensemble d'opérations sur le même thème.
Dans notre exemple ça serait : gestion des articles, gestion des catégories...

Eventuellement à plusieurs niveaux.
On aurait ainsi un arbre dans lequel les feuilles seraient des opérations, et les nœuds des groupements d'opérations. ( en gros une gestion de catégories et sous catégories, (récursivement n'importe quel nombre de sous catégorie) et dans chaque catégorie : des opérations.

D'ailleurs on pourrait même penser à ne pas faire un arbre, mais un graphe: chaque opération pourrait appartenir à plusieurs groupements thématiques (reste à voir si c'est réellement utile... mais je pense qu'on trouvera des exemples où c'est vraiment utile).

Ensuite, avec ces groupements d'opérations, on attribuerait un droit d'effectuer les opérations, en fonction des groupes xoops par exemple (même si parfois il serait utile d'avoir une gestion en plus par utilisateurs directement, pour ne pas multiplier les groupes, à voir si c'est trop compliqué/lourd/inutile à mettre en place...)
Un droit direct sur chaque opération peut aussi être utile, à voir...

Bon avec toute cette structure, on peut gérer facilement un affichage indépendant du module, et personnalisable : un affichage par défaut serait proposé, mais on pourrait changer la façon de présenter les choses, ou mettre une sorte de homepage pour la gestion d'un module, ou même une homepage générale pour l'admin.
Bref le système serait un peu calqué sur les blocs, qui est bien géré sous xoops à mon avis. (côté structure, car pour administrer, il faut jongler entre plusieurs façons de voir, mais bon la structure ne limite pas les évolutions, (enfin sauf les clonages de blocs, mais bon ça ne concerne pas la gestion de l'administration!))

Donc on pourrait imaginer le résultat en une sorte de homepage à la netvibe, avec chaque bloc une opération administrative à faire, ou même une information administrative (exemple : il y a 5 news en attente de validation) (serait-il utile de séparer réellement les 2 types : opération et information, à mon avis non, ou alors très peu : juste un champ en plus, et encore...à voir). Ceci en homepage de l'administration, mais en plus (éventuellement) la même chose pour chaque module, et on pourrait se balader dans les groupements d'opérations à chaque fois comme ça ( en fait ça permettrait de faire des interfaces vraiment variées et structurées, et ce, sans rien changer dans les modules).
Donc il faudrait qu'à une échelle dans les groupements d'opérations il y ait un groupement "toutes les opérations du module machin_truc"

Reste à voir comment gérer les droits d'opérer, car si c'est du côté du core xoops que ça se fait, il faudrait une standardisation d'au moins une partie des groupements d'opérations, et encore, je ne vois pas trop comment gérer tout ça...)


Tout ça pour remplacer le menu de gauche, et le menu horizontal d'onglets, codé à chaque fois dans le module.

Ensuite, pour la gestion même de l'affichage dans l'admin, un système avec les templates smarty pourrait être utile, même si de ce côté, il semblerait qu'il faille améliorer le système, pour encore mieux séparer informations et affichage...cf une autre discussion avec dugris je crois.
En attendant, une gestion smarty serait quand même une grande avancée côté admin.

Bref en tout cas voilà ce que je pense qui pourrait améliorer xoops côté administration.
Je n'ai pas réfléchi à la réalisation de la chose, donc il se peut que ça soit trop tordu (surtout côté gestion de tout ça dans un module, pour le programmeur du module... le pb étant que ça nécessite une nouvelle version pour tous les modules, ou alors il faut trouver un moyen de secours si le module n'est pas à jour...)

Désolé pour le post long mais j'ai essayé d'être explicite dans ce que je pensais.( et de rendre ça claire en mettant des lignes vides, mais ça ne doit pas suffire... bref merci d'avoir lu jusque là !)

Posté le : 11/10/2007 21:41
Partager Twitter Partagez cette article sur GG+
Re: Redesign Interface d'Administration
Régulier
Inscrit: 06/01/2006 23:55
Messages: 379
hum...

On va faire simple dans un premier temps ;)
Je vous explique ce que l'on peut faire avec quasi aucun developpement sur le xoops actuellement, juste en rangeant les choses correctement.
L'idee c'est juste de pousser l'idee du module system jusqu'au bout (une idee encore arrete en si bon chemin).

Si vous regardez bien ce module, chaque fonction ou categorie sont gerees dans des repertoires sous admin. Chaque fonction/categorie est bien rangee a sa place.
Si on regarde le xoops_version.php on trouve cela :
// Admin things
$modversion['hasAdmin'] = 1;
$modversion['adminindex'] = "admin.php";
$modversion['adminmenu'] = "menu.php";

Cela indique que pour creer le menu d'admin il lance le fichier menu.php (le truc qui s'affiche a gauche en flottant) et pour les index le menu admin.php (en fait la menu centrale qui se presente sous forme de tableau ici)

Le menu.php
$adminmenu[0]['title'] = _MI_SYSTEM_ADMENU1;
$adminmenu[0]['link'] = "admin.php?fct=banners";
$adminmenu[1]['title'] = _MI_SYSTEM_ADMENU2;
$adminmenu[1]['link'] = "admin.php?fct=blocksadmin";
$adminmenu[2]['title'] = _MI_SYSTEM_ADMENU3;
$adminmenu[2]['link'] = "admin.php?fct=groups";
$adminmenu[3]['title'] = _MI_SYSTEM_ADMENU13;
$adminmenu[3]['link'] = "admin.php?fct=images";
$adminmenu[4]['title'] = _MI_SYSTEM_ADMENU5;
$adminmenu[4]['link'] = "admin.php?fct=modulesadmin";
$adminmenu[5]['title'] = _MI_SYSTEM_ADMENU6;
$adminmenu[5]['link'] = "admin.php?fct=preferences";
$adminmenu[6]['title'] = _MI_SYSTEM_ADMENU7;
$adminmenu[6]['link'] = "admin.php?fct=smilies";
$adminmenu[7]['title'] = _MI_SYSTEM_ADMENU9;
$adminmenu[7]['link'] = "admin.php?fct=userrank";
$adminmenu[8]['title'] = _MI_SYSTEM_ADMENU10;
$adminmenu[8]['link'] = "admin.php?fct=users";
$adminmenu[9]['title'] = _MI_SYSTEM_ADMENU12;
$adminmenu[9]['link'] = "admin.php?fct=findusers";
$adminmenu[10]['title'] = _MI_SYSTEM_ADMENU11;
$adminmenu[10]['link'] = "admin.php?fct=mailusers";
$adminmenu[11]['title'] = _MI_SYSTEM_ADMENU14;
$adminmenu[11]['link'] = "admin.php?fct=avatars";
$adminmenu[12]['title'] = _MI_SYSTEM_ADMENU15;
$adminmenu[12]['link'] = "admin.php?fct=tplsets";
$adminmenu[13]['title'] = _MI_SYSTEM_ADMENU16;
$adminmenu[13]['link'] = "admin.php?fct=comments";


et le admin.php je vous mets juste une partie interressantes car le tableau on s'en fout un peu.
foreach($dirlist as $file){
        include 
$admin_dir.'/'.$file.'/xoops_version.php';
        if (
$modversion['hasAdmin']) {
            
$category = isset($modversion['category']) ? intval($modversion['category']) : 0;
            if (
false != $all_ok || in_array($modversion['category'], $ok_syscats)) {
                echo 
"<td class='$class' align='center' valign='bottom' width='19%'>";
                echo 
"<a href='".XOOPS_URL."/modules/system/admin.php?fct=".$file."'><b>" .trim($modversion['name'])."</b></a>n";
                echo 
"</td>";
                
$counter++;
                
$class = ($class == 'even') ? 'odd' 'even';
            }
            if ( 
$counter ) {
                
$counter 0;
                echo 
"</tr>";
                echo 
"<tr>";
            }
        }
        unset(
$modversion);
    }


Donc la il cherche dans chaque repretoire sous admin le fichier xoops_version.php lie a chaque sous-categorie

Et la je remarque une chose, c'est que si je veux rajouter une categorie, d'un cote j'ai un fichier a modifier et de l'autre je n'ai rien a rajouter juste initialiser correctement des donnees (ce qu'il faudrait faire de toutes les manieres)
=> pourquoi le menu.php ne boucle pas sur les memes repertoires?

Et du coup le menu.php devient
// Gestion un peu differente du menu qui apparait en passant la souris
    // sur l'icone du module dans la page d'administration
    //
    // Plutot que le menu soit construit directement ici de ce type là :
    // (exemple tire de wiwimod)
    //$adminmenu[1]['title'] = _MI_WIWIMOD_ADMENU1;
    //$adminmenu[1]['link']  = "admin/index.php";
    //$adminmenu[2]['title'] = _MI_WIWIMOD_ADMENU2;
    //$adminmenu[2]['link']  = "admin/acladmin.php";
    //$adminmenu[3]['title'] = _MI_WIWIMOD_ADMENU3;
    //$adminmenu[3]['link']  = "admin/myblocksadmin.php";
    //
    // Je construit le menu en fonction des parties d'administrations existantes
    // Chaque fonctionalites du menu admin se trouve dans un repertoire sous admin
    // Je recherche donc dans tous les repertoires sous admin les fichiers menu.php
    // et la lecture en boucle en incrementant $i me permet de creer le tableaux de la 
    // meme façon qu'au dessus.
    // L'avantage, je n'ai pas besoins de changer le menu.php a chaque fois que je rajoute
    // ou enleve une fonctionnalite. 
    // Chaque fonctionnalite est rangee dans son propre repertoire et est independante
    
    
    //var_export($xoopsModule->dirname());
    //echo XOOPS_ROOT_PATH.'/modules/Lexicon';
    
$ModuleDirectory XOOPS_ROOT_PATH.'/modules/Lexicon';
    
$admin_dir $ModuleDirectory.'/admin';
    
$handle opendir($admin_dir);
    
    
$i 0;
    while (
$file readdir($handle)) {
        if (
strtolower($file) != 'cvs' && !preg_match('/[.]/'$file) && is_dir($admin_dir.'/'.$file)) {
            include 
$admin_dir.'/'.$file.'/menu.php';
            
$i++;
        }
    }


et chaque sous menu ressemble a cela :
$adminmenu[$i]['title'] = 'Permissions';
$adminmenu[$i]['link'] = 'admin/permission/index.php';


Voila maintenant avec juste cela, on peut ajouter des fonctionalites a l'admin en creeant des entrees menus, juste en rajoutant un repertoire sous admin et en y collant un fichier xoops_version.php et un menu.php

La on a pas touche au code de xoops et on a un truc simple pour pouvoir rajouter enlever en dev sans se prendre la tete des choses dans le menu.
Vous allez me dire et l'ordre d'apparition? il suffit de changer le nom des repertoires de categories. C'est pris dans l'ordre alpha.

Bon maintenant l'affichage de tout cela...

En gros le but de la manoeuvre c'est de detacher l'affichage des traitements. Donc creer une classe qui ne sert qu'a l'affichage en fonction des donnees du module en question.

mon menu admin par exemple de mon module en cours devient
if (isset($_POST['fct'])) {
    
$fct trim($_POST['fct']);
}
if (isset(
$_GET['fct'])) {
    
$fct trim($_GET['fct']);
}
if (isset(
$fct) && $fct == 'users') {
    
$xoopsOption['pagetype'] = 'user';
}
//include '../../mainfile.php';
include 'admin_header.php';
include 
XOOPS_ROOT_PATH.'/include/cp_functions.php';
include_once 
XOOPS_ROOT_PATH.'/kernel/module.php';

if (
is_object($xoopsUser)) {
    
$xoopsModule =& XoopsModule::getByDirname('Lexicon');
    if ( !
$xoopsUser->isAdmin($xoopsModule->mid()) ) {
        
redirect_header(XOOPS_URL.'/',3,_NOPERM);
        exit();
    }
    
$admintest=1;
} else {
    
redirect_header(XOOPS_URL.'/',3,_NOPERM);
    exit();
}
$ModuleDirectory XOOPS_ROOT_PATH.'/modules/'.$xoopsModule->dirname();

if ( 
file_exists($ModuleDirectory.'/language/'.$xoopsConfig['language'].'/admin.php') ) {
    include_once 
$ModuleDirectory.'/language/'.$xoopsConfig['language'].'/admin.php';
} else {
    include_once 
$ModuleDirectory.'/language/english/admin.php';
}
include_once 
$ModuleDirectory.'/class/lexicon_menu.php';
include_once 
XOOPS_ROOT_PATH.'/class/xoopsmodule.php';

$admintest 0;



// Gestion du menu
$error true;

if (
$error != false) {
    
xoops_cp_header();


    echo 
'<script>function submitaction(extra_args) {';
    echo 
'var frm = document.getElementById("thisform"); ';
    echo 
'frm.action = "'.$_SERVER['PHP_SELF'].'"+(extra_args == "" ? "" : "?"+extra_args);';
    echo 
'frm.submit();';
    echo 
'}</script>';
    echo 
'<form id="thisform" action='.$_SERVER['PHP_SELF'].' method=post>';
    
    
$Menu = new menu_onglet();
    echo 
$Menu->getAdminMenu(0,_AM_WIWI_LISTPAGE_NAV);
    echo 
'</form>';
    
xoops_cp_footer();
}



Le menu en lui meme est gere par la classe ici menu_onglet.
C'est elle qui gere et elle n'est absolument pas lie a mes donnees.

C'est juste des tests. On doit pouvoir se passer de toutes references au module quasiment...

Donc fait correctement on peut avoir des gestions de menu a gerer que par des fichiers de parametrages dans des repertoires.
Le look est laisse a la discretion d'une classe unique...
Le tout peut meme etre certainement gere par le meme traitement de base pour tous les modules.
(=> travail en moins pour le dev du module )

On peut meme parametrer aussi de maniere globale au site la classe de menu a instancier. Ce qui nous permetrait de changer de look avec des choix de classes.

Et apres libre aux gens de se creer des onglets, des tableaux, des blocs avec du ajax etc... de toutes manieres tout serait gere en un seul endroit.

La par contre on pousse l'idee plus loin que la ou elle s'est arrete. On l'ameliore c'est tout.
Il n'y a pas de sous menu ou autre de creer.
Il n'y a pas de gestion des acces non plus. Ca ca doit toujours etre geres applicativement derriere.


On peut peut etre penser a des arborescences de sous-menu etc... pousser plus loin

Posté le : 11/10/2007 23:50
Partager Twitter Partagez cette article sur GG+
Re: Redesign Interface d'Administration
Aspirant
Inscrit: 24/09/2006 23:12
De Fès - Maroc
Messages: 62
Redesign de l'interface Admin est une Très bonne idée.
prsq déjà l'interface actuelle est basic niveau Design...

Bonne chance.

si non, j'ai apporté quelques modifications à mon interface Admin :
vous pouvez voir un aperçu ici ==> http://www.img.ville2fes.com/v.php?id=30445Admin-V2F.jpg

à bientôt

Posté le : 31/12/2007 09:10

Cordialement Mehdi.
Partager Twitter Partagez cette article sur GG+
Re: Redesign Interface d'Administration
Guest_
Bravo, très joli !

Par curiosité, combien de temps il t'a fallu pour refaire le design du back office ?

Posté le : 31/12/2007 10:43
Partager Twitter Partagez cette article sur GG+
Re: Redesign Interface d'Administration
Admin Frxoops
Inscrit: 04/02/2003 16:46
De Blois
Messages: 3071
le hack de l'admin proposé par MusS via le module xoopshack est tres bien.
Il faut distinguer le truc sapin de noel et le truc efficace, mais un minimum actuel au niveau look.

Posté le : 31/12/2007 11:12
Partager Twitter Partagez cette article sur GG+
Re: Redesign Interface d'Administration
Aspirant
Inscrit: 24/09/2006 23:12
De Fès - Maroc
Messages: 62
Merci Burning,

ça m'a demandé une petite nuit blanche ;)

la plus grande partie du temps a été consacré à la recherche des codes à modifier ;)

si non design et tout, c'est pas grande chose, j'en ai l'habitude ;)

See U

Posté le : 31/12/2007 11:26

Cordialement Mehdi.
Partager Twitter Partagez cette article sur GG+
Re: Redesign Interface d'Administration
Guest_
vi, le "truc efficace" serait selon moi que le back puisse ressembler au front... et sans passer trop de temps dessus, avoir la possibilité de ré-employer les styles du front.

L'idée de Ville2Fes est excellente (je crois l'avoir vue également chez MrTheme) !


Edit : @Ville2Fes, merci pour l'info. J'essaierai, montre en main

Posté le : 31/12/2007 11:34
Partager Twitter Partagez cette article sur GG+
Re: Redesign Interface d'Administration
Aspirant
Inscrit: 24/09/2006 23:12
De Fès - Maroc
Messages: 62
Attt att,
voilà un petit truc qui est déjà opérationnel et testé :)

===> http://www.img.ville2fes.com/v.php?id=37309admin-new.jpg

à bientôt

Posté le : 31/12/2007 12:42

Cordialement Mehdi.
Partager Twitter Partagez cette article sur GG+

 Haut   Précédent   Suivant
« 1 2 3 4 (5) 6 »



Vous pouvez voir les sujets.
Vous ne pouvez pas débuter de nouveaux sujets.
Vous ne pouvez pas répondre aux contributions.
Vous ne pouvez pas éditer vos contributions.
Vous ne pouvez pas effacez vos contributions.
Vous ne pouvez pas ajouter de nouveaux sondages.
Vous ne pouvez pas voter en sondage.
Vous ne pouvez pas attacher des fichiers à vos contributions.
Vous ne pouvez pas poster sans approbation.

Propulsé avec XOOPS | Graphisme adapté par Tatane, Grosdunord, Montuy337513

47 Personne(s) en ligne (38 Personne(s) connectée(s) sur Forum) | Utilisateur(s): 0 | Invité(s): 47 | Plus ...