I would second Kee's point. At $work, (a very large company which has been a heavy user of EmbPerl for years), they are considering switching away (from both Embperl and even Perl).
One of the biggest things that was a problem was a lack of a good MVC framework - we had to roll our own, slow and clumsy ones. If I could show people how to plug our existing EP code as a view layer into Catalyst, it would go a long way to convince the $powers that Embperl is worth looking at. ________________________________ From: Kee Hinckley <naz...@somewhere.com> To: rich...@ecos.de Cc: embperl@perl.apache.org Sent: Friday, September 7, 2012 3:59 PM Subject: Re: Status of Embperl? It's been a while since I've looked at existing frameworks in Perl (I'm stuck in a long-term Python project right now). When I last did, I used Catalyst and replaced TT with Embperl. I also augmented Embperl with a few features (a [] construct that does *no* escaping, and a dynamic include capability that works well with the object model for giving you what pieces you need in the right order only and only once—it's been a while, so I can't really describe it well). I'd be happy to contribute both of those, although neither are what I'd call polished. The key issue I have is Frameworks, Frameworks, Frameworks. People expect more out of their tools than Embperl provides. I think that Embperl would have a much better chance of survival if it could be embedded in an existing Framework. It's way faster than the pure-perl solutions, and it's much better at managing cross-site scripting areas and form filling than any other system out there. --------------------------------------------------------------------- To unsubscribe, e-mail: embperl-unsubscr...@perl.apache.org For additional commands, e-mail: embperl-h...@perl.apache.org
