perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerald Richter" <rich...@ecos.de>
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/epwebapp.pl . 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.
> 

Thanks!

> 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 www.kwiki.org, 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...

Gerald



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


Mime
View raw message