Re: [cgiapp] Closing the wiki
Hi Nic, On 12/8/2011 11:31 AM, Nic Zero wrote: I propose we close the wiki to uncontrolled edits for the time-being. Do you propose to allow no edits? Who should be allowed to edit? How long is the time being? As far as I can see, there's no simple revert button, No, it takes 3 clicks instead: 1. press the left-arrow button to view the pre-spammed version 2. press the edit button to see edit the pre-spammed revision 3. press the save button to restore the pre-spammed version But c'mon. It's not really all that difficult is it? It *can* be done with one hand, without lifting it off the mouse (even while eating a sandwich with the other). I con do it on my iphone during a 5 story elevator ride :-) so removing graffiti is time consuming. (I'd rather be coding.) If it's consuming too much of your time, um, don't do it. Don't worry -- someone else here will press the buttons. Feel free to code instead! -dave # 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] Open source applications written using CGI::Application
Gabor Szabo wrote: Hi, Hi Gabor! I was looking for some examples of applications written using CGI::Application that are open source and preferable even on CPAN. Here is what I found: I looked at the wiki: http://cgi-app.org/index.cgi?Examples and I keep wondering. - Krang http://www.krangcms.com/ was last touched 2 years ago (is it still used?) Krang is used (at least by me!) just about every day. Almost all of our clients, most of them publishing companies, use krang to manage their sites. Here is a partial list: http://erlbaum.net/clients/ As Michael Peters pointed out, the site has not been updated as conscientiously as we'd like -- I guess most of us krang users are developers and tend to learn of new releases by monitoring the svn mailing list (cuz we're just hard core like that -- heheh). So I just updated the krang news, changelog and documentation pages on the site so that now you -- and the rest of the world -- can see that the project has not been stalled for years! In fact, we've had about 6 releases since the site was last updated. My bad -- it was just the guy that was supposed to be updating the web site that was stalled for two years :-) Are there any open source CGI::Application based usable applications out there? I think the typical CGI::Application user is a professional web developer, who uses it to implement web apps for their clients' web sites. Such clients typically do not want their apps release as open source. They pay to have custom apps developed for the purpose of *differentiating* their site from their competition -- such custom tailored apps typically may not be released or distributed. SO, while CGI::App is itself a great open source project -- the apps we build with it tend to be proprietary. At least for most of our clients that is the case. Kinda like the Gimp is a great open source image editor, but the images that are edited with it, of course, do not tend to be open released as open source ...but that would be an interesting license restriction, wouldn't it? :-) thanks, -dave # 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] The Zero Barrier (was: Re: Anonymous home page editing?)
Hi Josh (and cgiapp-ers one and all), I wasn't paying attention back when the choice of Wiki software was made, installed (or skinned so nicely!), but the responsibility has fallen to me to host and (occasionally) maintain it. So when we decommissioned our previous server (last year?) and migrated the cgiapp wiki and mailing list (along with the rest of the company's web apps and mail systems) to this new machine, I had to reinstall the Wiki software, which I found was no longer maintained by the authors (at least not on CPAN -- they do seem to have a radically new version that requires a new fangled auto-magical auto-installer, neither of which are on CPAN (nor can be, iirc because it now ships bundled *with* with other CPAN modules) but I wasn't in the mood for radical) and it was also unclear to me whether the next new version was Considered Done yet, so I just got this creaky old wiki working again. In the process I found that about a kajillion spam posts had been added that no one had removed (because no one had noticed), and poking around the wiki docs, I also found that this creaky old version actually had some nice revision control features --- I guess all wikis do -- complete with view-history, a nifty view-diffs button, dead simple roll-back and, of course, email notifications. So instead of trying to fix the anyone can edit problem, I decided to try and fix the no one noticed problem: by telling the Wiki to post to this list each time anyone edits anything, the entire community is gently reminded that the wiki does still exist (perhaps the spammers do our community a small service, in this respect) and we're all nudged to help sweep up around the place. While certainly not an appropriate solution for larger communities, busier wikis or higher volume mailing lists, for us, and for me, this small change has been a big win. While I was initially annoyed that the Wiki change notices just say who and what page (I had toyed with the idea of setting up fully colorized html diffs in the email notices! but my laziness prevailed, as it does) in this case, the sparseness is kind of mysterious and teases me a bit. Each time I see email from the wiki I wonder (albeit mildly) if what changed was some new interesting piece of *content*, or some new spam that I really should delete. Usually, by the time I get around to checking (if ever), someone else has already fixed the spam. This causes the intensity of laziness feedback loop to increase further each time: the less I do, the less I have to do! Woo and hoo :-) So for me, the Zero Barrier to contributing thing -- whether the contributions are writing and posting content, or helping to fight spam -- is definitely A Good Thing. thanks, -dave On 5/14/2011 2:20 AM, Joshua Miller wrote: Is there a reason the home page can be modified by anyone sans- registration and sans-approval? I noticed some spam links were added, and removed them. It's easy enough to remove, but seems like some sort of protection wouldn't hurt (email address registration with captcha, or require manual approval of changes or of users?). It probably doesn't matter a whole lot, since it has low traffic and a small dedicated group. Just felt a bit weird that it was so easy to modify. If the ease of modification (no registration) was shown to actually increase participation significantly, then it'd make sense but I don't see much activity on the site anyway. This is almost 100% a third party opinion, cause I normally just lurk on this list, but if I were wanting to actively contribute, I'd personally have no problem registering and would not be offended if the registration had to be manually reviewed before I could modify pages. Anyway... thank you to whomever does provide valuable content on the site and this list :-) -- Josh I. # 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] testing 1, 2, 3...
Is this thing on? Sorry for the list downage. it needed a: chown mailman ~mailman Seems qmail ignores .qmail control files in home directories that are not owned by their owner thanks, Dan. Whilst yum feels that /usr/lib/mailman should be owned by root, and makes its feelings known during every update thanks, RedHat. -dave # 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] Weird Perl Internal Errors
Hi Jerry, Though off-topic for this list -- DBI appears to be the culprit -- since DBD::* modules usually have XS parts, that's probably where these errors are coming from. You might ask on a DBI mailing list or the appropriate DB Driver list (mysql-devel?) and be sure to include your operating system type and version, perl version, database type and version and the versions of DBI and the DBD driver you're running, and what triggers the error (apache restart? db reads, db writes?? something else?) Most likely you just have to re-install or upgrade your db drivers (e.g. DBD::mysql) hth, -dave On 8/28/2010 11:26 AM, Jerry Kaidor wrote: Hello, I'm getting some errors in my cgiapp-based application that seem to be related to Perl internals. They are produced by the Apache webserver, and are ending up in /var/log/httpd/error_log. There's one of them tacked onto the end of this message. I have no clue as how to even approach this stuff. I did find some mention of such items in the perlguts man page. The first one seems to be saying: There exists a scalar of unknown value. There is a reference pointing to 0x8c64f64 located at 0x8c64f58. (etc) Is there some way for me to get at the symbol table and find out what's at 0x8c64f58? I sure would like to troubleshoot this in some other way than just removing pieces of the app until it goes away Is there a usual cause for such distress in the cgiapp environment? BTW, the app seems to work fine. Thanks in advance, - Jerry Kaidor --- snip - [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] SV = [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] RV(0x8c64f64) at 0x8c64f58 [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] REFCNT = 1 [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] FLAGS = (ROK,READONLY) [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] RV = 0x8c64d28 [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] SV = [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] PVHV(0x8a0a51c) at 0x8c64d28 [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] REFCNT = 1 [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] FLAGS = (OBJECT,OOK,SHAREKEYS) [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] STASH = 0x8703ef8 [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] \tDBI::db [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] ARRAY = 0x8c68680 [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] KEYS = 0 [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] FILL = 0 [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] MAX = 7 [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] RITER = -1 [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] [Sat Aug 28 07:37:21 2010] [error] [client 10.120.102.6] EITER = 0x0 -- endsnip - # 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] Future of the wiki
r...@savage.net.au wrote: Before starting such a project, everyone needs to agree to support the definitive wiki syntax: http://www.wikicreole.org/ Agreed? If you can't even agree on that, forget it. Oh, fine! (deletes his pod-in-progress for Yet Another Mo Better Wiki Syntax) [more suggestions sniped] And lastly, are /all/ existing wikis unacceptable? Yes! If so, why? Because! Um, because they're not based on CGI-App of course :-) Does it matter if we a less-than-perfect wiki, when everything in life is less-than-perfect :-)? My preference would be to use an existing one, since then our efforts can be directed to other things, rather than just reinventing the wheel. You have better things to do than that? The wheels aren't going to reinvent themselves, you know! Seriously, I'd prefer use an exiting Wiki, too, if the goal was just to get some content out there in web editable form. But we already have that. I'm thinking that the development of a cgi-app based Wiki would be an enjoyable activity for the community, and could possibly result in a Wiki that we would not only meet our content publishing and community contribution needs but that would also serve as a best-practices example of what can be built with CGI application. -dave # 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] Future of the wiki
Mark Stosberg wrote: Perhaps the wiki would be more interesting to use if we used a different wiki engine. Kwiki is written in Perl, but certainly never took off [...] There was some interest in building a wiki based on CGI::Application, but that hasn't materialized. I think a cgi-app based wiki would be an awesome idea. I must not have been paying attention when it was last discussed or I'd certainly have volunteered to help with that. But back to the fundamental question: If the wiki was overhauled, would you use it and maintain it more? I definitely would! -dave # 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] Future of the wiki
Hi Gurunandan, Gurunandan R. Bhat wrote: I had offered Mark to port content on the wiki to Movable Type a few months earlier. At that time, Mark had very valid concerns - that MT does not offer key features required of a wiki. But that was MT4 and a re-evaluation of MT after the release of MT5 recently might be interesting. I like MT (2 or 3 years ago) but am not familiar with recent versions -- can it be used like a Wiki? I thought it was strictly blog software. I see TWiki has sprouted a blog plugin - I guess it's only a matter of time before MT grew a wiki-mode :-) -dave # 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] CGI::Application wiki page Examples updated by MarkStosberg
Hi Mark, Mark Fuller wrote: Would it make sense to have a mailing list specific to these wiki page notices? Allowing folks who don't want to receive them could opt out? The idea was that the 315 subscribers to this mailing list are the only people in the world with the slightest motivation to delete spam from the wiki and, since its not a terribly thriving, active wiki, even we members of the cgiapp community don't visit it all that much. So my hope was that by having these messages come to the list would remind people that the Wiki exists, ping them that people contribute to it, and maybe spark enough curiosity that someone checks to see what was edited, and in the process, is able to find and fix spam. It's my last attempt to save the Wiki. If it continues to be used more by spammers than the community, then it is not really worth the time and trouble involved in continuing to operate it. If, as I hope, these messages help spur the community to step up and contribute and help maintain and police the thing, then we'll be able to continue to have a Wiki for the foreseeable future! It's not a big deal. I've created a filter to delete them on arrival. Mark Glad these messages will not continue to annoy you, and I'm sorry if you're not interested in knowing when the Wiki it is updated and helping take out the trash when those updates turn out to be spam. Of course if no one want to see these messages I'll turn them off. I just don't look forward to cleaning out hundreds of spams again, and don't know who will help prevent that, if not this community. -dave # 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] More Kwiki work
Hi Emmanuel, Emmanuel Seyman wrote: * David Kaufman wrote: 2. Installed Kwiki::Diff so we can quickly see what was changed, and (hopefully) change it back easily if it's spam. I'm not seeing this. How does one use it? Yeah, Kwiki's default toolbar icons are kind of tiny and non-obvious aren't they? Click on the Revisions icon, at the bottom of each editable page, and you'll be taken to the previous revision of that page. The button looks like a left-pointing arrow and is in the row of toolbar icons just to the right of the search box (the next-to-last one, between the paper-and-pencil Edit icon, and the RSS icon, that says Revisions in the tooltip when you mouse over it). 2. Once you're looking at a previous revision, you'll see another new button down there, this time on the far right, *after* the RSS icon, called Differences (unhelpfully the icon just looks like a piece of paper), along with some other new icons for navigating revisions (they look like CD-player-style controls: Next, Previous, Last, etc.) 3. When you click on the Differences button, you get a nice side-by-side, colorized diff of the source text of the old version, compared to the next one after it, so you can identify exactly what was changed. 4. You need to be logged in to restore an old version (or to edit anything at all) so if you see You are Anonymous in the left column, click the Anonymous link and enter your WikiName to become Un-nonymous. 5. Then, if you come across a spammed or otherwise defaced page, you can simply navigate back to the old version of the page before it was vandalized, press the edit button and hit Save (or Preview, then Save) to revert the page to back to it's previously pristine and un-spammed condition. Thanks! -dave # 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] More Kwiki work (was: Re: searching on http://www.cgi-app.org/)
Hi Gabor, Gabor Szabo wrote: Great. Thanks! You're quite welcome! some more items I found: clicking on the 'Edit this page' icon at the bottom of the page I get Can't hook Kwiki::Edit::RequireUserName::require_username. Can't find package 'Kwiki::Edit::RequireUserName' The 'Recent Changes' link also gets me to a crash: Can't locate Kwiki/RecentChanges.pm Okay these are fixed now too. Sorry I didn't test very, um, deeply :-) I guess saying cpan install Kwiki doesn't install all the prerequisites, does it? So this time, I found the file: http://www.cgi-app.org/plugins and so, being lazy, I just did this: grep -E '^[^#]' htdocs/plugins | grep -v CGIApp | xargs cpan -i to install all the Kwiki::* modules that it was configured to use. Everything appears to work now (by which I mean: doesn't die). Which reminds me, when when I migrated Kwiki to the new server last summer I found and deleted 425 pages of Viagra spam pages (complete with images!). And just now I removed some evil executable php pages that someone was able to upload somehow -- nice. Apache will not execute PHP file on the wiki now :-) So we could all pitch in help out with spam-tending duties, I've also: 1. installed Kwiki::Notify::Mail so we can get notices sent here to the list whenever changes are made, and 2. Installed Kwiki::Diff so we can quickly see what was changed, and (hopeflly) change it back easily if it's spam. Thanks, -dave David Kaufman da...@gigawatt.com wrote: Hi Gabor, Installed Kwiki::Search, site search working again. Thanks, -dave Gabor Szabo wrote: I just tried to search on http://www.cgi-app.org/ and got and error Can't locate Kwiki/Search.pm in @INC ... Could someone fix it please or remove the search box. regards Gabor # 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] Spam Wars: Episode IV - The Return of the Kwiki
In which the spam pages installed by the PHP malware that was injected by the exploit in the Kwiki are smitten and the Kwiki is then returned to power, although less heroically, by upgrading Scalar::Utils. -dave # 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] Re: simple example of CA, jQuery, Ajax added to wiki
Hi Mark, Mark Stosberg wrote: [...] the wiki is currently returning a technical error page. I've notified Jesse about this now, and when I have am able to remember my password on that machine again, I may be able to fix such issues myself in the future. It looks as if someone was able to exploit Kwiki and upload some PHP-based malware to the server that has been poking around at our box for a few week -- nce. I'm checking for rootkits now. -dave # 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] Proposed new look and branding for cgi-app.org
Mark Stosberg wrote: [...] I'm interested in your feedback before moving forward: http://cosmicsitedesign.com/cgi-app/ The update addresses long standing complaints about the genericness of the name CGI::Application or that the project name includes CGI at all. The words CGI::Application also just hard to create a brand and marketing materials around. So the update emphasises the Titanium name and branding ... The design is very slick and professional, the name is fine for a software product. But I don't think CI::Application needs a brand, or any marketing materials created around it. Those are devices used to increase sales of a product when its inherent value, quality or benefits aren't producing sufficient sales. I'm of the opinion that CGI::Application sells itself just fine, and that any attempt to make it look more like a commercial software product simply makes the marketer come off as deceptive, especially to software developers who know that it is an open source product that has a community of developers who use it, and not a company who merely markets it, standing behind it. Does CGI.pm need better branding, or to remove CGI from its name? -dave, feeling curmudgeoney # 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] Q: Any guidelines for paging thru db records via CGIparams?
Hi Ron, Ron Savage [EMAIL PROTECTED] wrote: Hi Folks [...] it happens I'm using a per_page of 10 (say) to call get_winemaker_iterator(), so the first call returns records 1 .. 10 to the user. What's a good way to display buttons so the user can page forward to get records 11 .. 18, and (later) back from page 2 to page 1? I realize I'm chiming in a bit late here, but... Have you looked at the HTML::Pager module? http://search.cpan.org/perldoc?HTML::Pager Sounds like it does what you're looking for, and being by Sam Tregar, plays well with HTML::Template. -dave # 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] strategies for decoupling HTML::Template
Jason Purdy [EMAIL PROTECTED] wrote: Late chime-in, but my vote: -1 (Not that this is a democracy, but...) I vote no, too :-) HTML::Template, while it annoys me at times, is a small, fast and easy-to-install. Therefore it is an entirely reasonable default templating engine, which you can easily replace. Shipping CGI::App with *no* default templating engine would make it a) harder to install (not easier, as the OP suggests) because new users whould then have to jump through the additional hoops of choosing and then installing a templating engine. And the choosing would lead new users to threads full of religious templating flame-war debates such as this one, which just make choosing that much harder. b) less functional CGI-App would then be missing one of the two design features which (IMO) have made it so successful in the first place: sane and painless templating (the other one being, of couse, sane and painless dispatching). The mechanisms by which one chooses to author and populate one's templates, or define and call one's dispatched run-modes, are easily overridable and have been overiidden many times, in many ways by many people. But each of those people adopted CGI-Application in the first place, I think, due to its ease of use. And only decided to extend it after they become experts at using it. So to me it's just silly to remove of of the strengths, thereby making it *harder* for new users to get started, just because some fraction of the expert users choose to override that feature. c) backwards incompatible I'd have to update, like every web application I've written in the last six years, to make it work with the new version of C::A (which would make me a very unhappy camper). HTML::Template is one pure-perl module file - If that prerequisite is so hard to live with, simply upload your fork to CPAN: CGI::ApplicationNoTemplates (or CGI::ApplicationMyTemplates). Of course, then you'll have to port, or do without, the contributions of the rest of the community of C::A developers. And who knows? Maybe you're right! Maybe a community of developers who prefer to manually add a template engine to each of their CGI Applications will flock to your module. Maybe it will be most of this community and the original C::A will waste away Mozilla-style while new users all adopt the fork, Firefox-style. That's what open source is for, after all ;-) -dave # 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] Welcome to the new server!
If you can read this, the mailing list migration was a success. Welcome to Mailman on Qmail on RedHat ES4. (if not, then not). -dave ___ cgiapp mailing list cgiapp@lists.erlbaum.net http://www.erlbaum.net/mailman/listinfo/cgiapp
[cgiapp] more testings
... ___ cgiapp mailing list cgiapp@lists.erlbaum.net http://www.erlbaum.net/mailman/listinfo/cgiapp
[cgiapp] The Mailing List is moving!
Hi all, We are moving the mailing list to a new server, and also migrating it from ezmlm to Mailman. Expect minor chaos. You should not need to do anything. You do not need to resubscribe. Digest subscribers should still receive the digest version of the list. The list address will not change, and the subject lines will continue to have the [cgiapp] prefix. If you sort or filter your mail based on message headers, you might need to adjust them. If, for instance your system is looking for one of the ezmlm-style headers: Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:cgiapp@lists.erlbaum.net You might need to teach it to look for mailman's List-Id header instead: List-Id: CGI Application cgiapp@lists.erlbaum.net Thanks! -dave - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Returning XML output for AJAX
Hi Bruce, Bruce McKenzie [EMAIL PROTECTED] wrote: What I want to do is return XML (as an Ajax response) to the jQuery Interface library Autocomplete plugin [...] Of the modules on CPAN that could produce this XML structure, which would be *easiest* to use? Do I need to change the headers of the CGI::Application response? Others have answered the first question (I use XML::Simple, too!). But as for your second question, the answer is yes. Regardless of the AJAX framework you use, the xml response must have the Content-Type: text/xml for some browsers to be able to parse it into a full-fledged XML document object (and not simply as plain text). Why do you care? Well, if your code (or your framework) asks for xml it may expect to find the xml document objext in the ajax request's reponseXML property to be able to call DOM functions on it (those same handy functions used in Javascript to traverse the current HTML page document, like childNodes(), nextSibling, getElementsByTagName() and so forth). Google http://www.google.com/search?q=ResponseXML+Content-Type for more on the issues that arise if you try this in various browsers, and don't set your content-type header correctly. hth, -dave - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC: Thumbnail Image Server
Jesse Erlbaum [EMAIL PROTECTED] wrote: How about: HTTP::ImageAbuser Too obscure? Too cute? Kind of black-hat. Could you include a pragma to load the module with: abuse HTTP::ImageServer; # instead of use? As a few others pointed out, most of the WWW:: space is clients, so HTTP:: might be a better place. Also, this will work on non-Apache servers (although, I'd like to make it work particularly well in Apache). So since its not mod_perl or even Apache-specific, I'd guess CGI:: would be the correct namespace so I'd vote for CGI::ImageServer (or ImageTranformer). -dave, ...wondering if Morpher is a word. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC: Thumbnail Image Server
Jesse Erlbaum [EMAIL PROTECTED] wrote:
This application will dynamically create and cache image thumbnails at
request time, among other things. The ultimate goal is a Perl-based
implementation approaching Amazon's image server:
http://aaugh.com/imageabuse.html
That's cool. My favorite features are the overlaying of icons and image
tilting.
I'm looking for feedback in three areas:
1. Is there anything similar?
Here's the only similar mod_perl module I see on CPAN:
Apache::GD::Thumbnail
http://search.cpan.org/~isaac/Apache-GD-Thumbnail-0.03/Thumbnail.pm
As is, though, it's not flexible enough. It only lets you specify
ThumbnailMaxSize as the maximum length or width (whichever is
larger). So it can't give you an image that's constrained properly to
fit within a given *rectangle*, only a square. It also appears to lack
any caching :-(
Here's a PHP app with almost identical functionality goals:
http://www.evolt.org/article/Automated_Creation_of_Thumbnails_With_PHP/20/24498/
Though I'm not terribly fond of its URL-scheme -- too many squigglies!
2. Is this useful / what features would make it more useful to you?
Beyond simply downsizing, I like the ideas of adding pixel borders, drop
shadows and the like. These bells and whistles add a lot of polish.
Among the many thumbnailing modules I see on CPAN,
Image::Magick::Thumbnail::Fixed adds a unique and compelling feature I
hadn't thought of:
*** Fixed-size thumbnails!
http://search.cpan.org/~aroth/Image-Magick-Thumbnail-Fixed-0.04/Fixed.pm
It generates images of the *exact* dimensions you request, rather than
the largest (but inevitably different) size image that will fit *within*
the size you requested. This approach simplifies the use of the image
server a *lot* because the calling pages can then have completely
*static* height and width attributes on their image tags, which improves
their page-load times and avoids the jumpy HTML layouts you get when
you specify the height, just the width (or neither) without having to
add code that checks what size image you actually got *back* in response
to your request.
Since the fixed-size image has to be padded or filled up with empty
space, you do have to add some background-color support to your url
scheme (gifs and pngs could have this added space transparent, but jpegs
dont offer transparency. Of course white would probably be a likely
default and, although this module doesn't seem to do it, borders and
shadows and whatnot could still be added to the inner image.
(Although you didn't ask) Image::Thumbnail looks like a handy backend
image manipulation interface -- it wraps ImageMagick, Imager *or* GD for
the heavy lifting -- now that's flexibility!
http://search.cpan.org/~lgoddard/Image-Thumbnail-0.62/lib/Image/Thumbnail.pm
Essentially, given a particular request's parameters and a source
directory containing high resolution images, images will be
manipulated and returned to the user. This will obviate the need for
laborious graphic production and re-production every time the
high-res versions change.
For example:
http://foo.com/images/bigimage.jpg -- Returns high-res image
http://foo.com/images/640/480/bigimage.jpg -- Returns 640x480
version of same image
Exact URL structure TBD.
*** Real flexible/extensible URL schemes would be important to me. The
pick-a-scheme-and-bake-it-in approach would surely come back to haunt
you (the PHP application above as well as Amazon's complex, bizarre URL
scheme both appear to suffer badly from Weird URL You Cant Change
Syndrome). While graphic designers I've worked with tend to prefer a
*file* naming convention with named sizes such as *_thumb.jpg or
*small_*.gif, we programmers lean more towards more explicit and
structured choices like PATH_INFO (/resizer/x-100/y-200/image.gif) or,
better yet, ?url=parameters that non-programmers wont want to use. So
while I think a simple, obvious, human-readable (probably path-based)
default scheme is definitely a Good Thing, building in hooks that allow
implementors to completely override the way URL's are translated into
image transformation paramters would go a long way, I'd think.
For instance, I'd like to be able to roll my own conf file and subclass
the thing so that in
%directory = (
/foo_[\d+]/ = {
'/_thumb.gif$/ = { x= 100, y= 200},
'/icon_.+.png$/ = { x= 32, y= 32},
'/_hires.gif$/ = { x= 1024, y= 768, fixed=1},
},
# but in:
/bar/ = {
'/(\d+)/(\d+)/.+\.(gif|png|jpg)' = {
x = '$1',
y = '$2',
mime = 'png',
},
}
or something insanely configurable like that. But I don't want to see
all that in your Image::Transformenator, I want to be able to bake it up
and snap it in!
...When the request comes in the high-res
version and the cached thumbnail will be stat'd. If the thumbnail
does not exist or is older than the high-res version, a thumbnail
will be re-created.
If this is to be used for a high traffic site, I'd think that caching
would be best
Re: [cgiapp] RFC: Thumbnail Image Server
Jesse Erlbaum [EMAIL PROTECTED] wrote:
This application will dynamically create and cache image thumbnails at
request time, among other things. The ultimate goal is a Perl-based
implementation approaching Amazon's image server:
http://aaugh.com/imageabuse.html
That's cool. My favorite features are the overlaying of icons and image
tilting.
I'm looking for feedback in three areas:
1. Is there anything similar?
Here's the only similar mod_perl module I see on CPAN:
Apache::GD::Thumbnail
http://search.cpan.org/~isaac/Apache-GD-Thumbnail-0.03/Thumbnail.pm
As is, though, it's not flexible enough. It only lets you specify
ThumbnailMaxSize as the maximum length or width (whichever is
larger). So it can't give you an image that's constrained properly to
fit within a given *rectangle*, only a square. It also appears to lack
any caching :-(
Here's a PHP app with almost identical functionality goals:
http://www.evolt.org/article/Automated_Creation_of_Thumbnails_With_PHP/20/24498/
Though I'm not terribly fond of its URL-scheme -- too many squigglies!
2. Is this useful / what features would make it more useful to you?
Beyond simply downsizing, I like the ideas of adding pixel borders, drop
shadows and the like. These bells and whistles add a lot of polish.
Among the many thumbnailing modules I see on CPAN,
Image::Magick::Thumbnail::Fixed adds a unique and compelling feature I
hadn't thought of:
*** Fixed-size thumbnails!
http://search.cpan.org/~aroth/Image-Magick-Thumbnail-Fixed-0.04/Fixed.pm
It generates images of the *exact* dimensions you request, rather than
the largest (but inevitably different) size image that will fit *within*
the size you requested. This approach simplifies the use of the image
server a *lot* because the calling pages can then have completely
*static* height and width attributes on their image tags, which improves
their page-load times and avoids the jumpy HTML layouts you get when
you specify the height, just the width (or neither) without having to
add code that checks what size image you actually got *back* in response
to your request.
Since the fixed-size image has to be padded or filled up with empty
space, you do have to add some background-color support to your url
scheme (gifs and pngs could have this added space transparent, but jpegs
dont offer transparency. Of course white would probably be a likely
default and, although this module doesn't seem to do it, borders and
shadows and whatnot could still be added to the inner image.
(Although you didn't ask) Image::Thumbnail looks like a handy backend
image manipulation interface -- it wraps ImageMagick, Imager *or* GD for
the heavy lifting -- now that's flexibility!
http://search.cpan.org/~lgoddard/Image-Thumbnail-0.62/lib/Image/Thumbnail.pm
Essentially, given a particular request's parameters and a source
directory containing high resolution images, images will be
manipulated and returned to the user. This will obviate the need for
laborious graphic production and re-production every time the
high-res versions change.
For example:
http://foo.com/images/bigimage.jpg -- Returns high-res image
http://foo.com/images/640/480/bigimage.jpg -- Returns 640x480
version of same image
Exact URL structure TBD.
*** Real flexible/extensible URL schemes would be important to me. The
pick-a-scheme-and-bake-it-in approach would surely come back to haunt
you (the PHP application above as well as Amazon's complex, bizarre URL
scheme both appear to suffer badly from Weird URL You Cant Change
Syndrome). While graphic designers I've worked with tend to prefer a
*file* naming convention with named sizes such as *_thumb.jpg or
*small_*.gif, we programmers lean more towards more explicit and
structured choices like PATH_INFO (/resizer/x-100/y-200/image.gif) or,
better yet, ?url=parameters that non-programmers wont want to use. So
while I think a simple, obvious, human-readable (probably path-based)
default scheme is definitely a Good Thing, building in hooks that allow
implementors to completely override the way URL's are translated into
image transformation paramters would go a long way, I'd think.
For instance, I'd like to be able to roll my own conf file and subclass
the thing so that in
%directory = (
/foo_[\d+]/ = {
'/_thumb.gif$/ = { x= 100, y= 200},
'/icon_.+.png$/ = { x= 32, y= 32},
'/_hires.gif$/ = { x= 1024, y= 768, fixed=1},
},
# but in:
/bar/ = {
'/(\d+)/(\d+)/.+\.(gif|png|jpg)' = {
x = '$1',
y = '$2',
mime = 'png',
},
}
or something insanely configurable like that. But I don't want to see
all that in your Image::Transformenator, I want to be able to bake it up
and snap it in!
...When the request comes in the high-res
version and the cached thumbnail will be stat'd. If the thumbnail
does not exist or is older than the high-res version, a thumbnail
will be re-created.
If this is to be used for a high
Re: [cgiapp] RFC - CGI::Application::Plugin::JSON
Hey Michael,
Michael Peters [EMAIL PROTECTED] wrote:
Hello all,
I've found myself putting some very similar code into my base classes
of late to more easily deal with sending JSON to my Ajax
applications. So of course I thought I should put this out as a
plugin. I haven't uploaded to CPAN yet cause I wanted to see if
anyone had any thoughts about the interface, etc.
That looks great -- I'll use it!
The only suggestion I have about the interface is that maybe it could
allow this:
# add_json_header() is cumulative
$self-add_json_header( foo = 'Lorem ipsum...');
$self-add_json_header( bar = [ 0, 2, 3, 4 ] );
$self-add_json_header( baz = { stuff = 1, more_stuff = 2 });
to also be done like this:
$self-add_json_header(
foo = 'Lorem ipsum...',
bar = [ 0, 2, 3, 4 ] ),
baz = { stuff = 1, more_stuff = 2 },
);
Lookiing forward to playing with it!
-dave
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] blank page printed when using cgiapp_postrun
Hi Octavian,
Octavian Rasnita [EMAIL PROTECTED] wrote:
I have made a program using CGI::Application,
CGI::Application::Plugin::Authentication and
CGI::Application::Plugin::DBH [...]
if I use header_props() in cgiapp_postrun, nothing is printed ...
That method is just:
sub cgiapp_postrun {
my $self = shift;
$self-header_props(-charset = 'ISO-8859-2');
}
I guess there is an incompatibility with the Authentication plugins,
but I don't know how to solve it.
I don't know which plugin(s) are causing the problem (Im still using
CGI::App without any plugins) but I'd use one old-school workaround:
add the following meta tag somewhere in the head of your html
template:
meta http-equiv=Content-Type content=text/html;charset=iso-8859-2
/
hope this helps,
-dave
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] HTML Compression plugin?
Hi Bruce, Bruce McKenzie [EMAIL PROTECTED] wrote: Hi -- I've been enjoying the speed increase for cgi::app applications achieved by CGI::Application::Plugin::CompressGzip. I use CGI::App to generate static web pages with Template Toolkit. Is there a way that's as easy as CompressGZip to get the same kind of performance boost for static HTML pages? I could probably hack something together with Zlib -- but I'd much rather use a plugin or module written by someone else :-) A friend of mine put together a script and a mod_rewrite rule that would copy and gzip static files on the fly (saving them in an alternate document root to cache them) and deliver the compressed versions of the pages from the cache, only until the original file is modified. He did it to lower his bandwidth costs on a high-traffic, realtively static site several years ago, posted it our web host's support forum, and several others started using it and fixing the bugs. If you'd like i can dig it up, and ask if folks are still using (and maintaining) the solution... -dave - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] A new project name for CGI::Application
David Christensen [EMAIL PROTECTED] wrote: Mark Stosberg wrote: We need a project name. [snip list of reasons we're stuck with C::A] For the clients I go after, they have only a passing interest in the technologies I use; they want to know if I can build what they want, how much it will cost, and when it will be operational. +1 to that (except backwards: when, how much and *then* what technology) If your client (or S.O.) seems unimpressed with the flash and dazzle quotient of the name of your application development framework, invite them to hire (or date) a Ruby on Rails or Java Struts programmer and then call you back when they want something that is mature, powerful and works. One that I can say to my significant other without untangling an acronym. I am reminded of the story about an engineer trying to explain the bubbles in carbonated soda to his 3-year old son -- states of matter, aqueous solutions, super saturation, etc. It's better just to say they put the bubbles in at the factory to tickle your nose. I tell my wife that graphic designers make websites, and then I make them *work*. I used to tell her that I was a perl hacker, but then one day she asked why I never hacked *her* any pearls... -dave - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Best practices to keep the robots from shopping ?
Mark Stosberg [EMAIL PROTECTED] wrote: This morning I noticed that robots had been following add to cart links that I created. Oops. [...] But POSTing seems like a pain. Is there an easier way? A sprinkle of JavaScript would do the trick nicely. Here's an equivalent of what I do now: a href=script.cgi?change_state=1img src=add.jpg/a The shortest from here to there might be something like this: img src=add.jpg onclick=window.location='script.cgi?change_state=1' Still not restful, but no robot will even ~try~ to go there... and it's even *less* typing! or, if you really love your anchors, for tabbing or it's focus marquees then (tho I doubt any visitor has ever really cared) you could wrap that image up in a href=javascript: void 0/a tags so it still walks like a link and talks like a link, but doesn't jump-scroll to the top when clicked. To POST, I guess it would be like this: !-- Some extra CSS is also need to surpress the extra space that the form tag adds -- form method=POST action=script.cgi input type=hidden name=change_state value=1 input type=image src=add.jpg /form I wonder if you could post to your query-stringy URL like this, to avoid the hidden input: form method=POST action=script.cgi?change_state=1 input type=image src=add.jpg /form oh, and don't forget to add style=margin: 0 to that form tag so it doesn't introduce any unwanted vertical paragraphic whitespace, if it's a tight design. HTH, -dave Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. --Howard Aitken - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Ruby on Rails and CGI::Application
Owain [EMAIL PROTECTED] wrote: [...] I am going to have a play with Ruby [...] and Ruby on Rails (http://www.rubyonrails.com/) seems to fell rather similar to cgiapp in a lot of senses. I am reading up on Design Patterns and would like to try out Ruby and this seems to be a good way to try. Has anyone on the list had a shot already and what are the main differences? One problem I have already spotted is the likely difficulty of having mod_ruby or ruby installed at an ISP good old Perl is ubiquitous. Yes, that does seem to be the problem with Ruby (on or off of rails). Like mod_perl, finding low-cost hosting is difficult because the Apache module is too powerful to be safely deployed on a shared server. Ruby on rails *can* be run in CGI mode, but even the developers admit the performance is somewhat unbearable running that way. A virtual private server may be useful to you, where you have root control over a simulated Linux or FreeBSD instance that's really running as one of many instances on a (presumably very powerful) shared machine. Interland offers these: http://www.interland.com/vps/ and another provider that comes highly recommended (though I have no direct experience with them) is John Companies which offers both Linux and FreeBSD-based VPS servers: http://johncompanies.com/ These days though, with the prices of dedicated servers from EV1, Rackspace, ServerMatrix, and their ilk falling fairly steadily, I'm not sure if a *real* dedicated machine is much more expensive than a virtual one anymore... Either way, though, you assume the responsibility of installing, configuring, managing and monitoring your mod_whatever-enabled Apache (and everything else running on the box) when you rent a dedicated server, so that affects the cost, features and value in your decision as well, especially for a potentially high-traffic site. hth! -dave - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX
Steve Comrie [EMAIL PROTECTED] wrote:
If you haven't heard of XMLHTTPReqeust aka Remote Scripting aka AJAX
it's basically a way for web pages to communicate with the server and
return information through JavaScript without having to refresh the
page.
You can read more about it here:
http://www.adaptivepath.com/publications/essays/archives/000385.php
and see it in action here:
http://www.google.com/webhp?hl=encomplete=1
[and here] ...SAJAX (http://www.modernmethod.com/sajax/)
[and now the CGI::App port, here] I converted their demo app
to one running on my code using C::A
http://www.unobserved.org/misc/rs/
I invite anyone that's interested in learning more about using AJAX
to take a look at my sample app.
Nice proof of concept, Steve!
I guess this is an (actually old) idea that's seems to have been hitting
critical mass lately (probably due to the clever new acronym!) Just a
few days ago, I was devouring the examples at
http://www.pengoworks.com/workshop/js/gateway/ (the zip code lookup
examples rock!) which actually doesn't use XMLHttpRequest at all, but
rather a hidden IFRAME (because this code is 5 years old). The concept
of non-page-loading web apps has been banging around that long, but I
guess Google Suggest and Google maps have just recently pushed the
technique to the tipping point.
I'm working on app currently that uses JavaScript to load a dozen or so
dropdowns, each of which can grow quite long indeed. One client
populated the thing with so much data that dynamic JS code had swelled
the page weight well past 700K! Fortunately that wasn't as painful as
it sounds since the business users of this (non-public) web app all
enjoy fast broadband connections, but that, the old fashioned way sure
isn't gonna scale!
So Google Suggest has got me thinking about dynamically populating drop
downs as the user types, with only the incrementally defined subsets of
data that they need to see. So I'm really itching to try this out with
CGI::App, too!
But now I'm not sure if XMLHTTPRequest of this hidden-IFRAME hack is the
best way to go. Google maps seem to be using an IFRAME, while Google
suggest uses the XMLHttpRequest {sigh}. I guess it doesn't matter now,
cross-browser-wise. The link below (almost a year old) says that
XMLHttpRequest support has been in IE since IE5, Mozilla since 1.4 and
Safari since 1.2 (and dubs the IFRAME trick a hack):
Apple Developer Connection: Dynamic HTML and XML: The XMLHttpRequest
Object
http://developer.apple.com/internet/webcontent/xmlhttpreq.html
with it's own Appleesque example (loading an RSS feed of your mission
critical I-Tunes)
http://developer.apple.com/internet/webcontent/XMLHttpRequestExample/example.html
and here's another excellent article from the Apple developer
connection, this time a treatment of the hidden IFRAME route, which they
call Remote Scripting.
Remote Scripting with IFRAME:
http://developer.apple.com/internet/webcontent/iframe.html
While, here it is called Round-Tripping:
http://www.glendinning.org/webbuilder/roundTripIframe/
(which sounds more like something we'd rather not admit we did back in
high school...)
But whatever underlying technique is used, this is a Whole New Way of
thinking about developing web apps, and I'm guessing that, now that the
cross browser support is there, we'll be seeing (and building!) a lot of
these.
-dave
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Persistent $app object in mod_perl
Hi Chad, C. Chad Wallace [EMAIL PROTECTED] wrote: I'm thinking of using CGI::Application in a new project with mod_perl [...] The thing is, I just came from changing my use of Template Toolkit from one instance per request to a single instance (per Apache process) being reused across all requests. But now that I think about it, CGI::Application doesn't have anywhere near the startup overhead of Template Toolkit, so I agree the same principle doesn't apply here. You should find that HTML::Template has a much better performance profile than T::T :-) -dave - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Installing for perl 5.6.0
Joel Gwynn [EMAIL PROTECTED] wrote: On Mon, 20 Sep 2004 11:49am, Michael Peters wrote: Well, the only real dependancy is HTML::Template right? So you want it to build some of the dependancies but not all? Or do you want to install Yes, but HTML::Template depends on Test::More, which depends on a few other things, which bring me back to Test::More. I think I just have a sucky perl environment. Just a recommendation: avoid the shared UNIX (actually redhat) accounts on cihost.com. Sounds to me like you have a sucky hosting environment, in *general*. perl 5.6.0 (like just about all dot-zero release of perl) was a fairly buggy and short-lived initial version release. I never use dot-zero releases or perl... It was quickly followed by 5.6.1 which, IIRC was primarily a security and bug-fix release (that you should probably go ahead and allow CPAN to install). The sad thing is that even 5.6.1 is like three years out of date. Perfectly serviceable for simple CGI programming, but what kind of web hosting company hasn't installed bug fixes and upgraded to at least the security release, in several years?? and Gabor Szabo wrote: ...maybe installing a local version of 5.8.5 would be the best way to deal with this :) *shiver* I've already wasted too much time on this as it is. I'm thinking of just switching my client to pair. uh, yeah :-) That would be my suggestion, too! -dave - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Another framework: CGI::Application::Plus
Domizio Demichelis [EMAIL PROTECTED] wrote: Sam Tregar [EMAIL PROTECTED] wrote: I see absolutely nothing in your release that couldn't be done better as a sub-class of CGI::Application. OK, so I had to override the run() method, the new() method, and the param() method, just to start to have what I want (and please don't make me write any single point that is in the doc), but I have to inherit and manage the internal structure, that is not exactly what I need... it is extremely impolite, in my opinion, that while you felt the need to entirely *rewrite* CGI::Application from the ground up, changing each design decision in it to something that you liked better, you then felt the need to name your module with the same. At best, this implies that all you liked about CGI:App was the name. at worst we might wonder if your hope was to attract new users to your module who might mistake it for the real thing that they have heard or read so much about. your name implies that your software *is* CGI::Application but plus something, when in fact your module is *not* CGI::Application at all. it is at best, another approach to the solving the same problem (apparently in the same general way) but lacking experience, testing and -- oh yeah -- users seeking a replacement for CGI::Application. by choosing a similar name for a similar piece of software you appear to be attempting to gain mindshare through deception. by using the name (without explicit permission from the owner) of a well-known, heavily used and (i dare add) well-loved *existing* module, your similarly designed but entirely different module appears to be endorsed by CGI::Application's author (but he has remained, perhaps mercifully) silent, or by the user/developer community of the CGI::Application, but they apparently have not only *not* endorsed it, the community appears at best indifferent, if not outright hostile to it, so far. And after all that overriding it is very silly to have to depend and to be limited to a module that the sub class redefine at 70% is it not then silly to name your module CGI::Application::Plus? maybe you should consider CGI::Application::AlternativeApproach CGI::Application::TheWayIWouldveDoneIt, or simply CGI::YetAnotherApplication Besides CGI::Application is a very simple module (because it accomplish a very simple task), you can rewrite it in a very short time and implement the hooks you need to make your life simpler we are all glad your life was simpler after rewriting CGI::Application to your liking. however you make the life of the original project, it's author and community more *difficult* when you fork a project with neither the author's cooperation, community support or a Very Good Reason. it's open source. hack on it all you like, but when you decide to release something, try asking first what features the users are looking for, or what help the author may *want* instead of presuming that your code is better than what all of us have been using for all this time... I decided to make it compatible with the original CGI::Application because that is already a standard, simple to understand and very well documented interface, so it's a right starting point. a starting point for a competing module, perhaps. I write and publish my modules in the hope that they may be useful to other people. May be I make mistakes as others do, and I am happy to receive constructive criticism, but i don't think that the kind of sarcastic and malicious negative feedback that you used against my work in your last post is polite. the impoliteness you are experiencing is the direct result of the inappropriateness of your behavior. if you want to contribute to the community, listen first and learn what contributions the community values. alternatives to CGI::Application are not what we are looking for and that is apparently all that CGI::Application::Plus is good for. we would all love to hear about the specific ways you think it could be improved, but if you want to convince us that it even *should* be improved, you'll need to prove it. you'll need to show us exactly why each of your ideas are better. we are already using it -- we have already debugged it. it has been around a long time evolving to fit the needs of us, it's users. if you want to *compete* with a project you should at least have the politeness and respect to think up your own name. would anyone be using MySQL if it was named Oracle Plus? ...Besides, it makes smart people think that you are not a so nice person. It makes people think that may be you just feel that your popularity is somehow threaten by my work. no one has attacked you personally -- i'd suggest that you not start slinging mud at this point. it is simply unnecessary and counterproductive. my advise to you is 1) do not attack others, and b) worry about your own popularity Well, I don't know if the name is a mistake. If it is, I'm really sorry. Anyway, I
Re: [cgiapp] How to download a dynamically generated file
Steve Hay [EMAIL PROTECTED] wrote: I would rather do it in one step rather than two, and all inside CGI-Application, if possible. It seems a shame to have to step outside of CGI-Application to achieve something so simple. ... The -attachment parameter [...] would be annoying for PDF files which the browser normally handles by passing to the Adobe Reader. So I prefer not to use the -attachment argument in those headers. The browser will still pop up a Save As... dialogue box anyway if it doesn't recognise the MIME type or has no action configured for it. ...you can print anything you like to the browser as long as (1) you've set the correct Content-Type in the headers (using the -type argument) right. i've used that technique to return excel spreadsheets because i didn't want to save temp files on the server, just feed them directly to the browser. in my case i found that returing a scalar (even a multi-megabyte scalar!) worked perfectly fine for my application. it does seem a bit extreme, but this is not the type of thing one generally needs to do for thousands of concurrent users, hundreds of times per second :-) in low volume situations (password protected admin interfaces, etc.) it Just Works. i've done it in cgi mode and mod_perl mode. is this as elegant as it could be? i agree that it isn't. and often i've wished C:A would let me return a callback coderef instead of a scalar, that C:A would just execute repeatedly, until it, say, returned undef. perhaps jesse will consider such a patch... it certainly seems reasonable to want C:A to accept a file handle as a return value. in fact i believe it was relatively recently that he added scalal refs as allowable return values, in reponse to a few requests here on this list... -dave, putting in my vote for callback support too :-) - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] directory structure and static pages
Andy Taylor [EMAIL PROTECTED] wrote: 1. if you are doing a project with a superclass and several modules, where do you put your templates and how do you organize them? For instance, if /home/ataylor is my home dir, do most people do something like /home/ataylor/project/modules and /home/ataylor/project/templates and put all the templates in one big directory? i learned the way i do development environments from Jesse during my stint at Vanguard, have used this methodology pretty religiously since, and it's served me well. my development environments are always under cvs revision control, so one requirement of this system is a strong separation between what is, and what's not, under revision control. of course, perl modules and templates are always under cvs, while system generated data files, file uploads, and logs are not, but even these non-cvs files have homes in the project's directory structure. i lay out each project under a PROJECT_ROOT directory that contains no files itself, just the subdirectories, with project_name being the the cvs module name, as well: project_name/ htdocs/ modules/ templates/ devdocs/ conf/ bin/ externals/ logs/ the externals and logs subdirectories are where transient data files and apache logs live, but only the directories themselves exist in cvs, no files in these directories are version-controlled. these directories contain just one file in cvs, a .cvsignore file, containing a lone asterisk, to keep just the existence (and name) of the directory in the repository, while keeping the files themselves out of cvs,and local to the installation. bin/ is where i put miscellaneous command-line utilities such as backup scripts, cron jobs and tools for developers to use on a new checkout to say, set permissions on files and initially generate any local conf files. htdocs/ is obviously the apache document root of the site - i don't use cgi-bin directories, as such, outside of the document root, preferring instead to let my instance scripts live in place right alongside the static html pages and images etc. of the site's publicly accessible files. some clients, and other places that i've worked, have insisted on using a cgi-bin outside of the doc-root, and only allowing executable scripts to be invoked from there (using apache's ScriptAlias directive), which is fine and works well also. it just makes the list of subdirectories in the project_root one entry longer :-) modules/ is of course where the perl modules reside, and the templates/ directory contains the html-template files (more below) devdocs/ is just that, development docs, where the database schema and a log of database structure changes (an executable log of SQL DDL statements) is maintained, along with installation notes, and sometimes even tarballs of other software needed to be installed in the project root to setup new dev environments or production sites. having the database structure and it's changes, add-hoc installation notes and original versions of installed modules here, under CVS has saved me much grief. conf/ contains the local environment's configuration files, in particular an apache.conf file (or a relevant subset thereof, such as this site's VirtualHost block). Jesse often made this file an html template, especially in situations where there were multiple development environments, a staging server and a production site, each a cvs checkout and updated directly from cvs. in this case, one would run a script in bin/ after a cvs checkout or update if necessary, to regenerate a local conf file from the template. for a simpler setup i'l often keep a vhost.conf-sample (or .htaccess-sample) in cvs and maintain the corresponding live conf file for it in each environent by hand. but whether the site conf needs to be maintained from a template or by hand, it keeps all the local installation-specific information in one place, so that the virtual hostname, and Apache environment variables defined below, are all that have to be tailored so that the software will have what it needs to locate perl modules, templates, database connections to use, without having to touch the code. in the virtual host conf (or even an .htaccess file) i will typically have: # for perl to find my local modules SetEnv PERL5LIB /path/to/project_name/modules # for C::A and H::T to find my templates SetEnv HTML_TEMPLATE_ROOT /path/to/project_name/templates # for scripts to use as the base dir for data files, uploads, etc. SetEnv EXTERNALS /path/to/project_name/externals # for DBI to find a database connection # DBI_DSN and/or DBI_USER may also be defined here this way, perl scripts can just say: use MyProject::User::Manager; and since PER5LIB points to my environment's own modules directory, apache has already configured my scripts to resolve the relative location of:
Re: [cgiapp] Cookies and mod_perl
petersm [EMAIL PROTECTED] wrote:
sub _GetCookie
{
my ($self, $cgi) = @_;
that's an interesting construct. does it work?
i get the cgi request object from CGI::Application instance, like this:
sub _GetCookie {
my $self = shift;
my $cgi = $self-query;
this has always worked for me, in both exec-cgi, and mod_perl
environments. you might want to try it this way, and see that helps
you. the rest of your code looks fine to me.
-dave
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Weird Error with CGI::App and HTML::Template
Lance A. Brown [EMAIL PROTECTED] wrote... OK. I don't think I'm doing anything too crazy with these modules, but I keep running into problems with this error: [Thu Jun 5 17:59:49 2003] [error] [Thu Jun 5 17:59:49 2003] null: Error executing run mode 'main': HTML::Template : Attempt to set nonexistent parameter '/div' - this parameter name doesn't match any declarations in the template file : (die_on_bad_params = 1) at SwitchManager.pm line 84 Now, I don't have a '/div' parameter anywhere in my code. HTML::Template 2.6 i've run into that error lots of times too. but in every case it turned out to be because i was passing some oddly contrived data structure to the $template's param() function that wasn't doing what i thought it would do. Can anyone offer assistance? maybe. can you post a bit of the relevent code from the general vicinity of line 84? -dave - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Passing data between run modes?
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote (in part):
...I want to pass some data between run modes to maintain state...
[but] the main browser page has
links to several function pages, so I don't have any FORM tags on
the page at all, just links to specific run modes.
... do you just use links like: app.cgi?rm=tool1var=value
i do. i do that a lot, in fact. tho it's not pretty, i'll admit.
one other approach is to add an entire hidden form (or even several
named forms) somewhere on the page which has nothing but hidden inputs
(no submit button or anything), and use a javascript function called
from the link to populate the hidden fields in the appropriate form
and submit it, (which could even have a POST method). this keeps all
the parameter setting logic in the javascript function, frinstance:
head
script
function PostMyHiddenForm(foo_param) {
document.MyForm.foo.value=foo_param;
document.MyForm.submit();
}
/script
/head
body
form name=MyHiddenForm method=POST
input type=hidden name=foo
input type=hidden name=bar value=hardcoded
/form
a href=javascript:PostMyHiddenForm('tmpl_var name=this_one')
Post This One/a
of course, this only works if you're not allergic to client-side
javascript as an application requirement. it has the added advantage
over links that, sometimes you actually so *want* to cause a POST
request from a link, when you want the user to get the are you sure you
want to re-submit? prompt if they hit reload on the resulting page...
like when the request was to create a directory, for instance :-)
hth,
-dave
-
Web Archive: http://www.mail-archive.com/cgiapp;lists.vm.com/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Forms processing
[EMAIL PROTECTED] wrote: ... Thanks for taking the time David. you're quite welcome! did it compile? :-) If there is an FAQ being maintained on CGI::Application, I think David's response belongs in it. why, thank you. but alas, another question that ought to be in the FAQ is: Q: where's the FAQ A: what FAQ? :-p -dave - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
