Undolog.com

Après l'acquisition de Macromedia, Adobe crée ses Labs , laboratoires de développement! S'appuyant sur le succès de Microsoft avec son Internet Explorer 7 Blog - qui a (et a) a sauvé un grand nombre de services pack - Adobe a également adopté la technique de la version bêta. En fait, il était maintenant, au lieu d'attendre le temps maintenant très longtemps pour développer un logiciel (que ce soit la tradition, est une application Web) pourquoi ne pas vous proposons la version encore en développement? De cette façon, il ya une rétroaction en temps réel sur la qualité réelle du logiciel que vous développez.

Cependant, en toute honnêteté, le logiciel devrait haouse bas un peu 'les prix pour leurs logiciels, depuis la version bêta - vous payez ou qui sont payés - que nous faisons les utilisateurs!

Avec Adobe Soundbooth beta remplace la célèbre SoundEdit. Adobe Photoshop Lightroom est un nouveau produit destiné aux photographes professionnels, avec beaucoup de démos vidéo en ligne. Flash 9 avec ActioneScript 3 apparaît aussi dans la version alpha à ​​télécharger! Bien qu'il soit indiqué avant-première! Pour trouver le mobile Flash Lite 2.1 Mise à jour Authoring , mais il semble que la version finale plutôt que de l'anticipation. En dehors de ce recueil de petits beta, alpha et de mise à niveau croire que l'initiative est bonne, si elle n'est pas excellente.
Donc, pour les curieux qui veulent venir et ne pas attendre pour essayer une nouvelle version du logiciel, Adobe Labs est un lieu d'amusement en toute sécurité! Je tiens à souligner à nouveau la tendance à impliquer les utilisateurs finaux à des stades de développement, une tendance qui doit sa propagation à la génération Web 2.0. Très probablement, il y aura un mode dans le proche avenir, il se répandra comme une traînée de poudre la mesure du possible. Vous pouvez essayer de un'appartamente un'autombile ou avant qu'il soit libéré, par exemple ...

En savoir plus ...

Comme déjà évoqué sur " PHP JavaScript vs "(ou ASP, CFM, ...), la question de savoir si ou non d'entrer dans un noyau Web2.0 JavaScript dans vos scripts, au lieu de le laisser - dans la majorité des membres - le côté serveur, peut causer de la confusion si elle n'est pas désarroi. Cependant, il ya de bonnes raisons de favoriser le serveur que le client, les raisons qui n'ont rien à voir avec ce que Web2.0, en revanche, met l'accent sur ​​vos scripts JavaScript.

En savoir plus ...

Il ya une rumeur qui est actuellement un débat en cours sur l'utilisation de Javascript comme un fabricant de contenu HTML. En particulier, le dilemme hante l'Ajax univers. Sous cet acronyme se cache une méthode pour communiquer avec le serveur Web à l'aide script JavaScript, sans que le navigateur doit recharger la page entière avec le résultat - et ennuyeux - "fliker" vidéo.

Le fait que cette technique permet de communiquer avec les moyens du serveur Web, dans la pratique, vous pouvez envoyer - et recevoir - des informations à partir du serveur Web sans que l'utilisateur - en fait - si vous le connaissez! Sur cette dernière affirmation serait opportun d'ouvrir une discussion séparée.

Revenons à notre question, la question principale est: une fois qu'il reçoit la réponse du serveur Web qui doit construire le code HTML échafaudages que vous pouvez mettre la réponse dans la page courante? Le serveur Web doit faire au moment de la réponse ou d'une tâche est déléguée à l'Javascript côté client?

Dans la pratique, certains disent que le meilleur moyen consiste à emballer la réponse complète directement sur le côté serveur, de sorte que le code JavaScript client et ne devrait avoir lieu (obtenir et insérer). D'autres, cependant, soutiennent que la meilleure chose est la réception de données parasites, premières, peut-être dans une structure XML et traiter tout le côté client, l'utilisation de JavaScript, et toujours avec JavaScript pour créer l'échafaudage nécessaire pour insérer la page HTML.

