Re: [cgiapp] getting C::A::Dispatch to ignore certain URLs
On 1/25/09, Bradley C Bailey cgi...@brad.memoryleak.org wrote: You didn't say what environment you're using. My apologies... I am using plain vanilla CGI on Mac OS X with Perl 5.10. If you're using Apache/mod_perl you can add this to your configuration: Location /img SetHandler default /Location Regards, Bradley C Bailey The way I have set up my application, the following 3 URLs all result in displaying Target, that is, the 'view' runmode server/ server/Target server/view/Target I have other runmodes that are like so server/edit/Target servercreate/New_Target and so on. Here is the problem... if a page has a link to a resource that has to be displayed directly in the browser, for example, a PDF, C::A::Dispatch wants to handle it as well. For example, the following URL server/img/doc.pdf results in an error. How can I make C::A::Dispatch ignore URLs that point to anything in the server/img/ directory? # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] getting C::A::Dispatch to ignore certain URLs
P Kishor wrote: How can I make C::A::Dispatch ignore URLs that point to anything in the server/img/ directory? Let's try re-phrasing that question... How do I make my webserver not call C::A::Dispatch for anything under /img? Even if Dispatch had a way of ignoring certain urls, what would it do? Exit? What does that accomplish? The webserver itself needs to serve that content and since Dispatch runs under lots of different web servers there's no way for it to tell that server that it has decided it now doesn't want to handle that object after the server has passed control over to Dispatch. The webserver needs to make the decision as to whether or not Dispatch should serve it, not Dispatch. -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
Lyle wrote: Anyone had any ideas for a Pure Perl FillinForm replacement? At the moment I'm thinking of a simple regexp based alternative??? Please, please don't do that! HTML is a complicated language and any regular expressions you come up with will fail on real world code. Trying to identify and change the properties of HTML form elements would be tricky enough, but what about things like + Javascript code which has HTML in strings (very common in DHTML apps) + HTML comments? + targetting specific forms? Dealing with HTML requires a parser. Anything else won't make people happy. On a side note, get a hosting provider that gives you a compiler, gee wiz! -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] getting C::A::Dispatch to ignore certain URLs
On 1/25/09, Michael Peters mpet...@plusthree.com wrote: P Kishor wrote: How can I make C::A::Dispatch ignore URLs that point to anything in the server/img/ directory? Let's try re-phrasing that question... How do I make my webserver not call C::A::Dispatch for anything under /img? Even if Dispatch had a way of ignoring certain urls, what would it do? Exit? What does that accomplish? The webserver itself needs to serve that content and since Dispatch runs under lots of different web servers there's no way for it to tell that server that it has decided it now doesn't want to handle that object after the server has passed control over to Dispatch. The webserver needs to make the decision as to whether or not Dispatch should serve it, not Dispatch. Very well put. So, how do I make the webserver (in my case, Apache without mod_perl, for now) serve directly anything under /img (or any other specified folder) without invoking C::A::Dispatch? Many thanks in advance. Puneet. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] getting C::A::Dispatch to ignore certain URLs
P Kishor wrote: Very well put. So, how do I make the webserver (in my case, Apache without mod_perl, for now) serve directly anything under /img (or any other specified folder) without invoking C::A::Dispatch? Many thanks in advance. Puneet. Try moving the img directory out of the directory handled by dispatching and then accessing it through an Apache alias. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
On Sun, 25 Jan 2009, Michael Peters wrote: Dealing with HTML requires a parser. Anything else won't make people happy. Agree. On a side note, get a hosting provider that gives you a compiler, gee wiz! Easy for you to say Mr. Moneybags! I doubt if any of the cheap hosting providers offer this (or they charge extra for it.) But then again the ones I've seen that claim to support CGI already have HTML::Parser installed so perhaps this is not such a big deal in reality? -- Jaldhar H. Vyas jald...@braincells.com # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] getting C::A::Dispatch to ignore certain URLs
On 1/25/09, Matthew Whipple mwhip...@kothartech.com wrote: P Kishor wrote: Very well put. So, how do I make the webserver (in my case, Apache without mod_perl, for now) serve directly anything under /img (or any other specified folder) without invoking C::A::Dispatch? Many thanks in advance. Puneet. Try moving the img directory out of the directory handled by dispatching and then accessing it through an Apache alias. hmmm... I was hoping for a different solution. While the above is doable, it messes up my mellow. My directory structure is thusly site folder/ - index.cgi - _perl/.. various Perl modules for this site - _tmpl/.. html templates - _logs/.. my own logs - css/.. stylesheets - js/.. javascripts - img/.. images and other media All folders prefixed with '_' are *not* accessible directly via the web, while the other folders, css, js and img contain stuff that can be accessed through a URL. That way I can give some a direct URL to an image in the img directory, for instance. This also allows me to keep everything specific to a web application within its own folder. If I move the img directory outside the site folder, I no longer have a single folder for a single application. A related question -- am I attempting something that is unusual? I thought I was doing something very logical and reasonable, but then, we always tend to think highly of our own strategies until we are shown better ways. Many thanks, Puneet. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
On 1/25/09, Jaldhar H. Vyas jald...@braincells.com wrote: On Sun, 25 Jan 2009, Michael Peters wrote: Dealing with HTML requires a parser. Anything else won't make people happy. Agree. On a side note, get a hosting provider that gives you a compiler, gee wiz! Easy for you to say Mr. Moneybags! I doubt if any of the cheap hosting providers offer this (or they charge extra for it.) But then again the ones I've seen that claim to support CGI already have HTML::Parser installed so perhaps this is not such a big deal in reality? Actually, at least Dreamhost, a fairly cheap host, does allow compiling your own programs. You can also compile your own version of Perl as well as their site version of Perl is several versions behind (I think they are still serving Perl 5.8.4). I did encounter some problems compiling Perl on their server, which apparently has been fixed with a patch, but I didn't proceed any further with that. On the other hand, I successfully installed several of my own modules including ones that required compiling... for instance, DBD::SQLite. So, money is not really any issue. On the other hand, compiling is just a pain in the tush. It is just easier to zip up a bunch of files on your development computer (a Macbook, in my case) and upload it to the web server, usually some variant of Linux. Fortunately for me, I got employed in a position that gives me control of a cluster of Xserves so that problem doesn't apply anymore. Puneet. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] getting C::A::Dispatch to ignore certain URLs
P Kishor wrote: On 1/25/09, Matthew Whipple mwhip...@kothartech.com wrote: P Kishor wrote: Very well put. So, how do I make the webserver (in my case, Apache without mod_perl, for now) serve directly anything under /img (or any other specified folder) without invoking C::A::Dispatch? Many thanks in advance. Puneet. Try moving the img directory out of the directory handled by dispatching and then accessing it through an Apache alias. hmmm... I was hoping for a different solution. While the above is doable, it messes up my mellow. My directory structure is thusly site folder/ - index.cgi - _perl/.. various Perl modules for this site - _tmpl/.. html templates - _logs/.. my own logs - css/.. stylesheets - js/.. javascripts - img/.. images and other media All folders prefixed with '_' are *not* accessible directly via the web, while the other folders, css, js and img contain stuff that can be accessed through a URL. That way I can give some a direct URL to an image in the img directory, for instance. This also allows me to keep everything specific to a web application within its own folder. If I move the img directory outside the site folder, I no longer have a single folder for a single application. The issue is that (seemingly) you've assigned a default handler for the entire directory, overriding the web server normal functionality. This could potentially be reversed by Perl but that is a convoluted solution. You could restructure your directories so that all of the scripts (or those handled as such) are separated within the project parent directory (more of a traditional cgi-bin setup while still keeping projects grouped together), or implement more selective handler assignment. A related question -- am I attempting something that is unusual? I thought I was doing something very logical and reasonable, but then, we always tend to think highly of our own strategies until we are shown better ways. Many thanks, Puneet. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
Michael Peters wrote: Lyle wrote: Anyone had any ideas for a Pure Perl FillinForm replacement? At the moment I'm thinking of a simple regexp based alternative??? Please, please don't do that! HTML is a complicated language and any regular expressions you come up with will fail on real world code. Trying to identify and change the properties of HTML form elements would be tricky enough, but what about things like + Javascript code which has HTML in strings (very common in DHTML apps) Does the current parser pick that up? I don't think HTML::Parser executes any JavaScript. + HTML comments? + targetting specific forms? Dealing with HTML requires a parser. Anything else won't make people happy. I see. But there isn't a Pure Perl parser available, and for those that really can't get HTML::Parser on their cheap shared hosting, isn't a regexp that works most/some of the time better than nothing? On a side note, get a hosting provider that gives you a compiler, gee wiz! I've got a couple of dedicated boxs, one in the UK and one in the USA. I actually offer hosting on both. Being able to compile isn't an issue for me, but I make commercial scripts and some of my customers have cheap hosting where they can't compile. (Yes I offer them my hosting, or the scripts ran off my hosting, but some of them insist on having all scripts on their cheap hosting). Lyle # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
Hi Lyle I see. But there isn't a Pure Perl parser available, and for those that really can't get HTML::Parser on their cheap shared hosting, isn't a regexp that works most/some of the time better than nothing? No, it's not 'better than nothing'. Ever. All you're doing is lighting the fuse on a time-bomb. -- Ron Savage r...@savage.net.au http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
On 1/25/09, Ron Savage r...@savage.net.au wrote: Hi Lyle I see. But there isn't a Pure Perl parser available, and for those that really can't get HTML::Parser on their cheap shared hosting, isn't a regexp that works most/some of the time better than nothing? No, it's not 'better than nothing'. Ever. All you're doing is lighting the fuse on a time-bomb. Fortunately I am neither advocating nor desiring a pure-Perl form validation module, but I don't understand the resistance to this. The poor bloke is saying -- look, I have folks who want to utilize my scripts in situations where they cannot compile modules... what do I do? Give them something or give them nothing? I am surprised that there is so much vehemence against this. I don't believe Lyle is saying that a pure-Perl alternative is better or even as good as the compiled modules... all he wants is an alternative, which, while most likely unsuitable for more than the simple cases, is likely a pretty good fit for those simple cases. In fact, my suggestion would be to not do any form validation with Perl as much as possible... form validation should be done in the browser, and it just might be best to do it with JavaScript so good data reaches the server in the first place. Then, on the server, check for sanity and security. In any case, I respectfully disagree with the Ever qualification to No, it's not 'better than nothing.' There just might be situations in which it maybe better than nothing. Puneet. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
P Kishor wrote: On 1/25/09, Ron Savage r...@savage.net.au wrote: Hi Lyle I see. But there isn't a Pure Perl parser available, and for those that really can't get HTML::Parser on their cheap shared hosting, isn't a regexp that works most/some of the time better than nothing? No, it's not 'better than nothing'. Ever. All you're doing is lighting the fuse on a time-bomb. Fortunately I am neither advocating nor desiring a pure-Perl form validation module, but I don't understand the resistance to this. The poor bloke is saying -- look, I have folks who want to utilize my scripts in situations where they cannot compile modules... what do I do? Give them something or give them nothing? I am surprised that there is so much vehemence against this. I don't believe Lyle is saying that a pure-Perl alternative is better or even as good as the compiled modules... all he wants is an alternative, which, while most likely unsuitable for more than the simple cases, is likely a pretty good fit for those simple cases. I heartily agree :) In fact, my suggestion would be to not do any form validation with Perl as much as possible... form validation should be done in the browser, and it just might be best to do it with JavaScript so good data reaches the server in the first place. Then, on the server, check for sanity and security. I had given up on the idea of using Data::FormValidator until I read someone post a link to http://formvalidatorjs.berlios.de/ With a JS drop in for Data::FormValidator. It made sense to use these rather than create my own validation in JS and Perl. I've now finished and tested the Pure Perl alternative functions in Data::FormValidator and they pass all the Build tests. Note: These aren't a replacement to the XS modules, they are an alternative used only is the XS modules aren't available. In any case, I respectfully disagree with the Ever qualification to No, it's not 'better than nothing.' There just might be situations in which it maybe better than nothing. I agree. I'm not saying that a regexp solution will ever compare HTML::Parser. Just that those who really don't have a choice, a developed and tested collection of regexps will likely be better than them having noting or writing their own. Lyle # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
Data::FormValidator can be used without the stated XS prereq's, if you don't use the built in 'email', you don't need Net::DNS. Just use a regex in its place. Something like '/^[a-za-z0-9\_\-\...@[a-za-z0-9\_\-\.]+[a-za-z]$/' might do (NOTE: there are more complete ones out there). You don't have to use HTML::FillInForm (that's not a validation thing; it's a user convenience method). As for HTML::FillInForm, it's better to do nothing, than to use some regexp. I believe that is the point to which Ron was pointing. Using a regexp can cause you far more problems than good. That's not to say a pure-perl parser cannot be written, but that hand-writing a regex to attempt to half-ass the job is a horrible idea... you'll cause more problems than it's worth. It's still up to you, so you've been warned. As for validation, your suggestion to not do any form validation with Perl as much as possible is beyond bad advice. If anything, the advice should be reversed (and this is coming from the author of Data.FormValidator.js, which the following post recommends). The whole point of Data.FormValidator.js is to encourage backend validation along with frontend validation, and when issues arise, to encourage the use of backend validation. Javascript can NOT keep bad data from reaching your script. People can disable it. Heck, they can use LWP and script around it. It provides absolutely no protection for your site at all, and that's the way it should be viewed. Javascript validation provides for a better user experience (if you're going to reject their data, it's faster if you do it before they submit). it can also take the place of highlighting form fields like HTML::FillInForm - user convenience stuff. If you're using JS validation as a replacement (rather than in addition to) backend validation, you've failed. Sorry if that sounds blunt, but it is that simple. I'd second the ever qualification on using a hand made regex to replace a real html parser. It simple doesn't makes any sense. Find an html parser that is pure perl, and extend it - I'm sure there are ones out there. -- Josh I. On Sun, Jan 25, 2009 at 5:33 PM, P Kishor punk...@eidesis.org wrote: On 1/25/09, Ron Savage r...@savage.net.au wrote: Hi Lyle I see. But there isn't a Pure Perl parser available, and for those that really can't get HTML::Parser on their cheap shared hosting, isn't a regexp that works most/some of the time better than nothing? No, it's not 'better than nothing'. Ever. All you're doing is lighting the fuse on a time-bomb. Fortunately I am neither advocating nor desiring a pure-Perl form validation module, but I don't understand the resistance to this. The poor bloke is saying -- look, I have folks who want to utilize my scripts in situations where they cannot compile modules... what do I do? Give them something or give them nothing? I am surprised that there is so much vehemence against this. I don't believe Lyle is saying that a pure-Perl alternative is better or even as good as the compiled modules... all he wants is an alternative, which, while most likely unsuitable for more than the simple cases, is likely a pretty good fit for those simple cases. In fact, my suggestion would be to not do any form validation with Perl as much as possible... form validation should be done in the browser, and it just might be best to do it with JavaScript so good data reaches the server in the first place. Then, on the server, check for sanity and security. In any case, I respectfully disagree with the Ever qualification to No, it's not 'better than nothing.' There just might be situations in which it maybe better than nothing. Puneet. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
Joshua Miller wrote: As for HTML::FillInForm, it's better to do nothing, than to use some regexp. I believe that is the point to which Ron was pointing. Using a regexp can cause you far more problems than good. That's not to say a pure-perl parser cannot be written, but that hand-writing a regex to attempt to half-ass the job is a horrible idea... you'll cause more problems than it's worth. It's still up to you, so you've been warned. I've been reading up on it. It's true that a regexp will always break. A collection of regexps working to get individual parts would be better, but still break in some circumstances. Writing a Scanner - Lexer - Parser in Pure Perl would be ideal, but not without it's own problems. As for validation, your suggestion to not do any form validation with Perl as much as possible is beyond bad advice. If anything, the advice should be reversed (and this is coming from the author of Data.FormValidator.js, which the following post recommends). The whole point of Data.FormValidator.js is to encourage backend validation along with frontend validation, and when issues arise, to encourage the use of backend validation. I don't think he meant not do any form validation with Perl as much as possible. I think that came across wrong, as he later made a comment Then, on the server, check for sanity and security.. I think he was trying to say you should try and have JavaScript as well to reduce calls to the server which is more costly... I could be wrong... I'd second the ever qualification on using a hand made regex to replace a real html parser. It simple doesn't makes any sense. Find an html parser that is pure perl, and extend it - I'm sure there are ones out there. I've looked for one, the only one I could find is HTML::TagParser but it isn't suitable as it can't be used to recreate the page. Also looking at the source it uses regexp. As much as the idea of writing a Pure Perl parser intrigues me, I don't have the time :( Especially as at this time I wouldn't actually be using it (my script is generating all the html input tags and parsing them into the html template). Maybe I'll add it to one of my would like to do at some point if I get chance lists... Lyle # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
On Sun, Jan 25, 2009 at 7:00 PM, Lyle webmas...@cosmicperl.com wrote: Joshua Miller wrote: As for HTML::FillInForm, it's better to do nothing, than to use some regexp. I believe that is the point to which Ron was pointing. Using a regexp can cause you far more problems than good. That's not to say a pure-perl parser cannot be written, but that hand-writing a regex to attempt to half-ass the job is a horrible idea... you'll cause more problems than it's worth. It's still up to you, so you've been warned. I've been reading up on it. It's true that a regexp will always break. A collection of regexps working to get individual parts would be better, but still break in some circumstances. Writing a Scanner - Lexer - Parser in Pure Perl would be ideal, but not without it's own problems. As for validation, your suggestion to not do any form validation with Perl as much as possible is beyond bad advice. If anything, the advice should be reversed (and this is coming from the author of Data.FormValidator.js, which the following post recommends). The whole point of Data.FormValidator.js is to encourage backend validation along with frontend validation, and when issues arise, to encourage the use of backend validation. I don't think he meant not do any form validation with Perl as much as possible. I think that came across wrong, as he later made a comment Then, on the server, check for sanity and security.. I think he was trying to say you should try and have JavaScript as well to reduce calls to the server which is more costly... I could be wrong... You are correct. I was indeed saying that catch as much as possible on the client side using JavaScript. That makes for great user experience instead of round-tripping the erroneous entry. Then, on the server side, do all the sanity checks... what if JavaScript was turned off (although, more and more, that is going to be less and less), what if someone poked your server directly without going through your browser, etc. I am a big fan of jQuery, and try to implement most form entry checks on the browser using jQuery. Ok... back to the original thread... yes, something is worse than tested, complete, compiled modules, but something can also be better than nothing. I'd second the ever qualification on using a hand made regex to replace a real html parser. It simple doesn't makes any sense. Find an html parser that is pure perl, and extend it - I'm sure there are ones out there. I've looked for one, the only one I could find is HTML::TagParser but it isn't suitable as it can't be used to recreate the page. Also looking at the source it uses regexp. As much as the idea of writing a Pure Perl parser intrigues me, I don't have the time :( Especially as at this time I wouldn't actually be using it (my script is generating all the html input tags and parsing them into the html template). Maybe I'll add it to one of my would like to do at some point if I get chance lists... Lyle -- Puneet Kishor http://www.punkish.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
Hi Folks Fortunately I am neither advocating nor desiring a pure-Perl form validation module, but I don't understand the resistance to this. The poor bloke is saying -- look, I have folks who want to utilize my scripts in situations where they cannot compile modules... what do I do? Give them something or give them nothing? I am surprised that there is so much vehemence against this. I don't believe Lyle is saying that a pure-Perl alternative is better or even as good as the compiled modules... all he wants is an alternative, which, while most likely unsuitable for more than the simple cases, is likely a pretty good fit for those simple cases. I heartily agree :) So do I... I'm delighted this thread has gotten various ideas spelled out. To be more specific, I'm not against things when: o The advantages are clear o The disadvantages are understood Many things in like, and in programming, are compromises. What worried me about the regexp approach is that the disadvantages may have been under-estimated. Without even thinking about it, I'm instantly convinced too many special cases would arise to mitigate (lessen, enfeeble) the effectiveness of such an approach /where any reasonable alternative was available/. The problem is not a 'pure Perl' version 'v' an XS version. That's an installation issue, not a quality or design issue. In other words, lack of a compiler is a constraint to be worked abround. The problems are: o A web page can be saved, edited to delete the JS validation, and submitted with malicious data (i.e. corrupt intent), which means server-side is the only place security/data protection issues can be implemented. The client side work, as explained, is for user-convenience, i.e. nice-to-have. o Partial error checking (e.g using a regexp) means end-user pain when things go wrong, as they inevitablly will, and support-staff hassles, including trying the educate the end-user, amongst other things. o Since server-side validation must be done anyway, for any self-respecting claim to a quality package, don't spend time on a partial, client-side, solution. So, weigh up the constaints, programmer time available, priorities, etc, and go for it! -- Ron Savage r...@savage.net.au http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [Fwd: Re: ValidateRM not PP]
On Sun, Jan 25, 2009 at 7:40 PM, Ron Savage r...@savage.net.au wrote: Hi Folks Fortunately I am neither advocating nor desiring a pure-Perl form validation module, but I don't understand the resistance to this. The poor bloke is saying -- look, I have folks who want to utilize my scripts in situations where they cannot compile modules... what do I do? Give them something or give them nothing? I am surprised that there is so much vehemence against this. I don't believe Lyle is saying that a pure-Perl alternative is better or even as good as the compiled modules... all he wants is an alternative, which, while most likely unsuitable for more than the simple cases, is likely a pretty good fit for those simple cases. I heartily agree :) So do I... I'm delighted this thread has gotten various ideas spelled out. To be more specific, I'm not against things when: o The advantages are clear o The disadvantages are understood Many things in like, and in programming, are compromises. What worried me about the regexp approach is that the disadvantages may have been under-estimated. Without even thinking about it, I'm instantly convinced too many special cases would arise to mitigate (lessen, enfeeble) the effectiveness of such an approach /where any reasonable alternative was available/. The problem is not a 'pure Perl' version 'v' an XS version. That's an installation issue, not a quality or design issue. In other words, lack of a compiler is a constraint to be worked abround. The problems are: o A web page can be saved, edited to delete the JS validation, and submitted with malicious data (i.e. corrupt intent), which means server-side is the only place security/data protection issues can be implemented. The client side work, as explained, is for user-convenience, i.e. nice-to-have. o Partial error checking (e.g using a regexp) means end-user pain when things go wrong, as they inevitablly will, and support-staff hassles, including trying the educate the end-user, amongst other things. o Since server-side validation must be done anyway, for any self-respecting claim to a quality package, don't spend time on a partial, client-side, solution. So, weigh up the constaints, programmer time available, priorities, etc, and go for it! Very nicely put. This whole post makes a lot of sense, and should be kept in mind when designing an application. -- Puneet Kishor http://www.punkish.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Data.FormValidator.js [Was: ValidateRM not PP]
Joshua Miller wrote: (and this is coming from the author of Data.FormValidator.js, which the following post recommends). I'm just going through the docs and I've downloaded the script (JSAN site only has 0.06 and not 0.07). The script is almost 70K. Wouldn't it be worth offering a minimal version without all the comments, etc? I just fed it through http://javascriptcompressor.com/ and it shrank to less than 20K (although certainly not as pretty). I get the feeling a lot of people would see the size and jump to compress it like me, and you'd loose all your headers. If you offered a compressed version would could keep your copyright notice and site link at the top. Just an idea :) Lyle # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Data.FormValidator.js [Was: ValidateRM not PP]
Shipping a compressed copy is a good idea. That said, the option is there. You could even use http://jscompactor.berlios.de/ which includes a flag to exclude copyright comments from the compression (Sorry for the self-promotion, and to be honest, there are much better js compactors out there... this is just the only one I know w/ an option to selectively retain comments). I'll make sure to include that in the next release. In other sad news, the JSAN site download server is, and has been for a while, inaccessible to postings - ie. I can't update the version that is there. I've contacted one of the orig JSAN people, and basically, that server is just not maintained any longer. They aren't actively seeking someone to take the reigns, but if someone was fully qualified to do so (hardware, time, resources, and commitment to maintain it), I'm sure they'd appreciate it (anyone looking for a big volunteer project?). I wish I could update it to add a more prominent notice to point people to the berlios site. Oh well, such is life. Thanks, -- Josh I. On Sun, Jan 25, 2009 at 8:46 PM, Lyle webmas...@cosmicperl.com wrote: Joshua Miller wrote: (and this is coming from the author of Data.FormValidator.js, which the following post recommends). I'm just going through the docs and I've downloaded the script (JSAN site only has 0.06 and not 0.07). The script is almost 70K. Wouldn't it be worth offering a minimal version without all the comments, etc? I just fed it through http://javascriptcompressor.com/ and it shrank to less than 20K (although certainly not as pretty). I get the feeling a lot of people would see the size and jump to compress it like me, and you'd loose all your headers. If you offered a compressed version would could keep your copyright notice and site link at the top. Just an idea :) Lyle # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
