> > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
