Mailing List Archive

Embperl Abandoned: Next Steps?
It now seems abundantly clear that Embperl development/discussion has
become very dormant. Perhaps it has been abandoned. I don't wish to
criticize Gerald for abandoning this project, rather, I would like to
thank him for his fine work. I have been using Embperl professionally
since the beginning and am very grateful to him.

Now I am at a crossroads of sorts - I have to choose between continuing
to develop in Embperl or migrating my code (lots of it) to another
product that is actively supported. I think it's hard for me to justify
continuing Embperl development to my client given that the product
lacks:
- support
- ample documentation
- an active community (a la PHP) (and no, I do not like or advocate PHP)

So my question to the community (what's left of it) is this: which
language/product should I use instead of Embperl/Embperl Object? Here
are my priorities:
- Camelness: I would prefer to stay under the Perl umbrella if possible.
I am not unwilling to learn other languages if necessary but Perl rocks!
- Power: Properly implemented, Embperl/Embperl Object is VERY powerful
and productive. I don't want to downgrade to an inferior product
- Open Source: of course
- Continuity: I need to choose a product that is not on it's way to
retirement
- Documentation: Something well documented (perhaps supported by an
O'Reilly book).
- Community: There should be an active community with active discussion
boards and more than one person enhancing/maintaining the product
- Linux: Microsoft is out of the question.

Thank you very much for your time.

David G. Williams



---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl Abandoned: Next Steps? [ In reply to ]
Williams, David G. (HQ-JF000)[INDUS] wrote:
> It now seems abundantly clear that Embperl development/discussion has
> become very dormant. Perhaps it has been abandoned. I don't wish to
> criticize Gerald for abandoning this project, rather, I would like to
> thank him for his fine work. I have been using Embperl professionally
> since the beginning and am very grateful to him.
>
> Now I am at a crossroads of sorts - I have to choose between continuing
> to develop in Embperl or migrating my code (lots of it) to another
> product that is actively supported. I think it's hard for me to justify
> continuing Embperl development to my client given that the product
> lacks:
> - support
> - ample documentation
> - an active community (a la PHP) (and no, I do not like or advocate PHP)
>
> So my question to the community (what's left of it) is this: which
> language/product should I use instead of Embperl/Embperl Object? Here
> are my priorities:
> - Camelness: I would prefer to stay under the Perl umbrella if possible.
> I am not unwilling to learn other languages if necessary but Perl rocks!
> - Power: Properly implemented, Embperl/Embperl Object is VERY powerful
> and productive. I don't want to downgrade to an inferior product
> - Open Source: of course
> - Continuity: I need to choose a product that is not on it's way to
> retirement
> - Documentation: Something well documented (perhaps supported by an
> O'Reilly book).
> - Community: There should be an active community with active discussion
> boards and more than one person enhancing/maintaining the product
> - Linux: Microsoft is out of the question.
>
> Thank you very much for your time.
>
> David G. Williams
>

I wish Gerald would state clearly what his plans and intentions are for
Embperl, so that we users can make plans for either our continued use of
the tool, or transition to some other product, or perhaps even
transferring development to someone else who has time to dedicate to the
open source side of things. I know I have quite a substantial commitment
to Embperl at this point, but no money at the moment. I am still trying
to develop my own sites. If/when I become the internet millionaire then
I would be more than happy to help fund further development and support
for this wonderful tool - I think it still works so well, and would be
very sad to see it disappear through simple neglect. I for one could not
imagine transitioning to PHP from here, that would just be too
depressing. I like the Perl universe.

Ruby on Rails seems to be the tool that's been gaining the "buzz" of
late, but I also seem to be getting the impression that the honeymoon
may be over as people start to realize some of the realities of Ruby (no
expert myself there, just what I get the impression of from many posts
skimmed here and there).

I'm in the UK visiting family at the moment, but would be glad to
discuss further Embperl development options once I get back home after
Sept 12th. I'm not sure if Gerald has been run over by a bus, or if he
has simply been busy, or just lost interest in the community side of
things here. I remember in the past I got nervous when he appeared to
"go away" for periods of time, but then he always seemed to turn up
again and assure us that everything was ok and was still committed etc.
That's fine, if that's all this is. It would be nice to get an update
from Gerald on his status and intentions, whenever he can get to it.

Thanks,

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl Abandoned: Next Steps? [ In reply to ]
> So my question to the community (what's left of it) is this: which
> language/product should I use instead of Embperl/Embperl Object? Here
> are my priorities:
> - Camelness: I would prefer to stay under the Perl umbrella if possible.
> I am not unwilling to learn other languages if necessary but Perl rocks!
> - Power: Properly implemented, Embperl/Embperl Object is VERY powerful
> and productive. I don't want to downgrade to an inferior product
> - Open Source: of course
> - Continuity: I need to choose a product that is not on it's way to
> retirement
> - Documentation: Something well documented (perhaps supported by an
> O'Reilly book).
> - Community: There should be an active community with active discussion
> boards and more than one person enhancing/maintaining the product
> - Linux: Microsoft is out of the question.

I think you should look at Catalyst, perhaps the most active Perl Web
development framework. It's a full-featured MVC framework that meets all of
the above requirements.

The model part is most often DBIx::Class (if you're talking to databases), and
the view part is mostly recommended to be Template Toolkit. I'm getting tired
og the latter, but in Catalyst you can switch components, so I'm thinking to
use something else.
It's possible to plug in Embperl there, but as you've found, it's not actively
being developed.

Perhaps Template::Declare. I like the observation that designers don't
understand templates, only CSS :-)

--

Med venlig hilsen
Kaare Rasmussen, Jasonic

Jasonic Telefon: +45 3816 2582
Nordre Fasanvej 12
2000 Frederiksberg Email: kaare@jasonic.dk

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl Abandoned: Next Steps? [ In reply to ]
Hi Everyone,

Well some good news.

Gerald has not abandoned Embperl, and his projects are still dependent
on it. He's been very busy but I understand he will be catching up on
the mailing list next month and will be updating Embperl for the
latest version of perl.

It's obviously not ideal that the project is so dependent on one
person who obviously has other things to do than just support Embperl
by himself.

Michael

On Fri, Sep 5, 2008 at 2:37 PM, Williams, David G. (HQ-JF000)[INDUS]
<david.g.williams@nasa.gov> wrote:
> It now seems abundantly clear that Embperl development/discussion has
> become very dormant. Perhaps it has been abandoned. I don't wish to
> criticize Gerald for abandoning this project, rather, I would like to
> thank him for his fine work. I have been using Embperl professionally
> since the beginning and am very grateful to him.
>
> Now I am at a crossroads of sorts - I have to choose between continuing
> to develop in Embperl or migrating my code (lots of it) to another
> product that is actively supported. I think it's hard for me to justify
> continuing Embperl development to my client given that the product
> lacks:
> - support
> - ample documentation
> - an active community (a la PHP) (and no, I do not like or advocate PHP)
>
> So my question to the community (what's left of it) is this: which
> language/product should I use instead of Embperl/Embperl Object? Here
> are my priorities:
> - Camelness: I would prefer to stay under the Perl umbrella if possible.
> I am not unwilling to learn other languages if necessary but Perl rocks!
> - Power: Properly implemented, Embperl/Embperl Object is VERY powerful
> and productive. I don't want to downgrade to an inferior product
> - Open Source: of course
> - Continuity: I need to choose a product that is not on it's way to
> retirement
> - Documentation: Something well documented (perhaps supported by an
> O'Reilly book).
> - Community: There should be an active community with active discussion
> boards and more than one person enhancing/maintaining the product
> - Linux: Microsoft is out of the question.
>
> Thank you very much for your time.
>
> David G. Williams
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl Abandoned: Next Steps? [ In reply to ]
Michael Smith wrote:
> Hi Everyone,
>
> Well some good news.
>
> Gerald has not abandoned Embperl, and his projects are still dependent
> on it. He's been very busy but I understand he will be catching up on
> the mailing list next month and will be updating Embperl for the
> latest version of perl.
>
> It's obviously not ideal that the project is so dependent on one
> person who obviously has other things to do than just support Embperl
> by himself.
>
> Michael

How did you get this scoop? I've tried writing to Gerald and got no
reply. Is there some other forum where he posts stuff like this?

Thanks!

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl Abandoned: Next Steps? [ In reply to ]
It was actually done via a rather old form of communication known as
the telephone.

My IT Director took the liberty of calling him, as we've (in a
previous company) previously sponsored Embperl development, and might
do so again at some point in the future.

Michael

> How did you get this scoop? I've tried writing to Gerald and got no reply.
> Is there some other forum where he posts stuff like this?

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl Abandoned: Next Steps? [ In reply to ]
On Fri, 2008-09-05 at 17:09 +0200, Neil Gunton wrote:
> Williams, David G. (HQ-JF000)[INDUS] wrote:
> > It now seems abundantly clear that Embperl development/discussion has
> > become very dormant. Perhaps it has been abandoned. I don't wish to
> > criticize Gerald for abandoning this project, rather, I would like to
> > thank him for his fine work. I have been using Embperl professionally
> > since the beginning and am very grateful to him.
> >
> > Now I am at a crossroads of sorts - I have to choose between continuing
> > to develop in Embperl or migrating my code (lots of it) to another
> > product that is actively supported. I think it's hard for me to justify
> > continuing Embperl development to my client given that the product
> > lacks:
> > - support
> > - ample documentation
> > - an active community (a la PHP) (and no, I do not like or advocate PHP)
> >
> > So my question to the community (what's left of it) is this: which
> > language/product should I use instead of Embperl/Embperl Object? Here
> > are my priorities:
> > - Camelness: I would prefer to stay under the Perl umbrella if possible.
> > I am not unwilling to learn other languages if necessary but Perl rocks!
> > - Power: Properly implemented, Embperl/Embperl Object is VERY powerful
> > and productive. I don't want to downgrade to an inferior product
> > - Open Source: of course
> > - Continuity: I need to choose a product that is not on it's way to
> > retirement
> > - Documentation: Something well documented (perhaps supported by an
> > O'Reilly book).
> > - Community: There should be an active community with active discussion
> > boards and more than one person enhancing/maintaining the product
> > - Linux: Microsoft is out of the question.
> >
> > Thank you very much for your time.
> >
> > David G. Williams
> >
>
> I wish Gerald would state clearly what his plans and intentions are for
> Embperl, so that we users can make plans for either our continued use of
> the tool, or transition to some other product, or perhaps even
> transferring development to someone else who has time to dedicate to the
> open source side of things. I know I have quite a substantial commitment
> to Embperl at this point, but no money at the moment. I am still trying
> to develop my own sites. If/when I become the internet millionaire then
> I would be more than happy to help fund further development and support
> for this wonderful tool - I think it still works so well, and would be
> very sad to see it disappear through simple neglect. I for one could not
> imagine transitioning to PHP from here, that would just be too
> depressing. I like the Perl universe.
>
> Ruby on Rails seems to be the tool that's been gaining the "buzz" of
> late, but I also seem to be getting the impression that the honeymoon
> may be over as people start to realize some of the realities of Ruby (no
> expert myself there, just what I get the impression of from many posts
> skimmed here and there).
>
> I'm in the UK visiting family at the moment, but would be glad to
> discuss further Embperl development options once I get back home after
> Sept 12th. I'm not sure if Gerald has been run over by a bus, or if he
> has simply been busy, or just lost interest in the community side of
> things here. I remember in the past I got nervous when he appeared to
> "go away" for periods of time, but then he always seemed to turn up
> again and assure us that everything was ok and was still committed etc.
> That's fine, if that's all this is. It would be nice to get an update
> from Gerald on his status and intentions, whenever he can get to it.
>
> Thanks,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>

I'm using Catalyst since two years now and am in the process of
migration my last Embperl app to it.
MVC makes things much cleaner imho.

-Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl Abandoned: Next Steps? [ In reply to ]
Williams, David G. (HQ-JF000)[INDUS] wrote:
> It now seems abundantly clear that Embperl development/discussion has
> become very dormant. Perhaps it has been abandoned. I don't wish to
> criticize Gerald for abandoning this project, rather, I would like to
> thank him for his fine work. I have been using Embperl professionally
> since the beginning and am very grateful to him.
>
> Now I am at a crossroads of sorts - I have to choose between continuing
> to develop in Embperl or migrating my code (lots of it) to another
> product that is actively supported. I think it's hard for me to justify
> continuing Embperl development to my client given that the product
> lacks:
> - support
> - ample documentation
> - an active community (a la PHP) (and no, I do not like or advocate PHP)
>
> So my question to the community (what's left of it) is this: which
> language/product should I use instead of Embperl/Embperl Object? Here
> are my priorities:
> - Camelness: I would prefer to stay under the Perl umbrella if possible.
> I am not unwilling to learn other languages if necessary but Perl rocks!
> - Power: Properly implemented, Embperl/Embperl Object is VERY powerful
> and productive. I don't want to downgrade to an inferior product
> - Open Source: of course
> - Continuity: I need to choose a product that is not on it's way to
> retirement
> - Documentation: Something well documented (perhaps supported by an
> O'Reilly book).
> - Community: There should be an active community with active discussion
> boards and more than one person enhancing/maintaining the product
> - Linux: Microsoft is out of the question.
>
> Thank you very much for your time.
>
> David G. Williams
>
>

I still use it and it just works. Does it need more development?

Ruben


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl Abandoned: Next Steps? [ In reply to ]
On Wed, 8 Oct 2008, Ruben Safir wrote:

> I still use it and it just works. Does it need more development?
>
> Ruben

I wouldn't know - it just works for me, too. ;>

On a more serious note, I am aware that it's still not thread-safe, even
in the latest revs. This is a much more significant issue for people
who are trying to run web servers under Windows, as it only supports
Apache's threaded MPM. (On the other hand, running a web server under
Windows is, in many circles, considered ill-advised.)

I believe there are a number of other items on the TODO list as well,
such as improving documentation. They're certainly not things that I
miss, so I'm personally not too concerned about the situation.

Of course, I certainly wouldn't mind knowning that we had a truck number
greater than one - but as stable as the product is for me, I am
currently ok with the status quo.

Ed

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl Abandoned: Next Steps? [ In reply to ]
A year or so ago I burst back onto the list with some ideas about
boosting Embperl support, and then I promptly disappeared (my
apologies, work and personal stuff took over my life). Those comments
still stand, but I need to approach things a bit more slowly and
realistically.

> I think you should look at Catalyst, perhaps the most active Perl Web
> development framework. It's a full-featured MVC framework that meets
> all of
> the above requirements.

I actually have a library that integrates Embperl into Catalyst so
that you ca use it instead of the default system (Template Toolkit).
Embperl is faster and uses less memory than TT. I have the module
working in a production site, and while it needs documentation and
code cleanup, I'd be happy to share it with folks and even set up a
source repository if people are interested in assisting with the
development.

I've also added some Embperl syntax additions (see below).

I think the biggest barrier to expanding Embperl's audience (and
development) is its heavy reliance on some pretty obfuscated C code.
On the other hand, that's one of the reasons it's faster and less
memory hungry than the alternatives. A cleaner rewrite would be nice,
but I think that even just making it more extensible in Perl would be
a big bonus. In particular, the ability to write syntax extensions in
Perl would be a big win and would make it easier to create libraries
to help people move from other systems. The other piece that would
greatly help adoption would be integrating an AJAX system into
Embperl. I'm a big fan of MooTools (it has a *very* well designed
object model, it's clean, and it's small). Anything we could do to
make developing AJAX-based systems in Embperl would be a big win.

Aside from the speed/memory issues, the place Embperl excels is
security. Embperl understands the syntax of the HTML. Every other
templating language out there relies on the programmer to properly
escape their code to prevent XSS vulnerabilities. Embperl *defaults*
to properly escaping output--that's a huge win. Finally, Embperl's
ability to auto-fill forms *greatly* reduces the amount of code in
many applications. Embperl's MVC support is definitely limited, and
that's why I moved to Catalyst as an MVC platform. At some point a
version of Embperl that blocks out the code no longer needed in that
environment might be a good idea.

Syntax Additions

[% %]
Unescaped output. Much easier than [+ do { local($escmode) = 4; ... }
+], particularly useful for generating Javascript.

[$ set VARIABLE EXPRESSION $]
Sets a module-local "variable" (actually a method call) to the
passed-in value[s]. E.g.

[$ set TITLE "My Web Page" $]

The magic comes in retrieval. The simple case works as
expected.

<title>[+ $epreq->TITLE() +]</title>

Will return the value appropriate for the current context.
Which means the value set in the current file, or (if this file
was a template (object_base), the file that is the actual
object. In this sense it's just a slightly easier way to do
what is already possible. More interesting, however is when
the method is passed a non-zero value.

In our template, we define the following.

[$ set CSS qw(template helper $]

In our html file that it executes, we define this:

[$ set CSS qw(index helper $]

Back in the template, we have the following code. Note that
this can occur before any of the other files are included.

<style type="text/css">
<!--
[$ foreach $file ($epreq->CSS(1)) $]
@import url("/styles/[+ $file +].css");
[$ endforeach $]
-->
</style>

The call with the "all" argument set to true will return all of
the values of of all of the "CSS()" methods (with non-unique
elements removed). It will include all methods of all files
that list this file as an "ISA".
[- Execute({ isa => 'filename.epl' }) -] or the case of
"Execute('*')" where the ISA relationship is implicit.

So the above code will generate:

<style type="text/css">
<!--
@import url("/styles/template.css");
@import url("/styles/helper.css");
@import url("/styles/index.css");
-->
</style>

This allows you to create templates which will include CSS,
Javascript or
other elements that are required by individual Embperl files that
aren't
even known about at the time the template is created.

There are a few other additions I've made as well, but the [$ set $]
command is
probably the most useful.




---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl Abandoned: Next Steps? [ In reply to ]
Thanks for these additions Kee. This fixes two of my biggest frustrations
with Embperl. Good job and keep on keeping on.

-Allen

On Fri, Oct 17, 2008 at 08:47:28PM -0400, Kee Hinckley wrote:
> A year or so ago I burst back onto the list with some ideas about
> boosting Embperl support, and then I promptly disappeared (my
> apologies, work and personal stuff took over my life). Those comments
> still stand, but I need to approach things a bit more slowly and
> realistically.
>
> >I think you should look at Catalyst, perhaps the most active Perl Web
> >development framework. It's a full-featured MVC framework that meets
> >all of
> >the above requirements.
>
> I actually have a library that integrates Embperl into Catalyst so
> that you ca use it instead of the default system (Template Toolkit).
> Embperl is faster and uses less memory than TT. I have the module
> working in a production site, and while it needs documentation and
> code cleanup, I'd be happy to share it with folks and even set up a
> source repository if people are interested in assisting with the
> development.
>
> I've also added some Embperl syntax additions (see below).
>
> I think the biggest barrier to expanding Embperl's audience (and
> development) is its heavy reliance on some pretty obfuscated C code.
> On the other hand, that's one of the reasons it's faster and less
> memory hungry than the alternatives. A cleaner rewrite would be nice,
> but I think that even just making it more extensible in Perl would be
> a big bonus. In particular, the ability to write syntax extensions in
> Perl would be a big win and would make it easier to create libraries
> to help people move from other systems. The other piece that would
> greatly help adoption would be integrating an AJAX system into
> Embperl. I'm a big fan of MooTools (it has a *very* well designed
> object model, it's clean, and it's small). Anything we could do to
> make developing AJAX-based systems in Embperl would be a big win.
>
> Aside from the speed/memory issues, the place Embperl excels is
> security. Embperl understands the syntax of the HTML. Every other
> templating language out there relies on the programmer to properly
> escape their code to prevent XSS vulnerabilities. Embperl *defaults*
> to properly escaping output--that's a huge win. Finally, Embperl's
> ability to auto-fill forms *greatly* reduces the amount of code in
> many applications. Embperl's MVC support is definitely limited, and
> that's why I moved to Catalyst as an MVC platform. At some point a
> version of Embperl that blocks out the code no longer needed in that
> environment might be a good idea.
>
> Syntax Additions
>
> [% %]
> Unescaped output. Much easier than [+ do { local($escmode) = 4; ...
> } +], particularly useful for generating Javascript.
>
> [$ set VARIABLE EXPRESSION $]
> Sets a module-local "variable" (actually a method call) to the
> passed-in value[s]. E.g.
>
> [$ set TITLE "My Web Page" $]
>
> The magic comes in retrieval. The simple case works as
> expected.
>
> <title>[+ $epreq->TITLE() +]</title>
>
> Will return the value appropriate for the current context.
> Which means the value set in the current file, or (if this file
> was a template (object_base), the file that is the actual
> object. In this sense it's just a slightly easier way to do
> what is already possible. More interesting, however is when
> the method is passed a non-zero value.
>
> In our template, we define the following.
>
> [$ set CSS qw(template helper $]
>
> In our html file that it executes, we define this:
>
> [$ set CSS qw(index helper $]
>
> Back in the template, we have the following code. Note that
> this can occur before any of the other files are included.
>
> <style type="text/css">
> <!--
> [$ foreach $file ($epreq->CSS(1)) $]
> @import url("/styles/[+ $file +].css");
> [$ endforeach $]
> -->
> </style>
>
> The call with the "all" argument set to true will return all of
> the values of of all of the "CSS()" methods (with non-unique
> elements removed). It will include all methods of all files
> that list this file as an "ISA".
> [- Execute({ isa => 'filename.epl' }) -] or the case of
> "Execute('*')" where the ISA relationship is implicit.
>
> So the above code will generate:
>
> <style type="text/css">
> <!--
> @import url("/styles/template.css");
> @import url("/styles/helper.css");
> @import url("/styles/index.css");
> -->
> </style>
>
> This allows you to create templates which will include CSS,
> Javascript or
> other elements that are required by individual Embperl files that
> aren't
> even known about at the time the template is created.
>
> There are a few other additions I've made as well, but the [$ set $]
> command is
> probably the most useful.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>

--
Happy random title from the Fox News Channel reading list:

'The Lies of George W. Bush: Mastering the Politics of Deception', by David Corn

(http://www.foxnews.com/story/0,2933,77956,00.html)


*******************************************************************
keep it between you and me: get my pgp key with
gpg --keyserver wwwkeys.nl.pgp.net --recv-keys DEDDEE19
key fingerprint: 68B5 83BA 42CE 3305 F274 3D9E 71BF 4E42 DEDD EE19
*******************************************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
RE: Embperl Abandoned: Next Steps? [ In reply to ]
Hi Kee,

> I actually have a library that integrates Embperl into Catalyst so
> that you ca use it instead of the default system (Template
> Toolkit).
> Embperl is faster and uses less memory than TT. I have the module
> working in a production site, and while it needs documentation and
> code cleanup, I'd be happy to share it with folks and even set up a
> source repository if people are interested in assisting with the
> development.

Ideally I would like to see this live in the Embperl repo but as that is
perhaps a little less accessible (as in read-only for most of us) making
it available in its own repo is certainly a good first step to getting
this improved / documented / used outside your one site.

Launchpad seems to be the hosted repository 'du jour'.

> I've also added some Embperl syntax additions (see below).
[...]
> In particular, the ability to write syntax extensions in
> Perl would be a big win and would make it easier to create
> libraries to help people move from other systems. The other
> piece that would greatly help adoption would be integrating
> an AJAX system into Embperl.

Couldn't agree more.

> Syntax Additions
> [% %]
> Unescaped output. Much easier than
> [+ do { local($escmode) = 4; ... } +], particularly useful
> for generating Javascript.

Handy shortcut, I like it. Would it be difficult for you to provide a
patch against the current svn trunk back to Gerald on this one?

> [$ set VARIABLE EXPRESSION $]
> Sets a module-local "variable" (actually a method call) to the
> passed-in value[s].

The only improvement over Embperl object's inherited sub calls I can see
here is the removal of non-unique elements. Let me know if I'm missing
something :)

There are only 2 subroutines in my main site where this could have been
used and there I just do something like this:

[.!
sub jsfiles {
my $self = shift;
return [ @{$self->SUPER::jsfiles}, '/some/path/to/other/file.js' ];
}
!]

To make that strip out duplicates is a small addition. I guess if you're
doing this in lots of subs then its worth a special syntax.

I look forward to seeing the Catalyst library - that is certainly worth
improving to provide an alternative to TT/Mason. Embperl is superior
after all :)

Thanks for working on improving Embperl!

Cheers,

Andrew


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org