Recherche avancée

Sur d’autres sites (9465)

• XDCam EX gets some friends

  21 octobre 2009

  Sony has announced a couple new additions to the XDCamEX family - the PMW-350 and the PMW-EX1R.

  The 350 is a shouldermount camera with interchangeable lenses and 2/3" chips. That puts it somewhere between the 1/2" PDW-F355 and the 2/3" 4:2:2 PDW-700.

  

  The EX1R is a minor bump to the EX1, adding features that users have asked for, like a dedicated viewfinder and a DVCam recording mode.

  For me, the most interesting bit of news is that Sony is launching the "MEAD-MS01," an SXS to MemoryStick adapter. I guess Sony noticed that many EX1 and EX3 users have been using SD adapters, and decided to get into that market. And of course, they had to use everyone’s least favorite flash format, Memorystick. I’ll stick to my SD cards for now, but it’s nice to see Sony "legitimize" that recording option a bit.

• Evolution #3151 (Nouveau) : Gestion des statuts et WorkFlow

  18 janvier 2014, par YannX spip

  Pour etendre le workflow de SPIP, une exploration du code montre la possibilité d’ajouter des statuts nouveaux pour un objet editorial, qui seront traites dans intituer_objet et puce_statut mais pas de "gerer" les transitions de ces nouveaux statuts (en particulier dans #FORMULAIRE_INSTITUER_OBJET :
  - si j’ai bien compris, il est neanmoins possible de surcharger inc_puce_statut_dist,
  mais cela implique de recoder tout le fichier.php concerné

  je propose l’evolution suivante :
  1°/ migrer la fonction lister_statuts_proposés() depuis #FORMULAIRES_INSTITUER_OBJET dans inc/puce_statuts
  avec une syntaxe d’appel etendu (voir ci-dessous)
  2°/ definir deux autorisations nouvelles,
  avec instanciations pour les objes editoriaux traditionnels ,
  #AUTORISERinstituer_rapide...... qui permettrait ulterieurement de piloter de facon personnalisée _ACTIVER_PUCE_RAPIDE
  et surtout
  #AUTORISERproposer_statuts qui serait appelée par la version modifiée de lister_statuts_proposés() dans inc/puce_statut.php : celle-ci passerait donc les arguments identifiants ’objet’ et ’id’ pour faire appel à l’autorisation ; de plus elle devrait a mon humble avis recevoir, le statut actuel de l’objet (à passer en option pour l’autorisation), voire meme le statut visé (lors de l’appel de controle dans le #FORMULAIRE_INSTITUER_OBJET, pour controler effectivement le droit de traitement) en paramètres pour les transferer dans le $options : il me semble que cela pourrait eviter de devoir relire en SQL l’objet concerné pour traiter de son statut actuel !

  Dès lors, il sera possible, me semble-t-il, de gerer n’importe quel work-flow ou circuit de validation etendu, simplement en utilisant les primitives standard et API de SPIP, sans devoir passer par des circonlocutions sur les rubriques, et surtout sans devoir modifer quelque code natif du core.

  Ce qui devrait permettre aux utilisateurs de la Fabrique de traiter presque completement toute application ;
  - il ne restera qu’a proposer plusieurs formulaires correspondants à plusieurs stades de traitement de l’entite
  - il serait envisageable de generaliser certaines #SAISIES pour accéder à une liste de selection de cet objet

  <em>Cette réflexion a été initalisée suite à des cas pratiques concrets rencontrés dans une administration...</em>

  Votre avis...... ( je peux transferer des articles d’analyse et reflexion sur Carnet )

  YannX

  PS je vous propose de reagir sur spip-dev....

• Evolution #4105 : Constante ou config ?

  28 février 2018, par RastaPopoulos ♥

  Du coup maintenant on a trois discussions ouvertes sur les config, le ticket de Placido, le fil sur la liste emails, et ce ticket…

  b_b attention, dans l’idée de Maieul la constante est inversement prioritaire, et non pas à chercher en dernier recours.

  Mais mon avis c’est que les deux sont un peu de la merde. :D

  Déjà il ne faut pas comparer constantes et form de config, mais constante et meta (= une config gardée en mémoire en base). On a une API lire_config() et ecrire_config(), ça ne vient pas forcément que d’un formulaire avec interface humaine.

  L’avantage des constantes, c’est le déploiement, c’est défini et activé à chaque hit et donc pour l’exécution complète de tout ce qui suit. Ce qui est un énorme avantage pour vraiment activer des choses depuis un plugin (ou le mes_options général).
  L’inconvénient c’est que c’est un peu de la merde, vu que ça ne peut se surcharger qu’une seule fois et c’est super compliqué si plusieurs plugins chercher à faire des choix.

  L’avantage des config en base, c’est que c’est une API à nous, et qui peut être réécrite à tout moment. C’est beaucoup plus souple, et ça permet aussi des valeurs plus complexes.
  L’inconvénient c’est que c’est un peu de la merde : ça ne concerne qu’un enregistrement fixé en base. Et donc pas à chaque hit ! Du coup si un plugin personnalise une valeur lors de son installation, bah un form de config peut l’avoir réenregistré autrement ensuite, ou n’importe quel autre plugin en PHP avec ecrire_config(). Du coup c’est vraiment de la merde pour le déploiement contrôlé de variables de config !

  Mon idée est donc qu’il manque clairement quelque chose pour avoir une API complète de gestion des configurations.
  1) on doit pouvoir le garder en mémoire (chez nous en BDD)
  2) mais on doit AUSSI pouvoir le définir à chaque hit !

  Or il se trouve que le tableau des metas (donc des configs !) est de toute façon déjà chargé au démarrage de SPIP et trimballé entier durant tout le hit PHP !

  Du coup pour moi la solution la plus propre c’est qu’il y ait un nouveau pipeline "lire_config" qui permettent de modifier le tableau des configs après qu’il ait été initialisé depuis la base. Du coup on aurait bien les valeurs venant de la base (form de config ou autre), MAIS AUSSI n’importe qui pourrait forcer la valeur d’une config à chaque hit, exactement comme on le fait pour les constantes. Et du coup vu que pipeline, bah on pourrait le surcharger plusieurs fois, suivant le path, etc, easy et simple à comprendre pour tout le monde.

  monplugin_lire_config($metas) 
      // Je force une config
      $metas[’albums’][’activer_trucmuche’] = true ;
      return $metas ;