It's quite hard for me to find out whether I like what you're trying to do: I don't have a JAVA-enabled webserver (and am too lazy to install one on my Linux machine) and it looks like your supporting IE 6 only (I'm using Safari right now). So some screenshots would be nice.

The way I understand the problem, I might just as well try to solve it with a wxPerl app using database or LWP queries to get work done remotely.

That said, I think you would get more and better feedback if you took the time to write a meditation about it: Formulate the problem you're trying to solve, then explore your approach to solve it. That would make it much easier to make sound comments on the work you've done.

1. You do not need anything Java for doing Perl Rui work. The installation instructions detail the requirements
2. A screenshot is on the site
3. The partitioning you propose is fine. You propose a thick client talking to web services or a shared database. For some scenarios, partitioning on the presentation layer is better:
   • No client download/install of Perl, application (Shipping standalone perl apps on Win32), drivers, etc.
   • No need to think in two places (client + server) and write partitioning code (e.g. for using the web services)
   • Roaming support without writing roaming code
4. Mozilla client will be available very soon. No plans for Safari/Opera. It is very easy to write a Java/wxPerl/Flash/etc. client.
5. Is a feedback request a SOPW or a Meditation? Whatever the answer the site explains everything, and there is even a YAPC paper online
Monks are not feeding back on this because of the IE6-only requirement you mention, and perhaps because this is a strange technology.

Hello mvc,

seems I didn't read your site carefully enough. I somehow thought that I need both the Java Server and the Perl API. And I couldn't/still can't find a link pointing to your screenshot. Probably because it was late in the night :).

The requirements for Perl look fine to me; I might now even be tempted to try it out. Not having to have a local installation of perl and all the modules (Thanks for pointing to one of my articles :)) definitely is a plus.

The only thing that's holding me back now is that my platform is not covered -- but I think once you cover IE6 and Mozilla, it should be fine. It's a special product that probably doesn't need to run on every browser on this earth.

Why the Monks are not feeding back is always somewhat hard to estimate... I think in this case it is not due to requiring IE6, because we have quite a number of Perl Win32 users here. It is probably more because they don't get your question. It seems to be too broad to me. That's why I suggested writing a meditation about it, and then you might even ask some concrete questions:

• Is this something you find useful? Can you think of projects to use it in
• What do you think about the design?
• What features would you want to see?
• ...

Note also that monks tend to not like to have to go and browse through other sites in order to be able to make comments. If you do it this way, people will be confused, like I was :) because I didn't take enough time to browse through the site. It would be really better to sum it up nicely and ask the right questions if you want some good feedback. It's more work, but the monks tend to honour that kind of effort. And yes, I'd consider that a meditation, not a SOPW.

Reading about Rui was very interesting, but there's a serious problem that you have that will, IMHO, limit the odds of people reaching for Rui as a solution (as the above thread tends to suggest). Specifically, you spend much time explaining what Rui does, but you don't spend much time giving concrete examples of why I would want it. Even your Why use it information has the following:

The web itself is quite hostile to the developers who want rich object-oriented UIs. DHTML is a long way from a UI framework, and the entire idea of going from page-to-page-to-page, does not mix well with UIs that are efficient and usable. There are two scenarios where you might want to use the Rui IE6 DHTML framework:

• As the client to a specific server-side UI framework that partitions on the presentation layer: a Rui server ( Java or Perl ), or roll your own.
• As a UI framework for browser based applications. In this case you use the Rui IE6 DHTML framework in Javascript. The Javascript is hand-coded, generated by JSPs, WebForms, or whatever other way you use to generate HTML.

I can't speak for other developers, but when I see stuff like that, my eyes tend to glaze over. When I looked at the screenshot, I didn't see anything that looked like an application (is that it, buried in the upper left?).

I have a vague sense that there is something really interesting here. There's an MVC framework and the suggestion that I can add different front ends in wxPerl or something similar. However, to really get me excited, take a problem and show me why Rui is a good answer. Walk me through the problem step by step and then compare and contrast the Rui solution to alternatives. Until I see something like that, I'll likely just be confused.

Frankly, I hope you keep working with this. I do a lot of Web-based application development and sometimes the frustrations of this environment make me want to pull my hair out. Your work suggests that there are reasonable alternatives, but I cringe at reading such dense jargon (no offense!).

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

Excellent critique. We have been waiting for this.

Improvement in screenshots: at the bottom of this page

On to the crux of the biscuit:

...you spend much time explaining what Rui does, but you don't spend much time giving concrete examples of why I would want it...

For some reason we expected that everyone has done both desktop + web UIs, and would immediately see why Rui is useful.

