Projet d'interface http pour eedomus

[rover820i]

Pourquoi ne pas simplement faire un upload depuis un emplacement local ?

[jluc2808]

@serge81

je serais enclin à utiliser le mécanisme suivant:
- parcourir et upload
- ou dépôt dans 1 répertoire de Mydomus , ce qui revient au même que précédemment

l'ajout dans imgvue se fait depuis l'upload et avec un bouton création du fond de vue en ayant selectionné ce qui est uploadé

[serge81]

Je vois plusieurs contraintes qu’il faudrait pouvoir prendre en compte:
- un utilisateur peut ne pas avoir le droit de mettre une image directement dans le répertoire de MyDomus (c’est mon exemple avec mes enfants qui peuvent se faire un profil sur MyDomus mais qui n’ont pas accès directement aux répertoire de mon NAS car je veut éviter des bêtises). Il faut donc qu’un upload par MyDomus soit possible.
- l’upload ne peut pas se faire depuis un fichier stocké directement sur la machine de l’utilisateur (car ça pose problème pour une configuration directe depuis un smartphone).

Le fonctionnement actuel permet de répondre à ces deux points.
Mais pour un utilisateur qui a accès au serveur, qui voudrait pouvoir déposer et utiliser directement des images, c’est inutilement compliqué d’où la possibilité d’utiliser en plus directement des images stockées dans un répertoire de MyDomus.


Envoyé de mon iPad en utilisant Tapatalk

[serge81]

J’ai du mal à trouver une manière simple.
Le parcourir et upload, ça veut dire un bouton qui permet d’ouvrir une fenêtre qui permet de naviguer dans son arborescence locale pour aller chercher un fichier, ça utilise des objets propre au navigateur et je pense que ça posera problème sur tablette et smartphone. C’est plutôt un fonctionnement de page web pour PC.
L’upload dans un répertoire imgvue pourrait être fait par une page php à part, peut-être dans admin.php qui serait destinée à être utilisée depuis un PC et pas directement dans MyDomus... Je ne suis pas certain que ça soit top.


Envoyé de mon iPad en utilisant Tapatalk

[serge81]

J’ai regardé comment l’upload se fait depuis une tablette, c’est pas vraiment standard avec du javascript.
J’ai trouvé un composant qui a été fait pour Sencha Touch (et donc compatible MyDomus):
https://github.com/kostysh/File-uploading-component-for-Sencha-Touch
Mais il semble que suivant les versions du navigateur, ça bug...


Envoyé de mon iPad en utilisant Tapatalk

[rover820i]

J’ai du mal à trouver une manière simple.
Le parcourir et upload, ça veut dire un bouton qui permet d’ouvrir une fenêtre qui permet de naviguer dans son arborescence locale pour aller chercher un fichier, ça utilise des objets propre au navigateur et je pense que ça posera problème sur tablette et smartphone. C’est plutôt un fonctionnement de page web pour PC.

Non non c'est standard. J'utilise ça pour le logiciel de ma boite qui dispose aussi d'une version mobile, et l'upload fonctionne nickel.

Tu traites l'upload sur la page upload_photos.php (si tu as besoin de la source, dis-le moi)

Le retour (ajax) affiche le contenu de la page page-retour.php dans la DIV #photos

Précision : j'utilise la librairie jquery.

Code : Tout sélectionner

<input id="fileupload" class="fileupload" type="file" name="files" data-url="upload_photos.php">
<script>
      $('#fileupload').fileupload({
        dataType: 'html',
        formData: {donnee: 'cequetuveux'},
        done: function (e, data) {
            $.ajax({
              type        : "GET",
              cache       : false,
              url         : 'page-retour.php',
              data        : "donnee=cequetuveux",
              success: function(result) {
                $("#photos").html(result);
              }
            });
          }
      });
</script>

[serge81]

Je veux bien ta page php pour voir car tout ce que je trouve en Ajax avec Sencha Touch c’est une solution en encodant le fichier en binary64 ce qui ne me semble vraiment pas terrible.
Pour jquery, c’est peut-être la librairie qui le gère ce qui ne veut pas dire que c’est standard.
J’ai essayé en Sencha Touch, je peux avoir la fonction parcourir et choisir une image sur la tablette mais je ne trouve pas comment envoyer le fichier vers une page php.


