> What seems complicated?
>
> For example here:
> http://rifers.org/09_stateful_counters/src/
> There's no XML file in sight.
>
>
> Some people like external XML declarations, some don't.
> You use what you need. Like for example this:
> http://rifers.org/08_advanced_continuations/src/
>
> What does a checkout process. The XML hardly seems complex
> to me.

Personally, I am against code existing in files outside source code files; and encoding my program's flow in markup files like xml (or even worse, jsp) is just that. I want to be able to control my code, and not the other way around.

Maybe I am mistaken, but going through all the examples reveals that xml is plenty. Especially revealing is the numberguess game, because Echo2 has exactly the same example, and I can make direct comparisons.

Overall, here is my initial thoughts about the RIFE approach:

1) using non-source code files to encode application flow is bad. With Echo2 (used here as an example, not praised as the final solution to everything), I don't have to write external stuff, and the compiler can happily validate the code.

Even if I encode the application flow entirely with Java (file site.java), it seems pretty strange. Echo2 feels much more natural, like writing a Swing application.

2) RIFE templates can hapilly be Echo2 Java component classes. What is better than reusing a class?

3) the Echo2 approach seems safer because there is no string management with templates: all the string manipulation takes place behind the programmer's back.

4) I need to learn a lot of things even before starting reading the documentation (portlets, metadata, elements, flow language, etc).

I just do not see what the fuss is all about and why things are to be so complicated. The web browser is just another GUI client, like Swing or X-Windows. I prefer to keep things simple, and a framework like Echo2 gives me the simplicity I need.

I forgot to add my opinion about continuations: I do not see how they are necessary, in the context of an event-driven GUI (again, like Echo2). Maybe they are necessary when the user has the choice to make a mess of the application using the browser controls...

Achilleas,

I think this very dependent on the application that you're developing, the intended users and the preferences of the developers.

I for one don't look at web applications as just another GUI client with the same event model as desktop applications. To me they are totally different, with their own interaction model and UI guidelines. I have many times noticed that users of public sites don't understand a rich interaction model in a web site. This is the most important thing that is holding true RIA applications back. However, when creating a RIA, we much prefer to do that in OpenLaszlo with REST web services in the back-end, but to each his own.

Also, most websites are still informational or community-based and not desktop-like applications. A Swing model doesn't feel right at all to me in these cases. For the applications that we develop it's extremely important to have total control over the URLs since we have to localize them, to intelligibly use the pathinfo, ... It's also of capital importance that HTML and Javascript stay 100% isolated in dedicated files and stay as close as possible to the files that designers deliver. Additionally, total control of the state management is something that you can't neglect when creating meaningful URLs or RESTful applications. The concepts that one has to learn for all this don't go away, and things like meta-data, componentization, flow and state handling, ... will have to be dealt with sooner or later.

I think we might just have to agree to disagree on this one. This is the case why there are so many alternatives out there. One solution can't be right for everyone.

Best regards,

Geert

> I think this very dependent on the application that you're
> developing, the intended users and the preferences of the
> developers.

Indeed, but most apps have some common ground, especially apps with a user interface (i.e. most apps today).

>
> I for one don't look at web applications as just another
> GUI client with the same event model as desktop
> applications. To me they are totally different, with their
> own interaction model and UI guidelines.

There is no conceptual difference between a web application and a desktop application from a user-interface point of view: they both show some information to the user, along some commands to modify the information.

The differences you mention are a result of different technology, not different needs.

> It's
> also of capital importance that HTML and Javascript stay
> 100% isolated in dedicated files and stay as close as
> possible to the files that designers deliver.

That is a techical artificial constraint. Your designers could simply deliver files that describe the web pages which you could convert to Java classes. It is no different than someone designing a Qt form with Qt designer and me (the programmer) importing it in the application.

> Additionally, total control of the state management is
> something that you can't neglect when creating meaningful
> URLs or RESTful applications. The concepts that one has to
> learn for all this don't go away, and things like
> meta-data, componentization, flow and state handling, ...
> will have to be dealt with sooner or later.

I can not disagree with this, in the context of a URL-driven application.

But the above is not a issue in Ajax-driven applications.

And the RIFE examples are perfect candidates for AJAX-driven applications; they are not 'simple informational web sites'.

>
> I think we might just have to agree to disagree on this
> one. This is the case why there are so many alternatives
> out there. One solution can't be right for everyone.
>

Of course! it goes without saying.

Thanks for replying.

