Hi Kee, First of all thank you for trying to get Embperl back into the light.
As other already supposed I currently don't have as much time left over for Embperl as I would like to have. Anyway developement doesn't stand still (also it's only visible in the SVN). I currently working on a big framework for building and handling forms (including a lot of cool stuff, like tabbed views, grids, Ajax components and so on). The main reason why I currently not going in the direction of a web framework, is that I personaly do not develop web appliactions any more, but security appliances (for anybody who is currious look at www.ecos.de). We use Embperl extensivly there for the administration frontend and also for generation of configuration files. So I have a little different focus, but I am still using and working on it (e.g. I also did some stuff on the internationalisation framework) and it's guaranteed that I continue to maintain it. The main problem I see is that there never was a developement team. I always was the only developer (also many people send patches) and I (as far as I don't need the things for my business) have to do the things in my spare time. The error that I think I have made is, that I spent to much time developing Embperl and too less time for promoting it. I always hoped that some other people will step in (and a few times it had happen), but most the the time I have done the work. For example it had taken a very long time until Embperl::Object has been mentioned on http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html#HTML__Embperl . That was simply because I didn't wrote a few lines of text to update the page, so I guess many people did not know about the possibilities of Embperl. From my point of view, within the core engine (the part that is written in C) there is not much left to do (except perhaps makeing it work on mac os). So what is left over, is to enhance it (most of it can be done in Perl), add examples and documentation, so this shouldn't be the show stopper anymore. I think integrating Embperl with Catalyst really make sense, because most people starting a web project today will use such a framework and getting things to work smoothly together is necessary to have success. Haveing the Embperl::Form framework within Catalyst might give even more advantages for using Embperl as view in addition to these you mentioned. We have to check how this might integrate. So from my point of view I would love to see this Catalyst integration and I will support it as far it is possible for me (we can discuss the technical problems you metioned more in detail in another mail, there is, of couse same legency stuff (Embperl is more than 10 years old) and some compromises to gain performance (e.g. not letting you subclass everything)). Doing the technical implementation is only one thing, it's also necessary to make it public and promote the stuff. So we would need to have a website (either on perl.apache.org/embperl or a own website) with documentation and examples, we need also make sure that it is posted on the relevant lists and, if possible, have some articles e.g. on perl.com or other revelant sites. I think when we really make it public you will not be the last user, but to get to this point it has to be activly promoted. Gerald P.S. There are still 190 people on the Embperl list, that is not much less than is was during the times the list was more active ------------------------------------------------------------------------ -- Gerald Richter ECOS electronic communication services GmbH ******************* SECURING YOUR NETWORK ******************** Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 939-122 WWW: http://www.BB-5000.info Fax: +49 6133 939-333 Sitz der Gesellschaft: Dienheim; AG Mainz HRB 6889; GF: W.Heck, G.Richter ------------------------------------------------------------------------ -- > -----Original Message----- > From: Kee Hinckley [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 08, 2007 10:45 PM > To: embperl@perl.apache.org > Subject: Using Catalyst to revitalize Embperl > > This is going somewhere. Hang with me through the intro. > The goal is simple. I want Embperl back in the limelight > where it belongs. I haven't run this past Gerald, so I hope > I'm not stepping on any toes, but here goes... > > PICKING A WEB FRAMEWORK > It's been a long time since I've been active on this list. I spent > several years in Java hell, learning how *not* to do web > frameworks. > Then I was back doing some consulting. Now I have a new > startup under way. > > When I started the new company, I looked around to see what > the state of Perl web frameworks was. Mason is still around, > but frameworks have moved on. Jifty is interesting, but it's > not polished enough yet. Embperl::Object still does what it > used to, but it too hasn't really moved with the times. > Everyone buzzes about Ruby on Rails, and there are clear > advantages to having a structured development environment. I > wanted to find the Perl successor to RoR. I settled on > Catalyst with Template::Toolkit. (Frankly, the dearth of > choices is depressing. Far too many of the key Perl players > have gone off to play with Perl 6 when Perl's survival is > much more dependent upon Web and Application frameworks. > Right now Catalyst and POE are about all we've got. But > that's another discussion.) > > CATALYST AND TEMPLATE::TOOLKIT > Catalyst provides an MVC framework in the Perl tradition--by > which I mean that it provides a nice framework, and then lets > you bypass it if you need to. As opposed, for instance, to > Java Struts, about which the less said, the better. Catalyst > also has a very nice plugin model, and it uses the NEXT > module, so it's possible to insert plugin logic into the > existing stream of things. Additionally, the support for > class variables is very useful. There's also some progress > towards providing tools to create a basic application > framework, so you can get up and running fast. The > documentation isn't wonderful, but it's not bad. > > TT is interesting. At first blush I kind of liked it. You > don't have to worry about whether something is a scalar, an > array or a method--it just works. "$foo.bar" might translate > to "$foo->{bar}" or "$foo->bar()", you don't need to know. It > has an interesting object/ method model. And it has good > plugin support as well. However, a couple things bugged me. > > 1. The scripting meta language is kinda like Perl6, and kinda > like nothing else. Yet another thing to learn. Furthermore, > while it's all very fine to say that you aren't supposed to > do much coding in the "View". Practically it's not that > simple. So when you need to do something fancy to make the > presentation work on the server side-- > you really want the full power and syntax of Perl available to you. > TT is just not designed for that. > > 2. While not worrying about your data structures may make > life easier for the web designer, it can lead to sloppy and > confusing code. And the programmer *does* have to translate > between the backend and the frontend, and looking at the two > sides, using different syntaxes, can be very confusing. And > it's inefficient. > > 3. Which led to the next issue. Performance. I heard SixApart > had been having issues with TT. I got worried and did some > checking around. That took me to > http://www.chamas.com/bench/. Which claims that on > non-trivial templates, Embperl2 uses half as much memory, and > is a third faster, than Template::Toolkit. On small > templates their speed is comparable, but TT uses 3x the > memory of Embperl. > > 4. Security. There's one thing that Embperl does that nobody > else does. It auto-escapes your output. You have to go out > of your way > to let something get displayed to the user that isn't escaped. > (Perhaps too far out of your way, but that's easily fixed. > Furthermore, the escaping is contextual. TT, like all the > other systems out there, leaves it up to the programmer to > "do the right thing." In a URL? Then you want "$foo | url". > In HTML? you want "$foo | html". And so on. We all know > that programmers *don't* always do the right thing. And I'll > put up with an awful a lot of grief for a template system > that virtually guarantees I won't have cross-site scripting holes. > > So, I bailed on Template::Toolkit and installed > Catalyst::View::Embperl::Object. > > The Embperl::Object View plugin for Catalyst kind of gets you > up and running, but it's really not useable overall. It > neither integrates with Catalyst, nor gives you full access > (at least in the Catalyst debug server) to the EO > functionality. A week later I had a completely new > implementation, with much tighter integration. It's not > quite ready for public release, but it will be soon. More on > that in a minute. > > THE EMBPERL COMMUNITY (NOT) > The traffic on the Embperl list is sadly low. I don't know > how many readers there are (should I post this to the > mod_perl lists as > well?) Unfortunately the community has never really taken > Embperl and run with it the way they have with some other > systems. I think there are a variety of reasons for that. > There's a fair amount of C code, and it's pretty hairy > (although it rarely needs to be touched). It could really > use a good community effort to come up with better > documentation and examples--I have enough trouble documenting > my code, I don't know how Gerald rights the code, the docs > AND translates them. Also, because there's no high-level > framework like Catalyst, everyone does things somewhat > differently, so it's difficult to separate out the cool stuff > you've did in your web site and make it useable by others. > There's also no good way to provide compatible plugins. (The > syntax modules go a long way in this direction, but they > really need to be subclassed and simplified one more level.) > Some parts of Embperl are also a bit hard to subclass (the > model of mapping global variables temporarily into local > space is a bit messy and hard to extend, and some things are > virtually impossible to subclass/replace (the C-based > ::Config modules, or anything that gets called as > Embperl::foo($ref) instead of $ref->Embperl::foo()). And I > won't go into the things I had to do in order to make Embperl > hold off configuring itself until my application was in > control. Or trying to make it run as a simple library under > mod_perl without compiling it with the mod_perl libraries > > But all of those things can be fixed. Catalyst provides a > robust framework. Embperl fits in it very well. And Embperl > is demonstrably better in many ways than any of the other > templating libraries available in Catalyst or elsewhere. > > WHERE I WANT TO GO > So. Here's where my head is at. > > 1. I've got a new startup (social-networking related, needs > to scale massively, the usual Web2.0 requirements). I'm > committed to using Catalyst and Embperl::Object, and I'm > committing to feeding back any enhancements of those to the > community. But I'd hate to make all this effort and be left > as the last user. Never mind that I have another project in > mind in which Embperl would run within an application > context, rather than over the internet. So I want to see a > growing Embperl community again. > > 2. Embperl provides a number of features that simply don't > exist elsewhere. I believe those features make it a far > better View component for Catalyst (or any other framework) > than any other templating solutions. > > a. A fast, low-memory implementation with critical pieces > written in C. > > b. An efficient, well tested caching and pre-caching system. > > c. A parser that understands HTML and provides needed > security in presenting user-provided data in HTML. > > d. An extensible templating language. > Want a way to output unescaped content when you need to, > without using $escmode? Subclass Syntax::EmbperlBlocks and > add a new directive. [% %] for unescaped data. > > e. An excellent object-oriented framework for managing > templates, includes and libraries of HTML functions. > > f. Form autofill. > It amazes me how many hoops other developers have to jump > through just to display the stuff the user already entered a > minute ago. > > 3. Embperl integrated with Catalyst provides (so far) the > following features. > > a. The Catalyst "stash" elements automatically become > modifiable variables in the Embperl context. > E.g. If you do "$c->stash->{myhash} = {a => 1, b => 2}" in > your Catalyst Controller, the variable %myhash will be > instantiated in the Embperl files. > > b. Error to exception handling. > Embperl errors are translated into exception objects before > being passed to Catalyst. Embperl logging is also > intercepted and moved into the Catalyst context. > > c. Contextual error debugging > Embperl errors (and warnings, if there was an error) are > displayed on the Catalyst debug screen in context (line > numbers, context, error line highlighted, error text, if any, > underlined). > > d. Catalyst cookie/session/parameter information is > integrated with traditional Embperl mechanisms. > %fdat and friends are available so that you can continue to > use them, although the Catalyst "$c" variable also gives you > access to them. > (In addition, %nfdat exists with arrays for multiple values > instead of tab separations--however I'd like to make that an > Embperl option.) > > e. Plugin mechanism in progress. > I'm starting with things like the HTML::Prototype library. > There needs to be an easy way to import that into Embperl and > make sure that all the escaping is done right. I'm also > looking at easy ways to install multiple syntax extensions. > (E.g. when I want to use my EmbperlBlock syntax extension AND yours). > > f. Everything Embperl already did. > It may seem obvious, but it's a big boon for development when > I can put the display, controller logic, and database code > all in the same HTML file. Didn't I just say that MVC was > the way to go? Yes, absolutely. But it's a *lot* faster to > do the testing in one HTML file, and then once it works, move > all the pieces where they really belong. The power of > Embperl, and the flexibility of Catalyst, let > you do that when you need to. Could you do it in > Template::Toolkit? > Maybe. But when it came time move the code to the Controller > and Model, you'd have to rewrite it all--because TT doesn't > use Perl as the scripting language. With Embperl it's just > cut and paste. > > > WHAT I WANT TO KNOW > The question is very simple. Are other people interested in > going in this direction? If I put out an Embperl::Object > View component for Catalyst, is anyone going to use it? And > if I start discussing how we can grow and extend Embperl, is > anyone going to answer back? > > Well? > > -kee > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > ** Virus checked by BB-5000 Mailfilter ** > !DSPAM:416,46ba2d0f30571168618654! > > ** Virus checked by BB-5000 Mailfilter ** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