Envoyé de mon iPhone en utilisant Tapatalk

[rover820i]

Attention le code est vieux

Je l'ai commenté pour que tu t'y retrouves. j'ai épuré au max.

Code : Tout sélectionner

<?php
$filenames = $_FILES['files']['name'];

$ext = explode(".",$filenames);
$nb_ext = count($ext);
$ext = strtolower($ext[$nb_ext-1]);
 // On gère les extensions autorisées
  if($ext != 'jpg') {
    echo 'Erreur : fichiers JPEG seulement !';
    exit;
    }
  $targetfile = md5(time()).'.jpg'; // on définit le nom souhaité
  $pic_url_ul = './dossier/souhaite/'; // le répertoire de sauvegarde
  $targetpath = $pic_url_ul.$targetfile; // on concatène le répertoire et le nom du fichier

if(move_uploaded_file($_FILES['files']['tmp_name'], $targetpath)) {
// upload OK
}
else {
// upload échoué
}
?>

[serge81]

Merci pour la source mais visiblement jquery envoie le fichier « normalement » et il est possible d’utilise $_FILES.
Je n’arrive pas à le faire en sencha touch. Il y a peut-être une astuce mais je ne l’ai pas trouvée pour l’instant.


Envoyé de mon iPad en utilisant Tapatalk

[jluc2808]

Pour le "proxy", le widget digiclock n'a pas été développé par moi et donc il y a quelqu'un qui le met à jour (https://github.com/tcellerier/jdigiclock). A voir s'il vaux mieux prendre ta correction ou chercher à faire marcher le proxy pour bénéficier plus facilement des mises à jour sur github.
Pour le proxy, je pense que dans la page weather\script\proxy.php, c'est la ligne 6 qui pose problème :

Code : Tout sélectionner

$is_allowed = $referer && strpos($referer, strtolower($_SERVER['SERVER_NAME'])) !== false; //deny abuse of your proxy from outside your site

Tu peux tente de la remplacer par :

Code : Tout sélectionner

$is_allowed = true;

Si ça marche, c'est bien ça qui pose problème, ça veut dire qu'il y a un bout qui ne va pas (peut-être $_SERVER['SERVER_NAME']) et avec cette correction, il n'y a plus de vérification pour tester que la requête vient de ton site (ce qui en soit n'est pas très grave...).

je viens de tester avec le code original (donc sans ma modif) et en forçant $is_allowed = true;
il n' y a plus de soucis, le code fonctionne correctement, donc c'est bien ce que tu pensais, j'ai un souci dans la ligne de code avec le server_name, je vais voir si je peux trouver.

[jluc2808]

@serge81
j'ai avancé sur le problem proxy
c'est bien la ligne suivante, dans proxy.php, qui pose problème :

Code : Tout sélectionner

$is_allowed = $referer && strpos($referer, strtolower($_SERVER['SERVER_NAME'])) !== false;

et plus particulièrement $_SERVER['SERVER_NAME'] ou le contenu est '_' (souligné)

donc comme ma ligne de commande dans $referer = http://mon_adresse_ip_web_serveur:81/ee ... =5.6045412

il n'y a pas de '_' et donc on a comme retour 'You are not allowed to use this proxy!' et pas true dans le jsonp, ce qui fait que data dans la fonction d'après prend cette valeur et met le reste dans les choux

comment tu vois la correction ?

si je remplace la ligne par :

Code : Tout sélectionner

$is_allowed = $referer;

alors je n'ai plus de problème , mais en même temps on ne test rien !!!

[serge81]

Bonsoir,
La page proxy n’a pas été faites par moi. Le test qui compare http_referrer et server_name sert à vérifier que la requête vient d’une page de ton site pour que le proxy ne soit pas utilisé par d’autres.
Mais c’est une faible protection puisque côté client il est possible de modifier le http_referrer.
Donc il me semble que de ne pas faire le test ne change pas grand chose.
En même temps, le proxy est destiné à résoudre un problème de requête cross-origin non permise mais je me demande pourquoi jdigiclock le fait si avec ta modification ça marche sans le faire.

