Reprise du message précédent :

 
ensureOrderedResponsesDroppingTheOnesThatAreLate.
 
Ou sinon tu mets un nom qui te plait pas vraiment et à la pause café tu auras l'illumination et tu feras un source->refactor dans eclipse  

Pour vous c'est quoi la taille idéale (attribut size) d'un multiselect contenant plusieurs centaines d'éléments?
Et à-partir de combien d'éléments vous considérez ça inutilisable?

Quand tu dis multiselect tu parles d'un dropdown (Combobox)?

En général je dirais que les aides comme l'autocomplétion, ou un résumé à coté des sélections, permettent de pas s'y perdre et autorisent plus d'éléments.

Un <select multiple="multiple">.
Je pense aussi qu'on peut difficilement se passer d'aides javascript au bout d'un moment (dans la pratique mon machin finira probablement avec ce genre de trucs : http://www.quasipartikel.at/multiselect/ ), mais la question était pour la version html brut...

 
Ah ok. Je déteste ces trucs, je trouve ça chiant à utiliser. Avec plusieurs centaines d'éléments, je dirais le plus grand possible sans dépasser la taille du viewport. Dans la pratique je préfère mettre deux listes cote à cote avec des boutons > et < pour faire passer les éléments de l'une à l'autre.

C'est grosso-merdo ce que fait ce plugin jquery...

