Migration ScStyler

Bonjour,
Pour migrer un skin dans Styler (ici de Optim1.4 à Optim1.5), il est nécessaire de recréer le style ex nihilo puis de copier les modifs CSS ?
Merci,
Stéphane.

Bonjour Stéphane,

Plusieurs options sont possibles, soit tu pars de rien et tu copies tes modifs CSS, ça te permettra de récupérer les dernières modifs qu’on a pu faire sur les skins (dans le cas d’Optim, pas la peine).
Soit tu créés uniquement un skinset que tu paramètres pour Optim 1.5 et tu copies le skin.doss d’Optim 1.4.
Soit tu copies tout le skin d’Optim 1.4 (skinset + skin.doss) et tu modifies le skinset via la page « Edition XML » pour modifier les numéros de version, (de 1.4 à 1.5 donc)

Mickaël

Bonjour Mickaël,

Est-ce que la solution suivante pour les skins Scenari ne serait pas une
bonne idée :

  • skin.css qui commence par inclure un base.css (ou main, official,
    origin…) qui contient le style de base.
  • puis un perso.css qui permettrait de surcharger les règles.

Ce serait un peu moins performant, mais dans le cas de petites modifs,
ce serait peut être plus simple pour gérer les montées de version ?

Point2 : sauf erreur l’usage de variables pour les couleurs n’est pas
cross-navigateur, n’est-ce pas ? D’où les définitions en dur et un peu
partout ?

Merci pour ta réponse en tous cas,

Steph.

Bonjour,

C’est effectivement le concept que l’on avait mis en place pour faciliter le stylage d’Opale :

  • main.css : contient toutes les déclarations CSS web par défaut packagées avec le modèle
  • skin.css : vide, mais doit être complété par l’utilisateur. Comme son nom l’indique, fait pour être utilisé dans les nouvelles skins diffusées en skinpack.

http://scenari-platform.org/svn/opale/tags/sc50-v3.8.0.00/model/sources/aurora/web/auroraW.skin.doss/css/

Avant que cela ne fonctionne comme ça, il y avait un seul fichier et je recommandais aux utilisateurs de mettre leur contenu à la fin d’un fichier existant et en délimitant par un commentaire CSS, mais c’est moins clair.

J’ai eu a aider un certains nombre d’utilisateurs universitaires à modifier des skins, et par expérience modifier directement les déclarations CSS existantes, plutôt que par surcharge dans un emplacement isolé, cela fini par une perte de temps lors d’une mise à jour du modèle.

(on pourrait évidement s’en sortir un peu mieux avec des outils de merge si on sait gérer des conflits… mais pourquoi s’embêter avec des conflits s’il suffit de surcharger isolément !)

J’imagine que cela peut être différent avec optim si le modèle est packagé avec plusieurs skins, mais ce n’est pas idéal.

a+

Stéphane