L’erreur que tu obtiens vient peut-être d’une non définition du nom de serveur sous nginx ou de l’utilisation d’un virtual host.
Mais ce n’est peut-être pas utile de chercher beaucoup. Je vais peut-être modifier le zip que j’ai mis en ligne pour mettre le proxy.php sans le test.


Envoyé de mon iPad en utilisant Tapatalk

[serge81]

Pour l’upload des images, j’ai avancé.
Avec la librairie sencha touch, c’est un peu compliqué et je ne sais pas trop si ça marchera avec tous les navigateurs et serveur à la lecture de ceux qui est dit:

File uploads are not performed using normal 'Ajax' techniques, that is they are not performed using XMLHttpRequests.

Be aware that file upload packets are sent with the content type multipart/form and some server technologies (notably JEE) may require some custom processing in order to retrieve parameter names and parameter values from the packet content.

Je n’ai pas réussi avec un submit et l’utilisation de $_FILES, mais en faisant une manip un peu tordu qui consiste à envoyer l’image en données binaires et en à la récupérer avec un fopen, ça marche.
Je vais donc prévoir cette possibilité...


Envoyé de mon iPad en utilisant Tapatalk

[jluc2808]

Bonsoir,
La page proxy n’a pas été faites par moi. Le test qui compare http_referrer et server_name sert à vérifier que la requête vient d’une page de ton site pour que le proxy ne soit pas utilisé par d’autres.
Mais c’est une faible protection puisque côté client il est possible de modifier le http_referrer.
Donc il me semble que de ne pas faire le test ne change pas grand chose.
En même temps, le proxy est destiné à résoudre un problème de requête cross-origin non permise mais je me demande pourquoi jdigiclock le fait si avec ta modification ça marche sans le faire.

L’erreur que tu obtiens vient peut-être d’une non définition du nom de serveur sous nginx ou de l’utilisation d’un virtual host.
Mais ce n’est peut-être pas utile de chercher beaucoup. Je vais peut-être modifier le zip que j’ai mis en ligne pour mettre le proxy.php sans le test.


Envoyé de mon iPad en utilisant Tapatalk

bonjour, ça me semble bien , profites en pour corriger les 2 appels à appCache.status dans index.html qui sont en erreurs si undefined :

Code : Tout sélectionner

index.html:1372 Uncaught TypeError: Cannot read property 'status' of undefined
        at onReady (index.html:1372)

[jluc2808]

Bonjour,
Une nouvelle version béta à tester :
http://sb.domo.free.fr/mydomusbuild/mydomus1.01b2.zip

Modifications :
- correction du problème de la taille des icônes provenant de l'eedomus en mode non Retina.
- modification du fonctionnement du tap sur l'icône d'un volet du type open/closed (car ça ne devait pas marcher)
- modification du fonctionnement du tap sur l'icône et des barres des volet 100=fermé (j'espère que c'est plus logique comme ça...)

dans la nouvelle beta 1.01b2 je viens de tester la partie Img. slider vert. avec ton tuto

les images / fond / slider ne sont pas prises en compte parce que dans url background tu as :
resources/images/imgslider/fond2.png ==> donc ça pointe sur rien puisque les répertoires ou se trouvent les images imgslider, cslider sont sous les 3 types (old,flat2, default)

soit tu remontes imgslider et cslider sous images soit tu ajoutes le type dans le chemin de l'url mais en l'état ça fonctionne pas.

[serge81]

Désolé, j'ai fait le tuto avant de poster la mise à jour avec la correction du bug sur les sliders.
J'y ai mis aussi un slider image vertical avec le max en bas pour les volets SOMFY.
Je finalise une première version du upload des images des vues et je poste une béta 3.

Pour l'appCache.status, il y a une nouvelle version du "compilateur" Sencha, j'espérait qu'il corrigeait le problème mais ce n'est pas le cas.
Je vais regarder ça mais, à part l'enlever si undefined, le problème et que la mise à jour du cache sous Chrome est toujours pénible...

[serge81]

