Here's a post that I made to the Catalyst mailing list. It has step-by-step instructions on how to embed a Squatting app into a Catalyst app. The ensuing thread is interesting, too. A lot of good questions were raised.
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg03799.html
I question whether this will actually have the benefits claimed. If my goal is to write an app that works under Catalyst (for example), I'd probably write said app as a Catalyst application.
Will people adopt a new framework solely for the goal of seemlessly integrating with existing frameworks?
Other than the embedding functionality, I would like to know: what does Squatting bring of new to web frameworks?
Is there any other good reason to switch?
Or will people switch to Squatting because of the embedding functionality, and then switch back to other web framework?
Alberto
TPF GC Chair
I don't really see the benefits, either.
No one has to abandon their existing framework for Squatting, because Squatting will eventually be compatible with everyone. If you code to the Squatting API, the app that you write can be used with practically any other Perl-based web framework. That's what I meant when I wrote that "you don't have to join the Squatting cult".
It's similar in spirit to what the AnyEvent system by Marc Lehman has done for event frameworks in Perl. When you code to the AnyEvent API, your code will work w/ any Perl-based event framework.
----
There isn't anything besides embedding and composition that I would say is "new" in Squatting. Don't underestimate the power of embedding, though.
(And to Dave Rolsky -- I don't blame you for doubting me, because I realize I am making some tall claims. However, I am 100% willing to back those claims up with a useful collection of embeddable apps. It'll take me a year or two, but they will be making their way on to CPAN.)
----
Squatting *does* bring back something "old" that many Perl programmers seem to have forgotten.
Once upon a time, Perl was the language of the one-liner. Back in the day, programmers in other languages were regularly humiliated when their long programs were reduced to one line of Perl. Perl showed people that you didn't have to write a ton of code to get real work done.
In keeping with that spirit, the core of Squatting (Squatting, Squatting::Controller, and Squatting::View) add up to about 4.5K of code after all the comments and whitespace have been stripped. Yet, that tiny core is just as capable as its peers (if not more so!).
Squatting is a reminder to Perl programmers of the power of conciseness.
Actually...
There's one more special feature of Squatting. Before it was generalized and made to be able to squat on top of anything, it first squatted on top of Continuity.
Continuity is a library for Perl that implements a continuation server in the spirit of the Seaside framework from the Smalltalk world. When using Squatting on top of Continuity, you get the ability to drop down to the Continuity-level (like a Perl programmer drops down to C) and do some magical things like implement a COMET server. To see an example of this, download the Squatting pm distribution, and look at eg/Chat.pm. Also, download the Continuity pm distribution, and look at eg/chat-ajax-push.pl upon which eg/Chat.pm was based.
The benefit of using Squatting on top of Continuity is that Squatting presents a more "conventional" MVC-styled face to the capabilities of Continuity. Raw Continuity can be a bit disorienting, but with Squatting+Continuity, you can be MVC and RESTful most of the time, and switch to the RESTless Continuity-style where appropriate.
TMTOWTDI
(size[0] != @all)? # testing fitness...
(size[0] < @all)? # ... for one size
Consider CSS: The textual data of an HTML page has been decoupled from its layout characteristics because some (maybe it's turning out to be "most") people don't actually want every web-page to appear identical to pixel-perfect proportions irrespective of their display hardware, operating system, browser, etc.. Some people have wide displays with minuscule dot-pitch (e.g., Apple's 30" Cinema Display at 2560x1600) while others have a standard aspect-ratio display (e.g., Research In Motion's BlackBerry Curve at 320x240) or a relatively large dot-pitch (e.g., many inexpensive 19" flat-panels max-out at 1280x1024 which is only about 2/3rds as many total pixels as fit in a typical 20" at 1600x1200). Pixels are neither uniform in size nor physical distance && accessibility issues mean people have idiosyncratic preferences for distinct color schemes, so HTML shoehorned into the rigidity of a printed page or painting turns out not to be the most desirable or flexible option for an efficiently usable web. Different circumstances require or recommend correspondingly differing presentations of common text-data.
Try to see that Squatting does this too at the web-app level. It enables Perl hackers to whimsically attempt in-place upgrades of existing systems whenever such localized components' capabilities exceed those of their existing monolithic all-in-one system. The ability to plug (i.e., push, pop, unshift, && shift) components arbitrarily turns out to be an obvious fundamental advantage to whatever Catalyst-as-usual app. The parts can migrate or even embed within each other. This embed-ability should prove itself more valuable than the vast majority of abilities considered status-quo among existing Perl web frameworks.
Squatting is also remarkable for its elegant efficiency. It has been distilled down to DWIM so thoroughly that its apps will become much easier to write && maintain than any features of existing competitive frameworks (i.e., all those that lack this essential ability to become embedded seamlessly within most others) such that they seem to collectively say "We don't play nice with each other because our system is, && always will be, superior to every other possible competing framework in every way!" The prevalence of this minimalist attitude toward modularity && interchangeability in web-apps is precisely the wrong kind of competition, which favors inflexibility && avoids cooperation among hackers contributing to similar, but still separate enough to be logically encapsulated, components of distinct web-apps. Dynamically nestable framework hierarchies employing only essential functionality should eventually prove themselves as the more successful paradigm for all such development. Setting this pace with Perl is just what Beppu-san has in mind. Others could help too. I like that kind of sharing! Beautiful minds cooperating. ;)
Squatting will become better, crouching into spots that the heavy-weights couldn't fit within while still supporting their sometimes unwieldy vertical mass. I think others should be able to see this, if they try.
-Pip
P.S. Sorry if my commentary here is unwelcome or if some think my efforts should have been directed first toward Bavl. I've been away for the past week with my girlfriend to attend my little brother's elaborate wedding so I'm finally getting my draft responses && defenses polished && posted. Squatting is a dependency of Bavl too though, so I'm just trying to focus on first-things-first. Please feel free to engage me && I'll try to be more involved in any ensuing dialog on the merits && relevance of these proposals going forward.
TMTOWTDI
(size[0] != @all)? # testing fitness...
(size[0] < @all)? # ... for one size
Consider CSS: The textual data of an HTML page has been decoupled from its layout characteristics because some (maybe it's turning out to be "most") people don't actually want every web-page to appear identical to pixel-perfect proportions irrespective of their display hardware, operating system, browser, etc.. Some people have wide displays with minuscule dot-pitch (e.g., Apple's 30" Cinema Display at 2560x1600) while others have a standard aspect-ratio display (e.g., Research In Motion's BlackBerry Curve at 320x240) or a relatively large dot-pitch (e.g., many inexpensive 19" flat-panels max-out at 1280x1024 which is only about 2/3rds as many total pixels as fit in a typical 20" at 1600x1200). Pixels are neither uniform in size nor physical distance && accessibility issues mean people have idiosyncratic preferences for distinct color schemes, so HTML shoehorned into the rigidity of a printed page or painting turns out not to be the most desirable or flexible option for an efficiently usable web. Different circumstances require or recommend correspondingly differing presentations of common text-data.
Try to see that Squatting does this too at the web-app level. It enables Perl hackers to whimsically attempt in-place upgrades of existing systems whenever such localized components' capabilities exceed those of their existing monolithic all-in-one system. The ability to plug (i.e., push, pop, unshift, && shift) components arbitrarily turns out to be an obvious fundamental advantage to whatever Catalyst-as-usual app. The parts can migrate or even embed within each other. This embed-ability should prove itself more valuable than the vast majority of abilities considered status-quo among existing Perl web frameworks.
Squatting is also remarkable for its elegant efficiency. It has been distilled down to DWIM so thoroughly that its apps will become much easier to write && maintain than any features of existing competitive frameworks (i.e., all those that lack this essential ability to become embedded seamlessly within most others) such that they seem to collectively say "We don't play nice with each other because our system is, && always will be, superior to every other possible competing framework in every way!" The prevalence of this minimalist attitude toward modularity && interchangeability in web-apps is precisely the wrong kind of competition, which favors inflexibility && avoids cooperation among hackers contributing to similar, but still separate enough to be logically encapsulated, components of distinct web-apps. Dynamically nestable framework hierarchies employing only essential functionality should eventually prove themselves as the more successful paradigm for all such development. Setting this pace with Perl is just what Beppu-san has in mind. Others could help too. I like that kind of sharing! Beautiful minds cooperating. ;)
Squatting will become better, crouching into spots that the heavy-weights couldn't fit within while still supporting their sometimes unwieldy vertical mass. I think others should be able to see this, if they try.
-Pip
P.S. Sorry if my commentary here is unwelcome or if some think my efforts should have been directed first toward Bavl. I've been away for the past week with my girlfriend to attend my little brother's elaborate wedding so I'm finally getting my draft responses && defenses polished && posted. Squatting is a dependency of Bavl too though, so I'm just trying to focus on first-things-first. Please feel free to engage me && I'll try to be more involved in any ensuing dialog on the merits && relevance of these proposals going forward.
P.P.S. Sorry for posting twice. My first submission returned some strange error from MovableType && the second one showed the correct confirmation message providing a link back to the page which I had to force out of the browser cache to see including my submission. I'm not sure which of those caused me to double-post or if there's yet a way for me to rm the dup. I would tidy it up if I could.