Reprise du message précédent :

Intégration complète en deux semaines c'est pas déconnant, t'as les maquettes à produire aussi donc c'est même pas compté dedans...

 
Qu'entends tu par pages statiques ?
oui mon compte + mes commandes
page 404 of course
 
pour le support d'IE, je ne sais pas encore, j'attends les stats de son site, mais j'ai envi de partir sur du BS3 ou Foundation 5 donc ça va vite être réglé.
 
5K ça me parait ridicule, t'enlèves les charges, les frais fixes.. t'as plus grand chose quoi..
 
C'est vous qui faites le design aussi ?

 
Ah ok donc tu parles que de la partie Front End là ?

pour du responsive, foundation est juste génial , avec ses grilles adaptables.
 

Oui, j'ai pas les compétences pour chiffrer le reste.

 
d'acc, ça me parait honnête dans ce cas    
 
c'est ce que j'avais annoncé aussi, 2 semaines d'inté. puis la même chose en design. Sachant qu'il y aura les AR, des modifs etc..
 

En quoi c'est mieux que BS3 ? (question sérieuse)
BS3 m'avait l'air bien foutu (pour avoir fait un projet avec), enfin du moins biggrement mieux que le 2.

C'est quand même vachement court 2 semaines pour une intég complète

Au niveau frameworks PHP vous connaissez des truc sympa et plus légers que zend / symfony ? (POO évidemment)

J'ai jamais dépassé une semaine pour une intégration (faut un minimum de cohérence entre les vues quand même)

Comme ci-dessus, sta dire qu'il faut le PSD de chaque template + le responsive, et la découpe en HTML/CSS/JS ? Mwi tu te fais un beau squelette pour une page, pour les autres ça va vite, mais s'il y a des trucs en plus (genre slider / module particulier) + gérer les pages dynamique (lignes du panier, panier vide, etc etc..) c'est short 2 semaines quand même.

sur bs3, tu vas définir ta grille de manière identique pour toute les tailles d'écran :

<div class="row">
        <div class="col-md-3">.col-md-3</div>
        <div class="col-md-6">.col-md-6</div>
        <div class="col-md-3">.col-md-3</div>
      </div>

l'équivalent foundation va etre :

<div class="row">
  <div class="medium-3 columns">3 columns</div>
  <div class="medium-6 columns">3columns</div>
  <div class="medium-3 columns">3 columns</div>
</div>

Mais en bonus, tu vas pouvoir dire :
"la colonne centrale peut se reduire un peu, la colonne de gauche doit garder une certaine largeur et celle de droite peut etre carrement masquée"

<div class="row">
  <div class="medium-3 columns small-4">3 columns sur moyen et plus, 4 sur les petits</div>
  <div class="medium-6 columns small-8">3columns sur moyens et plus, 8 sur les petits</div>
  <div class="medium-3 columns show-for-medium-up">3 columns mais caché sur les petits</div>
</div>

idem sur des tailles plus grandes

Par contre l'ecosystème est bien moindre, donc si tu penses que tu vas devoir utiliser plein de scripts, BS sera plus rapide à intégrer

Tu peux ne prendre que des morceaux de symfony, : sylex, twig,....

Edit : j'  use et abuse du système de grilles de foundation sur mon essai de visio : https://stri.im/

<div class="row">
        <div class="col-md-3">.col-md-3</div>
        <div class="col-md-6">.col-md-6</div>
        <div class="col-md-3">.col-md-3</div>
      </div>

<div class="row">
  <div class="medium-3 columns">3 columns</div>
  <div class="medium-6 columns">3columns</div>
  <div class="medium-3 columns">3 columns</div>
</div>

<div class="row">
  <div class="medium-3 columns small-4">3 columns sur moyen et plus, 4 sur les petits</div>
  <div class="medium-6 columns small-8">3columns sur moyens et plus, 8 sur les petits</div>
  <div class="medium-3 columns show-for-medium-up">3 columns mais caché sur les petits</div>
</div>

 
Tu peux faire la même chose sur BS3 non ?
 

 
(avec des .visible-xs en complément)

a ben oui  
J'avais gardé le souvenir que ça ne fonctionnait pas avec des grilles fluides

Laravel, Silex basés sur des composant SF2, Auraphp pour des trucs assez autonomes.
 
Le mieux est de partir de composer et d'ajouter les composants dont tu as besoin dans la liste de ce qui est dispo.

Super, merci
 
Apparement Silex est bien pour un truc monopage, j'voudrais faire une vraie app mais sans toute l'usine à gaz derrière.
J'vais jeter un oeil, merci

http://phalconphp.com/en/

 
C'est pas mal ?  
 
Sinon vous pensez quoi de node.js ?
 
XaT

il y a des scenarii où c'est vraiment bien, et d'autres qui ne sont pas adaptés

Pour les BS3/Foundation etc : dans tous les cas avec Jade ça casse moins les bur**es d'écrire tout ce HTML àlacon
 
Pour les framework PHP bof
 
flo : quel cas où node est pas du tout adapté ? (pas encore croisé moi)

gestion de fichiers, j'ai testé y a pas  longtemps et ça se fait étaler par un apache/php.

Les cas un peu complexes où l'asynchrone apporte plus de complexité que d'avantage, même avec des promesses.

Tu peux tout faire en nodejs,  mais ce n'est pas toujours le plus simple.

 
Ta testé les fibers ? On utilise massivement nous
 
Sur la gestion des fichiers, j'ai pas rencontré encore (après ça dépend ce que tu entends pas gestion de fichier bien entendu )

