Undolog.com

After acquiring Macromedia, Adobe creates its Labs , development labs! Building on the success of Microsoft with its Internet Explorer 7 Blog - that has (and has) saved a lot of services pack - Adobe also adopted the technique of the beta version. In fact, he was now, instead of waiting for the now very long time to develop a software (be it tradition, is a Web Application) why do not propose to you the version still in development? In this way there is a real-time feedback on the actual quality of the software you are developing.

However, in all honesty, the software should haouse down a little 'prices for their software, since the beta - you pay or are paid - we do users!

With Adobe Soundbooth beta overwrites the known SoundEdit. Adobe Photoshop Lightroom is a new product aimed at professional photographers, with lots of video demos online. Flash 9 with ActioneScript 3 appears also in the alpha version to download! Although it is indicated preview! To find the mobile Flash Lite 2.1 Authoring Update , but it seems that a final release rather than anticipation. Apart from this small miscellany of beta, alpha and upgrade believe that the initiative is good, if not excellent.
So for the curious who want ahead and not wait to try a new version of software, Adobe Labs is a place of safe fun! I stress again the tendency to involve end users to the stages of development, a trend that owes its spread to the Web 2.0 generation. Most likely it will be a mode in the near future it will spread like wildfire wherever possible. You could try un'appartamente un'autombile or before it is released, for example ...

More ...

As already touched on " JavaScript vs. PHP "(or ASP, CFM, ...), the question of whether or not to enter a kernel Web2.0 JavaScript in your scripts, instead of leaving it - in the majority of members - the server side, can cause confusion if not bewilderment. However there are good reasons to favor the server than the client, reasons that have nothing to do with Web2.0 that, in contrast, puts the spotlight on your JavaScript scripts.

More ...

There is a rumor that is currently an ongoing discussion on the use of Javascript as a manufacturer of HTML content. In particular, the dilemma haunts the universe Ajax. Under this acronym hides a method to contact the Web Server using JavaScript script, without the browser has to reload the entire page with the result - and annoying - "fliker" video.

The fact that this technique allows to communicate with the Web Server means, in practice, you can send - and receive - information from the Web server without the user - in fact - if you know it! On this last statement would be appropriate to open a separate discussion.

Returning to our question, the main question is: once it receives the response from the Web Server who has to build the scaffolding HTML that you can put the answer in the current page? The Web server must make at the time the answer or a task is delegated to the client side Javascript?

In practice, some say the best way is to pack the complete answer directly on the server side, so that the client JavaScript and should only take place (get & insert). Others, however, argue that the best thing is receiving spurious data, raw, perhaps in an XML structure and process all the client side, using JavaScript, and always with JavaScript to create the scaffolding needed to insert the HTML page.

It appears immediately evident, however, that it is not possible - a priori - supporting a model relative to each other. Both, obviously, must be contextualized. E 'possible that in some cases to pack everything to the Web Server it is actually the best choice, both during development and in speed of transmission.

It must be said at once that the idea to load large quantities of Javscript code on the client is not a beautiful solution. I say this in remembrance of scalability. A system that has already heavy in its early stages, has little chance to progress in peace in the future. Moreover, even among the widespread incomptibilità browser available, then the client side Javascript code make it too tiring to develop articulated. However some people it does! Undoubtedly.

The moral, to date, with browsers and operating systems we have, seems to be that everyone must choose his own way, tomorrow we'll see. Visit our website Applick.com , the code was written using both methods, as appropriate.

Tomorrow, perhaps, the browser will come pre-coded on board! You will definitely revised the component HTTPRequest. For now this technique has its re-birth (see use of IFRAME TAG) is the minimum standard HTTPRequest made ​​on the component, its presence and implementation of both the increase in the browser and banda-media available to Internet users. The HTTPRequest HTTP is still a sub-channel, nothing more nor less. Send XML instead of HTML does not make much difference, by sniffing the network there realize now. Perhaps these are moaning about something else that goes beyond the question of Ajax. It 'true that a certain part of the Internet community calls for a change, structural changes. There has been talk - rightly - pemanenti connections, which certainly have nothing to do with the current policy (and original) of the HTTP protocol.

The reality, in the end, it may be to admit that the current technology of the Internet is outdated. His protocols, designed for other network speed and other conditions, are obsolete.

More ...

The new craze on the Web2.0 will also affect the market play the games online? Perhaps this has already happened for some time. Some of the concepts that underlie the web2.0 has long been used by numerous recreational experiences on the web. Online gamers are accustomed to using Ajax-style interface and know the advantage of having the software - the game - on a remote server.

In addition, this people on the network of players, had no problem to interface with the new pricing policies relating to these experiences. Pay only when you play or join with an annual fee to access the central server does not seem to have prevented the massive spread of online games! Indeed! On closer inspection many "players" are extremely pleased with the quality / price ratio compared to an approach to the console or DVD purchased at the store. All this shows also what has been overlooked aspect of online payment. It is evident from the number of players online around the world - and Italy - that there is no problem with credit cards and online transactions secure. Finally, update your online game with a single click makes the play-employees very happy.

What should be stressed, however, is that the differences with the web application using Ajax and derivatives, are many, if not many. If the approach - now - is a nice return to the concept of main-frame, the games have on their ability to use proprietary connections that go far beyond simple HTTP.

More ...