-
FEATURED COMPONENTS
First time here? Check out the FAQ!
Hello,
Is there any plan in ZK team for supporting of Html5?
I'll be looking forward for this,
thanks!
We don't have the schedule for it yet. May I know why it is important to you, and what ZK can do better with it? Thanks.
Don't worry. It is our job to make it compatible:)
In additions to ensuring the backward compatibility, we will, with ZK 6 perhaps, provide some features to explore the potential of HTML 5, such as Web socket, storing data locally, and so on.
Well, in my opinion HTML5 would give ZK some great enhancements.
Think about local storage and database features for example. Storing/Caching data on the client's browser can save traffic and webspace on the server.
Web workers also can help to improve application performance.
My #1 feature though is drag and drop support between desktop and browser. That really improves usability regarding file uploads.
I think D&D part is possible in near future(maybe a couple of months), but those local storage and database features are not that easy.
The problem is not about unknown tech part but spec.
The usage of local storage and database are too relative to each Web Application's design and purpose, currently I don't have any good Idea of how to integrate it, do you?
Actually, I think the biggest problems at the moment are cross-browser issues. The HTML5 spec is not done yet but browser manufacturers already started to implement these features, like e.g. some CSS3 functions:
"-webkit-corner-radius" and "-moz-corner-radius" instead of "corner-radius"
Regarding the usage of local storage/database: I'd find it pretty cool if there was an interface in ZK, which would provide me a possibility to use JDBC in order to store, delete, modify and retrieve data from the user's "browser-database" using HTML5. Then, the usage of such a database would not be dependent from the design of a web-application anymore. Instead, it's just an interface that can be used to communicate with a database.
It could be done and I believe wrap it as a generic interface at client side will provide Developer a better way to do things, just like JQuery to Browser DOM.
The issue is, "according to ZK's focusing, why and how ZK do this?" that's what I mean the problem.
Why: For Caching purposes -> Leads to less server polls -> Less server load
How: Provide an interface which lets the developer use the HTML5 storage functions through Java (or through a dedicated JavaScript library, like JQuery, as you suggested. I'd personally prefer the Java way through JDBC though.)
You mean wrapping client side DB and control it at the server side?
Then there will be a lo of callback and serialization to help crossing internet and which will make the API become complex.
I'm not sure if this is a good idea to ZK's architecture philosophy.
The better way that I can imagine is we can use such DB to store unused client widgets, objects and data, we can decrease the loading effort.
In such case, we can speed up some operation such as desktop resize.
Currently my personal opinion is, those UI features from HTML5 are definitely need to be studied, webSocket need to be evaluated if it will impact future Web Container design.
But the most important part and impact is not come from these features, because they are all exists in other multimedia-platform for almost 5 years, the pattern and usage of them will soon be mature and the integration won't be too difficult, the problem or challenge we will have is about the computing efficiency and improvement of javascript.
Quantitative change will make Qualitative change, the power of new generation of Jscript Engine will break the barrier between PC and cellphone, plus GPU support and Video Decode, 3D programming will become possible. I believe this part of software solution will come to the market in the next 3 years.
Asked: 2010-01-10 22:02:49 +0800
Seen: 2,125 times
Last updated: Nov 07 '12