Perl and Ext JS

[viktoriya2000]

We have a pretty large application in Perl. My manager wants to upgrade the look with some cool features that Ext JS offers. I started looking into it, and it seems like it's not gonna be that easy to just plug it in in what we already have. We have lots of forms, and Javascript validation, and it seems like we'd have to re-write the way we use forms and all the Javascript that comes with them. Am I right? And I also ran into the following opinion on perlmonks.org but since it's one person's opinion, I'm not sure.. :
I want to go on record, however, as saying that my honeymoon with ExtJS was over about 2 days after I started really working with it. It's very powerful and pretty out of the box but it has many places where it either degrades painfully, well actually, pretty much everywhere, and points which don't degrade at all; its form handling is pure JS, you cannot plug it into an HTML form without oodles of custom code.
I used YUI a bunch before I decided that Ext was a better idea. Now, I think I was wrong and looking down on YUI just because it is so much more verbose than jQuery (which I prefer but doesn't have anywhere near the same UI plugins of Ext and YUI). Especially with what I've seen of YUI 3; like its sanboxing.
Unless you are committed to marrying an application to Ext, which means a commercial license if you'll be selling your software, and don't mind building something which will be unusable without JS enabled, I'd say stay away from Ext.

I'd really appreciate any insight, thanks :)

[Mike Robinson]

This is Perl... the land of very strong tools and very strong opinions. ;) (I can say that... I live there too.)

I think that the only realistic approach to your task is ... a very systematic and methodical one. Start by identifying the five things that you (your business) wants to accomplish through the use of ExtJS, then zero-in on only the most important two. (Or maybe, one.)

The next tasks depend heavily on just what templating and other technologies you are now using on the Perl side. The techniques that you are now using are probably pretty-heavily template driven already, and standardized. Perhaps just one very small but very beneficial piece of your end-user presentation could be augmented by the well-placed modification of a few existing templates, so that they now deliver to the client-side some snippets of ExtJS code ... perhaps code that employs company-specific derivative JavaScript classes.

You can certainly dismiss the notion of "throwing the baby out with the bathwater" and/or making wholesale changes to your existing designs. That should be unnecessary.

There's quite a lot of CPAN support already out there for things which are ExtJS-based on the client side. You might wind up taking those implementations as a model for what you are contemplating.

[joeri]

You're going to have to make your own judgement, but I don't think ExtJS is particularly well suited to graceful degradation. For me this is actually a strength because it means that ExtJS doesn't have to compromise, it can really take full use of javascript and the DOM. YMMV.

IMHO, graceful degradation is the wrong model for web apps anyway. It always leads to bad UI designs for the majority of users, in the hope of placating the minority. Much better to design a separate UI for that minority and make no compromises on the UI for the majority. Again, YMMV.

[nathand]

We're a perl shop and we use ExtJS a lot. I won't lie to you, converting existing code that was designed 5 to 10 years ago to work with ExtJS has been a lot of work. Our strategy has been to redesign sections of the code as we add Ext functionality. When we are done, we have code that not only has a nice, fresh UI, but the backend is updated to use Model View Controller design pattern.

Here's my experience working with jQuery and ExtJS. jQuery integrates into "old" code much nicer at first. If you just want a few improvements, that may work nicely. With ExtJS, you have to commit to doing everything the ExtJS way. It's a lot of work, but you get a consistent, beautiful look. We use grids a LOT and the jQuery offerings of a few years ago didn't come close to what ExtJS had. I also spend a lot of time with jQuery trying to piece together a UI from different sources in jQuery. (I understand this has improved in jQuery lately.)

Really, it just comes doing to picking the best tool for what you want to accomplish. We drank the ExtJS koolaid. It's been tough sometimes, but we made the right decision with ExtJS.

[frew]

I work in the same shop as nathan and pretty much agree wholeheartedly. Ext is great for complex user interfaces. I haven't worked on a project yet where graceful degradation was an issue, but I can say that the perl offerings for ExtJS are certainly good. I've written a couple modules for pagination for ext with DBIx::Class for use in Catalyst and CGI::Application. Once the next version of DBIC comes out you'll be able to use them.

http://search.cpan.org/~frew/CGI-Application-Plugin-ExtJS-0.092820/lib/CGI/Application/Plugin/ExtJS.pm

I'm much happier to write Ext code with OO and whatnot than writing html that I have to deal with styling and all the weird stuff that goes with it.

Anyway, good luck!

[Mike Robinson]

I made the comment off-line also that there are many CPAN packages out there (including some HTML::FormFu ones) which use ExtJS in some capacity already.

I think that it is imperative that one understand ExtJS very well first, and that any projects are planned carefully for maximum "return on investment" because there will be a risk involved in any change to a production system. The changes that are implemented should be very-targeted to produce maximum "bang" for minimum risk, and they should be phased in very gradually. Certainly, a system should not be changed just because it would look prettier, even though it obviously would.

Perl-based websites do everything (of any consequence) from the server side, but traditional JavaScript applications do much more on the client. The ripples from a "little" rock dropped into this big pool will go a very long way indeed.

[kesteb]

It depends on wither you want a multi-page web site or a single page web application.

Ext is geared towards the single page web application.

The web engines available on CPAN are geared towards multi-page web sites. They do not work well with single page web applications. It's not their fault, they weren't designed to operate in that type of environment.

I tried to cobble one such engine so that it would work with an Ext front end, but eventually gave up and went another direction. This lead me to write my own framework, which better accommodates the needs of a single page web application.

[nathand]

We write lots of single page applications with perl and ExtJS.

If we have the option of starting from scratch, we use Catalyst (http://search.cpan.org/%7Eflora/Catalyst-Runtime-5.80013/lib/Catalyst.pm).

If we are fitting into existing stuff, we try to use CGI::Application (http://search.cpan.org/%7Emarkstos/CGI-Application-4.31/lib/CGI/Application.pm). Both work very well for single page apps.

[kesteb]

How do you handle multiply threads of execution thru the url handlers? Especially with session context and or shared data.

[metalsiren]

Maintaining session data is super easy with CAP::Session (http://search.cpan.org/%7Eceeshek/CGI-Application-Plugin-Session/lib/CGI/Application/Plugin/Session.pm) or Catalyst::Plugin::Session (http://search.cpan.org/dist/Catalyst-Plugin-Session/).
What do you mean by shared data? Between Ext objects? I'd handle that on the client side.

Viktoriya, a transition to Ext may have difficulties if your application is not well segregated into a MVC kind of format. Our biggest problem when updating our old sites was the monolithic structure the old apps used. It's much more difficult to use something like Ext when one script contains all the HTML, database interaction, and business logic. To be fair, that's a problem with outdated application design, not a failing of Ext (or any other UI framework).

[mschwartz]

You can run your existing forms and javascript for validation using the most excellent managed iframe plugin.

Recode them at your leisure into ExtJS ones.