|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 139
Messages: 139
Messages: 139
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
New Web Framework: Echo2, with Ajax-based Rendering
Echo2 is a reinvention of the Echo Web Framework built around an Ajax (Asynchronous JavaScript and XML) rendering engine. Distributed under the Mozilla Public License, Echo2 aims at providing a component-oriented/event-driven toolkit for developing web applications that approach the capabilities of rich clients.
Echo2 uses the array of Ajax technologies in the interest of providing a more rich-client-like user experience. All client/server interaction is accomplished over an XMLHttpRequest wire. An entire Echo application runs from within a single web page - without a reload nor full page update. User input is sent to the server by POSTing XML documents over XMLHttpRequests. The server reciprocates with XML messages containing synchronization instructions, which are then processed by pluggable client-side JavaScript modules. The net result is a markedly more fluid and "desktop-like" user experience and a dramatic performance improvement when compared to traditional web application technologies.
One way of understanding how the rendering engine works is to watch an Echo2 application run in "Debug Mode", which causes all the XML synchronization messages to be displayed. Debug Mode can be enabled by appending "?debug" to the URL of an Echo2 application. You can see this for yourself by visiting the "Interactive Test" application here: http://demo.nextapp.com/InteractiveTest/ia?debug (Please note that running in Debug Mode will cause a substantial performance degradation.)
All web rendering is performed behind the scenes with Echo2's entirely Java-based user-interface toolkit. The end-developer need only be concerned with the server-side representation of the user-interface. Echo's "Web Application Container" monitors the state of the component hierarchy and takes care of all communication with the client browser. The Application Container is responsible for processing synchronization messages from the client, and notifying the server-side application of user actions via plain Java events. When modifications are made to the server-side hierarchy of components representing an instance of the user-interface, the Application Container translates these changes into an efficient synchronization message sent to the client to bring its state up to date with the server.
The current release of Echo2 is 2.0 Alpha 3. Please understand that Echo2 is currently in the alpha stage and is under heavy development. We welcome input and participation in the project. Please visit http://www.nextapp.com/products/echo2 for more information and downloads. Our Echo community developer forums are also available at http://forum.nextapp.com.
For a sample demonstration application written using Echo2, please visit:
http://demo.nextapp.com/InteractiveTest/ia
|
Threaded replies
| · |
Wrong
by
% #
on Tue Mar 29 15:19:44 EST 2005
|
|
|
Message #163186
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Yay!
I am 100% confident that all major frameworks and portals will move to ajax before the year ends. Those who will not do it, will die. I would be greatly surprised if ASP.NET 2.0 will not do it.
Notice that:
* Echo preserves state on reload
* Because everything is pulled from one main page, the URL stays the same, Back button is not enabled and going Back is impossible.
With Ajax, Redirect-after-Post pattern becomes obsolete, and double-submit detection now does not differ from the same issues of desktop applications. And it is still good old HTML. I would bet on Ajax in the battle Ajax vs Flash.
P.S. MS created XMLHttpRequest about 5 years ago, but it needed someone like Google to show the magic of this object.
|
|
|
Message #163191
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why do they use the "frames hack"?
Echo2 instead takes advantage of the now widely-supported XMLHttpRequest feature to provide this capability, doing away with the hidden HTML frame altogether.
|
|
|
Message #163194
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
Just tried the demo! I have to admit this pretty damn cool. I look forward to trying this stuff out. Congrats to the developers!
|
|
|
Message #163195
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
Tod,
Can this be used with the EchoStudio?
How does this affect EchoPoint?
Mark
|
|
|
Message #163196
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ASP.NET 2.0 already does
ASP.NET 2.0 already does Cool, I did not know that. But isn't it funny that even .NET guys did not realize the full potential of this feature back when they developed ASP.NET 1.0. MSIE had in in 1999. Could be a killer (and compatible!) feature for .NET-built apps.
|
|
|
Message #163202
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
omg
stunned...now if everything was extending javax.swing
or combined with jsf...
will start project tomorrow ;)
without cookies i get circular redirect on ff btw
|
|
|
Message #163206
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
for me (running opera 8, which i admit is a beta), that demo dies with 'invalid response from server'
|
|
|
Message #163207
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
An entire Echo application runs from within a single web page
So I can't send a link to someone? Isn't that why frames are so hated?
Debug Mode can be enabled by appending "?debug" to the URL of an Echo2 application.
Hopefully this can be disabled in production?
|
|
|
Message #163211
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
An entire Echo application runs from within a single web page So I can't send a link to someone? Isn't that why frames are so hated?
Can you get a link to a certain window in a desktop application? Ajax is for web applications, not for hyperlinked documents. Documents should have a link, but items within an application... I guess REST paradigm would prefer that each resource had a distinct location. Well, they have this location, it is not shown to a user. Should it be shown to a user? Should anyone be able just to come from nowhere and to ask for "item #1234, in edit mode" like they do now? More likely not, than yes.
I guess applications should not use ajax for the whole site. They should use it with care. There should be islands of "constant location" for separate modules with a lot of interaction. On the other hand, there should be regular pages too, for bookmarking and for easier navigation between modules.
Or, if you need to bookmark a particular item, you would simply ask webapp to provide you with bookmarkable address of that item, outside of the application context. (It is not just some framed context, it is an application, which can provide this service). Presumably, it will be just a view of persistent data.
|
|
|
Message #163213
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
does not work in IE 5.5, windows 2000 :-( Maybe your browser is set up for more restrictive security zone.
|
|
|
Message #163214
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
for me (running opera 8, which i admit is a beta), that demo dies with 'invalid response from server' It is still Alpha. I'm sure it will be working closer to real release. Unless Opera doesn't support "ajax".
|
|
|
Message #163216
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
for me (running opera 8, which i admit is a beta), that demo dies with 'invalid response from server' It is still Alpha. I'm sure it will be working closer to real release. Unless Opera doesn't support "ajax".
It just got in in the version 8, afaik. And it is still beta. So much for trying to mimic IE. Opera has its own understanding of caching too. Opera does not reload a page on Back like MSIE and Mozilla do. Even if page is marked with "no-store". And Opera adds every page to the history, even after redirect, even from the same URL. No fun :(
|
|
|
Message #163217
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Yay!
I am 100% confident that all major frameworks and portals will move to ajax before the year ends. Those who will not do it, will die.
Agreed. A few months ago here I predicted the rise of JavaScript generators, but was not well recieved. Having used both Ajax and Struts, but never together, it's my naive impression that Ajax might be incompatible with Struts and JSF. In which case I assume Ajax will eventually out-compete these.
MS created XMLHttpRequest about 5 years ago...
Yep, I was working with it three years ago, though the acronym 'Ajax' is new. The sea change has been the recent support for it by non-IE browsers. Finally Ajax works on Linux and Mac. While Ajax shows the rising potential of clientside inclusion, strangely W3C has deprecated HTML frames, a big piece of clientside inclusion. What the heck is going on?!
|
|
|
Message #163218
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
done it 2 years ago (sort of...)
Well, not me, but this guy: http://jsolait.net/
A simple example of XMLRPC done in javascript:
http://jsolait.net/examples/xmlrpc/chat.xhtml
I did some testing some time ago together with apache XMLRPC, it was wonderful to see browser exchanging data with tomcat behind it, no page reloading at all. Felt like good old client-server days, but inside the browser! Very nice!!
Regards,
Henrique Steckelberg
|
|
|
Message #163220
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No feedback
I've just tried it with Firefox... well, for the moment I'm not very impressed. The problem is, I receive no feedback on wheter my clicks have any effect or not. No hourglass, no browser animation whatsoever.
In this state, it may be interesting for intranet application if all of the interactions require very fast operations on the back end, so that the response is immediate.
On an internet connection it seems pretty much unusable... during my experiments I kept wondering if I clicked for real or not...
|
|
|
Message #163224
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Struts does support Ajax
Having used both Ajax and Struts, but never together, it's my naive impression that Ajax might be incompatible with Struts and JSF.
Ajax is about making server calls from the client using XMLHTTPRequest or a hidden IFRAME. The delivery mechanism for the page still needs to exist and Struts is a good match here. Struts delivers the page and its javascript. Ajax calls Struts Actions that render JSON/XML/Strings using JSP, Velocity, or whatever.
Personally, I've been using XML-RPC from the browser for several years on a Struts-based application with great results. I'm tending to lean towards JSON lately as it is more compact and natural for the client.
A side note, Struts Flow, a Struts subproject, is working on native Ajax support using JSON as the transport. In this case, the server side glue language is Javascript as well, so it is a simple matter of the Javascript client calling a Javascript server function (with security checks, of course).
|
|
|
Message #163225
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No feedback
I've just tried it with Firefox... well, for the moment I'm not very impressed. The problem is, I receive no feedback on wheter my clicks have any effect or not. No hourglass, no browser animation whatsoever. It is still alpha (c) Mark Nuttal. They showcase the test app for you to appreciate the overall beauty of the solution.
Search for XMLHTTPRequest, see that it has several states, like "loading" or "loaded". So, client app can show something like "content is being loaded" or hourglass if access to the hourglass feature is possible.
You will need a new browser anyway for better XML/XSLT/SVG support ;)
|
|
|
Message #163227
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No feedback
checkout the forums for some answers to our questions.
I suggest people check out EchoStudio and think about what Echo2 will give you when it is production ready. It is incredible how good web application development can be. You almost don't know you are doing a web app.
|
|
|
Message #163231
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Some issues to think about
This is a great toolkit.
I have been a fan of AJAX for sometime now, since my old company based their entire system of client-side javascript. In fact, at least 60% of the business logic was in client-side javascript, which made things very responsive, but very brittle. This should provide a good inbetween.
Oh, and it avoids sharing your code base with the world.
|
|
|
Message #163232
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Disappointing
After clicking around on a few things using Mozilla, the application seemed to be hanging and I got the same message 'invalid response from server' a couple of times.
I like the fact that the page isn't refreshing, but it appears there is still some work to do.
|
|
|
Message #163233
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why do they use the "frames hack"?
Hi Brian,
That high-level technical overview is specific to Echo 1.x, which used a hidden controlller/synchronization frame for client-server communication. Echo 1.x did not make use of XMLHttpRequest, but rather submitted a plain-old-HTML-form to the server with state updates using the hidden controller frame. The 1.x server would respond to such requests with JavaScript directives to update, which generally replaced entire HTML frames to reflect the server-side application state changes.
In 2.0, we're not using any HTML frames at all. The XMLHttpRequests are made from within the one and only document, and both inbound and outbound messages are XML-based.
Best regards
--Tod Liebeck
NextApp, Inc.
|
|
|
Message #163234
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Disappointing
Hi Paul,
Sorry the demo didn't work too well for you. The "Invalid Response from Server" is a catch-all message indicating a server-side exception occured. Regrettably one feature that didn't make it into the framework for this release was proper server-side runtime exception handling, where the user's session is restarted. As a result, once you get one "Invalid response from Server" the application enters an indeterminate state, and from that point on you're very likely to see many more "Invalid Response from Server" messages. You'll need to either exit the browser or manually clear the session cookie in order to obtain a fresh session when this happens.
Correcting this issue is one of the highest priority items on the 2.0 todo list. I'll also be checking the server-side logs to see what exceptions were thrown today. This is the first time an Echo2 application has seen this level of real traffic.
Best regards
--Tod Liebeck
NextApp, Inc.
|
|
|
Message #163237
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EchoPoint/EchoStudio Support
Hi Mark,
EchoStudio/EchoPoint currently only support Echo 1.x. Brad Baker (the primary author of EchoPoint) is currently looking into a 2.0 version of EchoPoint.
EchoStudio 2.0 is also in the works, and I'll have more public information on this soon. The 2.0 version will be provided free of charge to developers who purchased 1.0 licenses.
Best regards
--Tod Liebeck
NextApp, Inc
|
|
|
Message #163238
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No feedback
Hi Andrea,
You're correct that "feedback" is a feature that has yet to be implemented in Echo2. We hope to have a highly configurable implementation available in future releases. In retrospect though, I think we probably should have at least included the minimum "hourglass cursor" support ahead of this release.
Best regards
--Tod Liebeck
NextApp, Inc.
|
|
|
Message #163240
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EchoPoint/EchoStudio Support
The 2.0 version will be provided free of charge to developers who purchased 1.0 licenses.Best regards--Tod Liebeck NextApp, Inc Thanks. I was hoping so. Just bought EchoStudio the end of January.
|
|
|
Message #163243
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Struts survives the revolution! Struts does support Ajax
In this case, the server side glue language is Javascript as well, so it is a simple matter of the Javascript client calling a Javascript server function (with security checks, of course).
The concept of ECMAScript at both ends suggests the possibility of a peer-to-peer grid of browsers. No need for Java or Sun at all in this case.
I'm thinking maybe our industry's future involves much ECMAScript, and this could immensely propel XULs such as SVG-2. What I find implausible is hand coded ECMAScript. Ajax begs for a code generation. I've even considered a the utility of a bytecode->ECMAScript converter. This has advantages:
1) Civilization has more JavaScript interpretors deployed than JVMs.
1) Custom script behavior could be developed in Java, a better language for handcoding and then deployed as ECMAScript.
2) Jars (including rt.jar) could be translated into pure ECMAScript.
4) ECMAScript could effectively replace bytecode as Java's executable format. Ie, human-editable Java executables!
|
|
|
Message #163245
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Some issues to think about
In fact, at least 60% of the business logic was in client-side javascript, which made things very responsive, but very brittle.
Code generation is the answer to brittleness. Does JSON generate JavaScript functions? I know that JSF renderers can theoretically generate JavaScript; maybe that's the best way.
Traditionally the best practice was to place JavaScript functions in .js text files. I think that hand praxis is doomed. I think JSF render encapsulation might be its evolutionary successor.
|
|
|
Message #163251
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Love it
I used the old Echo server extensively a few years ago but eventually abandonded using it when people complained my pages refreshed too slowly and too often. Back then there weren't many frameworks that provided a high-level of abstraction for web development. Now there's quite a few but the new Ajax-driven arch may give Echo an edge. They've certainly done a good job of eliminating the annoying whole-page-refresh -on-button-press issue.
I prefer writing standalone Swing/SWT-based rich client/server apps to standard web apps and Echo makes web development a very similar exercise.
|
|
|
Message #163253
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Some issues to think about
In fact, at least 60% of the business logic was in client-side javascript, which made things very responsive...
This should preempt false criticism that JavaScript is supposedly slow. JSP is slow. Fat client is much faster.
|
|
|
Message #163255
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
Seems like a very nice framework. Good job, guys!
I, only, have two concerns (only applicable to websites, though):
1) Enabling users to send URLs to each-other. Though, I admit, one can create some artificial way of doing it (not necessarily copy/paste from the URL bar but allow alternative way) - still a pain.
2) SEF - How well will search engines (most importantly Google) index these pages? SEF is _extremely_ important matter for a web-site (esp. e-commerce), much more important than if a user needs to refresh a page. I am very afraid that regarding SEF, non-URL-changing frameworks will suck, unless search engine logics change or frameworks accomodates, somehow.
These two are very important for a very large portion of web portals (not all). So the following, with all due respect, is just a juvenile escitement:I am 100% confident that all major frameworks and portals will move to ajax before the year ends. Those who will not do it, will die.
All portals _will not_ move to Ajax and those who won't, will not die. Those who use it wisely, if they need it - may get competitive advantage, but - that's it!
Also, this is no excuse:
Can you get a link to a certain window in a desktop application? Ajax is for web applications, not for hyperlinked documents.
I do not know a definition of "web application" vs. "web site as a collection of documents", because this is bullshit. All web portals are web applications, nowdays and THEY ARE DIFFERENT FROM DESKTOP APPs and always will be! The reason is simple - that's how internet works, HTTP is a stateles, one-way protocol. Very simple fact, why is it so hard to get it?
I think, presenting Ajax as just another attempt (none of which were successful, so far) to make web-development a clone of desktop app development, just diminishes its beauty and declaring that all web development must happen on Ajax, from now one - does no good to this beautiful technology, either.
Hint: Macromedia Flex.
|
|
|
Message #163256
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
welcome to the Club!
Here you can see the reaction from the old-school type of persons when I advocated XMLHtpp for two years ago with code sample and all.
Accepted Answer from rolftollerud
Ajax is an improvement though, for me people with IE was a big enough market. :)
Now when you at last begin to see the light, you can begin to ponder questions like
1) Ajax calling Web Service directly
2) Where do ORM fit into this (nowhere..)
3) Do you need the Big Elephant J2EE servers? (no..)
4) Do you need all this Frameworks? (no..)
and so on and so on...
Best regards
Rolf Tollerud
|
|
|
Message #163259
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
I do not know a definition of "web application" vs. "web site as a collection of documents", because this is bullshit. All web portals are web applications, nowdays and THEY ARE DIFFERENT FROM DESKTOP APPs and always will be! The reason is simple - that's how internet works, HTTP is a stateles, one-way protocol. Very simple fact, why is it so hard to get it? IP does not guarantee neither proof of delivery, nor packet order. But TCP/IP does. HTTP is stateless, but HTTP+session cookie+server state object is stateful.
Hint: Macromedia Flex. Bloatware pretending to be a window manager or even a mini-OS. Not even once I had a thought that web apps should have built-in windows. Thank you, I already have my native browser windows. Give me better support for simultaneous windows for one user session, and better keyboard support (hint: GMail), and I will be on ninth heaven.
|
|
|
Message #163265
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
Just want to say congratulations again to the Echo team for a fine product. I've used Echo1 and really like it. Looking forward to trying out Echo2, pretty sure I am going to like it as well.
Thx
regards
tmjee
|
|
|
Message #163266
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
[quote]So I can't send a link to someone? Isn't that why frames are so hated?[/quote]
I guess the way to do that in Echo is through implementing Service interface and registering it with the echo server as global service. It will be invoke upon, http request having a E_id = the_e_id_assigned_to_service
regards
tmjee
|
|
|
Message #163269
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Does it really?
>> 1) Civilization has more JavaScript interpretors deployed >> than JVMs.
Does it really? Do you have a definitive source for that claim?
|
|
|
Message #163272
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
1) Ajax calling Web Service directly
Already on the TheServerSide I think was mentioned a generic SOAP stub for JavaScript. With XMLHttpRequest, it turns out that WSDL and SOAP documents are first-class JavaScript objects, a feat equivalent to JAXB or Groovy. I mean, here in Boulder there's a commercial XML database system written in Python, so I think maybe scripting is a viable service language.
In the SOA universe, JavaScript is perhaps more object oriented than Java. An XML document is an extensible structure, and the document's script nodes are its extensible behavior.
<blockquot>4) Do you need all this Frameworks?
It turns out JSP or XSLT makes it easy to metaprogram JavaScript. I think annotations, aspects, and templates are all examples of generative metaprogramming. So I think JSP survives. I'm curious though, what the relationship between Ajax and server continuations (eg, Cocoon) might be. Also, what about client script continuations and Ajax?
|
|
|
Message #163283
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
done it 2 years ago (sort of...)
Well, not me, but this guy: http://jsolait.net/A simple example of XMLRPC done in javascript:http://jsolait.net/examples/xmlrpc/chat.xhtmlI did some testing some time ago together with apache XMLRPC, it was wonderful to see browser exchanging data with tomcat behind it, no page reloading at all. Felt like good old client-server days, but inside the browser! Very nice!!Regards,Henrique Steckelberg
It is good to see a lot of interest in this technology but like already mentioned by others IE had this support quite some time back.
Actually, in 2002, when we were building an enterprise Hospital Information Management System we were pitted against another vendor who offerred a VB solution. The management understood why enterprise technology was good, but this small question lingered in their mind,
"Will users find it difficult to use a HTTP based enterprise application, with page refreshes and all that!? Which will not happen in VB"
We were so thankful at that stage for this XMLHttpd Technology, that we went back to the client and said "IF you agree to the condition that users will only use IE 5.5 or above then we will avoid the page refreshes and build a FLICKER FREE! application for you"
They agreed and the application now works wonderful with more than 200,000 patient records processed through this. Each day more than 800 new OP patient visits are recorded and believe me, If the users had to go through the normal Web Applciation mode, they would have thrown the application out by now.!!!!
It is so heartening that now FireFox also supports this technology and for us as Solution Developers for the Enterprise world, IE and FireFox solve all our requirements.
Through out our applications we use AJAX consistently and to great benefit.
NOW I have a new arrow in my repoitre when i need to tell clients why Client Server Technology has passed its day for Enterprise Application Deployments.
Sarath
http://www.quadone.com
|
|
|
Message #163285
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
welcome to the Club!Here you can see the reaction from the old-school type of persons when I advocated XMLHtpp for two years ago with code sample and all.Accepted Answer from rolftollerudAjax is an improvement though, for me people with IE was a big enough market. :)Now when you at last begin to see the light, you can begin to ponder questions like1) Ajax calling Web Service directly 2) Where do ORM fit into this (nowhere..)3) Do you need the Big Elephant J2EE servers? (no..)4) Do you need all this Frameworks? (no..)and so on and so on...Best regardsRolf Tollerud
I do agree on some fronts with you and like i mentioned in some other post, we too used XMLHttp in about 2002, to build some wonderful FLICKER Free enterprise applications for our clients.
but in the context of some of the questions us have asked, I have a different story,
1. is a good question and a solution. I agree with you on that.
2. ORMs my opinion play a good role and for me hibernate as a ORM Tool did wonders for our Inventory Management, Electronic Medical Records, Pharmacy Module and other modules. For each of these XMLHTTP with ORM and a simple class design ensured that i had a responsive and effective solution that scaled well and was easily customizable.
3. I seriously think XMLHttpd and Hibernate provide amazingly effective and good solutions to most scenarios and costly J2EE servers. I donot say that there is no need for J2EE Servers, but now we donot have to use them for every application indescriminately.
there should be a strong reason to use J2EE Servers though ;-)
4. Many of the frameworks do multiple jobs, not just supporting UI, but creating a standard development framework, a design language that all users understand over a period of time. Using a framework is i believe a good design decision for maintainability and customizability that enhances code and design reuse.
Not using frameworks but just relying on servlets or jsp directly could be very detrimental for a non trivial project.
More over We found a wonderful advantage with XMLHttpd. Now we have our applications built with a combination of JAVA, PHP and .Net. Where if i need a quick query coming from a mysql database, I just send a XmlHTTP Request to a PHP script that gets the data for me, while some other functionality might be used from .Net or JAva Server application.
This flexibility is amazingly liberating ;-)
Sarath.
http://www.quadone.com
|
|
|
Message #163286
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
People, including me, have been doing this kind of stuff for a long time with Java applets. You certainly have compatibility problems (I've just discovered a new bug with one of my applets and JDK 1.5), but multithreading support and UI responsiveness is far superior with an applet. However, I agree it's far easier to have a graphically beautiful interface with HTML (and to update it !). Each approach has its pros and cons (Ajax based apps are easily deployed and beautiful, ont the other hand they are slower and can feel sluggish), so I'm not that sure that Ajax-based browser apps will eliminate the need for thick smart clients.
I'm thinking about it anyway for my business :)
|
|
|
Message #163291
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
Brian,
"Already on the TheServerSide I think was mentioned a generic SOAP stub for JavaScript"
What do you need a (fat!) SOAP stub for? It is just as easy to contruct your own SOAP message:
var oXMLHTTP =new ActiveXObject("Microsoft.XMLHTTP");
function getPage() {
var sURL = "http://localhost/testweb/adodb3.asp?id=12";
oXMLHTTP.open( "GET", sURL, true );
oXMLHTTP.onreadystatechange = managestatechange;
try {
oXMLHTTP.send();
}
catch (e) {
alert("Can not find the server");
}
var sURL = "http://localhost/consuming-WS/MyWebService.asmx";
oXMLHTTP.open ("POST", sURL, true);
oXMLHTTP.setRequestHeader ("Content-Type", "text/xml");
oXMLHTTP.setRequestHeader ("SOAPAction", "http://tempuri.org/Add");
var SoapRequest = "<?xml version=\"1.0\" encoding=\"utf-8\"?> "
+" <soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\""
+" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\""
+" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"> <soap:Body> "
+" <Add xmlns=\"http://tempuri.org/\"> <a> 1</a> <b> 3</b> </Add> "
+" </soap:Body> </soap:Envelope> ";
oXMLHTTP.onreadystatechange = managestatechange;
try {
oXMLHTTP.send(SoapRequest +"");
}
catch (e) {
alert("Can not find the server");
}
}
function managestatechange() {
switch (oXMLHTTP.readyState) {
case 4:
// var xml = oXMLHTTP.responseText;
// alert(xml);
var objReturn = new ActiveXObject("MSXML.DOMDocument");
objReturn.loadXML (oXMLHTTP.responseXML.xml);
//alert(objReturn.xml);
var strQuery = "soap:Envelope/soap:Body/AddResponse/AddResult";
var answer = objReturn.selectSingleNode(strQuery).text;
alert(answer);
break;
}
}
Regards
Rolf Tollerud
|
|
|
Message #163293
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
about normal hypocrisy in the IT business
Sarath,
"This flexibility is amazingly liberating ;-)"
Yes it is really.
But as you see in the link http://oldlook.experts-exchange.com:8080/Web/Q_20686584.html, the resistance has been absolutely total until now. All kind of reasons was used, security whatever.
But now that Firefox also have this technology suddenly alls the reasons disappears as clouds in the sky. It turns out that the real reason was that "the other browser" didn't have this capability! Why didn't they say so then! The hypocrisy is as dense as ever.
We never have suffered from this in real life though as clients for most cases are satisfied if it works in IE.
Regards
Rolf Tollerud
|
|
|
Message #163298
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: IE 5.5 Support
>For a sample demonstration application written using >Echo2, please visit:>http://demo.nextapp.com/InteractiveTest/iadoes not work in IE 5.5, windows 2000 :-(Dmitryhttp://www.servletsuite.com
IE 5.5 unforunately will most likely not be supported by Echo2, as this browser has some notable CSS issues that would require significant efforts to work around. Internet Explorer 6.0 has been available for 3 1/2 years, as it was originally released alongside Windows XP in October of 2001.
Currently only Mozilla, Firefox, and IE6 browsers are "officially" being tested. We're currently looking into supporting Opera 8 and the KHTML-based browsers (i.e., Konqueror and Safari).
Also, please note that the demo server will be going down momentarily for about 5 minutes at 4:30AM Pacific Standard Time (12:30PM GMT)
|
|
|
Message #163308
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
Now when you at last begin to see the light, you can begin to ponder questions like
1) Ajax calling Web Service directly
2) Where do ORM fit into this (nowhere..)
3) Do you need the Big Elephant J2EE servers? (no..)
4) Do you need all this Frameworks? (no..)and so on and so on...Best regardsRolf Tollerud
1) Do you produce hard testable code? Yes
2) Do you produce unmaintainable code? Yes
3) Do you produce unmanageable software? Yes
4) Do you produce bad designed software? Yes
|
|
|
Message #163311
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Yes, MS has invented everything in this damn world ;-)
ASP.NET 2.0 already does.Read about it here: http://msdn.microsoft.com/msdnmag/issues/04/12/CuttingEdge/default.aspxand here: http://msdn.microsoft.com/msdnmag/issues/04/08/CuttingEdge/
Come on are you kidding or what ?
IMHO, the visual designer for dynamic HTML code was invented by NextStep WebObject (now owned by Apple), no doubt of that. Or was it by ColdFusion ;-)
The problem with ASP.net is that it is almost IE only, plus it is cloacking the network bandwith with its famous "view state" hidden field. On the immediate perspective, ASP.net seem a good solution. But on the middle term, ASP.net (winforms) is dead because of the upcoming Avalon.
MS is realy good at one thing, deprecate their own developper technologies by bringing new ones : DNA, COM, MFC, VB ...
IF you are a ASP.net developper Be sure that longhorn will deprecate most of your skills.
|
|
|
Message #163319
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fantastic demo
Congrats to NextApp on the echo2 release. Nice demo and I really like the debug window - its a killer!
We use echo1 extensively for all our web applications. echo has always been a quality framework that has made web application development more sane for those building complex web applications that are difficult to model with page based frameworks like struts and jsf.
I think that echo2 with its ajax enabled engine is the missing piece that will put echo over the top. Now echo will be more lean and efficient even for large hosted internet applications.
Rauf
http://grandlogic.com/
|
|
|
Message #163320
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
Jon,
"This trivial example does not convince me of your genius"
Hmm, we are grumpy today aren't we? I was merely pointing out that you do not have to download a 300K library to play with SOAP, defeating the whole purpose. You can abstract away the string concatenation but it have to be done in some layer you know, it will not be done by some magic.
Mileta,
1) Do you produce hard testable code? Yes
2) Do you produce unmaintainable code? Yes
3) Do you produce unmanageable software? Yes
4) Do you produce bad designed software?
You forgot:
5) Do Google produce superior applications? Yes
6) Do J2EE engineers produce inferior applications? Yes
Regards
Rolf Tollerud
|
|
|
Message #163322
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
maintainability
I want to understand the cost impact of using AJAX style framework/architecture.
I don't think Google prooves anything about the general feasability of an all encompasing AJAX architecture. Google has hundreds of thousands if not millions of users for their apps. They can afford to develop very complex apps that are difficult to maintain because of the scale of their development.
What about for a 100 user app? Or a 10 user app? Do the costs make sense then? Or should you use AJAX only where appropriate in these apps? How hard will it be to maintain an app using this AJAX framework compared to an app using server side code?
Jon Paugh
|
|
|
Message #163327
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
maintainability
With echo2 you don't have to be a javascript guru to get AJAX capability.
The beauty of echo2 is that you actually do less client-side javascript because server-side interaction and responses are now much much more lean and efficient.
Very simple example - With echo2, when you click a button to change the background color of another separate component, you do all this in server side java (no javascript that you write). Echo sends the action to the server, which figures out that the color of another component has changed and sends back to the browser only the HTML markup to update that one components background color (more or less).
Note, you can see this if you build a simple echo2 app and use the debug window to see what requests and responses get sent back and forth.
Sam
|
|
|
Message #163331
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
about normal hypocrisy in the IT business
...the resistance has been absolutely total until now. All kind of reasons was used, security whatever.But now that Firefox also have this technology suddenly alls the reasons disappears as clouds in the sky.
I take this as a total validation of Gerald Bauer's rabid XUL evangelism and paranoid complaints of "resistance" (your word). Maybe all that RIA needs under the hood are XUL and Ajax.
It turns out that the real reason was that "the other browser" didn't have this capability!
Years ago I was awed by MSXML's clientside XSL, which complemented Ajax. I think the biggest impedement to evolution was W3C's refusal to acknowledge XmlHttpRequest. But this has been resolved now that W3C has defined DOM Level-3 Load-&-Save, which should completely revamp Ajax.
|
|
|
Message #163333
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
5) Do Google produce superior applications? Yes
6) Do J2EE engineers produce inferior applications? Yes
It pains me to find myself agreeing with monopoly-boy Rolf.
|
|
|
Message #163341
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Some of you are crazy
Let me see if I understand where some of you are trying to go with this????
------------------------
JavaScript is all of a sudden so awsome that we can/should do everything in browser: ORM, Business Logic, scientific computing.
------------------------
A couple people write a sort-of cleaver front-end, and everyone has a orgasm over it. People have been doing this stuff for 5 years. Sure Google is one of the first companies to provide it to the masses, and now we have a cute acronym for this programing style, but non of it is new.
Next we are going to see everyone waving flags over some new Apache Perl Mod or something, equally uninventive.
|
|
|
Message #163346
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
Rolf, sounds like you found your crack dealer's cell phone number again.
Why would ORM not be necessary? This client-side code is just that, client-side. Whether you're using J2EE or .NET, this is just a veneer on top of your normal application code. So the normal rules of good design still apply. If you're talking to a database in your application, the same reasons for using ORM in a normal web application apply here. The idea is to separate concerns, so that client code deals with client presentation and db code deals with db access. That way, changes to one won't always have a severe ripple effect. In such a scenario, ORM can take away a lot of the pain of mapping your application code to a database. I'd rather set up a mapping file than hand code JDBC or ADO.NET connection handling. I've done it in both and it's a pain. I shudder to think of JavaScript code calling your database and would hate to have to ever maintain or extend anything you wrote.
As for frameworks, what do you think is in that koolaid you're drinking? ASP.NET is a FRAMEWORK. It is a very heavy framework that dictates a certain way of writing pages. Would you prefer communicating directly with HTTP calls? Frameworks exist to codify and standardize a way of building an application. They should help more than they hinder. But they do help, and an application without some kind of framework, even if it is a custom framework, is probably not going to have a coherent design. If you can find a good web framework that supports the way you are thinking about a given application, they it is always more intelligent to leverage that work than to go off on your own with a cowboy mentality and just start coding at random.
As for J2EE servers, again, you are using the equivalent in IIS. The difference is that with J2EE, I have a choice of servers with varying degrees of complexity and features. I'm not stuck with one.
I really don't get where you pull these arguments out of. Saying "I supported using the XmlHTTPRequest 2 years ago" and then saying "see, that means you don't need ORM, J2EE servers, or frameworks" is about the craziest, stupidest thing I've heard anyone say on these boards in a long time.
|
|
|
Message #163347
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
selective memory
Rolf has this thing call selective memory. Even though plenty of people were saying things long before Rolf does, he loves to claim to be a leader or more enlightened as he likes to put it. If you read his posts like some kind of cheesy reality TV script, it's great fun :)
I'm guilty of proding him on a regular basis for entertainment, so I probably owe the community an apology for adding to the noise.
peter
|
|
|
Message #163348
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
"see, that means you don't need ORM, J2EE servers, or frameworks" is about the craziest, stupidest thing I've heard anyone say on these boards in a long time"
Hi Drew,
I am sure that ORM, J2EE servers and frameworks will exist even in the future. After all this newfangled "xmlHttp Rich Clients with Javascript" will not take all the market. :)
But some market space has to be given to this new style fashion. After all it almost begins to look like as if the Berlin-wall has fallen. If, and I say if, the communication between the server and client is XML-text and all the functionality resides at "the occasional connected client", what is the use of converting to Objects at the server if you just need some XML to send to the client anyway?
Regards
Rolf Tollerud
|
|
|
Message #163355
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tod, thanks.
Hi Brian,That high-level technical overview is specific to Echo 1.x, which used a hidden controlller/synchronization frame for client-server communication. Thanks for clarifying that Tod.
In 2.0, we're not using any HTML frames at all. The XMLHttpRequests are made from within the one and only document, and both inbound and outbound messages are XML-based.Best regards--Tod Liebeck NextApp, Inc.
Tod, are the same type of design docs currently available for the Alpha review of Echo2? If not, when would these be available for inspection outside NextApp?
Thanks.
|
|
|
Message #163361
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
If, and I say if, the communication between the server and client is XML-text and all the functionality resides at "the occasional connected client", what is the use of converting to Objects at the server if you just need some XML to send to the client anyway?
What's the use of using XML if it all comes out a string anyway? What's the use of any abstraction or modelling mechanism?
The answer of course is not the message, but the process by which the message is generated.
While we can see the FRONT END of what Google did with gmail or maps, it's safe to assume they have something on the backend to manage all the data.
|
|
|
Message #163363
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
for me people with IE was a big enough market
Declining now though, thank goodness.
:)Now when you at last begin to see the light, you can begin to ponder questions like1) Ajax calling Web Service directly 2) Where do ORM fit into this (nowhere..)3) Do you need the Big Elephant J2EE servers? (no..)4) Do you need all this Frameworks? (no..)and so on and so on...Best regardsRolf Tollerud
I guess if people are wanting to send very low-volume traffic to their personal desktop PCs, as in your
"Accepted Answer from rolftollerud"
http://oldlook.experts-exchange.com:8080/Web/Q_20686584.html
perhaps not. However, I don't think most companies would be happy with individual users setting up their desktop PCs as web servers handling traffic from the organisation's website (as indicated in the responses to your answer, there could well be problems it the users turn their PCs off).
Most companies are after solutions that won't collapse under load, can scale, and can be cleanly modified. Hence ORM, J2EE etc.
|
|
|
Message #163367
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tod, thanks.
Tod, are the same type of design docs currently available for the Alpha review of Echo2? If not, when would these be available for inspection outside NextApp? Thanks.
Brian,
The "high-level technical overview" is currently under development for Echo2; I'm hoping to have something online within a week or so. The other documentation priority at the moment is porting the "Echo Tutorial" found in 1.x over to Echo2, which should be available in roughly the same timeframe.
Best regards
--Tod Liebeck
NextApp, Inc.
|
|
|
Message #163368
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ORM, WORM, J2SE, J2EE, etc
"Most companies are after solutions that won't collapse under load, can scale, and can be cleanly modified."
A ha! I didn't knew that.
"Hence ORM, J2EE etc"
Hmm. Have you asked Vic about this? I was under the impression that it is stateless servers that scales best?
Regards
Rolf Tollerud
|
|
|
Message #163370
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
stateless frameworks are dead
Can you imagine, there are still people out there, that believe that stateless, page- oriented frameworks have seriousness?! Echo2 is cool! Congratulations!
|
|
|
Message #163371
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ORM, WORM, J2SE, J2EE, etc
"Most companies are after solutions that won't collapse under load, can scale, and can be cleanly modified."
A ha! I didn't knew that.
Hence your solution which routes part of a company website to a personal desktop PC.
"Hence ORM, J2EE etc"Hmm. Have you asked Vic about this? I was under the impression that it is stateless servers that scales best?RegardsRolf Tollerud
If we were all concerned with what scales best, we would write everything in assembler on specialised processors.
I actually know developers who write this kind of thing. It is a very specialised skill, but not something you would want to use to write your website.
Less specialised solutions assume that tailored proprietary, vendor-specific approaches can give scalability. This is also a possible solution, and is fine if you want to tie yourself into a specific vendor for years or even decades, and you assume that the vendor will support the technology you use for that long. This is a high-risk strategy.
The modern approach is to use solutions that are scalable and portable and modifiable. We deal with reasonable compromises. Thus ORM, Object Orientation and J2EE.
|
|
|
Message #163380
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
sweet, everyone throw away your databases
Hmm. Have you asked Vic about this? I was under the impression that it is stateless servers that scales best?
RegardsRolf Tollerud
If we take that statement at face value, it would mean stateful servers like Sql Server, Oracle, MySql, Postgresql, db2 and sybase should be thrown out. Since according to the statement above, they don't scale as well. Let me call up AP, Reuters and let the whole world know everyone was duped into thinking databases are useful.
this message brought to you be Over-Generalization.
|
|
|
Message #163383
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
why don’t you come aboard the train?
Steve & Peter think they are so funny and confuse the possible with the unpractical.
It is unpractical to write part of your app in assembler
It is definitive impossible to throw out the database.
The stateless server however, is neither impractical nor impossible, but a very useful concept that is too little used in the J2EE world. (Because they always like to over-architecture. )
Now Peter Lin is going to hang me and teach us how ridiculous the though is that the worlds largest financial broker should use a stateless system with no thoughts at all that it has nothing to do with the discussion.
Best wishes
Rolf Tollerud
(written from the first class wagon of the Service Orient Express, I just had Fresh croissants, fruit juice, and fruit salad, with coffee )
|
|
|
Message #163385
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIA, welcome to the Club!
Saying "I supported using the XmlHTTPRequest 2 years ago" and then saying "see, that means you don't need ORM, J2EE servers, or frameworks" is about the craziest, stupidest thing I've heard anyone say on these boards in a long time.
Agreed. By enriching the zero-administration client and encouraging more ambitious front ends, Ajax and XUL could help further grow the web application industry. In most cases the server ties ain't going away, so RIA's growth could give J2EE a big economic boost. I've managed to convince myself that Sun is surely happy about Ajax and XUL.
XUL + Ajax = RIA
The icing on the cake is that with W3C and ECMA standards, the entire client is internationally standardized. Not even WebStart has that. Now I understand why Sun targets servers -- fewer existing standards -- more opportunities to use proprietary specifications.
|
|
|
Message #163386
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Stateless, throw away your databases
I was under the impression that it is stateless servers that scales best? If we take that statement at face value, it would mean stateful servers like Sql Server, Oracle, MySql, Postgresql, db2 and sybase should be thrown out.
Um, 'stateless' means lacking a session, not lacking persistance.
You mentioned Oracle. Well, SQL is a CRUD language. CRUDlets are described as stateless. REST is also a CRUD language, and it too is described as stateless.
|
|
|
Message #163388
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
Interesting techniques, but I am wondering how this will work in a portal (JSR168) type application. On the surface it seems nice to be able to reload only the content of a single portlet when a user clicks in the UI, but how would it handle portlet collaboration? If the portlet on the server communicates with another portlet, so that in effect that other portlet should be reloaded as well, it seems that with the described approach that other portlet won't be updated. With the current "dumb" approach of reloading the entire page it is trivially updated. Do you have any solution for that as well? Otherwise it will probably be difficult to adopt this in a portal context.
|
|
|
Message #163389
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Database servers not stateful?
Um, 'stateless' means lacking a session, not lacking persistance.You mentioned Oracle. Well, SQL is a CRUD language...
I don't know about all the CRUDdy stuff you go on quoting their, but by it's own inherent nature, a transactional API is stateful. (Any database without transactions is not a database worth using). And, as I'm sure Cameron would agree, database servers really don't scale. That's just the nature of the beast.
God bless,
-Toby Reyelts
|
|
|
Message #163391
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
bye bye to both Sun and Microsoft
"I've managed to convince myself that Sun is surely happy about Ajax and XUL"
I don't think so Brian!
But the beauty of technology like AJAX/Echo2 is that it is a wonderful compromise that leaves both companies in the dust.
From Sun's standpoint, the whole enchilada of J2EE and Java is going to diminish in importance, giving place for other (potentially non-Java) solutions at the server. They will not be happy with that!
But on the other hand, with elegant zero-administration browser based solutions everywhere Microsoft will not succeed in its evil plans to bring all applications back to Windows desktops with Avalon/XAML.
I really think that it is quite funny, some kind of justice in effect here.
Regards
Rolf Tollerud
|
|
|
Message #163393
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
why don’t you come aboard the train?
it is definitive impossible to throw out the database.
True, but who was suggesting that? My view is that it is unwise to concentrate too much on the database itself as the heart of the application - this leads to too much dependence on specialised features.
(Because they always like to over-architecture. )
What you call over-architecting is, in reality, producing applications that have sensible abstractions allowing portability.
For example, I don't believe I am sacrificing significant performance by using J2EE and an ORM to abstract away the details of the database. In fact, I have performed benchmarks which reveal that I am not losing much doing this. However, the benefits are huge: I am actually in a position to obtain competitive tenders for ORM suppliers, J2EE suppliers, database vendors and OS vendors, while keeping my codebase. I am frequently amazed that so many developers are prepared to develop code tightly linked to a particular database or OS.
Best wishesRolf Tollerud(written from the first class wagon of the Service Orient Express, I just had Fresh croissants, fruit juice, and fruit salad, with coffee )
I am deeply envious!
|
|
|
Message #163396
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax is total crap
First of all, anyone who would base a tool, framework, or application on javascript is an idiot.
Second of all, Javascript will never work the same on more than one browser at a time for more than 6 months to a year.
Third of all fat client sucks, why go there?
(Show me a fat client that has a rich interface and Ill show you a piece of crap that wasnt built based on solid requirements , doesnt provide any business value, and pisses off users all day long. Dont make me name names.)
Fourth of all if AJAX is what you need to "get off citrix" then you are an idiot.
Fifth of all, if you are a full time professional javascript programmer, please...quit.
Sixth of all,
Stop bitching about webapps and grow up.
Seventh of all,
Stop rehashing all this bullshit and actually come up with something new. Make something better than the smell of your underwear when you wake up in the morning.
Javascript xml http requests is like my mother calling my older sister to tell her Im fat.
I am fat. So what. Deal with it. It doesnt make an application better.
|
|
|
Message #163397
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax-based Rendering - Have a look at Casabac
Casabac is in the market of desktop-like web applications since three years - have a look at http://www.casabac.com for a huge collection of demos + evaluation downloads.
Casabac comes with an extensive control library covering all application needs - from fields, labels, buttons, etc. over grids, trees up to complex reporting controls containing charts.
In addition to its web user interface Casabac allows - based on an XML layout defintion - user interfaces to be also rendered in a non-web, but Java-Eclipse-based client.
Bjoern Mueller, Casabac
|
|
|
Message #163398
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Casabac is absolute junk
I went through your demo here's the results.
The tab order worked on the web app and didnt work on the casabac app.
The stylesheet on the casabac app looked better by design. There was nothing visually better that couldnt easily be applied with a stylesheet to a normal web page.
Clicking the 'back' button on the casabac app caused a jarring and ridiculous error which no web app would normally throw. Showing that your app cant handle normal browser functionality at all.
And you are in business why?
Please quit. Casa - back- the heck outta here.
|
|
|
Message #163400
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and remote scripting..
I have to look into ajax, but it very much sounds like what remote-scripting does. Is ajax more like Remote scripting on XML ?
thanks in advance for clarifying.
|
|
|
Message #163403
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ORM, WORM, J2SE, J2EE, etc
"Hence ORM ... Hmm. Have you asked Vic about this?
Everybody recommends a combination of ORM and JDBC, because of their different +/-. Only Vic and Rolf recommends only JDBC ... interesting ... One would imagine that more options are always better than only one (well you need to have some skills to make right decision ...)
I was under the impression that it is stateless servers that scales best?RegardsRolf Tollerud
If you have a stateless server then you have a stafull client. And every time you call the steless server you have to pass a state. If a size of the state is not small, then your system does not need to be scalable. So sometimes it makes sense to keep your state close to DB ...
I got an impression on the TSS that some people here believe that one technology can be superior to all other ones under all conditions ... I wish the world would be so simple ...
I like J2EE because it gives me too many options ...
DF
|
|
|
Message #163411
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Obi-Van Kenobi, AJAX is our only hope
Dear Mr anonymous,
Contrary to you I think CasaBac has high quality products in the style of good old German thoroughness - but that was not what I really wanted to say.
The point is that you - obviously a "Big J2ee Elephant Server" fanatic, should better hope for all your worth that the XMLHttpRequest type of clients succeeds. Why? Because the other alternative is "Microsoft takes all".
Because there is no other competitor to Avalon/XAML. Nothing.
I hope you see the writing on the wall! :)
"One that only want the best for you"
Rolf Tollerud
|
|
|
Message #163419
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax is total crap
Agreed.
Basing everything on javascript is a disasterous idea. Javascript hardly works correctly between browsers at all.
In my opinion, a well designed, traditional site (that does plain old refreshes) it best. The site just needs to respond fast and have reasonably sized pages.
Look at gmail, it's probably never going to get out of beta because they are having so many problems getting it to work in all browsers. I personally find it only a *little* faster that traditional mail applications. Not enough to justify the complex/buggy javascript architecture.
Javascript is fine for simple things but building complex sites out of it is madness.
Mike
|
|
|
Message #163423
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
If the portlet on the server communicates with another portlet, so that in effect that other portlet should be reloaded as well, it seems that with the described approach that other portlet won't be updated.
Ajax can manage multiple frames. It's simple DHTML.
I initially wondered about friction between Ajax and Struts/JSF. But I think now the two are complementary, hopefully with a market boost for J2EE and Sun. I have this naive intuition that Ajax and Portlets would be a great combination. Since Struts and JSF combined to make Shale, further convergence of frameworks is likely. Toss in some code generation, and this could seriously threaten fat clients like WebStart and especially Swing. I think J2EE developers are well positioned for providing remote services for RIA.
|
|
|
Message #163427
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Obi-Van Kenobi, AJAX is our only hope
Because there is no other competitor to Avalon/XAML. It sounds interesting, have you ever used Avalon/XAML stuff ?
|
|
|
Message #163431
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Juozas must have been away on vacation
But my dear Juozas the Avalon/XAML has been available for a long time in the Longhorn PDC. Then it was the Community Technology Preview Build (CTP) for windows XP in January! And then all the third part implementations like Mobiforms and Xamlon that can be used with current versions of .NET.
Xamlon has gone beta last week. Pro Compact Edition (CE) is in Beta 2! Where have you been? Everyone’s doing it!
Best regards
Rolf Tollerud
(tip: the most cool is "Avalon Browser Application")
|
|
|
Message #163441
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
Aaah, hallelujah! The net is now saved!
This one of those things that has a hype following but will be of marginal importance. Just give it some time and the developers learn about the sour grapes. Javascript as the interoperability point - not very convincing.
All crappy web applications that are abundant in the Internet will outlive it all. They are like dinosaurs that rule the web, and can only be wiped out by an unexpected catastrophe - not by 'natural' selection.
|
|
|
Message #163445
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
If the portlet on the server communicates with another portlet, so that in effect that other portlet should be reloaded as well, it seems that with the described approach that other portlet won't be updated. Ajax can manage multiple frames. It's simple DHTML.
I'm sorry, but I don't understand how that relates to my question.
To elaborate, today the only way (more or less) that JSR168 portlets can communicate with each other is through the session. In other words, on an action in a portlet it can set a session variable which can be used by another portlet in its rendering phase. But that assumes that this other portlet is rendered in the first place. And since the session is being used as the communication channel there is really nothing to tell the portlet framework that an action in portlet 1 really should cause a reload of portlet 2. As I said, in the "dumb" implementation this is done trivially as the whole page is reloaded, but with this fragmented approach I can't see any way to do it, unless you want to specifically mark relationships between portlets (=a hassle).
So what are you suggesting, really?
|
|
|
Message #163447
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Juozas must have been away on vacation
I see it is old good ActiveX control generated from XML and code mix. Do I need to download .NET runtime to execute AtiveX code ?
|
|
|
Message #163458
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Juozas must have been away on vacation
But my dear Juozas the Avalon/XAML has been available for a long time in the Longhorn PDC. Then it was the Community Technology Preview Build (CTP) for windows XP in January!
Aaah, the Longhorn card. Previews, betas, cutting edge demos, this and that - no product. How incredible will the future be in a couple of years.
|
|
|
Message #163460
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Hasta siembre
"It is no hurry, we have plenty of time to come up with something"
Is that what you mean?
Xamlon is in beta, no ActiveX.
Today I installed Avalon and Indigo Community Technology Preview March 2005.
Regards
Rolf Tollerud
(from Service Orient Express)
|
|
|
Message #163485
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
To elaborate, today the only way (more or less) that JSR168 portlets can communicate with each other is through the session.
Yes, that's a limitation of portlets. No, it isn't a limitation of Ajax frames. Also frames work well with a session.
And since the session is being used as the communication channel there is really nothing to tell the portlet framework that an action in portlet 1 really should cause a reload of portlet 2.
I'm sure there are many ways to do this with Ajax. Since you seem to think it's impossible, here's a naive way of using Ajax for a portal that I sketch only to chip away at the skepticism: a hidden frame can be a controller of all other frames. All clicks are diverted into the hidden frame, and all responses arrive first at the hidden frame.
Somehow I doubt you would have raised the same suspicion if we were talking about a WebStart client.
|
|
|
Message #163494
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
Interesting techniques, but I am wondering how this will work in a portal (JSR168) type application. ... If the portlet on the server communicates with another portlet, so that in effect that other portlet should be reloaded as well, it seems that with the described approach that other portlet won't be updated. With the current "dumb" approach of reloading the entire page it is trivially updated. If JSR168 is dumb, is it problem of AJAX or JSR168?
|
|
|
Message #163497
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what do you need a hidden fram for?
Just save your session in a object like,
//in pageone
function saveObj() {
var session = new Object();
session.first = "red";
session.second = "green";
session.third = "blue";
top.session = session;
window.location.href = "pagetwo.htm";
}
Then from any other frame you can use it,
//in pagetwo
function getObj() {
var session = top.session;
alert(session.first);
alert(session.second);
alert(session.third);
}
Works in IIE, Moxilla and Opera.
Regards
Rolf Tollerud
|
|
|
Message #163504
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
Yes, that's a limitation of portlets. No, it isn't a limitation of Ajax frames. Also frames work well with a session. The first post mentioned that frameworks and portals would move to Ajax within a year. I was just curious whether this was actually realistic. Your response suggests that it isn't.
I'm sure there are many ways to do this with Ajax. Since you seem to think it's impossible, here's a naive way of using Ajax for a portal that I sketch only to chip away at the skepticism: a hidden frame can be a controller of all other frames. All clicks are diverted into the hidden frame, and all responses arrive first at the hidden frame. And how does that relate to the problem I described?
Somehow I doubt you would have raised the same suspicion if we were talking about a WebStart client. Me too, since I doubt a WebStart client would have the same kinds of problems to consider. It would probably have a whole host of other problems to consider though.
|
|
|
Message #163505
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
If JSR168 is dumb, is it problem of AJAX or JSR168? I didn't say that JSR168 is dumb. I meant that implementing it the common way, i.e. to reload the page when a link is clicked, is inefficient compared to Ajax, so it could be considered dumb.
However, I put dumb in quotes because it has one important feature: it works. And I have yet to see how an Ajax approach would work, given the problems I described.
|
|
|
Message #163506
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
If JSR168 is dumb, is it problem of AJAX or JSR168? I didn't say that JSR168 is dumb. I meant that implementing it the common way, i.e. to reload the page when a link is clicked, is inefficient compared to Ajax, so it could be considered dumb. However, I put dumb in quotes because it has one important feature: it works. And I have yet to see how an Ajax approach would work, given the problems I described.
Updating the whole page when only one component was changed is a stupid thing, it always was. Ajax shows a way to update only the component which needs updating. Portals are based on components. Thus, "updating only the needed component" and "portal" seems like a natural marriage to me. If portals in their current state cannot do it, they suck. The good one will have support for Ajax, either based on some updated JSR-whatever or without it.
|
|
|
Message #163511
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax rendering with Millstone (as well as Swing and Web)
Tod, excellent work! Great to see that Echo is going forwards at full speed.
As always, I was interested to see if this could be easily done with Millstone. In fact developers at the IT Mill have been keen to implement Flash and Ajax support for a long time, but unfortunately we have not had time yet to do it properly. As a proof of concept, I did implement simple prototype for Millstone Ajax Adapter (source code on Sourceforge).
The nice thing is that you can support different adapters with the same application without any changes on the application. Here is an example of a simple calculator with different adapters: Web Adapter, Ajax Adapter Prototype and Swing Adapter Prototype.
For more info on Ajax prototype, see Millstone forum.
|
|
|
Message #163512
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax prototype only supports firefox
If you test the Ajax Adapter Prototype url above, please note that only firefox is supported. Internet Explorer could also be easily supported. If we want to support Safari, XSLT must be done on server.
What is the state of the other browsers? Does Opera work with xmlHttpRequest? Does it support XSLT? What about the rest?
|
|
|
Message #163518
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
Yes, that's a limitation of portlets. No, it isn't a limitation of Ajax frames. Also frames work well with a session. The first post mentioned that frameworks and portals would move to Ajax within a year. I was just curious whether this was actually realistic. Your response suggests that it isn't.I'm sure there are many ways to do this with Ajax. Since you seem to think it's impossible, here's a naive way of using Ajax for a portal that I sketch only to chip away at the skepticism: a hidden frame can be a controller of all other frames. All clicks are diverted into the hidden frame, and all responses arrive first at the hidden frame. And how does that relate to the problem I described?Somehow I doubt you would have raised the same suspicion if we were talking about a WebStart client. Me too, since I doubt a WebStart client would have the same kinds of problems to consider. It would probably have a whole host of other problems to consider though.
The great thing about Echo - it can be converted to a Swing app - and a Swing app to Echo.
|
|
|
Message #163519
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
Now when you at last begin to see the light, you can begin to ponder questions like 1) Ajax calling Web Service directly 2) Where do ORM fit into this 3) Do you need the Big Elephant J2EE servers? 4) Do you need all this Frameworks? and so on and so on...Best regardsRolf Tollerud These are not questions, these are possible answers, if you know what I mean. Don't let technology overwhelm you! :)
|
|
|
Message #163520
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
welcome to the Club!
Now when you at last begin to see the light, you can begin to ponder questions like 1) Ajax calling Web Service directly 2) Where do ORM fit into this 3) Do you need the Big Elephant J2EE servers? 4) Do you need all this Frameworks? and so on and so on...Best regardsRolf Tollerud These are not questions, these are possible answers, if you know what I mean. Don't let technology overwhelm you! :)
Many times a pygmy elephant J2EE server will do.
http://www.pibburns.com/cryptost/pygmyele.htm
:)
|
|
|
Message #163533
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opera users: Help->Report a site problem
for me (running opera 8, which i admit is a beta), that demo dies with 'invalid response from server'
On Opera, on the page which is failing, go to Help->Report a site problem. Tell opera to fix it while its still in beta!!
|
|
|
Message #163537
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opera users: Help->Report a site problem
for me (running opera 8, which i admit is a beta), that demo dies with 'invalid response from server' On Opera, on the page which is failing, go to Help->Report a site problem. Tell opera to fix it while its still in beta!!
If they admit the problem. For example, they think that it is ok not to reload a page on going back, even if it has "no-store" cache control header. Opera is for users obsessed with caching. It is great as a client for hyperdocuments, but not the best choice as a client of dynamic webapp. Anyway, why use it, if there is Firefox?
|
|
|
Message #163540
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tomcat to complicated?
Mark,
"Many times a pygmy elephant J2EE server will do!"
Nice try but Greg Wilkins (of Jetty fame) seems to think that even an simple servlet container is overkill!
There is no standard lightweight deployment package for HTTP consumers such as SOAP. A full 2.4 web application container is a bit of overkill if all you want to do is transport XML blobs. Why should you have a fully capable web tier just to accept web services? http://www.mortbay.com/MB/log/gregw/?permalink=servletsMustDieSlowly.html
Regards
Rolf Tollerud
|
|
|
Message #163547
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tomcat to complicated?
Mark,"Many times a pygmy elephant J2EE server will do!"Nice try but Greg Wilkins (of Jetty fame) seems to think that even an simple servlet container is overkill!There is no standard lightweight deployment package for HTTP consumers such as SOAP. A full 2.4 web application container is a bit of overkill if all you want to do is transport XML blobs. Why should you have a fully capable web tier just to accept web services? http://www.mortbay.com/MB/log/gregw/?permalink=servletsMustDieSlowly.htmlRegardsRolf Tollerud No, he said a full-blown web application containter was overkill. That is not the same as a simple servlet container.
|
|
|
Message #163548
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tomcat, Jetty, Resin?
Enlighten me. Is Tomcat a full-blown web application container or is it simple servlet container? The same for Jetty and Resin (not the J2EE version) please.
??
Rolf Tollerud
|
|
|
Message #163553
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tomcat, Jetty, Resin?
Enlighten me. Is Tomcat a full-blown web application container or is it simple servlet container? The same for Jetty and Resin (not the J2EE version) please.??Rolf Tollerud Rolf, Why must you talk things out of context (the context is the servlet API) and add things to the context (Tomcat or Jetty being full blown web app containers). Please enlighten me.
|
|
|
Message #163556
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I can hear the J2EE architects crying already
Mark,
"Please enlighten me"
Sure!
A full-blown web application container == simple servlet container == Tomcat == Jetty.
A Weblogic person may refer to Tomcat as a simple servlet container. Rod and Juergen however calls Tomcat a full-blown web application container. It all depend on whom that is speaking.
The point is that Greg Wilkins thinks that the servlet API used in Tomcat and Jelly is overkill.
A full 2.4 web application container is a bit of overkill if all you want to do is transport XML blobs. .
So, "Tomcat/Jelly is overkill according to Greg Wilkins"
Quod Erat Demonstrandum
Regards
Rolf Tollerud
|
|
|
Message #163562
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I can hear the J2EE architects crying already
Mark,"Please enlighten me"Sure!A full-blown web application container == simple servlet container == Tomcat == Jetty. A Weblogic person may refer to Tomcat as a simple servlet container. Rod and Juergen however calls Tomcat a full-blown web application container. It all depend on whom that is speaking.The point is that Greg Wilkins thinks that the servlet API used in Tomcat and Jelly is overkill.A full 2.4 web application container is a bit of overkill if all you want to do is transport XML blobs. .So, "Tomcat/Jelly is overkill according to Greg Wilkins"Quod Erat DemonstrandumRegardsRolf Tollerud Yep. What I thought. Take truths, cut them up and spice them together to get different "truths".
|
|
|
Message #163563
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
Since you seem to think it's impossible, here's a naive way of using Ajax for a portal that I sketch only to chip away at the skepticism: a hidden frame can be a controller of all other frames. All clicks are diverted into the hidden frame, and all responses arrive first at the hidden frame. And how does that relate to the problem I described?
You don't see that the MVC pattern can be implemented in JavaScript for managing a frameset?! I know this is new stuff, but please at least try.
Forget the Ajax controller I naively proposed. Elegant frameset management more likely involves the portlet including in its response some JavaScript logic that runs within the context of the portlet's frame, but uses the DOM to manipulate other frames as well. Ajax has a huge advantage over plain portlets: the client can recieve portal management logic. But I think that Ajax and portlets are complementary. I think that Ajax will very much need servlets, server frameworks, and portlets. Ajax is just another big piece of the portal puzzle.
|
|
|
Message #163569
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
it is not an all or zero choice
"Take truths, cut them up and spice them together to get different "truths"
That is what logic is about, Mark. But anyway. You do not have to build a application 100% in JavaScript & DHTML. You can use AJAX just to "piff up" your application a little. And everything in between. That is why it is so usable.
Regards
Rolf Tollerud
|
|
|
Message #163571
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
You don't see that the MVC pattern can be implemented in JavaScript for managing a frameset?!
I keep asking one question and you keep answering a totally different one.
Since it seems to be very difficult to understand the question, I'll try to rephrase it once more:
If a "page" has two "components" (let's say A and B), and triggering an event for component A (i.e. "clicking a link in the HTML for component A") leads to an update of server state that causes B to produce different output. With a so-called "dumb" "old-fashioned" implementation this would not be a problem since the entire page is updated, hence both A and B will have a chance to produce new output. Since the explicit purpose of Ajax is to allow only A to be updated, HTML-wise, how would you handle this situation? Will you:
a) avoid the problem and say that "there can be no dependencies between components"
b) declare a dependency between the components so that when A is updated the framework can update B as well
c) do something else entirely
d) keep answering some other non-asked random question
So which is it? I'm genuinely curious. And please, at least TRY to READ the question BEFORE answering. Thank you. With sugar on top.
|
|
|
Message #163572
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
Somehow I doubt you would have raised the same suspicion if we were talking about a WebStart client. Just a little note: if you think I'm sceptical of the technology as such maybe I should inform you that we have been using this approach (except we use a Java applet instead of JavaScript) for two and a half years already in our CMS/portal product. But only for the admin UI, i.e. for creating/composing pages, since I believe there issues with it in the general case.
|
|
|
Message #163577
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax and portals
Hi Rickard,
First I must say I am pleased to see you back in TSS again. You have blogged about your new company Portal/CMS SenseLogic and also are participating in a trivial TSS discussion! Maybe I should say welcome back to humanity? :) I read the Norwegian article - congrats to your success.
I hesitate to comment on the question of how portlet A can trigger an update in portlet B, I am not familiar with JSR168. But on further though there can be only two alternatives at the client (regardless of how it looks at the server):
1) Frames or
2) No frames.
In the case of 1) After doing a XMLHttprequest update of (parts of) A, you do a simple frame refresh of B, forcing it to update.
In the case of 2) you can do XMLHttprequest update of both A and B (even if it perhaps defeats the component encapsulation)
Regards
Rolf Tollerud
|
|
|
Message #163581
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
it is not an all or zero choice
"Take truths, cut them up and spice them together to get different "truths" That is what logic is about, Mark. But anyway. Sure. But not good logic. You went from truths to a partial truth.
You do not have to build a application 100% in JavaScript & DHTML. You can use AJAX just to "piff up" your application a little. And everything in between. That is why it is so usable. RegardsRolf Tollerud Sure, but handcoding can become a big mess for anything more than minor. That is why I am looking forward to Echo2. I suggest you look at Echo (and Echo2) and see what they are doing.
|
|
|
Message #163582
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
There has been a lot of talk in this thread about the appropriate use of JavaScript in rendering and application etc..
One thing to keep in my when examining Echo2 is that "90%" of the code and action still occurs on the server side in good old Java (servlet based) code.
The real "magic" is the "framework" that Echo2 gives you as a developer for keeping the client and server side representations in sync.
As a developer you work in Java with "well defined" components and the framework takes responsibility for "client side" rendering, wheteher is be DOM replacement, JavaScript function invocations or whatever.
Its great stuff.
Brad Baker
echopoint.sourceforge.net
|
|
|
Message #163586
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
There has been a lot of talk in this thread about the appropriate use of JavaScript in rendering and application etc..One thing to keep in my when examining Echo2 is that "90%" of the code and action still occurs on the server side in good old Java (servlet based) code.The real "magic" is the "framework" that Echo2 gives you as a developer for keeping the client and server side representations in sync. As a developer you work in Java with "well defined" components and the framework takes responsibility for "client side" rendering, wheteher is be DOM replacement, JavaScript function invocations or whatever.Its great stuff.Brad Bakerechopoint.sourceforge.net Excellent Stuff. With EchoStudio and Echopoint - Incredible.
So how is EchoPoint2 coming? :)
Take Javascript away from a Web App and you get a Web Site.
|
|
|
Message #163619
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what do you need a hidden fram for?
var session = new Object(); session.first = "red"; session.second = "green"; session.third = "blue"; top.session = session; I am not javascript fan, but this workaround looks better than "application transaction".
|
|
|
Message #163731
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Google vs J2ee NOT!
5) Do Google produce superior applications? Yes6) Do J2EE engineers produce inferior applications? Yes It pains me to find myself agreeing with monopoly-boy Rolf.
Please. You compare a company to a technology.
Lets rephrase:
Does X company write good software (yes!)
Have there been bad C applications? (Yes!)
Thought processes like these result in bad software more than any technology. Garbage in. Garbage out. Agree with anyone you like.
|
|
|
Message #163733
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wrong
Server side generation of javascript does not make javascript server side technology.
Not that it would be good it if were server side.
Javascript itself, (and future incarnations such as)
Javascript-RMI
Javascript-XML
Javascript-Enterprise Beans
Javascript-Reflection
Javascript-whatever
Javascript-Web services
Is crap.
It doesnt matter whether you generate it on the server or the client.
Its crap CRAP. DONT YOU UNDERSTAND?
Have you ever written a line of that crap in your whole LIFE!?
|
|
|
Message #163749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
care about the user? That is an insult to them
Not only do J2EE engineers produce crappy applications but they are also proud of it, they usually like to boast over their ignorance of XHTML/CSS/DHTML etc.
In other words exact like the old mainfram programmers! BTW, I met one of them here the other day in a taxi..
Regards
ROlf Tollerud
(He was not a passenger)
|
|
|
Message #163762
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
care about the user? That is an insult to them
Not only do J2EE engineers produce crappy applications but they are also proud of it,
Ah, so companies like... Ebay produce crappy applications? (You did not say 'some' J2EE engineers)
they usually like to boast over their ignorance of XHTML/CSS/DHTML etc.
Both server-side technologies like J2EE and website design skills (XHTML/CSS etc) are vital to good web application design. However they are orthogonal. They need not be the concern of the same developer. Why should the person dealing with server-side data processing have any interest in the (CSS) style or colour of the webpage? Why should the webpage design artist have any concern about the (J2EE) mechanisms of data access and processing?
In other words exact like the old mainfram programmers
Perhaps, one of these years, you will produce a simile with some vague relevance. For the old mainfram[e] programmers the presentation technology was the line printer, which, if my memory from many decades ago serves me right, did not involve CSS, DHTML etc...
|
|
|
Message #163766
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
care about the user? That is an insult to them
Both server-side technologies like J2EE and website design skills (XHTML/CSS etc) are vital to good web application design. However they are orthogonal. They need not be the concern of the same developer.
Are you telling me you've never templatized a little JavaScript within an a JSP loop? If so, you're missing out on another world of metaprograming.
|
|
|
Message #163801
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
care about the user? That is an insult to them
Both server-side technologies like J2EE and website design skills (XHTML/CSS etc) are vital to good web application design. However they are orthogonal. They need not be the concern of the same developer. Are you telling me you've never templatized a little JavaScript within an a JSP loop? If so, you're missing out on another world of metaprograming.
Unfortunately I have to write highly portable public websites - I can't rely on JavaScript.
|
|
|
Message #163817
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
care about the user? That is an insult to them
Both server-side technologies like J2EE and website design skills (XHTML/CSS etc) are vital to good web application design. However they are orthogonal. They need not be the concern of the same developer. Are you telling me you've never templatized a little JavaScript within an a JSP loop? If so, you're missing out on another world of metaprograming.
I've written enough JavaScript to wish I would never have to write any again.
The cool thing about Echo[2] - if I don't create new components and don't fix any old ones - I don't have to do Javascript (If I am doing Web apps). Or HTML.
|
|
|
Message #163831
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
everything is now strict XHTML I presume?
So when the Java community finally has understood XMLHttpRequest I wonder when they will realize the power of XSL processing in the browser, client-side XSLT transformations! Can somebody tell me (I am too lazy myself) do Mozilla/Firefox support XSl transformation by adding one line to the top of the page? For example:
<?xml-stylesheet type="text/xsl" href="calc.xsl"?>
?
Regards
Rolf Tollerud
|
|
|
Message #163857
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
congratulations!
hi, tod
glad to know that echo 2 will come out.
I think it will be a dream framework~
and now, what left for echo3? :)
I will I can do something helpfull in china for echo
|
|
|
Message #163910
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
everything is now strict XHTML I presume?
So when the Java community finally has understood XMLHttpRequest How many does it have to be? 100%? Many in the Java community already do. I do and have for years. The issue has been tooling.
I wonder when they will realize the power of XSL processing in the browser, client-side XSLT transformations XSL in the browser is great for pages (web sites) but not applications. Been there, done that, lost hair. Again tooling will help, but not like the above.
Can somebody tell me (I am too lazy myself) do Mozilla/Firefox support XSl transformation by adding one line to the top of the page? I don't care cause I don't do web sites or pages.
|
|
|
Message #163933
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
everything is now strict XHTML I presume?
More client-side possibilities
Well I tried it myself and it works in Firefox (and therefore in Mozilla) just as it does in IE (good work Mozilla foundation!). To do the transformation at the server is not a viable option, as Peter Lin has pointed out a number of times.
That the "other" browser now also supports client-side XSLT transformations opens up a huge nest of possibilities.
Regards
Rolf Tollerud
|
|
|
Message #163942
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Harnessing AJAX, XSLTProcessor usning Java Servlets
Here is an article that helps you in understanding Ajax XSLTProcessor and how it applies in a Java J2EE Servlet or Portal based environment. The article begins with a working example on how you can use the XSLTprocessor() APIs to build a site where components or modules can request their content individually via XML on their own as opposed to the traditional approach where you refresh the entire portal page thereby minimizing the amount of work that an application server needs to do. You can view the technical example and it's source code to see how you can harness this technology. This is a major step in creating applications that persists in the browser while changing only parts of the application that needs to change. Once you review the article, you can download the example that includes sample code to try it out on your application server. The example is released under the GNU General Public License (GPL).
AJAX, Java Servlet and Javascript XSLTProcessor
|
|
|
Message #163954
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
?
I downloaded the example but I can not see that you are using neither AJAX nor XSLT processing. Hmm.. waist of time..
|
|
|
Message #163966
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Scalability, everything is now strict XHTML I presume?
To do the transformation at the server is not a viable option, as Peter Lin has pointed out a number of times.
Scalability prefers that any concern that can be reliably delegated to the client should be so. XSL, inclusion, and scripted processing are all things that should be delegated to the client when safely possible. Servers aren't as scalable as Ajax is.
|
|
|
Message #164576
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
New Web Framework: Echo2, with Ajax-based Rendering
I recently have created a tool, which is to speed up a
AJAX data-centric web-based app development. The tool will help you generate code for 3 tiers.
This will speed up at least 80% of your development, which you could then focus on complex business logic work-out.
The 3 tier of codes are as follows :
1) Client Tier
JavaScript AJAX, CSS, DHTML (XMLHttpRequest)
2) Middle Tier
A JSP Form with rich component taglib
An AJAX Request Handler JavaBean. An XMLHttpRequestServlet is a controller that dispatches the request from
the client to the Request handler classes.
JavaBeans for handling database query, transactions etc. (For simplicity, these are non-EJB)
You can run the middle tier on and J2EE container or JSP/Servlet container.
3) Any RDBMs (MySQL, Oracle, MSSQL, Informix etc.)
The web process diagram
http://www.smartborneo.com/images/webprocess.gif
This tool is good only for building data-centric web-based application. You can make all this code into
an up and running data-centric web app in just few hours time or even shorter.
A quick overview
A customer table in your MySQL database, the tool will generate the 3-tier of codes which is structured
as follows:
jsp/customer/js/fc.js # The Javascript that contains all the JavaScript
# function for handling database query/ transaction by using AJAX
jsp/customer/Form.jsp # The JSP Form with rich component, the form can be a 1-column, 2-column
# ,3-column or multiple-row (GRID) form
src/mypackage/Customer.java # The JavaBean which contains all the setter/getter methods and instance variables
# that mapped to each column of the customer table, it also contains methods handling
# database query, transactions e.g load(), create(), update(),
# updateAll(), delete(), exists() etc.
src/mypackage/CustomerPK.java # The primary key class, which represents the primary key of the customer
# table
src/mypackage/CustomerHome.java # This class is for handling database query that tends to return multiple
# rows, this can be used in a combination with Customer bean, for
# querying with wild cards etc. (e.g %%, !=, <>, >= ) as if Oracle forms
src/mypackage/handlers/CustomerRequestHandler.java # A sub-class of the XMLHttpRequestHandler, which is the AJAX
# request handling bean, which depends on the XMLHttpRequestServlet
# to dispatch actions from the client to it. The request handler bean will
# invoke the appropriate JavaBeans above for handling
# insert, update, delete, query
# and checking for duplication of primary key etc.
The above files will be generated and output to a zipped file, which you can nicely unpack &
deploy it to any Java IDE...
In order to make it work, you need to have the Motionk Framework, a template of the Motionk Framework is here
http://rhae.dunco.com.my/examples/downloads/template.zip
The above-generated code can be easily plugged into this framework template, to put it up into a complete data-entry up and running web-based application for your customer table.
Apparently, this tool is NOT as user-friendly as what Echo2 provides, this is only a tool for speeding up data-centric web-based app development, which you can simply put up a data-entry only web-based application w/o any line of code, which saves at least 80% of your development time, you can then focus on the complex business logic solving.
I'm working on this tool single-handedly, including the components etc, currently is being used my our internal development team for rapid development of data-driven web app. Would like to collect feedback from anyone, who is interested...
The tool is web-based , hosted at http://rhae.dunco.com.my/tools/LoginFormServlet, if anyone interested to find out more, email me at ketyung@smartborneo.com for an account to try..
For more info, please visit http://www.smartborneo.com
Documentation is being worked around, incomplete
http://rhae.dunco.com.my/examples/downloads/Rapid%20Interactive%20Web.pdf
|
|
|
Message #199614
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I don't know what to think
I always hate javascript for the reason we know: dificult to test, horrible to code, etc.
When i start to code i always prefer of reduce javascript to their minimal expresion...., and now this: ajax, i suffer years ago applications with a lot of js and always compatibility problems, one error on js that make that nothing runs. i learnt hate javascript.
Everybody said that it's a cool tecnology and the results are obiusly here. But what do you prefer when you are made a bank transfer: ajax technology or a web application based in the old http request.
Probably ajax its here to stay, but where. What do you think that will be his market: Paco Rabbanne web page, Nathinonal Netherlander or both.
Sorry my poor english
|
|
|
Message #221599
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: welcome to the Club!
Hi.
I totally agree with you..I failed to understand that why ORM wont be there.
My assumption is that if we are consuming WD using a SOAP stub on the client these WS will be backed by ORM technologies to provide implementations to these web services.
The only thing that changes is that we are consuming the WS directly through Javascript rather then through a Business Delegate in a Struts Action..
Correct me if you feel I am missing a piece..
Rgds
Shashank
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
