cvs commit: modperl-2.0/src/modules/perl mod_perl.c
dougm 2002/06/06 09:45:41 Modified:src/modules/perl mod_perl.c Log: need to run open_logs,post_config,child_init hooks APR_HOOKS_FIRST so they are run before those in modperl_hooks.c Revision ChangesPath 1.123 +3 -3 modperl-2.0/src/modules/perl/mod_perl.c Index: mod_perl.c === RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v retrieving revision 1.122 retrieving revision 1.123 diff -u -r1.122 -r1.123 --- mod_perl.c4 Jun 2002 16:16:50 - 1.122 +++ mod_perl.c6 Jun 2002 16:45:41 - 1.123 -530,10 +530,10 NULL, NULL, APR_HOOK_MIDDLE); ap_hook_open_logs(modperl_hook_init, - NULL, NULL, APR_HOOK_MIDDLE); + NULL, NULL, APR_HOOK_FIRST); ap_hook_post_config(modperl_hook_post_config, -NULL, NULL, APR_HOOK_MIDDLE); +NULL, NULL, APR_HOOK_FIRST); ap_hook_handler(modperl_response_handler, NULL, NULL, APR_HOOK_MIDDLE); -576,7 +576,7 NULL, NULL, APR_HOOK_FIRST); ap_hook_child_init(modperl_hook_child_init, - NULL, NULL, APR_HOOK_MIDDLE); + NULL, NULL, APR_HOOK_FIRST); modperl_register_handler_hooks(); }
cvs commit: modperl-2.0/src/modules/perl modperl_handler.c
dougm 2002/06/06 10:32:51
Modified:src/modules/perl modperl_handler.c
Log:
add support for Perl*Handler +Apache::Foo
Revision ChangesPath
1.11 +14 -0 modperl-2.0/src/modules/perl/modperl_handler.c
Index: modperl_handler.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_handler.c,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- modperl_handler.c 21 Oct 2001 22:11:34 - 1.10
+++ modperl_handler.c 6 Jun 2002 17:32:51 - 1.11
-5,6 +5,20
modperl_handler_t *handler =
(modperl_handler_t *)apr_pcalloc(p, sizeof(*handler));
+switch (*name) {
+ case '+':
+++name;
+MpHandlerAUTOLOAD_On(handler);
+break;
+ case '-':
+++name;
+/* XXX: currently a noop; should disable autoload of given handler
+ * if PerlOptions +AutoLoad is configured
+ */
+MpHandlerAUTOLOAD_Off(handler);
+break;
+}
+
handler-name = name;
MP_TRACE_h(MP_FUNC, new handler %s\n, handler-name);
File-upload problem with netscape and Internet-Explorer
Hello,
I build a simple File-Upload form:
html
form action=test_upload enctype=multipart/form-data method=post
input type=text name=text
input type=FILE name=Tfile accept=*/*
input type=submit value=upload
/form/html
and a script test_upload, which is called from the form:
%perl
my $file = $r-upload;
my $ftype = $file-info-{'Content-Type'};
my $fsize = $file-size;
my $fname = $file-filename;
$m-out($ftype : $fsize : $fname);
/%perl
%ARGS
$Tfile = undef
/%ARGS
With netscape this works well, but with opera and internet-explorer
(tested with 6.0), $r-upload isnt defined? What am i doing wrong here?
Bye, Olaf
Re: File-upload problem with netscape and Internet-Explorer
[EMAIL PROTECTED] wrote:
Hello,
I build a simple File-Upload form:
html
form action=test_upload enctype=multipart/form-data method=post
input type=text name=text
input type=FILE name=Tfile accept=*/*
input type=submit value=upload
/form/html
and a script test_upload, which is called from the form:
%perl
my $file = $r-upload;
my $ftype = $file-info-{'Content-Type'};
my $fsize = $file-size;
my $fname = $file-filename;
$m-out($ftype : $fsize : $fname);
/%perl
%ARGS
$Tfile = undef
/%ARGS
With netscape this works well, but with opera and internet-explorer
(tested with 6.0), $r-upload isnt defined? What am i doing wrong here?
Bye, Olaf
Try:
http://perl.apache.org/release/docs/1.0/guide/snippets.html#File_Upload_with_Apache__Request
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: File-upload problem with netscape and Internet-Explorer
Stas Bekman writes: Try: http://perl.apache.org/release/docs/1.0/guide/snippets.html#File_Upload_wi th_Apache__Request Thats where i got the idea for my script - but it doesnt work for me. Perhaps the $r (im using Mason 1.04 under debian) isnt a really Apache::Request? I use Mason with use HTML::Mason::ApacheHandler (args_method='mod_perl'); Bye, Olaf
Re: separating C from V in MVC
On Thu, Jun 06, 2002 at 12:02:47AM -0600, Rob Nagler wrote: These are the reserve words of TT: [...] Looks an awful lot like the same keywords in any general-purpose programming language. Yep, I agree. You can use it like a programming language and it gives you more than enough rope to hang yourself, or at least get tangled around your feet and trip you up :-) However, the way that I (mostly) use it, and the way that is encouraged in the documentation, is to use it like a programming language only with respect to presentation issues, not application issues. For example, using a FOREACH to calculate some sum of values is probably a Bad Thing, but using it to iterate over a data set and generate a table is a Good Thing. It a presentation loop, not a programming loop. Same goes for conditionals, and so on. Even defining the equivalent of functions or macros. If it's something that generates a presentation element and doesn't have any side effect on the application processing or underlying model then I generally think it's OK. Of course, it all depends on how you defined presentation and programming. But anyway, I'm not defending TT against HTML::Template or any other module because they admirably serve different purposes to different people at different times. TT is most definately not an enforced pure template language. You can use it that way if you like, but you can also use it as a quick, dirty and butt-ugly hacking tool. I construe that to be a good feature of a general purpose templating solution that TT aspires to be. But I also readily admit that too much freedom to Do the Wrong Thing can be a weakness in particular environments. That's why we have different modules. Sometimes you need a hammer, sometimes you need a saw, sometimes you need a socket set. Sometimes you use a wrench to bang in a nail because you can't find your hammer. That's a useful feature of a wrench, even if it's not what it was designed to do. I think the rule is: if you can solve Towers of Hanoi in the language, its general purpose enough. Indeed. And TT was designed to be general purpose enough to solve the Towers of Hanoi. I personally don't use it like that when I'm building web sites, preferring to adopt a much more rigorous coding standard, but there are also plenty of times when I do for small hacks. To solve this problem, we added a letter. bOP is MVCF, where F stands for Facade. Yep, I'm doing something that's roughly similar. Rather than have a facade which presents a collection of backend objects, I'm building what is, I suppose, a composite built from a collection of backend objects. The way our data is structured seems to favour this approach to my current way of thinking, but I will give the facade option some more thought now that you've mentioned it. But I think the concept is the same. You have some object or data structure which represents the collection of all the different components that combine to form one particular configuration of a site. This is our site model, a separate entity from our MVC, similar to your F. There are some basic design rules. Eliminating redundancy is one of them. Eliminating redundancy is another. :-) I don't see how it is an Aspect (in the capital A sense). Only really in the sense that it's an orthogonal dimension in our data space. A degree of freedom, if you like. Something that cuts across a system but needs to be defined in one place (or plane). I suspect you'll find AOP won't be in heavy use in five years except for debugging features. The magic of OO is hard enough to understand, and AOP is really magical. AOP also doesn't solve very many problems. I agree, but I found it useful in the way that it helped me to identify and put a name on a common problem. Once the lightbulb went on in my head and I said Oh, this is like the problem described in AOP then it gave me a direction to tackle it. Why is there so little discussion of the M in MVC? It's far from a trivial problem. Indeed. A
Re: Separating Aspects (Re: separating C from V in MVC)
Ow. That philosophy of 'make it impossible for the programmer to mess up' sounds too reminiscent of Pascal and other straightjacket development environments. I don't think there's any real substitute for well-disciplined, thinking programmers. So my own quest right now is to develop more of the right disciplines, rather continue on some quest for a mythical Template System to End All Template Systems or whatever. For example, you mentioned you don't like objects in templates because they introduce complexity. But others have already pointed out that objects can be used in templates as simple read-only accessors by HTML designers who don't need to know how the object is implemented. That's the great thing about encapsulation. Sure this feature could be abused, but I'd rather err on the side of freedom. --Wes Sam Tregar [EMAIL PROTECTED] on 06/05/2002 06:45:34 PM To: Andy Wardley [EMAIL PROTECTED] cc: modperl List [EMAIL PROTECTED], Template Toolkit List [EMAIL PROTECTED] (bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: Separating Aspects (Re: separating C from V in MVC) Here's my theory: the best usage of most templating systems are virtually indistinguishable and all result in reasonably maintainable systems. However, the bad usage of some templating systems is much worse than others. Also, the general usage of a templating system, even by otherwise bright people, tends more towards the bad than the good. Thus my solution: a templating system that simply will not allow you to put anything significantly complicated in the template. You can't. If you want complexity you'll just have to put it in the code, where it belongs. That's HTML::Template in a nutshell. [% silver.bullet %] isn't the answer by itself... Here here. Neither is tmpl_var silver_bullet but I'd rather get shot with mine than yours! -sam
Re: RPM for apache/mod_perl/mod_ssl
In the spirit of the teach a man to fish proverb (sorry if that's a random reference), maybe I should really be asking what's involved in making such an rpm? Is it a case of just figuring out which files are installed by openssl/mod_ssl/mod_perl/apache and making a big ole spec file, or is there some configuration magic that needs to happen? If this is straying too far off-topic I'll take the discussion off-list, but I really should learn how to do this properly for myself. Thanks, Fran Christof Damian wrote: On Wed, 05 Jun 2002, fliptop wrote: i have an rpm for apache 1.3.22, mod_perl 1.26, and mod_ssl 2.8.5 that i run on redhat 6.2. i'd be glad to give you the .src (or the .rpm if you also run redhat 6.2) if you would like it. or, i could just give you the .spec if you'd like to build a new rpm with the latest versions. i got one for redhat 7.0, i am in the progress to update it to the current versions of apache/mod_perl/mod_ssl though. christof
Re: RPM for apache/mod_perl/mod_ssl
Fran Fabrizio wrote: In the spirit of the teach a man to fish proverb (sorry if that's a random reference), maybe I should really be asking what's involved in making such an rpm? Is it a case of just figuring out which files are installed by openssl/mod_ssl/mod_perl/apache and making a big ole spec file, or is there some configuration magic that needs to happen? If this is straying too far off-topic I'll take the discussion off-list, but I really should learn how to do this properly for myself. it probably is ot, so i'll make this short. a good place to start is http://www.rpm.org/max-rpm/
Re: Separating Aspects (Re: separating C from V in MVC)
Sam Tregar wrote: Now, I don't use HTML::Template::Expr. I think it's generally not such a good idea. But it's there if you want it... For posterity, and possible inclusion in the next rev of the templating tutorial, how would you recommend people handle this sort of situation without using HTML::Template::Expr? Suppose you have a model object for a concert which includes a date. On one page, the designers want to dipslay the date in a verbose way with the month spelled out, but on another they want it abbreviated and fixed length so that dates line up nicely. Would you put that formatting in the controller? What if you had a model object that generates a list of these concerts, and on a certain page the designers want to show it in two columns. Would you split it into two arrays in the controller? - Perrin
Re: tutorials (was: Re: rfc Apache::Dynagzip)
At 03:37 06.06.2002, Slava Bizyayev wrote: It's going to be something like Features of Content Compression for Different Web Clients for Part IV: Client side facts and bugs. We'll be able to discuss details next week. Ok, great Slava, thanks a lot! -- Per Einar Ellefsen [EMAIL PROTECTED]
RE: Doing security for backend applications
Thanks the for info! Where my design was coming from was trying to enforce access control completely outside of application - if a request made it to an application, then the application could be assure that the user was allowed to be there. But I think implementing this would be rather difficult. The solution you suggest is not one I had thought of; I guess letting the application worry about invoking access/authen/authz control is much easier than trying to enforce it at a higher level. All I'll have to do is provide the service (ala Passport) that implements the functionality. Cheers! -klm. -Original Message- From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 4:18 PM To: Ken Miller Cc: Modperl Subject: Re: Doing security for backend applications On Tue, 4 Jun 2002, Ken Miller wrote: [...] So, php application requests would bounce from the proxy server to the mod perl server to the php server. You could also make it so it's only when requests needs to be authenticated they go to the mod_perl server. Something like having the php server forward authentication requests to the mod_perl server; but support the same cookie format would be relatively simple. This is all related to a single sign-on environment - once the user has signed on an encrypted cookie will contain the application security information used to authorize the user int the various applications. at perl.org we have made it so authentication requests gets forwarded, and then we have an internal interface for the various servers can validate and migrate authentication cookies. You should be able to find documentation on how passport.com does it; if nothing else then on the pages where it's described why their implementation was insecure at some point. ;-) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
[OT] MVC soup (was: separating C from V in MVC)
I, like many, find these discussion really interesting. I always wish there was some write up for the mod_perl site when all was said and done. But I guess one of the reasons it's so interesting is that there's more than one correct point of view. My MVC efforts often fall apart in the C an M separation. My M parts end up knowing too much about each other -- typically because of error conditions e.g. data that's passed to an M that does not validate. And I don't want to validate too much data in the C as the C ends up doing M's work. Anyone have links to examples of MVC Perl code (mostly controller code) that does a good job of M and C separation, and good ways to propagate errors back to the C? -- Bill Moseley mailto:[EMAIL PROTECTED]
Re: [OT] MVC soup (was: separating C from V in MVC)
On Thu, 6 Jun 2002, Bill Moseley wrote: Anyone have links to examples of MVC Perl code (mostly controller code) that does a good job of M and C separation, and good ways to propagate errors back to the C? http://pagekit.org,; might be interesting. Fiq
RE: [OT] MVC soup (was: separating C from V in MVC)
Hi Bill -- I, like many, find these discussion really interesting. I always wish there was some write up for the mod_perl site when all was said and done. But I guess one of the reasons it's so interesting is that there's more than one correct point of view. I expect to complete an article on this exact topic in the next month which is scheduled to appear in one of the major Perl-related publications. I'll try to keep my typically unyielding and vitriolic opinions in check. :-) My MVC efforts often fall apart in the C an M separation. My M parts end up knowing too much about each other -- typically because of error conditions e.g. data that's passed to an M that does not validate. And I don't want to validate too much data in the C as the C ends up doing M's work. First off, it is less of an MVC crime to combine your Model and Controller than it is to combine your Controller and View. In fact, on a small application which is not going to be used in a radically different way anytime soon it makes very good sense to do so! Investing in writing reusable code without a (re)use-case in mind is a waste of time and money. Don't build it -- you won't need it! Assuming you have a (re)use-case in mind for your Model, handling errors is pretty easy. If some code calls a method in your model with invalid arguments just throw an exception! Handle errors just like you would in any method! Don't get hung up on the fact that this is the Holy Model. It's just a method. Don't be afraid to croak() if the situation deserves it. This is basic exception handling, and all the usual techniques (or, in Perl, the lack thereof) apply. TTYL, -Jesse-
Re: [OT] MVC soup (was: separating C from V in MVC)
On Thu, 6 Jun 2002, Bill Moseley wrote: Anyone have links to examples of MVC Perl code (mostly controller code) that does a good job of M and C separation, and good ways to propagate errors back to the C? I'm working on my own impelmentation at the moment and am planning to have a mechanism in my unoverridden forms controller subclass which hosts methods which can validate data based on types derrived from the form's input names, together with a set of valid fields. For more complex validation I'm planning on subclassing and overloading these methods. The validation routines get called if there is a '_validate' field and these in turn generate an errors structure which gets fed to the View's view of the model. I have a seed method in my controller which determines the execution order, however what it does is call other seeds in the model layer. If all is cool, it does an internal redirect to the next page as supplied in a hidden field - or determined at runtime. You'll have to excuse me for the mubling, but my face is currently being stuffed full of falafal. :) Try some? Fiq.
RE: [OT] MVC soup (was: separating C from V in MVC)
From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] Sent: 06 June 2002 19:34 To: 'Bill Moseley'; [EMAIL PROTECTED] First off, it is less of an MVC crime to combine your Model and Controller than it is to combine your Controller and View. I disagree - coupling Controller and Model contradicts the fundamental tenet of MVC which is separation of Model from the Controller and View UIs. As I understand it, the main benefit of MCV is that the Model knows the minimal possible about the Controller and View UIs. Most pundits indicate that the only relationship between a Model and View is that of the weakly typed observer pattern. I should point out that the mod_perlish MVC as described so far in these threads is only loosely based on the MVC pattern, which was originally designed for more traditional stateful user interfaces than web browsing. Here are some MVC pages that indicate Models should NOT be closely linked to Controller, and that in fact the relationship between the two user interface components [ie Controller and View] may be stronger. http://ootips.org/mvc-pattern.html And the MVC relationships are covered, esp on page 5 of this http://www.cs.indiana.edu/~cbaray/projects/mvc.html and there are some good pictures on this link http://www.object-arts.com/EducationCentre/Overviews/MVC.htm which also says: 'What we really want, though, is a tight coupling between AM and View but a loose coupling between Domain Model and View' I parse this as 'tight coupling between Controller and View but a loose coupling between Model and View' £0.02 Regards Jeff
Re: Separating Aspects (Re: separating C from V in MVC)
On Thu, 6 Jun 2002, Perrin Harkins wrote: For posterity, and possible inclusion in the next rev of the templating tutorial, how would you recommend people handle this sort of situation without using HTML::Template::Expr? Suppose you have a model object for a concert which includes a date. On one page, the designers want to dipslay the date in a verbose way with the month spelled out, but on another they want it abbreviated and fixed length so that dates line up nicely. Would you put that formatting in the controller? In the script: $template-param(long_date = $long_date, short_date = $short_date); In the template: The long date: tmpl_var long_date br The short date: tmpl_var short_date What if you had a model object that generates a list of these concerts, and on a certain page the designers want to show it in two columns. Would you split it into two arrays in the controller? I'm not sure I understand what you mean. You're asking about how to flow a list between two columns? With vanilla HTML::Template that would requrie a small amount of work in the script. Either there would need to be a column_break variable thrown in at the appropriate place or two separate loops. I think I would prefer the former. In the template that would look like: tabletr tmpl_loop concerts tmpl_if column_break /trtr /tmpl_if td tmpl_var long_date /td /tmpl_loop /tr/table In the script you'd just set the column_break in the appropriate row (or rows for a multi-column layout). Is that a point in favor of scripting in the templates? Perhaps. Of course by limiting the power of template syntax I've made some things more difficult. If simple things should be simple and hard things should be possible then not everything can be simple! -sam
Re: rfc Apache::Dynagzip
On Thu, 6 Jun 2002, Slava Bizyayev wrote: I'd prefer to address it the point where the web server administrator has to fix the Accept-Encoding HTTP header, if one is incorrectly issued by buggy web client. I really like your idea, in a perfect world shouldn't be that fixup :) Ciao, Valerio Valerio Paolini, http://130.136.3.200/~paolini -- what is open-source about? Learn, and then give back
OT: MVC alphabet soup (= MVP?)
and so my research into the world of MCV continues, and suddenly I feel cheated when I discover that the MVC world moved on years ago to something brighter, shinier and newer? MVP - Model-View-Presenter So for us poor folks lagging behind, do any of the MVC pundits have any comments on Model-Vew-Presenter? My uninformed reading leads me to the following intermediate conclusions: The best explanation [and it covers MVC] that I have found seems to be ftp://www6.software.ibm.com/software/developer/library/mvp.pdf It appears to me that the MVC we are discussing in mod_perl is a simplification of the original - an almost stateless remote user interface is somewhat different from the richly interactive GUI apps that MVC was originally designed for. I would guess that there is no need for Views to register as observers with the Models [is there??] etc. Interestingly, most of the limitations of MVC that led to MVP seem to have to do with the interaction of Controller and View, which led to additional intermediate components that IBM call Interactors. Additional formalisations include the addition of Command components with do, undo and redo methods to communicate between the Controller aka Presenter and the Model, and Selection components to identify ranges and selections of data in the Model to be acted upon. All in all, the additions that led to MVP do not seem particularly applicable to web development - it seems to me that a simplified MVC may work better here. Do others concur? Does anyone know of an MVC disseratation similar to the IBM MVP document, that particularly discussed MVC in a web development context?
RE: [OT] MVC soup (was: separating C from V in MVC)
From: Bill Moseley [mailto:[EMAIL PROTECTED]] Sent: 06 June 2002 19:06 To: [EMAIL PROTECTED] My MVC efforts often fall apart in the C an M separation. My M parts end up knowing too much about each other -- typically because of error conditions e.g. data that's passed to an M that does not validate. And I don't want to validate too much data in the C as the C ends up doing M's work. This sounds like an interesting area to explore - I would quite like to get down to some specifics, for example to work through some concrete examples and bounce some designs around. Can we take a real instance where you have a problem, and see if we can develop an understanding? Will you be willing to post some descriptions of [possibly simplified] cases where you want to review your current MVC split? Or should we take a simple example and see what happens? For example, we could model a basic internet banking site - the data strunctures, range of events, presentation etc are simple and generally well understood. We can take the discussion off-line if the list feels it will be too OT. Regards Jeff
RE: MVC alphabet soup (= MVP?)
Hey Jeff -- All in all, the additions that led to MVP do not seem particularly applicable to web development - it seems to me that a simplified MVC may work better here. Do others concur? YES! I would agree whole-heartedly. As I said in my first message on this thread, a pattern is not a panacea. Practical, useful solutions are rarely academically correct. Let's not get caught up in pattern-for-pattern's sake thinking here. If an aspect of someone else's idea (and that's all patterns like MVC are -- someone else's idea!), then TOSS IT! Jettison. Use what works and throw out the rest. IMHO, -Jesse-
RE: MVC alphabet soup (= MVP?)
From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] Sent: 06 June 2002 23:21 To: 'Jeff'; [EMAIL PROTECTED] All in all, the additions that led to MVP do not seem particularly applicable to web development - it seems to me that a simplified MVC may work better here. Do others concur? YES! I would agree whole-heartedly. As I said in my first message on this thread, a pattern is not a panacea. Practical, useful solutions are rarely academically correct. Let's not get caught up in pattern-for-pattern's sake thinking here. If an aspect of someone else's idea (and that's all patterns like MVC are -- someone else's idea!), then TOSS IT! Jettison. Use what works and throw out the rest. Jesse, I see your assertions, and may agree with them, but I am interested to know specifically WHY you think MVC might be more appropriate than MVP, and what parts of MVP are actually [!]cool-for-web concepts. Call me old fashioned, but when I see that a large community of folks have obviously invested much thought and effort into the original Smalltalk MVC and then into MVP. I am reluctant to throw out the baby until I am sure that the water is cold! I too like a 'use what works' approach, but tempered with a bit of 'softly slowly lookee feelee', especially when it comes to fundamental design and approach 8-) Regards Jeff
Re: [OT] MVC soup (was: separating C from V in MVC)
Bill Moseley writes: Anyone have links to examples of MVC Perl code (mostly controller code) that does a good job of M and C separation, and good ways to propagate errors back to the C? I humbly (do believe that ;-) submit http://petshop.bivio.biz Every page contains the control logic which is dynamically parsed from the Task configuration. Here's an example: http://petshop.bivio.biz/pub/products?p=BIRDS The configuration for this task is: [qw( PRODUCTS 500 GENERAL ANYBODY Model.ProductList-execute_load_all_with_query View.products )], The name of the task which is used for all internal linkages is PRODUCTS. The number is a convenience for FormContext, i.e. our closure mechanism for holding state between HTTP forms. The realm is GENERAL, i.e. there is no particular owner. You might have a USER realm or CLUB (group) realm, which have owners. Permission bit is ANYBODY. You can have multiple permission bits, e.g. DATA_WRITEDATA_READ. The rest of the list are items which are executed serially. The syntax is ClassMap.Class. A class map allows you to configure where your models are loaded from. Here's another example: [qw( LOGIN 517 GENERAL ANYBODY Action.UserLogout Model.UserLoginForm View.login next=CART MISSING_COOKIES=MISSING_COOKIES )], The '=' elements (which is not strictly perl, but hey, we all have are inconsistencies ;-) map events to other tasks. For example, if you get a MISSING_COOKIES exception you go to the MISSING_COOKIES task. next=CART says that the next task on an OK on the form is the CART task. All tasks can be found in http://petshop.bivio.biz/src?s=Bivio::PetShop::Agent::TaskId This is all you need to know about the controller if you use bOP. You list your tasks and bOP's Agent does the rest. BTW, the tasks might be executed via e-mail or HTTP or the command line. The controller abstracts this away, too. (We actually removed our Bivio::Agent::Mail implementation, because it made more sense to implement everything via Apache instead of custom servers.) The interface for Views, Actions, and Models is called execute. You'll be passed a Bivio::Agent::Request object which holds the context for the transaction. Rob
OSC early bird and mod_perl T-Shirts
1. http://use.perl.org/article.pl?sid=02/06/06/1810253 gnat writes Early registration for the Open Source Convention (which includes The Perl Conference) ends June 10. You can save up to $750 if you register before then. 2. We want T-Shirts. Is there some kind company to sponsor the mod_perl T-Shirts this year? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Building high load mod_perl/Mason servers
Hi, I just got the chance to be in charge of a very busy website, and its future growth. Currently it is running with PHP on two round robin servers with a separate mysql db server. We are going to be moving to mod_perl, but I am worried about how to keep from getting into the same kind of trap with mod_perl as with PHP. The PHP guys don't know OOP, so we have to code halfway, modules exporter but not OOP modules. It has to be something OOP like without getting too complex at first. The PHP trap is just the horrible require once stuff all over the place and global vars etc. I know lots of people blame this kind of coding on perl geeks, but the PHP stuff I have been seeing is pretty bad with it because the constant thought is must fix current problem wait till later to be pretty but later never comes. Also things like using ten instr functions instead of one reg exp. So I am thinking whatever I do it should fit within an existing framework, something like Mason. But I am confused about what real advatage Mason provides, and how things like source code control would work if we are running lots of servers. Do people use rsync to keep up to date? Say one machine is always the upload point and the rest get synced from that one? I am having a hard time asking really good questions I think because there are so many things I am trying to think out. Thanks for any ideas, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
