RE: Reading XML input from flash
-Original
Message-
From: Marc Slagle
[mailto:[EMAIL PROTECTED]]
Sent: Monday, December 09, 2002 8:02 PM
To: [EMAIL PROTECTED]
Subject: Reading XML input from
flash
Has
anyone had any luck reading in the XML sent by the flash XML.sendandload
function? I've looked on Macromedias site, and all over the
web, but cant seem to get it to work. I know that the flash code is
supposed to be POSTing the data.
Ourflash app connects to the
server and seems to be trying to send the data, but I cant capture it.
If there's any sites or code
snippets anyone can provide it would help out a lot.
Thanks,
Marc Slagle
The Fulkert Consulting Group, Inc.
559 Liberty Hill 2W
Cincinnati, OH 45210
You
know what, It might be a bug or some too complicated feature, but it does not work :S
But you can use this hack:
XML.prototype.sendAndLoad = function(url,xml_callback){
this.xml_callback = xml_callback;
this.onLoad = function (success){
if (success){
this.xml_callback.parseXML(this.toString());
this.xml_callback.onLoad();
}
}
this.load(url+?xml=+escape(this.toString()));
}
myXML2
= new XML ();
myXML2. (){
//trace(Weve got new XML:+this.toString());
}
myXML = new XML();
myXML.parseXML(testxml/);
myXML.sendAndLoad(script.cgi,myXML2);
It
redefines sendAndLoad method.
on server side you can receive that xml from $HTTP_GET_VARS[xml].
I
hope that helps.
Jevgeni Ivanov
Perl Cookbook modperl chapter
I need some people with brains (instead of the warm gray mush filling my head, the effects of becoming an editor) to look over the first 1/3 or so of a mod_perl chapter for the upcoming Perl Cookbook. I need people to read the work for accuracy. If you're interested, send me mail: [EMAIL PROTECTED]. I also need help on content. I'm not competing with Geoff, Randy, and Paul's excellent book (mod_perl Developer's Cookbook)--they have 630 pages to cover way more topics than I do. Their book will always be the definitive place for a hard-core mod_perl developer to go--in fact, I'll have them in the See Also sections of the Perl Cookbook. But I need to cover 15-20 topics that most people of beginning to intermediate mod_perl use will encounter. Current recipe list: [gnat:~] grep head1 Ora/pcb2/ch21.pod =head1 Introduction =head1 Authenticating in mod_perl =head1 Setting Cookies in mod_perl =head1 Accessing Cookie Values from mod_perl =head1 Redirecting the Browser from mod_perl =head1 Interrogating Headers in mod_perl Handlers =head1 Accessing Form Parameters from mod_perl =head1 Receiving Uploaded Files in mod_perl All suggestions appreciated. Thanks, Nat
RE: Perl Cookbook modperl chapter
From: Nathan Torkington [mailto:[EMAIL PROTECTED]] Sent: 11 December 2002 20:58 To: [EMAIL PROTECTED] Subject: Perl Cookbook modperl chapter I also need help on content. I'm not competing with Geoff, Randy, and Paul's excellent book (mod_perl Developer's Cookbook)--they have 630 pages to cover way more topics than I do. Their book will always be the definitive place for a hard-core mod_perl developer to go--in fact, I'll have them in the See Also sections of the Perl Cookbook. But I need to cover 15-20 topics that most people of beginning to intermediate mod_perl use will encounter. Current recipe list: [gnat:~] grep head1 Ora/pcb2/ch21.pod =head1 Introduction =head1 Authenticating in mod_perl =head1 Setting Cookies in mod_perl =head1 Accessing Cookie Values from mod_perl =head1 Redirecting the Browser from mod_perl =head1 Interrogating Headers in mod_perl Handlers =head1 Accessing Form Parameters from mod_perl =head1 Receiving Uploaded Files in mod_perl URI Rewriting and TransHandlers? Ie the basics of webserver URI - file/resource location, with a little bit on rewriting the URI with a view to session management or ~user dirs Logging Handlers? ie how to tweak the logging phase and log to a Database or log dependant on some request parameter? Greg All suggestions appreciated. Thanks, Nat This message and any attachment has been virus checked by Pfizer Corporate Information Technology, Sandwich.
Re: Perl Cookbook modperl chapter
Nat,
Obviously you (or ORA) _are_ competing with mod_perl Developer's
Cookbook ...
If ORA wanted to cover mod_perl they should not have let Geoff co. get
away to another publisher.
Trying now to cover highly complex topics like Authenticating in
mod_perl in a recipe in a chapter of the Perl cookbook is futile. It will
only serve to oversimplify and lead novices into a false sense of
competence. They'll then show up on this list demanding to know why their
hacks on your recipes do not function as expected.
I do not believe you will do any service to mod_perl or to your readers by
glossing over how large a field of study mod_perl is. It's almost as bad
as the Teach Yourself Perl in 24 Hours title put out by Geoff's
publisher.
I urge you to rethink this plan.
- nick
Nick Tonkin {|8^)
On Wed, 11 Dec 2002, Nathan Torkington wrote:
I need some people with brains (instead of the warm gray mush filling
my head, the effects of becoming an editor) to look over the first 1/3
or so of a mod_perl chapter for the upcoming Perl Cookbook. I need
people to read the work for accuracy. If you're interested, send me
mail: [EMAIL PROTECTED].
I also need help on content. I'm not competing with Geoff, Randy, and
Paul's excellent book (mod_perl Developer's Cookbook)--they have 630
pages to cover way more topics than I do. Their book will always be
the definitive place for a hard-core mod_perl developer to go--in
fact, I'll have them in the See Also sections of the Perl Cookbook.
But I need to cover 15-20 topics that most people of beginning to
intermediate mod_perl use will encounter.
Current recipe list:
[gnat:~] grep head1 Ora/pcb2/ch21.pod
=head1 Introduction
=head1 Authenticating in mod_perl
=head1 Setting Cookies in mod_perl
=head1 Accessing Cookie Values from mod_perl
=head1 Redirecting the Browser from mod_perl
=head1 Interrogating Headers in mod_perl Handlers
=head1 Accessing Form Parameters from mod_perl
=head1 Receiving Uploaded Files in mod_perl
All suggestions appreciated.
Thanks,
Nat
Re: Perl Cookbook modperl chapter
Nick Tonkin writes: Obviously you (or ORA) _are_ competing with mod_perl Developer's Cookbook ... If ORA wanted to cover mod_perl they should not have let Geoff co. get away to another publisher. Actually, we do cover mod_perl--we published the Eagle book, Writing Apache Modules ... way back in 1999. We have Stas and Eric's book coming out in 2003 (March? April?). It busts my nut that we didn't publish Geoff's, Randy's, and Paul's book, but that's the way the dice fall. There's no way that 20 recipes in the Perl Cookbook will compete with the what, 250? in the mod_perl Developer's Cookbook. Especially when the introduction and each recipe points the reader to the mpDC. The Perl Cookbook has over a hundred thousand readers. I want to push as many as I can onto the mpDC. If that's competing, then I can only say that you have a strange sense of competition :-) If we were going to compete head-to-head with the mod_perl Developer's Cookbook, O'Reilly would publish the mod_perl Cookbook. We've done it before (PHP Cookbook vs PHP Developer's Cookbook). We don't have plans to do that, and I'd fight them if we did. Geoff et al.'s book is very good, and I want to help their sales not hurt them. Trying now to cover highly complex topics like Authenticating in mod_perl in a recipe in a chapter of the Perl cookbook is futile. It will only serve to oversimplify and lead novices into a false sense of competence. The Perl Cookbook has never pretended to be the definitive guide to anything it covers (have you seen the Perl Cookbook? I recommend it :-). Each recipe includes references to definitive sources of information (manpages, web sites, and other books). Nat
Re: Perl Cookbook modperl chapter
On Wed, Dec 11, 2002 at 01:13:30PM -0800, Nick Tonkin wrote: Obviously you (or ORA) _are_ competing with mod_perl Developer's Cookbook ... Why wouldn't they be? They have Writing Apache modules with Perl and C after all. And with Stas' and Eric's book on the way (www.modperlbook.org) they already have two books (soon hopefully). If ORA wanted to cover mod_perl they should not have let Geoff co. get away to another publisher. Maybe they felt that the book(s) they already have signed for will/would saturate the market? A publisher can only justify a certain amount of books on each topic. [Don't really want to go into wheter or not mod_perl should be covered in gnat's book, but if they have decided to include it they are certainly within their rights to do so. If you don't like that, just don't buy the book?] -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/ !(C)http://copywrong.dk/ http://apachegallery.dk/ Putting the HEST in .COM http://www.hestdesign.com/
RE: Perl Cookbook modperl chapter
Nathan Torkington wrote: Current recipe list: [gnat:~] grep head1 Ora/pcb2/ch21.pod =head1 Introduction =head1 Authenticating in mod_perl =head1 Setting Cookies in mod_perl =head1 Accessing Cookie Values from mod_perl =head1 Redirecting the Browser from mod_perl =head1 Interrogating Headers in mod_perl Handlers =head1 Accessing Form Parameters from mod_perl =head1 Receiving Uploaded Files in mod_perl Database persistence is an important topic but it's hard to say whether one directive ... PerlModule Apache::DBI ... constitutes a 'recipe' Using stacked handlers to filter content is another useful technique. Grant
Re: Perl Cookbook modperl chapter
On Wed, 11 Dec 2002, Nathan Torkington wrote:
Actually, we do cover mod_perl--we published the Eagle book, Writing
Apache Modules ... way back in 1999.
Yes, I have had my now dog-eared copy since then :)
There's no way that 20 recipes in the Perl Cookbook will compete with
the what, 250? in the mod_perl Developer's Cookbook. Especially when
the introduction and each recipe points the reader to the mpDC. The
Perl Cookbook has over a hundred thousand readers. I want to push as
many as I can onto the mpDC. If that's competing, then I can only say
that you have a strange sense of competition :-)
Ahem, well, without wanting to get into a fruitless argument about this
part, I might say that you have a strange idea of how to push people onto
their book. At close to $50 a pop, I know I'd think twice about purchasing
the mpDC if I'd shelled out for the Perl Cookbook and it had a section on
mod_perl. I venture to say Geoff et al will see less overall sales, rather
than more, if the PCB has a mod_perl section. This notwithstanding the
fact that _some_ people _will_ no doubt have their appetite whetted and
move on to the definitive mpDC. (Of course there's nothing definitive
about Perl, that's the whole point about TMTOWTDI, right?)
Trying now to cover highly complex topics like Authenticating in
mod_perl in a recipe in a chapter of the Perl cookbook is
futile. It will only serve to oversimplify and lead novices into a
false sense of competence.
This was really my point.
The Perl Cookbook has never pretended to be the definitive guide to
anything it covers (have you seen the Perl Cookbook? I recommend
it :-). Each recipe includes references to definitive sources of
information (manpages, web sites, and other books).
I have also owned the Perl Cookbook since it came out. It's very useful as
exactly what it says: a cookbook. You can turn to it for a recipe to
accomplish a small, simple task which you guess others may have tackled
before you. You can also use it as a tutorial, if you choose to, by
studying each chapter as a whole. I do not believe that mod_perl lends
itself to the former, and I think that the mpDC more approaches the
latter. One can go look up a recipe, true, but it is useless without a
pretty thorough prior understanding of mod_perl. So, I stand by my
prediction that just putting a few mod_perl recipes in the PCB will lead
more than a few people into more problems than solutions.
While I've been writing this reply a few people have responded to your
request for content suggestions. Stacked handlers, among other things
... I think it just goes to show that there can be no successful trivial
coverage of mod_perl. (That's why the Eagle book, and the mpDC, are so
good.)
- nick
Nick Tonkin {|8^)
Re: Perl Cookbook modperl chapter
On Wed, 11 Dec 2002 13:58:18 -0700, Nathan Torkington wrote: Nathan I also need help on content. I'm not competing with Geoff, Randy, Some of us are trying to implement authentication/login/logout where, if at all possible, cookies are not to be used. A cookie-free discussion would be most welcome. Having 2 books which can both be casually, if incorrectly, called The mod_perl Cookbook, is asking for endless (minor) trouble. A distinct name would be a distinct advantage. -- Cheers Ron Savage, [EMAIL PROTECTED] on 12/12/2002 http://savage.net.au/index.html
Re: Perl Cookbook modperl chapter
Nick, I think you raise valid points that I think Nathan and the reviewers should take on board when they do this chapter and subsequently review it. However... 1) I believe that rather than entirely naysay that some common cookbook items can be covered in a mod_perl chapter, I would prefer to see what Nathan et al come up with rather than discourage them from trying at all. Will it be "futile" as you suggest? Maybe. But then Nathan and the reviewers can choose to cut the chapter. Will it be too complex and therefore cause problems for readers? Maybe. But I think I would trust Nathan and his reviewers to judge after it's done. And again, there is the option of always cutting that chapter as mentioned above. In my past writing life, I've cut plenty of chapters when after seeing a whole book, deciding that they didn't fit (or worse, where it just was a bad chapter I wrote). I suspect Nathan has done the same in his lifetime and I would trust his professionalism in this manner. In other words, I think we should trust that Nathan et al have been writing/editing for a long time. Can they make mistakes? Yes. No one is perfect. But I also trust that their experience will allow them to come up with something for this chapter which will suit a market need. And if it doesn't, to not use that material. But I think it would be sad not to try at all since there could be benefits to this chapter. 2) Will mpdc lose sales? I suppose so. Short-term maybe. But then should Stas stop publishing his book? MacEachern and Stein theirs? Surely they also overlap with mpdc. And there will be other books by other publishers that will overlap with mpdc as well. I suppose that I feel like I am more of an economic optimist than you. While short-term, it may appear that more mod_perl books being released would cause fewer sales in a market that is "fixed", long-term, I believe having more written material about mod_perl will actually help the market. Provided it is done well, I think a chapter in TPC that covers mod_perl explicitly is a good idea also for spreading mod_perl community advocacy and learning. Nick Tonkin wrote: On Wed, 11 Dec 2002, Nathan Torkington wrote: Actually, we do cover mod_perl--we published the Eagle book, "Writing Apache Modules ..." way back in 1999. Yes, I have had my now dog-eared copy since then :) There's no way that 20 recipes in the Perl Cookbook will compete with the what, 250? in the mod_perl Developer's Cookbook. Especially when the introduction and each recipe points the reader to the mpDC. The Perl Cookbook has over a hundred thousand readers. I want to push as many as I can onto the mpDC. If that's competing, then I can only say that you have a strange sense of competition :-) Ahem, well, without wanting to get into a fruitless argument about this part, I might say that you have a strange idea of how to push people onto their book. At close to $50 a pop, I know I'd think twice about purchasing the mpDC if I'd shelled out for the Perl Cookbook and it had a section on mod_perl. I venture to say Geoff et al will see less overall sales, rather than more, if the PCB has a mod_perl section. This notwithstanding the fact that _some_ people _will_ no doubt have their appetite whetted and move on to the definitive mpDC. (Of course there's nothing definitive about Perl, that's the whole point about TMTOWTDI, right?) Trying now to cover highly complex topics like "Authenticating in mod_perl" in a recipe in a chapter of the Perl cookbook is futile. It will only serve to oversimplify and lead novices into a false sense of competence. This was really my point. The Perl Cookbook has never pretended to be the definitive guide to anything it covers (have you seen the Perl Cookbook? I recommend it :-). Each recipe includes references to definitive sources of information (manpages, web sites, and other books). I have also owned the Perl Cookbook since it came out. It's very useful as exactly what it says: a cookbook. You can turn to it for a recipe to accomplish a small, simple task which you guess others may have tackled before you. You can also use it as a tutorial, if you choose to, by studying each chapter as a whole. I do not believe that mod_perl lends itself to the former, and I think that the mpDC more approaches the latter. One can go look up a recipe, true, but it is useless without a pretty thorough prior understanding of mod_perl. So, I stand by my prediction that just putting a few mod_perl recipes in the PCB will lead more than a few people into more problems than solutions. While I've been writing this reply a few people have responded to your request for content suggestions. Stacked handlers, among other things ... I think it just goes to show that there can be no successful trivial coverage of mod_perl. (That's why the Eagle book, and the mpDC, are so good.) - nick
Re: Perl Cookbook modperl chapter
Hi, I only speak for myself, but I am happy to see mod_perl covered in the Perl Cookbook. Why you ask? I see the inclusion of mod_perl helping increase the size of the mod_perl pie. A rising tide lifts all boats. I'm not too worried about the content. I'm sure it will be top-notch. Consider that the Perl Cookbook already gives you good coverage of several complex domain specific areas: DBI, LWP, CGI, Sockets, Tk, etc. I'll be very happy if the Perl Cookbook gets the novice mod_perl programmer started and then leads them to the mpDC, which is really an intermediate to advanced work. My only concern? If the Perl Cookbook gets any larger I might throw out my back carrying it around :) -- Paul Lindner[EMAIL PROTECTED] | | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org/ Human Rights Declaration http://www.unhchr.ch/udhr/
Re: Problem with dbm files?
Warren Pollans wrote: One app uses MLDBM (with DB_File) to store a complex hash. One doc, mod_perl and dbm files, suggests that there might be consistency problems (locking related) when using dbm files with mod_perl. It seems that the MLDBM::Sync module is supposed to eliminate this concern. Could someone that uses MLDBM with DB_File under mod_perl please let me know if there are, in fact, problems with this combination. If so, will MLDBM::Sync fix them or do I need to rewite my app to use mysql? MLDBM::Sync is a drop in replacement for MLDBM for typical use, and correctly deals with concurrency issues as long as the files are on the local disk, files on network mounts may not respect the file locking that MLDBM::Sync uses. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: Perl Cookbook modperl chapter
On Wednesday, December 11, 2002, at 03:17 PM, Ron Savage wrote: Having 2 books which can both be casually, if incorrectly, called The mod_perl Cookbook, is asking for endless (minor) trouble. A distinct name would be a distinct advantage. Nat's book is _The Perl Cookbook_, not _The mod_perl Cookbook_, and is the *original* cookbook. He wrote the book on cookbooks, you could say. :-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Perl Cookbook modperl chapter
* Ron Savage ([EMAIL PROTECTED]) [12 Dec 2002 10:19]: [...] Having 2 books which can both be casually, if incorrectly, called The mod_perl Cookbook, is asking for endless (minor) trouble. A distinct name would be a distinct advantage. Given there's already XML and Perl and Perl XML (I must admit I was amused when someone publicising the former called it the latter); and the myriad combinations of Perl, CGI and Web in titles; I don't think Perl Cookbook and mod_perl Developer's Cookbook are not sufficiently distinguished. Of course, people will call both 'the cookbook', but no doubt we'll be able to spot which one they mean by the question. mod_perl will be only one chapter in Perl Cookbook. cheers, -- Iain.
Re: Perl Cookbook modperl chapter
Paul Lindner wrote: Hi, I only speak for myself, but I am happy to see mod_perl covered in the Perl Cookbook. Why you ask? I see the inclusion of mod_perl helping increase the size of the mod_perl pie. A rising tide lifts all boats. I second that. And just like Paul, I only speak for myself. We need more coverage/crossreference for mod_perl in places where people don't know/use mod_perl yet. If Nat's chapter gives plenty of crossreferences to the eagle book, cookbook and our new book, it's a goodness. I'd like to think of Nat's chapter as a teaser, to get the reader all excited about mod_perl. So you should a simple auth recipe and say, to learn about more complex implementation, see Chapter XXX Book YYY. Now if that reader is not really interested in getting to know mod_perl, chances are that he would never have bought Book YYY. But if Nat's chapter raised enough curiosity for that person to go and buy Book YYY, that's a goodness! Also please don't forget that the majority of mod_perl users use or at least start with *only* Apache::Registry and Apache::PerlRun, so just covering these two meaning to bring many more converts to mod_perl, by just letting them know that it takes a few minutes to make your perl/cgi scripts fly. Do they need more than that? Time will show. To me what's important is to have as many people as possible *know* about mod_perl and its strengths (and weaknesses I guess ;). Because if people don't know about mod_perl they obviously won't buy mod_perl books. The real problem with mod_perl books not selling as well as they could is the availability of the online documentation, which certainly doesn't cover the cool things in the cookbook and the eagle books, but is good enough for many purposes. So I was thinking to help the sales of our book when it hits the shelves in March 2003, we should pull the documentation site down for a few months and redirect everybody to http://modperlbook.org/ ;) (...for those who miss the smiley, I'm joking of course) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Perl Cookbook modperl chapter
Paul Lindner wrote: Hi, I only speak for myself, but I am happy to see mod_perl covered in the Perl Cookbook. Why you ask? I see the inclusion of mod_perl helping increase the size of the mod_perl pie. A rising tide lifts all boats. I totally agree - at this stage in the game, the more quality books that cover mod_perl, the better for those of us that want to get paid to use and/or develop it. I'm not too worried about the content. I'm sure it will be top-notch. Consider that the Perl Cookbook already gives you good coverage of several complex domain specific areas: DBI, LWP, CGI, Sockets, Tk, etc. and kudos to Nat for adding mod_perl as a topic at all. it's difficult to decide which topics to cover in a work, especially one with such broad coverage as the Perl Cookbook. having a chapter dedicated to mod_perl is not only an honor for the application we all love, but is bound to increase its overall exposure. I'll be very happy if the Perl Cookbook gets the novice mod_perl programmer started and then leads them to the mpDC, which is really an intermediate to advanced work. of course, I also consider it an honor that Nat and ORA have decided to mention our book at all - as a publisher competing in many of the same areas as Sams, ORA certainly is not required to do so. but the friendliness that (usually :) surrounds the members of our community is part of what makes it strong as well as a fun project to be involved in. --Geoff
