I use Embperl just about everyday. Anything that would make
it more popular and thus increase the overall attention,
use, and dev of Embperl would be welcome in my opinion.
I have not used catalyst, having built my own web app
framework for Embperl over the years. I would love to toss
my framework into the trash if there was something better
available with Embperl. I know next to nothing about
catalyst, so I can't comment on it, but it seems pretty
popular.
As far as Embperl promotion...it seems odd to me that both
Embperl and Mason have gotten so little attention over the
years. I wonder if it may have more to do with the
popularity of Perl however, especially as PHP and more
recently Ruby have stolen the web dev thunder.
I also wonder if it wouldn't be better to get the Mason
maintainers to look at replacing the core of Mason with the
fast internals of Embperl and merge some development
efforts.
Anyway, a couple of thoughts from the peanut gallery.
________________________________________
From: Gerald Richter - ECOS GmbH [richter ecos.de]
Sent: Wednesday, August 15, 2007 12:55 AM
To: embperlperl.apache.org; nazgulsomewhere.com
Subject: RE: Using Catalyst to revitalize Embperl
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/t
utorials/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: richterecos.de 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:nazgulsomewhere.com]
> Sent: Wednesday, August 08, 2007 10:45 PM
> To: embperlperl.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->" 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/b
ench/. 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-> = {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: embperl-unsubscribeperl.apache.org
> For additional commands, e-mail: embperl-helpperl.apache.org
>
>
> ** Virus checked by BB-5000 Mailfilter **
> !DSPAM:416,46ba2d0f30571168618654!
>
>
** Virus checked by BB-5000 Mailfilter **
------------------------------------------------------------
---------
To unsubscribe, e-mail: embperl-unsubscribeperl.apache.org
For additional commands, e-mail: embperl-helpperl.apache.org
------------------------------------------------------------
---------
To unsubscribe, e-mail: embperl-unsubscribeperl.apache.org
For additional commands, e-mail: embperl-helpperl.apache.org
|