si tu peux taper la premiere lettre ( ce qui est le comportement normal si tues champs select ne s'appelle pas ----->valeur ), c'ets utilisable, même avec plusisuers centaines
après, tu mets un champ autocomplete par dessus, et zou
 

fig 2 : accessibilité done wrong

 
 
Ah oui j'avais pas compris comment il fonctionnait

 
Dis ça à jquery.

tu viens améliorer un select avec du jquery. Mais le select doit exister sans

wut?
Je trouve ça bien pratique à l'usage, perso, d'avoir une vision rapide de ce qui est sélectionné...

[edit]

Ah ok, tu croyais que le html brut n'était pas basé sur un simple select multiple.

 
Et le rapport avec ce que j'ai dit?

Le truc le plus pratique, c'est quand même un widget genre textext je trouve.

Mouais, pas pratique quand tu veux pouvoir en sélectionner un gros paquet : dans mon contexte il est tout à fait possible d'en sélectionner 150 sur 200, qui plus est avec des libellés autrement plus longs...

sEcho
Ca n'indique en effet pas le traitement (ou plutôt l’absence de traitement dans ce cas) effectué sur la requête en revanche. Mais comme c'est un index que tu envoies dans ta requête et que ta réponse doit renvoyé, le nom me parait pas déconnant, son but est pas de savoir comment tu traites une requête dans le désordre après (on pourrait d'ailleurs imaginer que certaines requêtes spécifiques soient traitées, même dans le désordre).

Là ce serait spécifiquement une stratégie de gestion de requêtes dans le désordre, donc bon

 
THIS is awesome.    

un coup de la virgule flottante à tous les coups

Un coup de la timezone pas gérée correctement partout, plus probablement, amha - genre le toString me renvoie l'année de la date GMT au lieu de GMT+1...
M'enfin je vais pas aller chercher dans le code ce qu'ils peuvent bien avoir foutu non plus, hein.

 
Léger flou sans doute dû à la compression (ou mes yeux qui ont du mal), sinon c'est mieux
 
Je ferais un retour plus tard sur le reste. Là ma première impression c'est de ne pas trop comprendre le workflow.  On voit pas la liste des gens qui ont la même striim ?

Quelqu'un a testé jQuery Mobile?

On l'avais mis sur un projet récemment.. obligé de tout dégager à l'arrache pour revenir à du html/css/js de base tellement c’était la cata... (faut dire on avait pas mal de données à afficher mais bon...)

Bon après on a peut être mal configuré le truc mais les mécanismes de bases me font un peu gerber (lors d'un changement de page, ils planquent la page précédente dans un div en display:none pour y réaccéder plus vite en cas de retour arrière .. )

Non c'est lié a un redimensionnement a la porc fini a 5h du mat
On est en train de faire un mini site de com/pub
Et vu que l 'inscription a un striim est libre, on n'a pas le nom des participants

Pour le coup, j'ai pas mal joué avec
Tu as eu quoi problèmes ?
Perso a par pour les sélect non natif(a fuire sur mobile) le reste marche pas trop mal
Tu sais que tu peux désactiver la navigation ajax globalement.

De toute façon, sur un écran de mobile, les listes a plus de 20 entrées, c'est la misère ( un site mobile c'est une mise en page ET un contenu adapté)

Oui nos pages sont trop grosses (listview de 900 éléments).
Ca passe en mode html/css/js de base (affichage en 2 a 3s), par contre avec la surcouche jquerymobile c'est inutilisable et x10 en temps de chargement / execution du JS (même en mode non-ajax)
 
D'ailleurs, même leur demo avec 500 item dans la listView à un bon vieu temps de latence de 7-10s sur un galaxy s2
 
Bref jquery mobile à éviter quand on doit gérer de gros volume de données.

nan mais sur un mobile on génère pas des listes de 900 éléments, on se démerde pour soit avoir un système de pagination, soit avoir un système de loading au fur et à mesure que tu scrolles.
 
Et les events sur les items de vos listes, vous les collez sur chaque item avec une boucle for des familles ou vous utilisez le delegate de jquery (remplacé par on en version 1.7)

Donc le monde de oui oui, effectivement c'est con d'avoir 900 items dans un mobile, mais on doit faire avec (client toussa)
 
Les events sur 900 items, on en a pas besoin (au clicks sur un item on est redirigé vers une autre page = full html) mais jquery mobile devait faire de ce genre de merde comme un grand (+ des rajouts de class ui-xxx-xxx partout)

C'est le nombre d'éléments dans le dom qui pourri les perfs

c'est pas jquery ui qui est pourri mais ta commande
 
J'ai testé de grosse listview : contenu stocké en webdatabase + pagination +champ de recherche Ca fonctionne très bien .
a moins que la pagination soient aussi interdite

 
D'après ce que je comprends il ne pagine pas à cause de son client.

d'après ce que j'ai compris la commande du client est "affichez une liste de 900 items", pas "affichez mal une liste de 900 items"
Au passage, tu peux aussi faire du jquery mobile , et déclarer ta liste sans le data-role=listview, puis gérer à la main le style de cette liste

tu gardes les listviews et le reste des widget de jqm pour le reste

j'etais bien adepte de Redbean Php pour manipuler mes bases de données, c'est une sorte d'orm simplifié quoi
 
La j'ai un projet php / odbc, Redbean ne gere pas ca (mysql, postgre et sqlite), vous avez une idée d'orm simple qui ferait l'affaire ?

 
=> c'est ce qu'on a fait après avoir désactivé le mode ajax .. et puis après 30s, on s'est dit.. "mais il sert à quoi au final jquery mobile? ... A rien, ca dégage".

A avoir des formulaires sympa
A avoir des widgets pratiques (boutons,navbar,intégration des icônes,listview,switch)

Ceci dit,même avec une grosse liste ajax doit passer  si tu n utilise pas une listview

Enfin

// on PHP 5.4
$secondElement = getArray()[1];

 

la fonction "introduce variable" de phpstorm vient de perdre 50% de ses usages.

// on PHP 5.4
$secondElement = getArray()[1];

Tout comme :

$var = new MyClass()->myMethod();

$var = new MyClass()->myMethod();

 
Ouais enfin là je vois moins l'intérêt, à première vue...c'est une méthode qui devrait être statique, ça, non?

 
Pas forcément.
 
Je n'ai plus l'exemple en tête, mais je sais que j'ai déjà dû faire :
 

$foo = new Foo();
$foo->bar()->baz()->qux();

 
Alors que ça aurait été mieux :
 

new Foo()->bar()->baz()->qux();

$var = new MyClass()->myMethod();

Mais pas

foo()()

La méthode peut renvoyer son this, ou bien sérialiser tout un tas d'information de l'instance (qui dans ce cas sont juste des défauts), genre Builder (pattern) ou chaînes à la jQuery.

$foo = new Foo();
$foo->bar()->baz()->qux();

new Foo()->bar()->baz()->qux();

 
Si tu n'utilises l'instance que pour appeler une méthode, cette dernière a de bonnes chances de pouvoir (devoir?) être statique.

Ouais enfin, si c'est pour faire un new sur une Classe pour n'utiliser qu'un bout de fonction, ben autant foutre cette méthode en statique