Следуя традиции, начатой в TSSJS Мэттом Райблом и продолженной Говардом Льюисом Кораблем о гобелене , ItsNat v0.3 был выпущен несколько дней назад и готов начать бой. (Кстати, вступительную статью о ItsNat можно найти здесь .)
Справочная информация: ItsNat, «Natural AJAX», представляет собой инновационную веб-платформу на основе компонентов Java AJAX с открытым исходным кодом, ориентированную на сервер. Он предлагает совершенно новый способ веб-разработки: TBITS, подход «браузер — сервер». В основном ItsNat имитирует универсальный Java-браузер W3C на сервере. ItsNat хранит дерево DOM на сервере, браузер — это в основном зеркало состояния сервера, пользовательский интерфейс этого браузера. Если дерево сервера DOM изменяется с использованием API-интерфейсов DOM Java W3C в зависимости от кода пользователя, DOM клиента автоматически обновляется соответствующим образом. Кроме того, клиентские события DOM отправляются на сервер с использованием AJAX в качестве транспорта и преобразуются в Java W3C DOM Events, если код сервера зарегистрировал прослушиватель событий DOM для того же симметричного элемента DOM.
Q) Какова общая производительность вашей платформы по сравнению с другими?
У меня нет номеров для сравнения с другими; Я могу говорить о том, как ItsNat серьезно относится к производительности.
Архитектура является ключевой: поскольку сервер поддерживает дерево DOM, сервер точно знает, что должно измениться в клиенте, когда разработчик что-то изменит. Например, если код сервера изменяет определенный атрибут на сервере, ItsNat автоматически генерирует код JavaScript, необходимый для повторения этого действия в клиенте, адаптированном для конкретного браузера, в этом примере вызов setAttribute для соответствующего клиентского элемента. Этот абсолютный точный контроль зерна минимизирует код, отправляемый клиенту, с увеличением пропускной способности и производительности.
Под капотом ItsNat использует собственную реализацию XPath для определения местоположения узлов на клиенте и сервере (не является стандартной реализацией и используется внутри компании). Используя кэши часто используемых узлов, мы можем значительно сократить потребность в абсолютных путях и избежать обхода дерева с самого начала.
InnerHTML используется в клиенте, когда он присваивается для обновления состояния клиента (innerHTML на несколько порядков более производительный, чем вызовы DOM).
Наконец, дерево DOM никогда не анализируется с нуля, ItsNat генерирует клоны исходного дерева DOM страницы для различных запросов страниц.
Эти функции являются внутренними и полностью прозрачными для разработчика.
В) Как ваша веб-платформа позиционирует себя по отношению к веб-компонентам?
Я думаю, что это может звучать немного странно, но ИМХО мы сегодня живем в фанатичной тенденции IoC. Фанатизм IoC = BOP, бюрократическое программирование. Позвольте мне объяснить, подумайте на минуту, что вы должны объяснить своему телефонному оператору, когда и кому вы звоните по телефону, затем ваш телефонный оператор позвонит вам, говоря: «Эй, теперь вы должны позвонить этому человеку».
Собираемся ли мы производить такое программное обеспечение в ближайшее время?
@Component
public class OrderFactory
{
@Produces @ConversationScoped @Current
public Order getCurrentOrder(@New Order order, @Selected Product product)
{
order.setProduct(product);
return order;
}
}
Этот фрагмент кода взят из спецификации Web Beans и примера такого вида BOP: «Я являюсь контейнером, если вы хотите, чтобы я вам позвонил, пожалуйста, заполните эту форму запроса».
IoC может уменьшить котельную плиту, но ввести другой тип котельной плиты в виде правил, это изменение императивного программирования на основанное на правилах / декларативное программирование. Следуя аналогии, в классическом императивном программировании мы просто называем A, B, C, в декларативном программировании мы должны объяснить контейнеру «A всегда должен вызываться первым», «B не может быть ни первым, ни последним» и, наконец, « C может вызываться в любом порядке », и контейнер решает порядок вызова. Я думаю, что IoC — это как острая пища, слишком острая еда не может быть съедена (или с риском возникновения боли в животе). Это будущее? Я не знаю, но я должен признать, это текущая тенденция.
Мы могли бы классифицировать веб-фреймворки как ориентированные на IoC (JSF, Spring MVC …) и неориентированные на IoC (Wicket, GWT …). ItsNat не является инфраструктурой, ориентированной на внедрение IoC / декларативный / зависимый. Я понимаю, что IoC дополняет DC (Direct Control), когда метод структуры делает X, Y может быть интересно предложить некоторый дополнительный хук в форме «классического» слушателя, который будет вызываться при финализации X, чтобы полностью избежать действия Y или изменить, как Y сделано. Например, ItsNat использует необязательные слушатели для переопределения структуры компонента или того, как данные отображаются в виде разметки, все они являются примерами «классического» IoC.
Я согласен с Питером Томасом (фанатом Wicket) по поводу декларативных рамок :
- Удивительно, но многие веб-фреймворки Java подталкивают разработчиков к работе не-Java, не-OO
- Большая часть времени разработки тратится на пользовательский интерфейс
- Основанные на DSL / декларативные подходы имеют ограничения
- Java == сила и выразительность
Питер обращается к JSF и основанным на действии средам, в основном Struts и Spring MVC.
Декларативным фреймворкам обычно нужны тонны артефактов, альтернатива чистому X / HTML, чистая Java сильно упрощают разработку веб-приложения. Следующая диаграмма Питера Томаса впечатляет:
http://ptrthomas.files.wordpress.com/2008/05/why_wicket.png
Она была нарисована для объяснения Wicket, но она действительна и для ItsNat. Калитка как старший брат для ItsNat, подход отличается, но оба разделяют многие философские принципы.
В) Насколько легко создать повторно используемый компонент в вашей среде? Это так же просто, как подклассифицировать существующий компонент?
Прежде всего, что такое компонент? Концепция компонента является движущейся концепцией, например, любой объект Java является компонентом, если мы применяем определение компонента в старые времена C ++.
Может быть, мы говорим о визуальном веб-компоненте как объекте Java:
- Как способ изменить визуальный макет с Java: в ItsNat любой узел DOM является компонентом, пользовательский интерфейс можно изменить с помощью API DOM.
- Это связывает некоторые данные с пользовательским интерфейсом: любой узел DOM является компонентом, и с помощью API DOM мы можем вводить данные в пользовательский интерфейс.
- Готов к приему событий пользовательского интерфейса: узел DOM является компонентом, поскольку получает и отправляет события DOM зарегистрированным слушателям событий.
- Контейнер других компонентов: любой узел DOM является компонентом; если узел удаляется, то любой дочерний узел тоже удаляется.
В ItsNat компонент представляет собой объект Java, связывающий модель данных (и иногда модель выбора), поддерево DOM и предопределенное поведение при получении события пользовательского интерфейса. Да, ItsNat предоставляет типичные компоненты, такие как кнопки, текстовые поля, списки, таблицы и деревья.
В наследовании ItsNat нет способа расширить существующие компоненты. Я думаю, что фреймворк не должен предоставлять классы разработчику, потому что внутренние методы также предоставляются разработчику, а классы препятствуют переключению реализаций, поэтому API-интерфейс ItsNat почти полностью основан на интерфейсах. Некоторое время назад высококвалифицированный технический специалист в Sun сказал что-то вроде «самая важная ошибка в Java API — это … классы» (конечно, это утверждение несколько преувеличено).
Более простой способ расширения существующих компонентов — использование слушателей; Компоненты ItsNat предоставляют много типов прослушивателей: событие DOM, изменение модели данных, выбор, структурное описание, прослушиватели рендерера и т. Д.
Поскольку любой узел DOM содержит базовые функции «компонента», создание нового компонента ItsNat удивительно просто, реализуя ItsNatComponent в класс, связывающий узел / поддерево DOM, некоторые данные и некоторое поведение, связанное с некоторыми событиями пользовательского интерфейса.
Самое интересное, что компоненты не являются строго необходимыми для создания сложных приложений AJAX с ItsNat, базового уровня, Core, достаточно. Нам нужны только API-интерфейсы Java W3C DOM и очень небольшое подмножество API-интерфейсов ItsNat (многие интерфейсы ядра на самом деле не нужны). Фактически компоненты ItsNat полностью основаны на уровне ядра; любой разработчик может создавать одни и те же компоненты, не полагаясь на внутренние компоненты фреймворка.
В) Какова основная отличительная черта вашей структуры, которая делает ее лучше, чем остальные?
ItsNat — это совершенно новый подход, «Браузер — это сервер», на момент написания статьи, уникален. Jaxer, технология «JavaScript на сервере», не обеспечивает синхронизацию DOM клиент / сервер с AJAX, базовой функцией ItsNat.
- Java and pure X/HTML (or SVG), no more artefacts like expression languages, XML files, custom tags etc.
- AJAX a very basic feature not a forced add-on.
- Absolute control of the page layout along the life of the page including on AJAX events.
- Learning curve flat, plain: any developer with a basic background of JavaScript in the web (DHTML), plain Java and a very small subset of ItsNat interfaces and methods, knows enough to develop very complex AJAX applications.
- Extreme separation of concerns: pure X/HTML templates with absolutely no logic. View logic in pure James Gosling-Java allows reusing code related with view management in Java. This view logic with some techniques (use of Document.getElementById, structural patterns, Node.cloneNode, optional use of ${} variables etc) can be highly independent of the concrete layout.
- No special tools, not oriented to IDEs: any X/HTML editor and a decent Java editor are enough.
- Out of the box remote view of pages opened by other users/browsers with any supported browser. An open door to uses like help desk, “legal spying” etc.
- Comet amazingly simple with no special servers.
- Server-sent events with no special browsers: from the server you can fire DOM events and send to the client simulating user actions. Server-sent events can be dispatched directly to the server without browser (again useful for functional testing). Both modes are very useful for functional testing driven by the server.
- Beyond X/HTML: SVG elements embedded in XHTML can receive events, can be associated to components etc. Furthermore, ItsNat supports pure SVG pages with the same features of X/HTML pages (AJAX, COMET etc), for instance the server can receive DOM events from a client SVG page.
- Referrers: this feature is based on AJAX but introduced for “classic navigation”. A page can automatically access to the server document of the previous page left behind, and can reuse (copying) data, pieces of markup etc.
- Data models and selection models in components are based in Swing. A web application and the Swing counterpart can share very much code and the same structural design because an ItsNat application may be designed as the typical event based desktop application. ItsNat reuses Swing as possible but is not a forced Swing clone in web, for instance ItsNat is not pixel based.
Q) What do you think about the various scopes introduced by Seam, e.g. conversation vs request or session? If you support these additional scopes, do you also provide some sort of concurrency control?
Conversation, request, sessions… this way to think a web application will be obsolete any time soon. When you develop a desktop application you never think in conversations and sessions, you only distinguishes “load time” and event requests. The same is in ItsNat, with ItsNat you can develop classic applications but is not the strong point, ItsNat is strongly focused in AJAX and is highly event based.
You only need a single page as in a desktop application (main frame), including rewriting big parts of the page, because ItsNat provides “markup fragments”. Markup fragments are pure X/HTML (or SVG) documents where only the markup below <body> (or <head>) counts; these fragments can be loaded in any time as DOM and inserted in any part of the DOM tree of the main page usually as the response of a client event.
About synchronization: ItsNat automatically synchronizes the document object for instance when an event is received, if other event with the same target document is received, as the document is locked this second event will wait its turn. In this way server code called by ItsNat in a context of a document load or event request is executed as single-threaded. Wherefore server code can access any server document (to access to the DOM, components etc) with no problem if the document target is synchronized first.
Q) Why can’t we, the Java Community, come together and adopt the best application framework and settle the web development subject?
No, we can’t.
Because there are several development styles, any style have strong points and shortcomings. For instance, JSF, GWT, ItsNat or “your JS Lib + DWR” are three very different styles of programming a web application. For instance if you want drag-drop bloated closed components in a framework highly intrusive like JSF, then ItsNat is not for you. If you need a client centric application with tons of JavaScript and “special effects”, ItsNat is not for you (in spite of ItsNat may be mixed with JavaScript libraries, ItsNat offers a pull and push-Comet communication with the server similar to DWR).
Q) What are you doing to help with developer productivity?
A tool for reusing, reusing and reusing… did I say reusing? Typical approach of web frameworks is to offer closed, bloated and impressive visual components tightly bound to view logic, outside those components there is no hope, developing custom components (beyond composition) is impossible or very hard. ItsNat doesn’t follow this route, ItsNat components are highly customizable, furthermore, ItsNat components don’t have X/HTML view, the view is designed as pure X/HTML by the developer and attached to the component in Java. This promotes reusable components highly configurable not attached to a specific aesthetic and layout, and as the view logic is done in Java, this code is open to the goodness of the Object Oriented Programming.
Q) 2008 is a huge year for the mobile web. How do you help developers build great mobile web applications?
ItsNat brings AJAX, COMET, server-sent events, remote views etc to the following mobile browsers:
Opera Mini 4, Opera Mobile 8.6, NetFront 3.5, Minimo 0.2, IE Mobile 6 (Windows Mobile 6), iPhone/iPod Touch, Android, S60WebKit (S60 3rd, Nokia phones), Iris browser 1.0.8 and QtWebKit embedded (Qt 4.4)
And to the following desktop browsers: MSIE 6+, FireFox 1+, Safari 3+, Opera 9+ and QtWebKit (Qt 4.4).
The server centric nature of ItsNat is especially interesting on mobile browsers because the browser is not bloated with tons of JavaScript code.
I’m specially proud of IE Mobile 6 support, IE Mobile is poor and buggy. ItsNat leverages this browser to similar level of any other (of course with many limitations); using Java W3C APIs ItsNat can provide DHTML behaviour never seen before in Redmon and “almost impossible” using direct JavaScript code.
Q) If you couldn’t use your framework, what would you use and why?
GWT is a brilliant technology highly focused for desktop-like applications with some serious problems to develop web sites. And Wicket for web sites.
Q) How do you enable rich Ajax applications?
ItsNat is strongly based on AJAX, is not an add-on. Client events are transported using AJAX. AJAX is the base of COMET (using long-polling), server-sent events (based on COMET), timers (scheduled AJAX events) and remote views (using timers or COMET).
Q) Can a developer make a change to source, and hit RELOAD in the browser to see the change? If not, why not?
ItsNat supports hot update of pure X/HTML and SVG templates (pages and fragments); when you change a template (page or fragment) on the filesystem any new page requested or fragment inserted uses the new version automatically. This feature is very useful in production too for instance in web sites with many static parts.
Of course you can change dynamic parts of the template, if your view-logic in Java is tolerant to layout changes you don’t need to change the Java code. For instance the layout of a tree can be changed from a UL/LI based layout to a TABLE based with no code changes.
ItsNat doesn’t offer hot reload of Java code, a tool like JavaRebel may be useful in this case. Of course we are talking about Java code, nothing prevents you of using a JVM based scripting language for your view logic and/or business logic.
Anyway ItsNat offers some interesting techniques to bring your application to a desired state with a direct path. Imaging a very complex AJAX based web application, to navigate to the current development zone you need to fill a login form and 5 clicks; you can use server-sent events coded in Java with or without browser intervention (easier) to simulate user actions to bring your application to the desired state after an application reload. This feature is very useful for functional testing and bookmarking too.
Q) What do you think about the whole Flex revolution, and do you think you are competitors to this technology?
If we are talking about Flex as a new web based technology… we don’t need another web engine. Flex seen as a new client side technology… Flex is nice but it has some serious shortcomings: a proprietary technology, a non-typed language, client centric nature (return to the flat client), Google/search engines don’t like Flex, ActionScript is not a low level language (ever limited by Adobe), is not ubiquitous like standard web technology is (including low end devices) and finally is not the only kid on the block (Silverlight, JavaFX/Consumer JRE).
We have web for many years. AJAX, COMET, SVG, canvas and native support of video will reduce the “feature mismatch” with Flash/Flex/AIR technologies. I must recognize that Internet Explorer is a problem, the necessary plug-in we really need is an easy to install ActiveX, wrapping the FireFox engine, for Internet Explorer!
Q) How easy is it to create a module and plug it into a bigger application, complete with configuration, code, and view?
ItsNat is fully configured in pure Java. In the same way you can add cool visual DHTML components including a JavaScript file, you can add new visual components using pure Java (may be in a jar) because the method ItsNatDocument.toDOM(String) allows to convert an string with markup to DOM on the fly ready be inserted (this is not the recommended practice, big pieces of markup should be put in HTML files and registered into the framework). As you have full control of the markup you can invent new custom tags and replace them when you want with your custom markup.
In summary: ItsNat offers a solid foundation to build your own super custom amazing high level web framework.