Et donc c'est quoi le remède du tu veux que ton contenu soit indexable ?

 
http://eviltrout.com/2013/06/19/ad [...] tions.html

pas encore testé, c'est sur ma liste. Il n'empeche que c'est une notion de plus a maitriser pour gérer des cas qui n'existent pas en synchrone ( même si ça a des gros avantages aux final)
 
pour les fichiers, j'en ai parlé il y a 3 ou 4 pages : apache a 30% de perfs de plus sur les petits fichiers ( oui il est bloquant, mais il est optimisé à mort )

 
ça déboîte
 
30% de perfs de plus, wow Gageons que ça s'améliore avec le temps alors

de toute façon les assets ça se sert avec du nginx, apache ou CDN

nginx est vraiment impressionnant de performance tout en restant simple à configurer.
Les versions récentes gèrent parfaitement les websockets, ce qui m'a permis de virer haproxy de ma stack

   
J'ai pas vraiment de connaissances en développement web, donc j'aurais besoin de vous pour me donner des pistes.
Je souhaite faire un genre d'API non-officielle pour un site web, en gros mon serveur se connecte disons toute les 15 minutes à une page web pour la parser et récupérer les infos qui m’intéresse, et ensuite je peux me connecter à mon serveur depuis une app pc/android pour afficher ces infos.
Pour la partie "serveur" qui va parser la page et générer les réponses pour les clients, ca tournerait sous quoi, php ?
Pour la partie "API" pour les clients, il vaut mieux opter pour du JSON ou XML ?
J'ai juste besoin de quelques pistes, genre noms de bouquins, noms de logiciels que je peux googler, etc. pour savoir dans quelle direction je dois m'orienter    

pour le serveur, tu as complètement le choix des armes , tous les langages le permettent.
Tu peux aussi prendre python et la  librairie http://www.crummy.com/software/BeautifulSoup/ pour parser ta page html  
pour l'api, j'aurai tendance à partir sur du json, si tes clients savent le parser, c'est un format compact et lisible

merci pour le lien.

En gros ça suce un peu, faut mettre une version low-fi de ton HTML en no script pour quand meme avoir un peu de contenu
par contre j'ai pas compris si c'est juste pour que la preview de la google search puisse afficher un peu de texte, ou si ça joue pour l'indexation du contenu

 
Vu que c'est un petit projet perso, j'aimerais faire tourner ca sur un serveur mutualisé dans un premier temps, j'ai pas vraiment envie de prendre un dédié juste pour ca, c'est pour cela que je pensais m'orienter vers php, j'imagine que c'est pas possible de faire tourner du python ou java sur un serveur mutualisé (ouais j'y connais vraiment que dalle en développement web   ).
Pour les clients, je vais les développer, donc je peux choisir ce que je veux. Je pensais au XML car si j'arrive à parser du XHTML sur le serveur, parser du XML sur les clients devrait être relativement proche.

haha
le xhtml des pages web et le cousin bourré et dégénéré du xml . Il y a plein d'exceptions.
Tu as ça en PHP : http://simplehtmldom.sourceforge.net/
 
En plus le langage côté serveur et côté client sera différent, donc tu devras de toute façon avoir 2 parser.

http://symfony.com/fr/doc/current/ [...] awler.html

Après une modification de window.location, mes requêtes JS en cours sont annulée.

$.get("/foo", function (data, status, xhr) {
    // le callback n'est jamais executé
});
window.location = "/bar";

En soit ça me parait plutôt logique, le navigateur stoppe les chargements courants lors d'un changement de page, mais y'a moyen de contourner ça ?
S'il n'y existe rien d'autre, je modifierais le window.location dans le callback, mais dans le code j'ai une batterie de cas imbriqués, ça va être crado.

Edit : rendre les appels synchrones sinon, mais j'en ai quelques uns, donc il vont être chaînés plutôt que parallèles... Une autre idée ?

Ben te mettre à faire de l'asynchrone pour tout sera la chose la plus intelligente que tu feras sur ton projet

les appels synchrones c'est la mal. Ton navigateur est bloqué complètement le temps de la réponse. Si ton erveur ne réponds pas en quelques ms, le site aparait planté

L'existant est déjà en asynchrone.

J'entends bien, mais vous ne me donnez pas plus de solutions

Edit jQuery.when à l'air de faire le job, vous confirmez ?

$.get("/foo", function (data, status, xhr) {
    // le callback n'est jamais executé
});
window.location = "/bar";

C'est surtout très logique, si tu changes de page, tous les scripts vont s'arrêter pour laisser place à la nouvelle page.
 
 
Dans la logique, je comprends pas pourquoi tu veux faire des appels et ne pas attendre le résultat pour changer de page
Et si erreur, ou mauvaises manipulation de l'user ? Tu va changer de page sans vérifier le résultat de ta requête ?
 
Autre solution, au lieu de changer de page, tu fais un get de ta nouvelle page, et tu remplaces le contenu de ta page par le résultat de ton get, comme ça tu casses pas l'execution des autres threads.

Parce que le window.location n'est pas là pour changer de page, mais pour déclencher un téléchargement de fichier côté navigateur. Du coup on reste sur la même page, avec éventuellement les erreurs qui vont bien.
Voir ce post pour plus de précisions : http://forum.hardware.fr/hfr/Progr [...] m#t2214143
 
Ça vous plait donc pas jQuery.when() ?
 

Non, mais par contre, tu peux faire une iframe juste pour le DL de fichier, et que tu déclenche le onlocation dans celle-ci, le navigateur va proposer la popup de DL pour le fichier.