...take a problem and show me why Rui is a good answer. Walk me through the problem step by step and then compare and contrast the Rui solution to alternatives...

Let us compare Rui vs. existing Perl web app technologies. We will compare it to a CGI + Template Toolkit solution. This is pretty much the best that Perl can offer for web UIs.

The application is a simple contact manager. It is the demo project included with the distribution. The use cases are:

1. Create contact
2. Remove contact
3. Change contact name, phone, email

We will ignore persistence, so that we can focus on the UI stuff. The model will be plain old Perl objects. They could be persisted with the amazing Tangram, or even Storable. The domain model for both versions is:

1. Model::PhoneBook: entry point object. Keeps a collection of all contacts
2. Model::Contact: model of a contact, with name, phone, and email.

Web Application

We have two pages:

1. Contact Manager: shows a list of all contacts. Each contact is shown with 2 links: edit, and delete. There is also one link for creating a new contact. Hitting edit/new sends you to the contact editor, hitting delete removes the contact and refreshes the list.
2. Contact Editor: a form with 3 fields- name, email, phone. There are 2 buttons: apply and cancel. Both send you to the contact manager.

We chose a design which is typical of the current wen UI situation. There will be a Perl class for each page. They will use TT2 templates for generating the HTML. They could be CGIs, mod_perl handlers, or some kind of view object dispatched by a front controller. This is how they work:

1. Get the HTTP request and translate it into an application event (new/delete/edit/cancel/update)
2. Translate the event into a set of method calls on the domain model, read the form result values and set them on a contact
3. Now that the request has been processed, find the page that handles the response, and call it
4. Generate data for the template, interpolate it, and return the HTML to the client

Some of this work can be done by frameworks such such as Mason, but as you can see on this page, it is still a very strange, HTTP/HTML centered, way to build a UI. Especially when compared to desktop UI frameworks like WxPerl.

Rui

Screenshot here. We have 3 classes- two views and an application:

1. View::Contact (source): shows 3 text fields for editing a contact
2. View::PhoneBook (source): shows a toolbar with new and delete buttons, a listbox of all contacts, and a View::Contact for editing the selected contact
3. Application::PhoneBook (source): setup the model and create the PhoneBook view

Comparison

1. Checkout the source code links above. With Rui it is easier to create quality code. Web apps force the developer to slave under the tyranny of the HTTP request-response cycle, and to worry about producing HTML markup. These implementation details have nothing to do with your UI requirements. Rui feels like a desktop UI framework, just like Gtk or WxPerl. As the UI gets richer (as all UIs do, unless they die), the difference between developing a web UI vs. a desktop UI increases.
2. With the web app we had to write in Perl, TT2, and HTML. With Rui there is only Perl. As web applications evolve, they all eventually require Javascript to increase usability. With Rui there is still only Perl.
3. Layout: Rui uses layout managers. Widgets resize automatically when the window is resized, you can easily align widgets, and there is a splitter between the list box and the contact editing form. HTML layout is horrible, unless you want to read mind boggling words from the W3C, find out what your browser supports from all this, and then write resize handlers in Javascript.
4. Bandwidth: with the web application, the entire list of contacts is sent to client on every other event. Rui only sends the UI deltas. The web application also resends the buttons, forms, and labels, with every event. Rui will never send more that 50 byte per event in this application. You could use frames for better control of bandwidth, but that complicates other things.
5. Reuse: it is hard to reuse web application artifacts. Compare the number of PerlTk widgets on CPAN (stopped counting after 10) to the number of web application widgets available there (?). Despite the fact that there are probably 10^2 - 10^4 web applications in Perl for each single PerlTk application, I could not find an HTML directory tree widget.
6. Usability: the winner is obvious. Which is more usable: Hotmail or Outlook? You could increase usability using fancy javascript, but then you would just be recreating Rui. And recreating it again, in the next application you develop. Have you ever seen a web application with an Undo button? This humble button has been around for some time, almost all desktop apps have it, and humans are known to make mistakes. Current web app technologies suck for rich UI work. Rui sucks less.
7. State: as the application becomes more complex, the developer will have to think about keeping session state. She is expected to work with a session object. CPAN modules help (CGI::Session), but they have to be learned and used. In desktop apps you dont think about state at all. Its just there.

And we could go on. For links on the issue of web vs. presentation server see the Rui related page.

Web applications are a hiccup in the evolution of rich UIs. They are excellent for things like PerlMonks.org, but when the UI grows, desktop UIs are the way to go. With Rui you can write desktop apps that deploy to the web.

Some CSS layout madness

The description at the site is better than the one here? Perhaps this is the best description:
A Perl remote user interface framework.