perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerald Richter" <>
Subject RE: Some philosophical questions
Date Tue, 02 Aug 2005 05:22:57 GMT
> On a side note, I find some of the new stuff in 2.0 a little 
> obscure. As an application programmer I can well appreciate 
> the ability to deconstruct the request to the extent that 2.0 
> appears to allow, but I honestly cannot see how or why I 
> would personally want to do any of that. Perhaps more 
> concrete examples of where these new features come in useful 
> would be helpful, both to people like me and newcomers 
> thinking about using Embperl.

Yes, have some small example would be good. The Embperl website in eg/web is
a big example that uses many of these technics, but it's not easy to
understand for the beginner

> On a philosophical note, I have discovered from personal 
> experience that new ideas are not necessarily self-evident to 
> other people, they need prompting and examples to bring it 
> all to life so they can see how it applies to their own 
> situation. There is an "Aha!" moment you're looking for here, 
> where programmers look at this and see in a flash how it will 
> make their lives easier.

I agree

> Currently, all I really want out of Embperl is the ability to 
> a) embed Perl code in the HTML templates, and b) structure my 
> website in a vaguely object-oriented manner through the 
> inheritance that EmbperlObject (or Embperl::Object) provides. 
> All that is currently satisfactorily supplied by Embperl 1.x. 
> So to me, the only current perceived benefit of moving to 
> Embperl 2.x is the performance increase, and this is 
> certainly outweighed by the lingering bugs and continuing 
> almost-but-not-quite compatibility with 1.x. I'll continue to 
> test my codeset under 2.x, but I am fearful of putting it up 
> live on the production server because it's almost impossible 
> for me to test every little case - it's a lot of code (over 
> 50,000 lines in crazyguyonabike) and there's a lot of 
> community input, which I don't want to risk breaking.
> On the new feature front - Why exactly would I write a new 
> recipe or rearrange the providers? No doubt there are good 
> examples, if someone would be good enough to provide these 
> then they could form some of the foundation for the Cookbook.

See eg/web/ . There is a method get_recipe, which depending on
the extention of the input file and the extention of the requested file sets
the correct recipe, so you can output text, pod, html,...

Writing a new provider is would make sense for example to insert a filter
e.g. doing syntax highlighting or to read a different fileformat or source
(for example to fetch everything form a db instead of the filesystem).

> I decided to take another look at the README.v2 and correct 
> the English grammar/spelling issues that I could find. I am 
> attaching this for you to look at, I hope it's useful as a start.


> I will investigate, as time allows, the different Wiki 
> toolkits that are available out there and see if there is 
> anything that looks like being a good fit here. 

I suggest, if anybody has any better idea let me know

> I agree that 
> perhaps making this a Wiki would be more scalable that having 
> one person write a document, though I do still like the 
> "ownership" and consistency of style that can come from a 
> document written by a single person rather than committee. 
> Committees come up with something that attempts to please 
> everybody but often ends up being uninspired and bland.

But as long as there is nobody who writes this one consitent document, it's
better to have at least this "uninspired and bland" stuff...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message