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

On Wed, Aug 08, 2007 at 04:45:02PM -0400, Kee Hinckley
wrote:
> 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, I'm not looking at Catalyst; I have my own "home
grown" framework
which works and I'm not tempted to change it, since it is
working.
But I do like your "grow and extend" Embperl
ideas.

Embperl can be frustrating.  It's wonderfully powerful, and
I love Perl,
and it can do heaps, but there *are* places where things
don't "just
work", and I've had to do workarounds.

I also get the impression that Gerald is kind of running out
of steam as
far as developing Embperl goes.  I know that I reported a
bug in
Embperl::Form::Validate last year, but there still hasn't
been an
official bug-fix release for that.  (Yes, it's in SVN, but
that doesn't
help when one is installing things via CPAN)

The fact that a lot of Embperl is written in C is an
advantage and a
disadvantage.  An advantage because, of course, it makes it
lovely and
fast.  A disadvantage because it makes it harder to
understand (and
therefore contribute to) the code.

Kathryn Andersen
-- 
 _--_|     | Kathryn Andersen	<http://www.katspace.com&g
t;
/          | 
_.--.*/    | GenFicCrit mailing list <http://www.
katspace.com/gen_fic_crit/>
      v     | 
------------| Melbourne -> Victoria -> Australia ->
Southern Hemisphere
Maranatha!  |	-> Earth -> Sol -> Milky Way Galaxy
-> Universe

------------------------------------------------------------
---------
To unsubscribe, e-mail: embperl-unsubscribeperl.apache.org
For additional commands, e-mail: embperl-helpperl.apache.org

> 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?

I'll have to adopt a wait-and-see attitude. Right now it is,
as you say, 
Template::Toolkit where the action is. Documentation, user
base etc. are 
important. More developers using it means more people who
can help, extend 
and fix bugs.

Also, as already noted, it seems that Gerald doesn't have
the time and/or 
energy to move Embperl forward.

Speed and performance are important, off course, as is
diversity, so I'll hang 
around and try to see if there's anything I can help with
with the limited 
time I have.

-- 

Med venlig hilsen
Kaare Rasmussen, Jasonic

Jasonic                 Telefon: +45 3816 2582
Nordre Fasanvej 12
2000 Frederiksberg      Email: kaarejasonic.dk

------------------------------------------------------------
---------
To unsubscribe, e-mail: embperl-unsubscribeperl.apache.org
For additional commands, e-mail: embperl-helpperl.apache.org

> 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?

I'm personnally using embperl for most of my web-coding for
7-8 years 
now. But as things go I'm still stuck with the outdated
apache 1.3 and 
embperl 1.3.6 as most of my projects have not updated to the
2.x 
releases yet. But as my projects are mostly for
internal/expert usage 
they are mostly simply structured and I haven't had the need
for a 
sophisticated web-framework of any kind. (for example many
of them don't 
use database backends)

Now that should not mean that I'm not interested in
web-frameworks, but 
you have to invest a considerable amount of time to learn
how to use 
them and this initial investment only pays if you do a
long-term 
development on a project.

-- 
---> Dirk Jagdmann ^ doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org

------------------------------------------------------------
---------
To unsubscribe, e-mail: embperl-unsubscribeperl.apache.org
For additional commands, e-mail: embperl-helpperl.apache.org

Hi!

We're using Embperl for the admin part of our monitoring
application.
The user website was already rewritten from scratch with
Catalyst.
I want to do the same with the admin part but I don't have
the time, so maybe 
using the View is a good way to start it.

-Alex

> -----Original Message-----
> From: Kaare Rasmussen [mailto:kaarejasonic.dk]
> Sent: Thursday, August 09, 2007 10:33 PM
> To: embperlperl.apache.org
> Subject: Re: Using Catalyst to revitalize Embperl
>
> > 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?
>
> I'll have to adopt a wait-and-see attitude. Right now
it is, as you
> say,
> Template::Toolkit where the action is. Documentation,
user base etc.
> are
> important. More developers using it means more people
who can help,
> extend
> and fix bugs.
>
> Also, as already noted, it seems that Gerald doesn't
have the time
> and/or
> energy to move Embperl forward.
>
> Speed and performance are important, off course, as is
diversity, so
> I'll hang
> around and try to see if there's anything I can help
with with the
> limited
> time I have.
>
> --
>
> Med venlig hilsen
> Kaare Rasmussen, Jasonic
>
> Jasonic                 Telefon: +45 3816 2582
> Nordre Fasanvej 12
> 2000 Frederiksberg      Email: kaarejasonic.dk
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: embperl-unsubscribeperl.apache.org
> For additional commands, e-mail: embperl-helpperl.apache.org
>

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

Kee Hinckley <nazgulsomewhere.com> writes:
> 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.

Hi,

I'm the one to blame for Catalyst::View::Embperl::Object.
Indeed it's
quite a minimal integration between Catalyst &
Embperl::Object. I did
it that because I switched an old code base from
Embperl::Object only to
Catalyst + EO and nothing was available at that time.

I'm curious about your implementation off course. Can I see
it?

> 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.

I'm glad to hear that. You would certainly not be the last
user. I'm
using EO+Catalyst on several real projects here and plan to
extend that
use.

> 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.
[... lot's of nice ideas ...]

> 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?

I'm in.


-- 
Christophe 


------------------------------------------------------------
---------
To unsubscribe, e-mail: embperl-unsubscribeperl.apache.org
For additional commands, e-mail: embperl-helpperl.apache.org