UNPKG

epubjs

Version:

Render ePub documents in the browser, across many devices

18 lines (17 loc) 1.81 kB
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"><head><title>Limitations of Visual Design</title><link rel="stylesheet" href="core.css" type="text/css"/><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"/></head><body><div class="sect1" title="Limitations of Visual Design"><div class="titlepage"><div><div><h1 class="title"><a id="learnjava3-CHP-22-SECT-7"/>Limitations of Visual Design</h1></div></div></div><p><a id="idx11159" class="indexterm"/> <a id="I_indexterm22_id822709" class="indexterm"/> <a id="I_indexterm22_id822716" class="indexterm"/>These examples have pointed to the idea that we can create at least a trivial application by hooking beans together in a mostly visual way. In other development environments, this kind of bean hookup has been pushed even further. For example, Sun’s original “BeanBox” experimental Java bean container took a different approach than NetBeans. It allowed the developer to work with “live” Java bean instances, dynamically generating adapter code at runtime and relying solely on object serialization to save the resulting work. This kind of design is, in a sense, the real goal of the JavaBeans architecture. It is true “what you see is what you get” (WYSIWYG) programming. However, pure visual design without the ability to integrate handwritten code, as we can do in NetBeans, has not yet proven to scale beyond these kinds of simple applications, and pure visual programming environments beyond just GUI screen layout have thus far failed to catch on.<a id="I_indexterm22_id822743" class="indexterm"/></p></div></body></html>