Il apparaît immédiatement évident, toutefois, qu'il n'est pas possible - a priori - de soutenir un modèle de rapport à l'autre. Les deux, évidemment, doit être contextualisée. E 'possible que dans certains cas, de tout emballer vers le serveur Web, il est en fait le meilleur choix, tant au cours du développement et de la vitesse de transmission.

Il faut dire tout de suite que l'idée de charger de grandes quantités de code Javascript sur le client n'est pas une belle solution. Je dis ceci en mémoire de l'évolutivité. Un système qui a déjà lourde dans ses premiers stades, a peu de chances de progresser dans la paix à l'avenir. En outre, même parmi le navigateur incomptibilità généralisée disponible, alors le côté client du code Javascript en faire trop fatigant pour développer articulé. Toutefois, certaines personnes il le fait! Sans aucun doute.

La morale, à ce jour, avec les navigateurs et systèmes d'exploitation que nous avons, semble être que tout le monde doit choisir son propre chemin, demain nous verrons. Visitez notre site Web Applick.com , le code a été écrit en utilisant les deux méthodes, selon le cas.

Demain, peut-être, le navigateur viendra pré-codées à bord! Vous aurez certainement révisé le HTTPRequête composant. Pour l'instant cette technique a sa re-naissance (voir utilisation de IFRAME TAG) est la norme minimale HTTPRequête fait sur ​​la composante, sa présence et la mise en œuvre à la fois de l'augmentation dans le navigateur et Banda-médias accessibles aux utilisateurs de l'Internet. Le HTTPRequête HTTP est encore un canal sous-marin, ni plus ni moins. Envoyer XML plutôt que HTML ne fait pas beaucoup de différence, en sniffant le réseau il me rends compte maintenant. Peut-être ceux-ci sont gémir quelque chose d'autre qui va au-delà de la question de l'Ajax. C'est vrai qu'une certaine partie de la communauté de l'Internet appelle à un changement, les changements structurels. Il a été question - à juste titre - les connexions pemanenti, qui ont certainement rien à voir avec la politique actuelle (et originale) du protocole HTTP.

La réalité, à la fin, il peut être d'admettre que la technologie actuelle de l'Internet n'est pas à jour. Ses protocoles, conçues pour la vitesse du réseau et d'autres d'autres conditions, sont obsolètes.

En savoir plus ...

Le nouvel engouement sur le Web2.0 aura également une incidence sur le marché jouer en ligne jeux? Peut-être cela est déjà arrivé depuis un certain temps. Certains des concepts qui sous-tendent l'web2.0 a longtemps été utilisé par de nombreuses expériences récréatives sur le web. Les joueurs en ligne sont habitués à utiliser Ajax-style de l'interface et de savoir l'avantage d'avoir le logiciel - le jeu - sur un serveur distant.

En outre, ce peuple sur le réseau de joueurs, n'a eu aucun problème à l'interface avec les nouvelles politiques de tarification relatives à ces expériences. Vous ne payez que lorsque vous jouez ou se joindre à une redevance annuelle pour accéder au serveur central ne semble pas avoir empêché la propagation massive de jeux en ligne! En effet! Sur une inspection plus minutieuse de nombreux «acteurs» sont très heureux avec le rapport qualité / prix par rapport à une approche à la console ou un DVD acheté dans le magasin. Tout cela montre aussi ce qui a été négligé aspect de paiement en ligne. Il est évident à partir du nombre de joueurs en ligne partout dans le monde - et en Italie - qu'il n'y a pas de problème avec les cartes de crédit et des transactions en ligne sécurisées. Enfin, mettre à jour votre jeu en ligne en un seul clic permet aux employés des play-très heureux.

Quel devrait être souligné, cependant, est que les différences avec l'application web utilisant Ajax et dérivés, sont nombreux, si ce n'est pas beaucoup. Si l'approche - aujourd'hui - est un bon retour à la notion de principal-cadre, les jeux ont sur leur capacité à utiliser des connexions propriétaires qui vont bien au-delà HTTP simple.

En savoir plus ...