Une nouvelle version à tester :
http://sb.domo.free.fr/mydomusbuild/mydomus1.01b3.zip

Nouveautés :
- Correction d'un bug sur les sliders et ajout d'un slider vertical avec le max en bas.
- Correction erreur sur l'app.cache avec certain navigateur (mais le cache ne se met pas à jour automatiquement avec ces navigateurs, sous Ios la mise à jour est toujours automatique).
- Modification de la gestion des fonds des vues avec la possibilité d'un upload d'image.

Pour les fonds :
- les images sont uploadées dans resources\config\img
- elles ne sont pas renommées
- une images uploadée peut être utilisée plusieurs fois et sur plusieurs profils
- si lors de l'upload, une image a le même nom, elle est écrasée
- je n'ai rien mis pour gérer la suppression d'une image (j'ai peur des effacements par erreur).

Et je ne sais plus si c'était déjà dans la béta 2:
- Ajout d'un Widget "zone de texte" pour ajouter du texte sur une vue.
- correction du problème de la taille des icônes provenant de l'eedomus en mode non Retina.

A voir si c'est mieux...

[jluc2808]

Une nouvelle version à tester :
Nouveautés :
- Correction d'un bug sur les sliders et ajout d'un slider vertical avec le max en bas.
- Correction erreur sur l'app.cache avec certain navigateur (mais le cache ne se met pas à jour automatiquement avec ces navigateurs, sous Ios la mise à jour est toujours automatique). ==> testé OK
- Modification de la gestion des fonds des vues avec la possibilité d'un upload d'image. ==> testé OK

Pour les fonds :
- les images sont uploadées dans resources\config\img ==> testé OK
- elles ne sont pas renommées ==> testé OK
- une images uploadée peut être utilisée plusieurs fois et sur plusieurs profils
- si lors de l'upload, une image a le même nom, elle est écrasée ==> pas testé
- je n'ai rien mis pour gérer la suppression d'une image (j'ai peur des effacements par erreur). ==> tu le laisses pour de la suppression manuelle directement dans le répertoire ? ça revient au même l'erreur n'est pas plus grave ?

Et je ne sais plus si c'était déjà dans la béta 2:
- Ajout d'un Widget "zone de texte" pour ajouter du texte sur une vue. ==> testé OK
- correction du problème de la taille des icônes provenant de l'eedomus en mode non Retina. ==> pas testé

A voir si c'est mieux...

je vois dans la console sous windows un appel qui revient de manière récurrente et qui retourne
[violation] 'readystatechange' handler took 180ms , c'est dans app.js ligne 3600

Code : Tout sélectionner

  return function() {
    var callArgs = args || arguments;
    if (appendArgs === true) {
      callArgs = slice.call(arguments, 0);
      callArgs = callArgs.concat(args);
    } else {
      if (typeof appendArgs == 'number') {
        callArgs = slice.call(arguments, 0);
        Ext.Array.insert(callArgs, appendArgs, args);
      }
    }
    return method.apply(scope || window, callArgs);
  };

tu sais pourquoi ?

[jluc2808]

pour les textes qui s'affichent avec les icônes, notamment dans les actionneurs , modules standard qui ont des états avec du texte, le texte s'affiche en dessous et justifié à gauche

peux-tu ajouter 2 arguments pour mettre le texte ou on veut :
- position : haut/bas/gauche/droite ==> pour le mettre à la position que l'on veut par rapport à l'icône
- justifié: gauche/droite/centre ==> pour l'aligner ou on veut par rapport à l'icône

[jluc2808]

c'est bizarre quand je suis sur ma tablette android (et pas sur windows)
si je mets dans un module de type consomètre : Num. icône = vide
que j'ai ajouté dvide_0.png, lvide_0.png, dvide_0@2x.png dvide_0@2x.png dans perso des 3 types

avec Windows j'ai bien pas d'icône affiché (ou mon icône vide) , mais sur tablette si je recharge la page je retrouve l'icône consomètre et pas l'icône vide alors que Num. icône est bien = vide dans config

comme je suis sur tablette je ne sais pas afficher la console pour voir ce qui est réellement appelé (je suis avec la beta3)