There is no conceptual difference between a web
> application and a desktop application from a
> user-interface point of view: they both show some
> information to the user, along some commands to modify the
> information.

I don't agree with that at all. In a desktop application you're not supposed to be able to access any intermediate step (page / url) directly. You don't bookmark them and you certainly don't pass the locations around. You don't have to deal with latency issues when performing UI interactions. You don't have to handle the fact that there should be printable versions of most pages. You don't have to be paranoid about who's using the application or about privacy since you can mostly rely on the OS security model. You don't have to deal with different browsers that render the same information, nor do you have to handle the fact that people can disable essential features like Javascripts, Java, Flash, Images, ... I can continue a long time like that.

Apart from all these, a lot of people expect different things from websites than what they expect from desktop applications. I have seen from experience that apart from very well defined applications (like web mail, chat, ...). Most site visitors don't understand what they can do with a web UI that functions (almost, but not quite) like a desktop UI. A lot of people are totally lost. This makes sense, since it's essentially an information architecture that's now being migrated to new functionalities that are many times just bolt-ons. Almost none of the habits that took them years to acquire to work with desktop applications can be applied, so why would they understand the UI?

> That is a techical artificial constraint. Your designers
> could simply deliver files that describe the web pages
> which you could convert to Java classes. It is no
> different than someone designing a Qt form with Qt
> designer and me (the programmer) importing it in the
> application.

That is wishful thinking and I've never seen any complex web design that doesn't need carefully crafted HTML, CSS and Javascript to be able to work on the majority of browsers.

> And the RIFE examples are perfect candidates for
> AJAX-driven applications; they are not 'simple
> informational web sites'.

Well, they are trivially simple, tightly packaged examples do demonstrate specific functionalities.

Take care,

Geert

> I don't agree with that at all. In a desktop application
> you're not supposed to be able to access any intermediate
> step (page / url) directly. You don't bookmark them and
> you certainly don't pass the locations around.

Choosing a specific page to view is no different than choosing a specific window from a list (as a concept, not as an implementation). But most web applications, especially intranet ones, are most like desktop apps rather than what you describe. And even if the app needs to be like that, again there is no need to mess with non-code.

> You don't
> have to deal with latency issues when performing UI
> interactions.

It depends on the interactions.

> You don't have to handle the fact that there
> should be printable versions of most pages.

A printable version of a page means the page is informational only - hardly an application.

> You don't have
> to be paranoid about who's using the application or about
> privacy since you can mostly rely on the OS security
> model.

That's irrelevant to how you code the application.

You don't have to deal with different browsers that
> render the same information,

Exactly. Using an API prevents you from doing that.

But the point of this discussion is 'what API'. An all-Java API (where 'Java' can be substituted with your language or preference) is certainly easier to handle than several different languages.

> nor do you have to handle the
> fact that people can disable essential features like
> Javascripts, Java, Flash, Images, ... I can continue a
> long time like that.

Again, the API can take care of that.

>
> Apart from all these, a lot of people expect different
> things from websites than what they expect from desktop
> applications. I have seen from experience that apart from
> very well defined applications (like web mail, chat, ...).
> Most site visitors don't understand what they can do with
> a web UI that functions (almost, but not quite) like a
> desktop UI. A lot of people are totally lost.

Oh, come on. You are exagerrating. Most computer users are able to use almost all functions after a while in a well-designed application, either web or desktop.

> This makes
> sense, since it's essentially an information architecture
> that's now being migrated to new functionalities that are
> many times just bolt-ons. Almost none of the habits that
> took them years to acquire to work with desktop
> applications can be applied, so why would they understand
> the UI?

I disagree. The habits of clicking commands, writing text, clicking to focus, opening and closing forms is just the same in web and desktop apps.

> That is wishful thinking and I've never seen any complex
> web design that doesn't need carefully crafted HTML, CSS
> and Javascript to be able to work on the majority of
> browsers.

Why don't you check out Echo2 then? I am not in anyway advertising it, but it is the only Java API I know that does not require anything else than Java.

Choosing a specific page to view is no different than choosing a specific window from a list (as a concept, not as an implementation). But most web applications, especially intranet ones, are most like desktop apps rather than what you describe. And even if the app needs to be like that, again there is no need to mess with non-code.

Not true. Users can submit a form, hit the back button, change a value, then submit it again. You can prevent that in a desktop app.

As to continuations based development - I do everything in seaside these days and it is MUCH easier to deal with the web using continuations than it is without.

http://seaside.st