Le 27/10/2011 17:08, Régis Houssin a écrit :
Bonjour,
Je suis en train de mettre au point des fonctions permettant de
modifier des champs sans recharger la page, et j'ai commencé à
déplacer les champs 'note publique' et 'note privée' dans la fiche
principale afin de supprimer l'onglet note, ce qui limite un peu plus
le nombre de clic...
Le pb est que les notes sont des champs tres gros, et les avoir sur les
pages principale pour les éléments déjà chargées comme les factures ou
commandes vont trop fortement surchargé les écrans.
vous pouvez tester ceci dans les fiches "note de frais" et "intervention"
il faut ajouter la constante "MAIN_USE_JQUERY_JEDITABLE" avec la
valeur 1 pour activer l'option.
Le pb est que cela rond l'homogénéité des écrans en ayant les notes
secondaires parfois dans l'ecrans principal, parfois dans l'onglet note.
A moins de mettre juste une ligne dans les tabelaux actuel de type:
note Aucune
ou
note "premiere ligne du texte suivi de ..." (plutot que d'afficher
tout le contenu)
Car afficher des longs textes sur les fiches principales, ca va trop
charger.
je vais encore lancer une discussion, mais je penses qu'il faudrait
revenir à fonctionnement traditionnel des css et ne plus les avoir en
css.php afin d'avoir la possibilité de les compresser, on peut très
bien reproduire ce qu'apporte la méthode actuelle à un niveau supérieure.
Le fait de les avoir en css.php n'empeche pas la compression.
D'ailleurs, on peut meme décider de la compression soit par config du
serveur web, soit par configuration de l'appli (MAIN_OPTIMIZE_SPEED =
4). Mais ces fonctions sont sans interet car si compresser des pages php
a un interet, pour des feuilles de styles css, cela n'en a aucun puisque
des feuiles de styles ont un type text/css qui fait que le fichier est
en cache dans le navigateur et par conséquent la page n'est chargée que
lors de l'affichage de la logon puis plus jamais (voir le plugin FireBug
onglet réseau qiui laissera en grisé ces lignes pour s'en persuader). La
taille des feuilles de styles n'a donc aucun effet sur les perf dolibarr
(sauf si on fait clic droit-actualisé sur firefox car on force le
rechargement sans tenir compte du cache, mais a on est pas dans un cas
d'utilisation mais dans du dev).
Avoir les fichier en css.php est par contre indispensable pour gérer les
langues (langues left to rights) ou encore pour le controle dynamique du
rendu selon options, ou la gestions des styles basés sur des élements de
modules externes, et encore d'autres choses.
Donc, non il faut prendre la tendance inverse et ne plus mettre de
feuille .css autre qu'en .css.php
Ceci pour pouvoir avoir le beurre (fonctionnalités dynamiques) et
l'argent du beurre (performances).
Autre point, je vais déplacer le thème smartphone dans un module
externe car le fonctionnement actuel est inutilisable et ne sert à
rien, je vais tout reprendre à zéro quitte à faire une application
parallèle tant qu'on aura pas réglé le problème des templates.
OK, pour faire une appli a part.
De mon coté le theme fonctionne bien avec le gestionnaire de menu
smartphone mais uniquement sur du firefox, sur le browser d'android 2.1,
jquery mobile a l'air de bien buggué.
Tu peux me mettre dans le projet.
-------------------------
I am trying to develop functions to edit fields without reloading the
page, and I started to move the fields 'public notes' and 'private
note' in the main card to remove the tab notes which limits a little
more the number of click ...
You can test this in the cards "trip" and "intervention"
must be added the constant "MAIN_USE_JQUERY_JEDITABLE" with the value
1 to enable the option.
I'll even start a discussion, but I think he should return to the
traditional functioning of css and no longer have them in css.php to
be able to compress them, one can very well reproduce this method
brings current level.
Another point, I will move the smartphone theme in a plug for the
current operation is useless and serves no purpose, I'll start from
scratch even if it means a parallel application as we will not solve
the problem of templates.
Cordialement,
--
Régis Houssin
---------------------------------------------------------
Cap-Networks
30, quai de Verdun
71700 Tournus
FRANCE
VoIP: +33 1 83 62 40 03
GSM: +33 6 33 02 07 97
Web:http://www.cap-networks.com/
Email:[email protected]
Dolibarr developer:[email protected]
Web Portal:http://www.dolibarr.fr/
SaaS offers:http://www.dolibox.fr/
Shop:http://www.dolistore.com/
Development platform:https://doliforge.org/
---------------------------------------------------------
* Français - détecté
* Anglais
* Français
* Espagnol
* Anglais
* Français
* Espagnol
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--
Eldy (Laurent Destailleur).
---------------------------------------------------------------
EMail: [email protected]
Web: http://www.destailleur.fr
Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: [email protected]
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: [email protected]
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
