|
Dear Mr. Arthur Ryman,
It is true that
SVG is not widely deployed. But it is not so
difficult to convience users to install a plugin if the web application is
attractive enough. Flash plugin and Java VM 1.4 pluin do the same things.
Another thing, I am now developing a Flash player for J2ME, the core codes can
also be used in render SVG. The point is this player require so minimum
resources that it can surely be run under Java VM 1.1 which has been widely
installed. So we can develop a small SVG Player java applet. If the browser has
no SVG viewer installed, the server embeds the small SVG Player applet in HTML
instead.
Now I explain why I prefer SVG to Java
widget. Most developers think that AWT is too ugly, while the footprint of Swing
is too large. It is true that Swing allow developers to personalize its
components by developing another set of Looks & Feels. But it is so
difficult, I am sure it would beyond most developers' capability. I have
developed a set of SVG widgets including Component, Container, Button, Checkbox,
RadioButton, ListBox, ScrollBar, ScrollablePanel, TextBox, TextEdit etc. The
source code of _javascript_ is only 70.1kb ( you could download it from my website
www.openvue.projects). I could not
believe, with Java, we can personalize so many widgets with only 70 kb.
Moreover, there are already many Flash developers, they could benifit from their
experience of ActionScript when developing SVG widgets.
Anyway, I think we could lead the fashion of web
application, not just waiting for it.
Best Wishes ,
Xinjie ZHANG
----- Original Message -----
Sent: Tuesday, May 11, 2004 11:20
PM
Subject: Re: [wtp-proposal] Proposal
About SVG Plugin
Xinjie,
Thx for your note. Personally, I like SVG, however, my
main concern about it is the lack of a widely deployed client runtime
environment. The main one I know about is the SVG Viewer from Adobe, but I am
uncertain about the future of that technology. There are also Java SVG
libraries, but if the client is Java, then Java widget libraries would
probably be used for most of the UI and SVG would only be used for presenting
the graphics.
My personal tool
development philosophy is that tools are only interesting if there is a good,
widely deployed, runtime on which to deploy the artifacts that the tools
create, i.e. the runtime must preceed the tools. For example, HTML tools are
interesting because Web browsers are ubiquitous. J2EE tools are interesting
because there are many production quality J2EE servers.
However, I think SVG has potential, so at a minimum the
WTP project should provide components that can be used by others to develop
SVG tools. For example, the _javascript_ editor used in our HTML editor should
also be usable in an SVG editor. Similarly for the _javascript_ debugger.
Arthur Ryman,
Rational Desktop Tools
Development
phone: +1-905-413-3077, TL 969-3077
assistant:
+1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile:
+1-416-939-5063
intranet: http://w3.torolab.ibm.com/DRY6/
"Xinjie ZHANG"
<xjzhang78@xxxxxxxxxxx>
Sent by: wtp-proposal-admin@xxxxxxxxxxx
05/11/2004 04:38 PM
|
Please respond
to
wtp-proposal |
|
|
To
| <wtp-proposal@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| [wtp-proposal]
Proposal About SVG Plugin |
|
Dear Mr Arthur Ryman, Mr. Christophe Ney, Mr. Dominique De Vito
...
Thank you for your attention to SVG Plugin. In this email
I would like to explain more my ideas.
1.Background
Although there
are many well-designed frameworks, developing a stable, easy-to-maintain and
personalized web application is still a big challenge for developers. Where is
the problem? I don't think the frameworks, such as Struts,
Spring,Maverick,Hibernate etc, are not good enough. Their archetectures all
sound reasonable. But when you put them into practice, you will find them
difficult to tame. They are all based on MVC/Model 2 archetecture. I should
say the "View" is the weakest section in all these framework. I do not think
HTML could be a suitable format for the GUI of web applications, although it
would still be the first choice for a long time. Let's look into its
shortcomings:
(1)The bigest problem of HTML should be its layout strategy. It heavily
relies on Tables. In order to render interface elements properly, you should
put a lot of efforts to carefully design the Tables. In most cases, it is
beyond the capacity of a developer. Moreover, to make application developers
and HTML web designers understand each others and cooperate smoothly is never
so easy.
(2)The capacity to generate dynamical HTML elements is very limited and
not easy to control.
(3)HTML is a stateless language, all middle states should be
transfered between servers and browsers with GET/POST. Network timeout
problems may lose all the middle state data, it is really annoying for users
to enter them again and again. Moreover it could also cause security problems.
(4)Personalizing a HTML web application is difficult. Maybe a lot of
images would be helpful, but it will cause a web application to be
slow.
For
those reasons, I think a more powerful browser side language is necessary.
Flash and SVG could be taken into account
2.Flash or SVG
Macromedia brings
us a new term "Rich Internet Application" or RIA when it announces its new
product Flash MX. Of course, we should not consider it as a new conception.
Even several years ago, Sun's Java Applet could do the same thing, certainly
with more efforts. Unfortunately, for Java Applet's long load time, big
footprint and bad supports of Microsoft, it could not be a widely accepted
solution for RIA. Flash MX seems the best choice.However Its overall developer
environment is still focused toward animation development. The program uses a
score in which you add cast members within a timeline - a method used for
traditional animation. But linear timeline-based development just doesn't make
sense in an application environment. Moreover the standard SWF is completely
controled by Macromedia, it is not so good for an open source project.
So why not SVG(Scalable Vector Graphics)? SVG
could be another choice for RIA. It is a XML based 2D vector graphics open
standard, under development by the W3C. It has some unique advantages, such as
homan-readable format, manipulation of graphics elements via DOM, full
supports of _javascript_ and even Java ect. In the point of a developer, it is
really great. Unfortunately, an IDE (Integrated Development Envirement) for
SVG can not yet be available. There are even no professional SVG authoring
tools, which could be as powerful and robust as Flash MX. So developing an
easy to use, scalable and robust IDE for SVG should be meaningful.
3.Features of
SVG Plugin
The first version of SVG
plugin has been already available in my website(www.openvue.net/projects).
Although it is still in its very begining stage, it now allow developers to
design their web application interface in a way of WYSIWYG as what you have
done with Visual Basic. There are still many things to do:
(1) A better _javascript_
editor
(2) Integrated _javascript_ debugger.
Almost all SVG components in the plugin are generated dynamically by
_javascript_. It would be hard to maintain these codes without a
debugger.
(3) "Looks & Feels"
feature, it should allow users to change the L&F at runtime
(4) Some _javascript_ classes to communicate with
the servers with different protocols, such as SOAP, XML RPC etc
(5) Some advanced SVG component, such as Table,
TreeView, ListView, Chart etc, to represent data
(6) More stable and more fast
4.Conclusion
I think the Web Tool Project should not only focus in improving the
develops' efficiency but also the users' experiences. SVG is a good way to
personalize our web application, smooth the web development and make the
maintain much easier.
|
