Re: [cgiapp] CAP Dispatch and encoded backslashes
On 08/06/12 00:41, B. Estrade wrote: On Thu, Jun 07, 2012 at 03:45:15PM +1000, Ron Savage wrote: Hi Brett On 07/06/12 13:42, B. Estrade wrote: On Thu, Jun 07, 2012 at 01:17:12PM +1000, Ron Savage wrote: Hi Brett On 07/06/12 05:37, B. Estrade wrote: I am having an issue with CAP Dispatch that seems to be rearing its ugly head when I send, as part of the route, serialized JSON data. The issue is that I have a value with a backslash in it. I am pretty sure the URL parsing done by Dispatch is splitting on this backslash, but I though that it wouldn't be a problem since it's being sent as an encoded string. When I don't include this one field, it works; when I do, I get a 404 thrown by Dispatch. The documentation says: To get the name of the application module the path is split on backslahes (C/). Clearly (?) it means slash (/), not backslash (\). You are right, it's not the backslash, it's the forward slash. I saw that part in the docs, but I was not sure how to include that in the serialized string; I assumed if it was uri encoded it'd be fine. So the next question is: Does the problematic / get converted to %2f? If so, I'd expect CAD to ignore it. If not, why not? I'm thinking that if not, you'll have to use JS attached to the submit button to capture the value and encode it yourself. It is encoded, and I am using YUI 3's Y.IO to submit a POST request. The whole, serialized JSON encoded is: %7B%22id%22%3A%228734%22%2C%22name%22%3A%22heello%20the%20dog%22%2C%22email%22%3A%22estrabd%40gmail.com%22%2C%22phone%22%3A%22123456%20%22%2C%22phoneext%22%3A%2278%22%2C%22status%22%3A%22inactive%22%2C%22locale%22%3A%22local%22%2C%22isexempt%22%3Anull%2C%22timezone%22%3A%22American%2FChicago%22%2C%22isdevadmin%22%3Anull%2C%22last_modified%22%3A%222012-06-07%2009%3A36%3A05%22%2C%22adminlvl%22%3A%22-1%22%2C%22vendcode%22%3Anull%2C%22username%22%3A%22iamthefrog%40gmail.com%22%2C%22endday%22%3Anull%2C%22administaffid%22%3A%22-1%22%2C%22startday%22%3Anull%7D You'll note the offending character at American%2FChicago. OK. Are you using CGI::Application::Dispatch V 3.07? If so, I'd patch line 8 our $DEBUG = 0; to our $DEBUG = 1; and check the log. What you're looking for is the output of line 660: warn ... I think you'll find the %2F has been de-coded as per the CGI protocol so the code sees a real, live '/'. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] CAP Dispatch and encoded backslashes
Hi Brett On 08/06/12 06:52, B. Estrade wrote: This issue may be rendered moot. I have discovered that I am unitentionally relying on GET-like behavior to pass data during a PATCH method request. I suppose this leads me to ask, is the data in a PATCH request handled the same way it is in a POST? PATCH? If you mean GET, then the answer is no. Data sent via POST is not appended to the submitted URL, as it is with GET. That indeed should be the answer to your problem. Sometimes you'll see docs refer to 'side-channel' or 'out-of-band', meaning the data and URL are sent via 2 separate channels, which is (as I understand it), no more than what I said :-). -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] nginx fastcgi configuration problem for C::A app
Hi James On 02/08/12 15:25, James.Q.L wrote: Hello, I am trying to get a C::A app work in nginx fastcgi environment (debian 6.0) and using spawn-fcgi. Sorry, I use nginx and Debian, but don't use fcgi. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] nginx fastcgi configuration problem for C::A app
On 02/08/12 15:35, Ron Savage wrote: Hi James On 02/08/12 15:25, James.Q.L wrote: Hello, I am trying to get a C::A app work in nginx fastcgi environment (debian 6.0) and using spawn-fcgi. Sorry, I use nginx and Debian, but don't use fcgi. I do use Starman, hint, hint. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] *****SPAM***** Re: nginx fastcgi configuration problem for C::A app
Hi James On 03/08/12 17:17, James.Q.L wrote: thanks. I did try passing along PATH_INFO with that but it doesn't work, as in PERL5LIB etc all passed to my C::A app but just not PATH_INFO. even tried to set it as a string and still no dice.. my temporary workaround is to manually set path_info with request_uri value in my C::A app.. James. P.S sorry for the top posting. yahoo mail just reminds me how crap the new interface is.. Don't forget - On some mailing lists top posting is the norm. And some of us prefer it. TMTOWTDI! -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] uploads
Hi Brett On 11/08/12 08:13, B. Estrade wrote: What is the idiomatic way for dealing with uploads via CAP? I am using CGI::Simple. You might try CGI::Upload or CGI::Uploader. The latter is unsupported. Let us know how it works. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] uploads
Hi Brett On 11/08/12 11:10, Ron Savage wrote: Hi Brett On 11/08/12 08:13, B. Estrade wrote: What is the idiomatic way for dealing with uploads via CAP? I am using CGI::Simple. You might try CGI::Upload or CGI::Uploader. The latter is unsupported. I should mention CGI::Uploader on metacpan.org is V 2.18. My patched version (not online) is V 2.92. You're welcome to have a copy. Also I have a V 2.90_03. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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 status update from the maintainer
CGI.pm with request and response objects. As the CGI.pm maintainer, I could devote another full post to reasons why I don't to be using it in another 5 or 10 years. Details here are still to be determined as well. This is important, and probably why moving to PSGI should be considered if not done sooner rather than later. I think I am not really clear on what change in perspective means. Is it truly a semantic change or is it just a different name? I am somewhat familiar with some of the other new fangled frameworks, but not well enough to know what the difference is between this request/response versus query objects. In brief, the CGI way has been re-thought and replaced. The end result is just request/response of course (what else could it be?), but done again with the knowledge of years of experience with CGI. - The popular and small ::Forward() and ::Redirect() plugins will be merged into the core. Good idea. It would be really nice to merge in some bare bones Authentication and Authorization support - maybe ever by more fully developing CAP's lifecycle. Likewise. It's a pity a standard(!) way of doing this with CAP doesn't seem to have evolved /with the approval of all/. Here are some items I would like to see addressed. 1. scalability - it is unnecessarily awkward to have more than 2 levels of subclassing currently. This statement worries me. Could you please expand. Also, did you look at CGI::Snapp::Demo::Four::Wrapper, which easily wraps CGI::Snapp::Demo::Four. It's specifically a (simple) demo of sub-classing. Direct subclass of CAP uses cgi_init; child of subclass uses setup; anything else must call SUPER::setup. How does this differ from any other class which uses sub-classing? The parent method is either completely overridden or called /and/ partially overridden. Or am I missing something? 3. a more fully developed plugin/event system; I think this goes along with #2 (i.e., a few more hooks), but in addition to this I have always thought it would be useful to have some sort of mechanism through which plugins might be able to query one another. A good example (and actually the main motivation for #2 and #3) are the CAP Authorization and Authentication plugins. The short list of troubles I have had with using these two are: * when used together, Authorization is called before Authentication, making it awkward to handle authorization errors of unauthenticated guests (or maybe Authz assumes an authenticated session); * default behavior of Authz is to query directly the Authorization plugin instance for a username; this works fine in that situation, but there is no clear way for plugin A to make information available to plugin B; There's no doubt they are awkward. I'd argue the underlying CAP structure is sound, and just this part need a bug re-think. 4. more flexibility with the query object...err response object; I've run into some hoops to jump through when I wanted to use CGI::Simple and be able to upload capabilities on or off in a sub class. It'd help if you could expand on this issue. 5. persistence - I would like to say that I'd like to learn more about CAP and the ecosystem in persistent environments. It's my impression that there are some corner cases or funny issues with it. I do not claim this is true, but I think that we can all agree that while persistent environments such as mod_perl are considered old fashioned, I think that they will prove remain relevant amist the tide of alternatives and middleware laden configurations. For me, the ultimate goal would be to use CAP to create a responsive and consistent daemon type application as served by Apache, defined strictly through things like runmodes, plugins, etc. Is PSGI the path to this? Maybe, maybe not. I only use plack (dev) and starman (prod), but I used to use Apache(2)::Registry, with CAP. Is that what you're referring to. Is there something specific which needs to be added? 6*. the last mile - in application frameworks, I am unsure of any that take the finite state machine model to its logical max. This thought may be way out there, but defining things like runmodes only takes you so far. Going a step further, perhaps done through more feature dispatching or routing, it'd be really nice to be able to define the application runmodes in terms of a transition function (e.g., current runmode, input, resulting runmode). In otherwords, support defining an application to the fullest extent possible though some sort of runmode dispatch table annotations. Perhaps you need Mojo after all :-)). *(forgive me this one is out there, and I still have not sat down to figure out what such a capability would look like or value it would actually add) On the contrary - many thanx. We need all ideas to be put out there... -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # CGI::Application community mailing list
Re: [cgiapp] CGI::Application wiki page HomePage updated by MikeTonks
Hi Mike On 06/09/12 18:58, Mike Tonks wrote: Just a note to say I'm pretty sure we don't want these two spam links on the front page of the wiki, but if I've got the wrong end of the stick just let me know. Big game hunter - Shoot on sight! -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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 status update from the maintainer
Hi Brett
On 07/09/12 00:48, B. Estrade wrote:
What I mean is that there are 2 methods that basically do the same
thing. If you have MyApp (ISA CGI::Application), you would initialize
runmodes and whatnot via cgiapp_init. Say you subclass MyApp to get
MyApp::Foo, but want to keep what is going on in MyApp::cgiapp_init;
but you have your own specific MyApp::Foo runmodes. You'd most cleanly
do this by defining MyApp::Foo::setup. Now, what if you want to
subclass MyApp::Foo into MyApp::Foo::Derp, but you have some Derp
specific runmodes. You end up having to redefine cgiapp_init or
setup; in either case, you're going to have to make an explicit call
to SUPER::cgiapp_init or SUPER::setup.
You're limited to 2 generations below CAP if you want to subclass
without explicitly calling on SUPER because you have 2 explicit
methods -cgiapp_init and setup. I am suggesting a way to provide any
number of generations without having to call on SUPER.
Rhesa has replied with one (slightly more complex) way of doing things.
Here is another:
package WebCommon;
use base 'CGI::Application';
sub cgi_init # or setup
{
$self - web_common_init;
}
package WebAPI;
use base 'WebCommon';
sub cgi_init # or setup
{
$self - web_api_init;
}
package WebAPI::Stuff;
use base 'WebAPI';
sub cgi_init # or setup
{
$self - web_api_stuff_init;
}
The 3 new subs can be stand-alone or call each other or call common
code. They can do whatever you think best.
The point is that the sub-class cgi_inits are overridden by the /normal/
operation of CAP, and hence are called at the appropriate time
/automatically/.
Obviously you can call SUPER::cgi_init or SUPER::anything if you wish.
(Sometimes of course calling a super class's method is mandatory. For
instance, with CGI::Snapp, a sub-class must call SUPER::_init($arg), as
in the demo. But that's to initialize object-level variables, having
nothing to do with what we're talking about.)
The problem is that SUPER::* is a way of sharing /all/ the code in the
super class's cgi_init.
If you don't wish to do that, then do as I've indicated above, and just
share none or some of the code via web_common_init etc. You really do
have a variety of ways to work.
Lastly, there is no limit on the depth of nesting possible.
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# 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 status update from the maintainer
Hi Mark On 09/09/12 10:28, Mark Stosberg wrote: - Uses Any::Moose / Mouse. I endorse the Moose API and Mouse brings much of that API to lower resource environments, like the CGI environment where CGI::Application has always performed well. This is tricky. Why is the env low-resourced? And if it is, what's wrong with targeting it with a low-overhead env such as non-Moose? I'm thinking primarily of these environments: - CGI, used in shared hosting accounts where there is persistent option - Automated tests, which like CGI, need to load modules each time. These environments also see non-persistent CGI::App use sometimes: - Cron scripts (I use CGI::App for cron scripts for convenience) - Interactive command-line scripts (I also use CGI::App for some of these which are part of a large website). OK. Good points. I'm not thinking so much in terms hardware. A few years ago I benchmarked the start-up times of various Perl-based web building tools, which would apply to the environments above: http://mark.stosberg.com/blog/2008/11/startup-benchmarks-for-mojo-catalyst-titanium-httpengine-and-cgiapplication.html Since then, hardware has gotten faster, and SSDs are becoming more common. Today I benchmark Mouse taking .05 seconds to load on my laptop. That's price I think is completely reasonable to pay. Without using a timing tool, the difference in indistinquishable from instant. Agreed: .05 sec is nothing. time -p perl -MMouse -e 1 these object layering might incite some sort of religious war. Ultimately, this decision is clearly in the hands of those who do the work. I have my reservations about moving away from Perlish idioms and towards the oop flavors of the week. Any core might be well served by avoiding any sort of meta object sugar over the long haul. I think my overall point is that CAP and what it provides is timeless. The pendulum swings both ways, and it would be nice to see CAP focus on improving its strengths and not trying to do what the other kids might be doing. Just as PSGI Middleware presents a new opportunity for code re-use, Moose/Mouse roles present another alternative to plugins that can be shared between frameworks. For example, methods for logging, database access and config data are all good candidates to be implemented as roles. This is important. See: - Class::Method::Delegate (no dependencies [actually Carp], no bugs) - Role::Tiny (ditto [actually Exporter], 1 bug) - Role::Basic (Storable, 3 bugs) - Moo::Role (various, 2 bugs) - Moose::Role (ditto, 52 bugs) But see what Role::Tiny has to say about Role::Basic. So Moose/Mouse are not actually needed, if smallness is a virtue. I also see that CGI.pm has over 80 open bugs, while Plack::Request/Plack::Response appear to have 2 open bugs in the Plack bug queue that apply to them, with both them appearing to be enhancement requests. The number of bug reports a project has seems to often be driven by popularity. There's also a certain accumulation that comes with age. The comparison above is misleading in any case, as as the small role solutions have just one module or so in the distribution, so those bugs are exactly about roles. The Moose bug queue is for the whole Moose project. Only about 5 or 6 that I see have role in the title of the bug reports. Also consider that CGI.pm has one person committing fixes for the 80+ bugs (for lack of interest from others, it seems), while the Moose project appears to have about 8 maintainers. On it's own, I don't think the general presence of bugs in a bug queue presents a great concern about the quality of project, although specific bugs certainly could. Are there specific bugs with Moose or Mouse roles that you find troubling? Nope. I did not intend the # of bugs to say anything about the relative merits of the modules. It was all about (potential) user education. IMHO Role::Tiny looks like the best choice. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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 status update from the maintainer
Hi Brett On 11/09/12 00:05, B. Estrade wrote: I think what I was thinking of for a more developed plugin system is to provide a way to better manage when plugins are fired wrt hooks. For example, have an after or before type of modifier when registering a callback would be nice. Even better would be a way to easily manage the handler queue associated with each hook. It's not entirely clear to me how to ensure that handlerA will fire before handlerB; I also know from reading the documentation that a class level handler will fire before instance level handlers. This might be by design or just a consequence of the implementation; however being able to control the handler execution order would be useful I believe. I don't mind if you choose to continue with CGI::Application rather than switch to CGI::Snapp, but you should be aware that in the latter's documentation, I went to great lengths to spell out this matter. See/Read for yourself my explanation: https://metacpan.org/module/CGI::Snapp#The-Flow-of-Control HTH. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] Announce CGI::Snapp V 1.02
Hi Folks
A few small changes:
- Add CGI::PSGI to the pre-reqs (Andreas Koenig).
- Change (in Build.PL) configure_requires{Module::Build} from 0.3800 to
0, after adapting advice from Andreas Koenig.
- Roll the source of CGI::Snapp::Plugin::Forward into CGI::Snapp.
See also t/forward.t and t/lib/CGI/Snapp/ForwardTest.pm.
Update docs.
- Roll the source of CGI::Snapp::Plugin::Redirect into CGI::Snapp.
See also t/redirect.t and t/lib/CGI/Snapp/RedirectTest.pm.
Update docs.
Shortly, I'll release new versions of the 4 demos, specifying CGI::Snapp
V 1.02 as the pre-req.
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# 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] Encoding special chars (eg '+') in CGI form data
Hi What general rules do people use when users try (or want) to encode special chars in form data? Use JS to exclude them, or... URLS of such chars: http://webdesign.about.com/od/forms/a/url_encoding.htm https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/encodeURI TIA -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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 SettingDropDownValues updated by BryanSmith
Hi Mark On 26/10/12 02:01, Mark Stosberg wrote: On 10/25/2012 10:51 AM, Brian Wightman wrote: Are we able to block this username (I know it won't be very effective) from doing any type of updates? Perhaps just bit-bucketing them or blacklisting the IP for a period of time? I believe we have, or can have, root access on the server where the site is hosted. So we have some options to block IPs at the OS or Apache level. AFAIK, some ISPs, including Amazon, share IPs among many users, so blocking an IP is contentious. The application could be patched to ban this username as well. Could be done, but then he'd switch. I suggesting disabling edits unless the user name is on a list. Then there's the chance the abuser would see legit edits and impersonate that user... If anyone is interested to work on it, I would be grateful, and see what can done about arranging appropriate access. Mark # 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/ ## #### -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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 SettingDropDownValues updated by BryanSmith
Hi Mark On 27/10/12 01:27, Mark Stosberg wrote: On 10/25/2012 05:58 PM, Ron Savage wrote: Ron, You are right on all points. That brings me to Plan B, which is perhaps over due: Thanx. Start over the wiki using a new platform. It's due for a refresh anyway. I'm sure a lot of the content should use a review for updates, purging and adding, and the design is stale now as well. Are you thinking of a pre-existing system? -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] replace the wiki?
Hi Mark On 30/10/12 07:16, Mark Stosberg wrote: The Mojolicious project just uses the Github wiki system. That's one option to consider. As one of the default maintainers of such a system, I appreciate the outsourcing of this maintenance work to Github, even if it's means the wiki software itself isn't open source. Github does allow the wiki to be accessed as a git repo, which provides a reasonable exit plan if were to become an unsuitable place to host in the future. OK. I just had another look at that wiki, and it looks good, so I'd say just take the decision and switch. We don't need a long discussion about it. Not everything has to be Open Source, or Perl. Think OSes, compilers, web servers, db servers, email servers, etc etc. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] draft version of PSGI::Application published (not the final name)
Hi Mark On 06/11/12 12:21, Mark Stosberg wrote: COMPATIBILITY WITH CGI::Application Official API Changes * Removed dump() and dump_html Of course. * run_as_psgi() is now just run() Excellent. * The cgiapp_ prefix is dropped from method names Excellent. * query() is now req() and new(QUERY=...) is now new(REQUEST=...) I'd go with request(). I see no need to introduce an abbreviation. * Hash keys for new() must now be upper-case now. Ridiculous. Lower case hash keys are the norm throughout Perl. Upper case is SHOUTING. * The delete() method has been removed. Excellent. * The default request object has changed from CGI.pm to CGI::PSGI Excellent. * The default 'start_mode' behavior has changed. This corresponds to Apache's It works!, so excellent. * forward() and redirect() are now in the core. Excellent. * load_tmpl() and html_tmpl_class() have been removed Of course. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] Proposal: Change CGI::Snapp's base class from Hash::FieldHash to Moos (sic)
Hi I am planning to change CGI::Snapp's base class from Hash::FieldHash to Moos (sic). I understand this will cause some disruption to users of CGI::Snapp (if any :-), but there will be a number of benefits. And it's these benefits which has convinced me to propose this. The new CGI::Snapp would jump to V 2.00, to indicate a significant internal change. It's currently V 1.03. Benefits: o Moos is extremely light-weight (as is Hash::FieldHash). o Moos (naturally) supports inheritance, with 'extends'. o Moos supports consumption of roles, with 'with', if you have Role::Tiny installed. It's name says it all. This means, e.g., the internal logger would become CGI::Snapp::Logger, a role. o The Moos syntax is, of course, Moose-like. o Using Moos means if you use a MVC code structure, and were previously having difficulty deciding if you should use Hash::FieldHash or Moose (sic), or similar in your controllers, etc, you could now use Moos there too. This particularly appeals to me, since I've been using Moose in all three, M, V, and C, and the mismatch with Hash::FieldHash has always bugged me. Unifying them has other benefits, since I have some modules which will dove-tail nicely by switching to Moos as well: o Local::Config. This loads a config file per project. It wraps File::HomeDir to load a file using the project's name. o Local::Connector. This uses Local::Config's per project file to wrap DBIx::Connector to create a project-specific dbh. This can then be passed to any code in the project, minimizing the # of dbhs used (if that appeals to you). o Local::Logger, which uses the project-specific dbh from Local::Connector, since my projects all log to a db. The point of these is to be able to drop and create db tables without needing DBIx:Class. Then, constant tables can be populated and exported to HTML and CSV, still without DBIx::Class. Finally, when the tables exist, I can use DBIx::Class itself to generate the source code of the Schema::* modules for use by other classes, e.g. the M and V in MVC. As I type this email, the idea is growing on me more and more. So, if you have any comments, now is the time to speak up. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] Proposal: Change CGI::Snapp's base class from Hash::FieldHash to Moos (sic)
Hi Mark On 21/11/12 12:49, Mark Stosberg wrote: I am planning to change CGI::Snapp's base class from Hash::FieldHash to Moos (sic). I would definitely support using one of the Moose-compatible projects. I am thinking of moving PSGI::Application from Any::Moose to Moo. I just had another look at Moo. I'm undecided so far. I looked at 'Moos' a bit as well. I factored in that Moo has quickly traction and has a number of extensions and users already, while Mouse appears to have lost steam, and Moos appears to have a rather small user base at this point as well. I'll have to investigate the extensions before deciding. Since Moo is comparatively small, it's definitely a possibility. Unifying them has other benefits, since I have some modules which will dove-tail nicely by switching to Moos as well: o Local::Config. This loads a config file per project. It wraps File::HomeDir to load a file using the project's name. o Local::Logger, which uses the project-specific dbh from Local::Connector, since my projects all log to a db. o Local::Connector. This uses Local::Config's per project file to wrap DBIx::Connector to create a project-specific dbh. I'll be interested to see these. In parallel, I've been developing Moose roles for PSGI::App for config file loading, logging and databas access. I'll look at any private data they might contain, and upload them to my web site. A few minutes ago I added Local::Session, to wrap Data::Session. Naturally it uses Local::Connector. What I have now is for Moose and a bit project-specific, but I plan to make CPAN-ready Moo-based variants at some point. Would you support Moo /and/ Moose variants long term? I wouldn't bother myself. Or are you saying the public versions would use Moo? I wrote more about the config role here, and posted a link to some similar code: http://www.modernperlbooks.com/mt/2012/11/the-curious-case-of-the-justifiable-but-slow-singleton.html#comment-1768 Hmm. Perhaps I should write an article too. My Database role integrates with DBIx::Simple currently. Eventually, I would like to switch transactions to use DBIx::Connector as well. Understood. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] Proposal: Change CGI::Snapp's base class from Hash::FieldHash to Moos (sic)
Hi Mark
On 22/11/12 01:25, Mark Stosberg wrote:
What I have now is for Moose and a bit project-specific, but I plan to
make CPAN-ready Moo-based variants at some point.
Just for record, you can't use a BUILD sub with Moo. I'm just trying to
write work-around code now, using the construct:
has x = ();
around 'x' = sub{...}
But it's a pain.
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# 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] Proposal: Change CGI::Snapp's base class from Hash::FieldHash to Moos (sic)
Hi Hmm. Perhaps I should write an article too. I've sent off to chromatic (for publication on perl.com) my 2nd article on lexing and parsing with Marpa::R2, so I've made a start on this new article, which will appear on blogs.perl.org. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] Proposal: Change CGI::Snapp's base class from Hash::FieldHash to Moos (sic)
Hi Mark
On 27/11/12 01:51, Mark Stosberg wrote:
On 11/21/2012 07:46 PM, Ron Savage wrote:
Hi Mark
On 22/11/12 01:25, Mark Stosberg wrote:
What I have now is for Moose and a bit project-specific, but I plan to
make CPAN-ready Moo-based variants at some point.
Just for record, you can't use a BUILD sub with Moo. I'm just trying to
write work-around code now, using the construct:
has x = ();
around 'x' = sub{...}
But it's a pain.
Ron,
I'm confused. The docs imply that you can:
https://metacpan.org/module/Moo#BUILD
Perhaps you mean you can't use one in a Moo Role? I haven't explored
that yet.
My mistake. I got confused between different modules' capabilities.
I've finished the article. I will proof-read it again and post it to
blogs.perl.org this morning.
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# 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 ColorChooserExampleApp updated by MidLifeXis
Hi Brian It's not just the page you edited. Every page is likewise displayed. Is that perhaps deliberate? On 06/12/12 05:14, brian.t.wight...@jci.com wrote: Would someone be willing to take a look at https://github.com/markstos/CGI--Application/wiki/ColorChooserExampleApp, and see where my markdown is hosed? It seems to be losing it in the example templates that look phpish. Thanks, Brian -- Brian T. Wightmanbrian.t.wight...@jci.com Global Data Managementhttp://pdmwebcg.jci.com/ Johnson Controls, Building Efficiency (414) 524-4025 From: cgi...@erlbaum.net To: cgiapp@lists.erlbaum.net Date: 12/05/2012 11:28 AM Subject: [cgiapp] CGI::Application wiki page ColorChooserExampleApp updated by MidLifeXis CGI::Application page http://cgi-app.org/index.cgi?ColorChooserExampleApp edited by MidLifeXis # 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/ ## #### -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] Proposal: Change CGI::Snapp's base class from Hash::FieldHash to Moos (sic)
Hi Mark
See https://rt.cpan.org/Public/Dist/Display.html?Name=Moo
As I said in my last msg on that thread, I'd better re-write the article
:-((.
On 27/11/12 09:00, Ron Savage wrote:
Hi Mark
On 27/11/12 01:51, Mark Stosberg wrote:
On 11/21/2012 07:46 PM, Ron Savage wrote:
Hi Mark
On 22/11/12 01:25, Mark Stosberg wrote:
What I have now is for Moose and a bit project-specific, but I
plan to
make CPAN-ready Moo-based variants at some point.
Just for record, you can't use a BUILD sub with Moo. I'm just trying to
write work-around code now, using the construct:
has x = ();
around 'x' = sub{...}
But it's a pain.
Ron,
I'm confused. The docs imply that you can:
https://metacpan.org/module/Moo#BUILD
Perhaps you mean you can't use one in a Moo Role? I haven't explored
that yet.
My mistake. I got confused between different modules' capabilities.
I've finished the article. I will proof-read it again and post it to
blogs.perl.org this morning.
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# 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] Proposal: Change CGI::Snapp's base class from Hash::FieldHash to Moos (sic)
Hi Mark On 11/12/12 01:13, Mark Stosberg wrote: On 12/08/2012 09:23 PM, Ron Savage wrote: Hi Mark See https://rt.cpan.org/Public/Dist/Display.html?Name=Moo As I said in my last msg on that thread, I'd better re-write the article :-((. The summary I see from there is that in a Moo Role, you should do this: use Moo::Role; not this: use Moo; use Moo::Role, ( which would make the package both a class and a role). In theory. But I found the code won't compile if I /just/ use 'use Moo::Role'. I'll fabricate a sample (again) shortly. I forget now, but I think it was my use of BUILD(), again, which caused problems. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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] Proposal: Change CGI::Snapp's base class from Hash::FieldHash to Moos (sic)
Hi
Amazing. I don't get it get.
On 12/12/12 01:29, Mark Stosberg wrote:
On 12/10/2012 06:05 PM, Ron Savage wrote:
Hi Mark
On 11/12/12 08:38, Mark Stosberg wrote:
On 12/10/2012 04:27 PM, Ron Savage wrote:
Hi Mark
Ah, yes. No 'use Moo', means new() is not generated, so you don't end up
with a class.
And the class-less-ness makes it a problem for putting BUILD in a
Moo::Role?
Yes. The role has a BUILD() from when it was a class:
Can't locate object method new via package Local::Config at
scripts/test.config.pl line 17.
I just tried putting together a Moo::Role with a BUILD method in it, and
it worked... producing the same result as Moose did.
See here:
###
use 5.14.0;
package My::Moose::Role {
use Moose::Role;
sub BUILD { shift-result(in My Role) }
}
package My::Moose {
use Moose;
has 'result' = (is = 'rw');
with 'My::Moose::Role';
}
package My::Moo::Role {
use Moo::Role;
sub BUILD { shift-result(in My Role) }
}
package My::Moo {
use Moo;
has 'result' = (is = 'rw');
with 'My::Moo::Role';
}
use Test::More;
my $moose = My::Moose-new;
my $moo = My::Moo-new;
is($moose-result,$moo-result,
Moose and Moose support BUILD in roles the same?);
done_testing();
###
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# 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 HomePage updated by ronsavage
Hi Joi On 10/01/13 06:29, Joi Ellis wrote: Is there no way you can block that loser from repeatedly vandalizing the pages with his spam? No, but the wiki is currently being transferred to another form, so it matters little. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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 HomePage updated by NickNolte
Hi On 18/01/13 05:35, Mark Stosberg wrote: On 01/17/2013 01:26 PM, Brian Wightman wrote: Ok, I don't plan on plan wack-a-mole with this bozo. Any other easy-to-implement LARTs available until things are fully transferred to the new wiki? Maybe we could put the old wiki in read-only mode? Yes. Just disable updates for the time being. I have not looked into this, but it doesn't seem hard, even if we have to hack it. We just have to disable the update feature and post a notice. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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 HomePage updated by NickNolte
Hi Joi On 19/01/13 09:52, Joi Ellis wrote: LART. I haven't seen that term in years. It's just like old times. ;) I used to have an email address proxied at bofh.org, until my friend got bored with it and stopped running it. I assume you mean the 2nd of these 6 meanings? http://www.acronymfinder.com/LART.html On Thu, Jan 17, 2013 at 3:51 PM, Ron Savager...@savage.net.au wrote: Hi On 18/01/13 05:35, Mark Stosberg wrote: On 01/17/2013 01:26 PM, Brian Wightman wrote: Ok, I don't plan on plan wack-a-mole with this bozo. Any other easy-to-implement LARTs available until things are fully transferred to the new wiki? Maybe we could put the old wiki in read-only mode? Yes. Just disable updates for the time being. I have not looked into this, but it doesn't seem hard, even if we have to hack it. We just have to disable the update feature and post a notice. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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/ ## #### -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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 lease CGI::Application::Plugin::Header
Hi Ryo
Why on earth do you use a '-' prefix on parameters?
That is user-hostile code, like the '--' required on the command line
for (some) apps.
Yes, I know that many, many years ago '--' was used to distinguish
between command line parsers, where the original used '-', but that's a
red herring these days.
On 26/03/13 05:55, Ryo Anazawa wrote:
Hi all,
Thanks for maintaining CGI::Application.
I'll release yet another CGI::Application plugin,
CGI::Application::Plugin::Header, on CPAN soon.
This plugin adds the header() method to your CGI app which helps you handle
CGI.pm-comptible HTTP header properties.
Since header() is compatible with the existing handlers such as header_type,
header_props, header_add,
it will not break your application.
You can use header() as follows:
package MyApp;
use parent 'CGI::Application';
use CGI::Application::Plugin::Header 'header';
sub do_something {
my $self = shift;
my $type = $self-header('-type'); # getter
# setter
$self-header(
-charset = 'utf-8',
-type = 'text/plain,
);
my $header = $self-header; # returns CGI::Header::Props object
}
FEATURE
- You can pass key-value pairs of header props. to header().
Unlike header_props(), header() *merges* the pairs into the existing
header props.
- CGI::Header::Props implements push_cookie() and push_p3p() methods. These
methods behave like CGI::Application#header_add.
- Normalizes property names automatically (-Content_Type - -type), and
so you can specify them consistently.
CAP::Header is still in development. You can download the latest code in the
following repository:
https://github.com/anazawa/p5-CGI-Header-Props
I'm waiting for your suggestions. Patches are welcome :)
Thanks,
Ryo
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# 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 lease CGI::Application::Plugin::Header
Hi Mark But supporting it adds complexity for no gain :-(. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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 lease CGI::Application::Plugin::Header
Hi
On 26/03/13 14:31, Ryo Anazawa wrote:
Thanks for your reply.
I wouldn't use a '-' prefix, too, and so I'll remove the prefix from
SYNOPSIS.
Excellent!
I agree we shouldn't promote it. SYNOPSIS should be as follows:
Excellent!
sub do_something {
my $self = shift;
my $type = $self-header('type'); # getter
# setter
$self-header(
charset = 'utf-8',
type = 'text/plain,
);
}
However, CGI.pm' header() method requires the prefix in some cases:
Yes, that's where the problem starts.
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# 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] Switching CGI::Snapp from Hash::FieldHash to Moo
Hi All I've almost decided to switch the class builder in CGI::Snapp from Hash::FieldHash to Moo. The point of the switch is that sub-classes can then use Moo and Moo::Role. Just before I do I'd like to know how much trouble that's going to be for users (if any :-). -- Ron Savage http://savage.net.au/ # 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] Dispatching with PSGI
Hi Rob On 10/09/14 23:34, Robert Mills wrote: Hi all I'm a long term user of CGI::Application in vanilla CGI environments but now want to make a new project using PSGI/Starman/nginx. As far as I can see I almost have to use CGI::Application::Dispatch otherwise I would need a seperate .psgi instance for each module in my application (right?). Which leads onto my main question, how should I best incoroporate CGI::Application::Dispatch with PSGI? Is CGI::Application::Dispatch::PSGI still the way to go or is there another way now CGI::Application has native PSGI support. Perhaps this will help: https://metacpan.org/pod/CGI::Snapp::Dispatch -- Ron Savage - savage.net.au # 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/ ## ####
