cvs commit: modperl-2.0/src/modules/perl mod_perl.h
dougm 2002/05/31 08:41:11 Modified:src/modules/perl mod_perl.h Log: add some MP_LARGE_FILES_ macros that could come in handy Revision ChangesPath 1.43 +22 -0 modperl-2.0/src/modules/perl/mod_perl.h Index: mod_perl.h === RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.h,v retrieving revision 1.42 retrieving revision 1.43 diff -u -r1.42 -r1.43 --- mod_perl.h19 May 2002 02:26:11 - 1.42 +++ mod_perl.h31 May 2002 15:41:11 - 1.43 -14,6 +14,28 #include modperl_hooks.h #include modperl_perl_global.h +/* both perl and apr have largefile support enabled */ +#define MP_LARGE_FILES_ENABLED \ + (defined(USE_LARGE_FILES) APR_HAS_LARGE_FILES) + +/* both perl and apr have largefile support disabled */ +#define MP_LARGE_FILES_DISABLED \ + (!defined(USE_LARGE_FILES) !APR_HAS_LARGE_FILES) + +/* perl support is enabled, apr support is disabled */ +#define MP_LARGE_FILES_PERL_ONLY \ + (defined(USE_LARGE_FILES) !APR_HAS_LARGE_FILES) + +/* apr support is enabled, perl support is disabled */ +#define MP_LARGE_FILES_APR_ONLY \ + (!defined(USE_LARGE_FILES) APR_HAS_LARGE_FILES) + +/* conflict due to not have either both perl and apr + * support enabled or both disabled + */ +#define MP_LARGE_FILES_CONFLICT \ + !(MP_LARGE_FILES_ENABLED || MP_LARGE_FILES_DISABLED) + #ifdef MP_USE_GTOP #include modperl_gtop.h #endif
cvs commit: modperl-2.0/xs/APR/PerlIO apr_perlio.c
dougm 2002/05/31 08:41:40
Modified:xs/APR/PerlIO apr_perlio.c
Log:
seek is ok if both perl and apr have largefiles enabled
Revision ChangesPath
1.14 +1 -1 modperl-2.0/xs/APR/PerlIO/apr_perlio.c
Index: apr_perlio.c
===
RCS file: /home/cvs/modperl-2.0/xs/APR/PerlIO/apr_perlio.c,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- apr_perlio.c 31 May 2002 02:20:29 - 1.13
+++ apr_perlio.c 31 May 2002 15:41:40 - 1.14
-152,7 +152,7
IV code;
apr_off_t seek_offset = 0;
-#ifdef USE_LARGE_FILES
+#if MP_LARGE_FILES_PERL_ONLY
if (offset != 0) {
Perl_croak(aTHX_ PerlIO::APR::seek with non-zero offset
not supported with -Duselargefiles);
Re: Confusion: Perl/mod_perl ????
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 31 May 2002 4:09 am, Stas Bekman wrote: Actually the new site (which should be released realy soon now) has a nice and easy intro to mod_perl (thanks to Bill Moseley and others who helped): http://perl.apache.org/release/start/index.html So Jeff, you may want to start from this URL first. Also a really good read is Kip Hampton's mod_perl intro on take23: http://take23.org/whatis_mod_perl.xml - -- :-get a SMart net/:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE89xfoVBc71ct6OywRAsluAJ4p7MesbitTOdry4XZWWW/aVp6sGACg1uPe Kc8RbHplc8IJ9AhIoz6zP6w= =vzGh -END PGP SIGNATURE-
Re: Best compile options for perl 5.8 for mod_perl 1.x and 2.x
Steven Lembark wrote: Also worth using large file support if you habitually munge 2GB files. Which is the default on linux. -- Rafael Garcia-Suarez
RE: separating C from V in MVC
From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 22:42 To: 'Ray Zimmerman'; modperl List; Mason List Jesse, thanks for your comments, I found them very interesting. I am comfortable with Perl and Web programming (though previously not the two together) and am about to embark on development of a new product for an ASP, so have considerable interest at this stage of the proceedings. I would like to ask some further questions, please forgive the extensive haircut of your comments: applying a design pattern such as MVC is not a panacea I agree - I much prefer Perlish DWIM dweomer Model: The business logic. Not related to the UI at all. View: The user interface. Controller: The glue between the View and the Model. ... the Model is simply a Perl module... make it entirely separate from the user interface... the methods... being called from a web application, a cron script, or an email-based interface Makes sense, in old-style speak [yes, I am approaching 'Ancient of Days' status] this seems to indicate the Model accepts method calls and returns data that will be rendered elsewhere. In our planned development, there is a LOT of tabular data - do you use any standards for the data being returned to the Controller? eg do you use a struct [ie hash/array Perl primitive] or do you return an object? eg a table object etc? The View, in a web application, is really the HTML output. Sounds good, so I could also pass the Models returned data to a different flavoured rendering view eg PDF, Spreadsheet, Text etc. This sounds a lot like our existing Perl reporting infra which does exactly that. W3 did a huge amount of analysis on layout and style as part of the CSS specs. In our setup, the table objects contain lots of style info. It is easy to render complex tables in PDF [as HTML will be] but formats like Excel are very hard, as there are layout constraints [eg a column can have only one width for the entire page - we call this the 'Highlander Effect'] Is this true of your setup? does the Model returned data contain lots of style hints? Or do you leave this completely to the View layer? How does the view layer know for example to render an Error cell as RED in HTML but blue in Excel due to Excel palette limitations? Optimally, the View avoids *ALL* application logic. - so the Model has to say RED rather than ERROR? but that wouldn't work if rendering something where RED is illegible? Our reporting knows about basic things like Error, Good, User Date / Numeric preferences etc. At my company we use HTML::Template ... it's damn fast, too will look at this - is there a list somewhere? The Controller connects the View to the Model... takes user input ... translates it into method calls on the Model... then takes output from the Model and passes it to your View. Sounds like Controller only interacts with one Model? I would assume that a Controller might collect data from a number of Models, and then pass the collection of data to a View? What controls the overall layout? e.g. what is the equivalent of the 'Grid Bag' layout manager - is this done in the Controller? and then passed to the View with all the data from a set of Models? Or do you make the Controller minimalist and have a meta-Model that assembles all the sub-Models into a layout. CGI::Application modules will do some reading on this also then. separating the View from Controller is a problem. I guess this is a balance between purist and DWIMism, but as we already have this separation for reporting, I would like to extend it into our dynamic web page generation. If you have to work with an SPS such as Mason but you still want to separate your View from your Controller, you have to work twice as hard. Interesting! Jesse, I found your posting extremely useful - thank you very much! Regards Jeff
RE: separating C from V in MVC
From: Jeff AA [mailto:[EMAIL PROTECTED]] Hiya, my 2 pence worth: status] this seems to indicate the Model accepts method calls and returns data that will be rendered elsewhere. In our planned development, there is a LOT of tabular data - do you use any standards for the data being returned to the Controller? eg do you use a struct [ie hash/array Perl primitive] or do you return an object? eg a table object etc? Your M and V need a protocol to exchange data irrespective of what the V is (email / text, HTML, XML). Is this true of your setup? does the Model returned data contain lots of style hints? Or do you leave this completely to the View layer? How does the view layer know for example to render an Error cell as RED in HTML but blue in Excel due to Excel palette limitations? The M should signal errors, and then the V should format them as per V formatting rules. Optimally, the View avoids *ALL* application logic. - so the Model has to say RED rather than ERROR? but that wouldn't work if rendering something where RED is illegible? Our reporting knows about basic things like Error, Good, User Date / Numeric preferences etc. I would suggest the M reports an error, not red, and then the V formats it - possibly in red, depending on its formating rules. At my company we use HTML::Template ... it's damn fast, too will look at this - is there a list somewhere? HTML::Template has a list, although it is very simple and there was little trafic last time I looked. Greg This message and any attachment has been virus checked by Pfizer Corporate Information Technology, Sandwich.
Re: DBI error_log Logging
Cees Hek wrote: Quoting Jayce^ [EMAIL PROTECTED]: I've been researching the different modules for pushing your access log to a dbi storage vs. local file and have one question which I'm not sure any of them are able to do yet. Perhaps somebody has already thought of this and I'm just not seeing the answer (very likely). I need to log my error_log entries also, not just the access log. For a non mod_perl way of dumping error_log into a DB just use the standard Apache ErrorLog directive with a pipe: ErrorLog | /usr/local/apache/bin/error_logger.pl oh, yeah :) along those same lines, I forgot to mention Apache::LogSTDERR, which is similar I suppose (though I've never used it). additionally, if you are only interested in your own log statements and not errors thrown by mod_perl or Apache proper, then you can also try Apache::LogFile or Log::Dispatch (which is DBI friendly IIRC). HTH --Geoff
'Apache::Session' using REMOTE_USER as key
Hi,
I would like to implement sessions using only $ENV{REMOTE_USER} as the
session key as described on page 259 (Ch. 5) of the Eagle book.
I'm trying to use Apache::Session::MySQL. Since I'm generating my own
session key outside of Apache::Session (using $ENV{REMOTE_USER}), what
method(s) do I have to override to prevent Apache::Session from trying
to create a session key for me? Since I'm not using Apache::Session's
key generation capability, is there another implementation that would be
more appropriate for my application?
(Sorry, if this is OT.)
TIA,
Brian
Re: Persistent Net::Telnet Objects
French, Shawn wrote: Recall that I am using: Apache/1.3.20 (Win32) mod_perl/1.25_01-dev mod_ssl/2.8.4 OpenSSL/0.9.6a on Windows 2000 with PHP 4.21 Would this be why my scripts are working? Mystery solved! Yes, that's why. You are running mod_perl in single process mode because you're on Windows, so only one request is handled at a time. That means that every user will always return to the same Apache process, since there is only one of them! Does this mean that as long as I stay with windows I will be alright? For certan definitions of alright, yes. It won't be speedy if you start getting many concurrent requests. - Perrin
Re: Persistant references [was] Persistent Net::Telnet Objects
First, there is no way to effectively pass compiled code between
processes at this time. It isn't likely to happen with Perl 5 because
attempts at loading compiled bytecode from disk have usually had poor
performance and other issues.
Second, what you're proposing is probably not a good idea unless this is
for a small in-house project.
What I mean is, if a request comes in for a certain form I would like to be
able to do something like this:
my $form = load_form($r);
$c{$session_id}-{handler} = $form-{handler}; # -- this being a code
ref...
$r-send_http_header;
print $form;
Then when the user completes the form and resubmits:
my $handler = $c{$session_id}-{handler};
$r-send_http_header;
print $handler-($r);
What if the same user has multiple browser windows open and starts on a
new form before finishing the existing form? Remember, sessions are
global to all browser windows.
The right thing to do here is pass the form data the old-hasioned way,
in URLs or form fields. Those are distinct for each browser window.
I would like to be able to dynamically create anonymous
subroutine handlers based on input and have them be active until the form is
submitted, at which time they are used to process the form then discarded.
But why go to all that trouble, generating subroutines on the fly? It
just doesn't seem necessary for processing form input.
- Perrin
Re: separating C from V in MVC
Jeff AA wrote: do you use any standards for the data being returned to the Controller? eg do you use a struct [ie hash/array Perl primitive] or do you return an object? eg a table object etc? HTML::Template requires you to pass a perl data structure. Template Toolkit can handle objects as well (i.e. automatically call their accessor methods to fetch properties). Passing perl structs is faster, while passing objects allows for some additional tricks, like lazy-loading data in Class::DBI objects. (Class::DBI is a module for modelling database data as objects.) For more background on templating tools, see my article here: http://perl.apache.org/features/tmpl-cmp.html does the Model returned data contain lots of style hints? Or do you leave this completely to the View layer? Ideally you should have no style information at all in the model. How does the view layer know for example to render an Error cell as RED in HTML but blue in Excel due to Excel palette limitations? You have different views for different targets. Make an HTML view and an Excel view and have the controller know which one to use. Optimally, the View avoids *ALL* application logic. - so the Model has to say RED rather than ERROR? Just the opposite: the model provides the list of errors, and the view knows how to display them. Sounds like Controller only interacts with one Model? The model might be made up of dozens of different classes, but it's still referred to as the model as in the application's data model. What controls the overall layout? The view. e.g. what is the equivalent of the 'Grid Bag' layout manager - is this done in the Controller? and then passed to the View with all the data from a set of Models? Or do you make the Controller minimalist and have a meta-Model that assembles all the sub-Models into a layout. I don't know what a Grid Bag is, but the idea is pretty simple: - Controller looks at input and decides which model objects to call. - Controller calls some methods on model objects. - Controller picks a view and passes data from model objects to it. I wrote about this in my article on the eToys system: http://www.perl.com/pub/a/2001/10/17/etoys.html - Perrin
Re: DBI error_log Logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 along those same lines, I forgot to mention Apache::LogSTDERR, which is similar I suppose (though I've never used it). Any idea where I can find this one? Searching CPAN doesn't give me anything. Jayce^ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE896mgoTgdT9hhlCIRAuquAJ438twVFUW4ngfwOYuN0cCe+cT2PQCgg0px 0Sf3NEcRYmSJDOQXaAap1rg= =YUEd -END PGP SIGNATURE-
Re: DBI error_log Logging
Jayce^ wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 along those same lines, I forgot to mention Apache::LogSTDERR, which is similar I suppose (though I've never used it). Any idea where I can find this one? Searching CPAN doesn't give me anything. http://www.modperlcookbook.org/download/Apache-LogSTDERR-0.12.tar.gz but I thought Paul uploaded this to CPAN already... --Geoff
RE: separating C from V in MVC
Hey Jeff Perrin -- HTML::Template requires you to pass a perl data structure. Template Toolkit can handle objects as well (i.e. automatically call their accessor methods to fetch properties). Passing perl structs is faster, while passing objects allows for some additional tricks It's the addition tricks which bug me out. With those two words you establish the mother of all slippery slopes to architecture oblivion. When you have objects passing freely between your Controller and View (which are quoted here, 'cuz I don't think they are separate in this case), how do you decide where to put a particular bit of code? The answer is, it is completely arbitrary. In the architecture you describe it is inevitable that given enough time and different programmers your Controller and View will coalesce into a undifferentiated mash of code and HTML, separated only by the fact that they are in two different files. Sooner or later someone will get smart and move what little code remains in the Controller into the View, and get rid of the Controller altogether. Now you're back to square one -- old school CGI script-style web apps, a la 1996! IMHO, any system built on Template Toolkit (unless it is small and always managed by the same programmer) will ultimately devolve in just the same way as a Server Page system. HTML::Template isn't just faster than just about everything else out there -- it also is pretty much the only templating system which has an actual clear vision when it comes to how it fits into the larger architecture. does the Model returned data contain lots of style hints? Or do you leave this completely to the View layer? Ideally you should have no style information at all in the model. Absolutely. The Model really just features functions and methods. Does localtime() provide style hints? Of course not. Neither should anything which is designed to be a Model function. Optimally, the View avoids *ALL* application logic. - so the Model has to say RED rather than ERROR? Just the opposite: the model provides the list of errors, and the view knows how to display them. I think the Model methods would throw exceptions like any normal programming interface. How those exceptions are relayed to the View (e.g., list of errors, Internal Server Error, etc.) is the job of the Controller. Sounds like Controller only interacts with one Model? The model might be made up of dozens of different classes, but it's still referred to as the model as in the application's data model. To further elucidate -- the Controller would not dynamically select a different Model depending on what it is doing, as it may select a different View depending on what it is asked to do. Unless it does. :-) Warmest regards, -Jesse- Jesse Erlbaum, CTO Vanguard Media http://www.vm.com 212.242.5317 x115 [EMAIL PROTECTED]
RE: separating C from V in MVC
From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: 31 May 2002 16:27 Perrin, fab feedback as ever, I think I am almost at the 1,000 thanks for Perrin level 8-) - oh, and 1,000 apologies too, for all the questions you've answered before! I hope you don't mind me pestering you with yet more MVC questions! For more background on templating tools, see my article here: http://perl.apache.org/features/tmpl-cmp.html Very interesting, and obviously more to look into... describes the Pipeline model as more MVC. Ideally you should have no style information at all in the model. Ok - but based on my experience with our reporting system which currently renders in PDF, Excel, Text and HP-PCL, the rendering engine aka View needs to know a little more... For example to render a date in Excel some jiggery pokey is required, and I would also expect a HTML V to print pretty dates rather than 20020531172534 (or something other than the raw stringification) We also deal with lots of numerics - some are quantities, and others are values or interest rates - they need zero, 2 or 4dps when being presented. And don't forget the 1,000's separator - I want real Excel numbers, that users can SUM() but which are presented as commified, whereas the HTML V will have to commify the numerics itself. How does the view layer know for example to render an Error cell as RED in HTML but blue in Excel due to Excel palette limitations? You have different views for different targets. Make an HTML view and an Excel view and have the controller know which one to use. This was more a question about how a View would decide to render a style like OVERDRAWN / ERROR rather than which view to use - ie the same as the issue above about working with more than strings. the model provides the list of errors, and the view knows how to display them. Apologies, my use of the word ERROR has confused folks. I was not talking about errors that occurred in the model processing, but rather about more advanced STYLES that might be applied to an element (eg a cell in a table) for some business reason. So for example if your savings balance has gone negative, the value should be rendered as an error balance rather than a normal balance. In HTML you might choose to display the cell with a RED background, but this does not work in Excel, where a RED background prints as black, so you can't just tell the view RED - you need to tell it the reason and let Excel choose one of its limited bg colours. The model might be made up of dozens of different classes Ok - so results from a collection of models are assembled and passed to the view. What controls the overall layout? The view. e.g. what is the equivalent of the 'Grid Bag' layout manager - is this done in the Controller? and then passed to the View with all the data from a set of Models? Or do you make the Controller minimalist and have a meta-Model that assembles all the sub-Models into a layout. - not sure if I like this. I thought the whole point of the View was to contain all the logic about things like HTML tags or Excel binary representation etc, and as little as possible about other things. Layout man agent is a problem that has been isolated in other langs - the Grid Bag layout manager is an [old!] Java class that manages the interaction of collection[s] of widgets and sub-forms on a screen and is esp. useful when screens can be dynamically resized, and controls, text etc will flow / realign / resize and generally shuffle about. In HTML things like the WIDTH=100% attribute of a table or TD are directives to the HTML layout manager implemented in browsers. The layout manager is usually concerned with several elements of the interaction of a collection of things - alignment, flow and sizing. Exactly where in the MVC world, would I decide that column 3 which contains a description should expand to fill 70% of the available space and that column 5 which contains a possibly long name should use the remaining available space, whilst column 1 which contains a name should not be wrapped? I think of a layout manager as a collection of hints to the V on how all the bits should be fitted together in relation to each other. I want my various Vs to be supplied data from the same set of Models - but don't forget that the PDF V will not support scroll-bars! Poor ol PDF-V will have to intelligently render data that does not fit within the width of the users selected physical page width! I guess I have talked myself round to thinking that the Controller is actually the layout manager, in that it marshals results from a set of models, decides how this collection should interact, and then asks an appropriate View to render the result in a specific interface flavour. Have I talked myself out of HTML:Template route? Not sure, I guess it depends on whether HTML::Template can be smartened up to understand that I want Dates rendered in a pretty format,
mod_perl 1.99_01 installation problem
1. Problem Description: * WrapXS/APR/Lock/Lock.c fails to compile. See the cut and paste at the end (3). * CC seems to be looking for libperl.(so|a).5.6.1 in /usr/lib/perl/5.6.1/CORE/, but Debian seems to put libperl.so.5.6.1 in /usr/lib. This doesn't seem like a mod_perl installer bug, but never having fiddled with the libraries, more people should encounter this, erm, feature :) A simple symlink from /usr/lib/bla to the CORE directory seems to fix this one. -L/usr/lib doesn't (unsurprisingly) work. 2. Used Components and their Configuration: *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APXS = /usr/local/apache2/bin/apxs MP_CCOPTS = -L/usr/lib MP_GENERATE_XS = 1 MP_INST_APACHE2 = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 *** /usr/local/apache2/bin/httpd -V Server version: Apache/2.0.36 Server built: May 30 2002 16:16:31 Server's Module Magic Number: 20020329:1 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/usr/local/apache2 -D SUEXEC_BIN=/usr/local/apache2/bin/suexec -D DEFAULT_ERRORLOG=logs/error_log -D SERVER_CONFIG_FILE=conf/httpd.conf *** /usr/bin/perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.13, archname=i386-linux uname='linux duende 2.4.13 #1 wed oct 31 19:18:07 est 2001 i686 unknown ' config_args='-Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.6.1 -Darchlib=/usr/lib/perl/5.6.1 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.6.1 -Dsitearch=/usr/local/lib/perl/5.6.1 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Duseshrplib -Dlibperl=libperl.so.5.6.1 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-DDEBIAN -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.4 (Debian prerelease)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -ldb -ldl -lm -lc -lcrypt perllibs=-ldl -lm -lc -lcrypt libc=/lib/libc-2.2.4.so, so=so, useshrplib=true, libperl=libperl.so.5.6.1 Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Jan 11 2002 04:09:18 %ENV: PERL_LWP_USE_HTTP_10=1 INC: /usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/lib/site_perl . 3. This is the core dump trace: (if you get a core dump): Compile error instead: cc -c -I/usr/src/apache/apache-2.0/mod_perl-1.99_01/src/modules/perl -I/usr/src/apache/apache-2.0/mod_perl-1.99_01/xs -I/usr/local/apache2/include -DDEBIAN -fno-strict-aliasing -I/usr/local/include -DMOD_PERL -L/usr/lib -O2 -DVERSION=\0.01\ -DXS_VERSION=\0.01\ -fPIC -I/usr/lib/perl/5.6.1/CORE Lock.c In file included from Lock.xs:26: /usr/src/apache/apache-2.0/mod_perl-1.99_01/xs/APR/Lock/APR__Lock.h: In function `mpxs_apr_lock_create': /usr/src/apache/apache-2.0/mod_perl-1.99_01/xs/APR/Lock/APR__Lock.h:11: incompatible type for argument 4 of `apr_lock_create' /usr/src/apache/apache-2.0/mod_perl-1.99_01/xs/APR/Lock/APR__Lock.h:11: warning: passing arg 5 of `apr_lock_create' from incompatible pointer type /usr/src/apache/apache-2.0/mod_perl-1.99_01/xs/APR/Lock/APR__Lock.h:11: too many arguments to function `apr_lock_create' Lock.c: In function `XS_APR__Lock_acquire_rw': Lock.c:68: `apr_readerwriter_e' undeclared (first use in this function) Lock.c:68: (Each undeclared identifier is reported only once Lock.c:68: for each function it appears in.)
mod_perl error
can i ignore this error? the script seems to work fine... Subroutine print_get_num redefined at /var/www/perl/cancel.cgi line 19. Subroutine print_gonna_del redefined at /var/www/perl/cancel.cgi line 27. Subroutine print_do_nothing redefined at /var/www/perl/cancel.cgi line 74. Subroutine print_do_del redefined at /var/www/fosbow/cancel.cgi line 83. Subroutine error_handler redefined at /var/www/fosbow/cancel.cgi line 156. matt
RE: separating C from V in MVC
Jeff AA writes: space and that column 5 which contains a possibly long name should use the remaining available space, whilst column 1 which contains a name should not be wrapped? We call this a Grid widget in our framework (bOP). There are many options: http://petshop.bivio.biz/src?s=Bivio::UI::HTML::Widget::Grid and here's an example use: http://petshop.bivio.biz/src?s=View.menu Rob
Re: separating C from V in MVC
Hi Jesse, It's the addition tricks which bug me out. With those two words you establish the mother of all slippery slopes to architecture oblivion. When you have objects passing freely between your Controller and View (which are quoted here, 'cuz I don't think they are separate in this case), how do you decide where to put a particular bit of code? The answer is, it is completely arbitrary. First of all, I don't do it that way. I pass simple Perl data structures to Template Toolkit, because I know what data I want to send and it's faster that way. However, I don't really understand your objection. The view doesn't get to do anything but call accessor methods on the object. They look just like simple structures: NAME: [% person.name %] The template coder doesn't know that person is an object and TT called a method to get that instead of just doing a hash lookup. The reason people usually do this is so they can do lazy-loading. With something like Class::DBI you can set it so that if no one ever uses person.name in a template it will never be loaded from the database. It's a performance optimization. People who like that approach have objected to my approach of passing data because it requires the controller to know exactly what data the template will need, or else pass data that may not be needed and possible waste effort. Personally, I don't mind having the controller know what data is needed, as long as it doesn't make any decisions about how the data is shown. In the architecture you describe it is inevitable that given enough time and different programmers your Controller and View will coalesce into a undifferentiated mash of code and HTML, separated only by the fact that they are in two different files. I don't see where you're getting this from. The objects return data, not HTML, and they have no side effects. They are read-only. The view (template) does all of the formatting. IMHO, any system built on Template Toolkit (unless it is small and always managed by the same programmer) will ultimately devolve in just the same way as a Server Page system. Well, you're not right about that. We built a very large system at eToys using TT and it never had any of these problems you're describing. The separation was clear, and the templates did nothing but display data. HTML::Template isn't just faster than just about everything else out there -- it also is pretty much the only templating system which has an actual clear vision when it comes to how it fits into the larger architecture. I don't agree with that either. Template Toolkit and AxKit (or any other XSLT-based system) can both enforce a clear separation of responsibilities. Template Toolkit allows people to do it other ways if they want to, through the use of plugins or by passing objects that do more than just return data, but the documentation and most of the mailing list discussion centers around the same approach as HTML::Template. The speed differences aren't really significant at this point. All of these tools are blazing fast. They all have C code under the hood now (with the new HTML::Template compiler). The bottleneck on performance of web applications is still what it always was: data access. - Perrin
Apache::TicketAccess
Hi Where did it go? Arnold
Re: mod_perl error
At 19:42 31.05.2002, Boex,Matthew W. wrote: can i ignore this error? the script seems to work fine... Subroutine print_get_num redefined at /var/www/perl/cancel.cgi line 19. Subroutine print_gonna_del redefined at /var/www/perl/cancel.cgi line 27. Subroutine print_do_nothing redefined at /var/www/perl/cancel.cgi line 74. Subroutine print_do_del redefined at /var/www/fosbow/cancel.cgi line 83. Subroutine error_handler redefined at /var/www/fosbow/cancel.cgi line 156. It depends. These errors are related to the following pitfall (I think): http://perl.apache.org/release/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs You should read through that and find out how you can make your errors disappear and make your code more mod_perl friendly. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Apache::TicketAccess
At 21:50 31.05.2002, Arnold van Kampen wrote: Hi Where did it go? The modules written for the Eagle book haven't been released to CPAN. They are available online. See http://modperl.com:9000/book/source/apachemod-code-1.02/lib/Apache/ -- Per Einar Ellefsen [EMAIL PROTECTED]
RE: mod_perl error
I assume you are running your scripts under Apache::Registry. Apache::Registry checks the modification time of your script on every request and will recompile (via eval) it if it has changed. However, nothing removes the old symbols from the previous compilation, so Perl generates a warning. For scripts, this warning is usually harmless. You can turn it off with the warnings pragma (Perl = 5.6.0): no warnings qw(redefine); -- Kyle Oppenheim Tellme Networks, Inc. http://www.tellme.com -Original Message- From: Boex,Matthew W. [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 10:43 AM To: [EMAIL PROTECTED] Subject: mod_perl error can i ignore this error? the script seems to work fine... Subroutine print_get_num redefined at /var/www/perl/cancel.cgi line 19. Subroutine print_gonna_del redefined at /var/www/perl/cancel.cgi line 27. Subroutine print_do_nothing redefined at /var/www/perl/cancel.cgi line 74. Subroutine print_do_del redefined at /var/www/fosbow/cancel.cgi line 83. Subroutine error_handler redefined at /var/www/fosbow/cancel.cgi line 156. matt
Re: separating C from V in MVC
Jesse Erlbaum wrote:
As you have already identified, the Model is simply a Perl module. The most
important thing to think of when writing a Model module is to make sure you
make it entirely separate from the user interface. It helps me to think of
the methods in the Model as potentially being called from a web application,
a cron script, or an email-based interface. The Model should not contain
anything specific about any of the interfaces through which it might be
accessed.
Hi, Jesse. I think this part is probably an evolution from the earlier
days of CGI::Application, at least in the applications your company
wrote for my former, now defunct, employer. :)
There was a tendency to make the CGI::Application-derived modules both M
and V. I'm glad to see that's less the case these days.
My current approach is to use Mason for implementing the controller and
view, with a lot of the business logic put in the model. I'm probably
going to explore using CGI::Application and either HTML::Template or
Template Toolkit for a current side project.
Do you have a favorite approach for writing the Model objects? At
Investorama we created a class called TableObject that would deal with
getting/setting values from the database, plus doing data verification
like checking for values being present and well-formed XML in fields
that needed it. I still use that approach on my consulting projects.
It's not a very complex object, and it doesn't do things recursively,
like mapping an attribute to an object and handling that object as well.
TableObject doesn't act as a base class. It just becomes one of the
attributes of the object.
A typical invocation is something like this:
my %fields = (
id = { type = 'num', pkey = 1, sequence = 'seq_users' },
email = { type = 'string', required = 1 },
password = { type = 'string', required = 1 },
first_name = { type = 'string', required = 1 },
last_name = { type = 'string', required = 1 },
valid = { type = 'num', required = 1},
member_id = { type = 'num' },
);
my $table = NAIC::TableObject-new(DBH = $self-dbh,
OBJECT = $self,
TABLE = 'users',
FIELDS = \%fields,
VERIFY = 1);
$table is then put into $self as an attribute called '_table'.
Storing/retrieving/verifying are done with $self-_table-store etc. It
expects that the attributes of an object like $self-email match the
database columns.
--
Barry Hoggard
Tristan Media LLC
e: [EMAIL PROTECTED]
p: 212-627-1596
aim: hoggardb
Re: Apache::TicketAccess
You might want to consider Apache::AuthTicket, which IS in CPAN. It's an expanded version of the Eagle book's modules, and very capable, yet also relatively simple. --Jon Robison Per Einar Ellefsen wrote: At 21:50 31.05.2002, Arnold van Kampen wrote: Hi Where did it go? The modules written for the Eagle book haven't been released to CPAN. They are available online. See http://modperl.com:9000/book/source/apachemod-code-1.02/lib/Apache/ -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: separating C from V in MVC
On Fri, 31 May 2002, Barry Hoggard wrote:
Do you have a favorite approach for writing the Model objects? At
Investorama we created a class called TableObject that would deal with
getting/setting values from the database, plus doing data verification
like checking for values being present and well-formed XML in fields
that needed it. I still use that approach on my consulting projects.
It's not a very complex object, and it doesn't do things recursively,
like mapping an attribute to an object and handling that object as well.
TableObject doesn't act as a base class. It just becomes one of the
attributes of the object.
A typical invocation is something like this:
my %fields = (
id = { type = 'num', pkey = 1, sequence = 'seq_users' },
email = { type = 'string', required = 1 },
password = { type = 'string', required = 1 },
first_name = { type = 'string', required = 1 },
last_name = { type = 'string', required = 1 },
valid = { type = 'num', required = 1},
member_id = { type = 'num' },
);
my $table = NAIC::TableObject-new(DBH = $self-dbh,
OBJECT = $self,
TABLE = 'users',
FIELDS = \%fields,
VERIFY = 1);
$table is then put into $self as an attribute called '_table'.
Storing/retrieving/verifying are done with $self-_table-store etc. It
expects that the attributes of an object like $self-email match the
database columns.
Alzabo could handle a _lot_ of this for you. Class::DBI could handle some
of it (though less).
People should use one of those (and check out poop.sf.net for more
options) rather than re-inventing the wheel.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: 'Apache::Session' using REMOTE_USER as key
Perrin Harkins wrote:
Brian Parker wrote:
I'm trying to use Apache::Session::MySQL. Since I'm generating my own
session key outside of Apache::Session (using $ENV{REMOTE_USER}), what
method(s) do I have to override to prevent Apache::Session from trying
to create a session key for me? Since I'm not using Apache::Session's
key generation capability, is there another implementation that would be
more appropriate for my application?
Just write a replacement for Apache::Session::Generate::MD5.
Thanks Perrin. That at least got me looking in the right place.
I had to replace 'Apache::Session::Generate::MD5' as you suggested and then
create my own subclass of 'Apache::Session' (specifies which 'validate' and
'generate' subroutines to call). Because 'Apache::Session' does not provide a
way to create a session with a certain id, I ended up having to do doing
something like this:
my $rm = $ENV{REMOTE_USER}
eval{
# see if the user has a session created
tie %session, 'WC::ApacheSession::MySQL', $rm, {
Handle = $dbh,
LockHandle = $dbh
};
1;
} or do {
# create the session using $ENV{REMOTE_USER} as key
tie %session, 'WC::ApacheSession::MySQL', undef, {
Handle = $dbh,
LockHandle = $dbh
};
};
... to handle the case of the the first time a user. This will work until I
invent a cleaner solution.
regards,
Brian
You can
look at Apache::Session::Generate::ModUsertrack, which is probably very
close to what you want to do.
- Perrin
Re: [Mason] Re: separating C from V in MVC
Dave Rolsky wrote: Alzabo could handle a _lot_ of this for you. Class::DBI could handle some of it (though less). SPOPS is also a good choice for this. All of them are on CPAN, just waiting for you. - Perrin
Re: separating C from V in MVC
Jeff AA wrote:
For example to render a date in Excel some jiggery pokey is required,
and I would also expect a HTML V to print pretty dates rather than
20020531172534 (or something other than the raw stringification)
Yes. That's why you need to use a good templating system. There is a
plugin for date formatting in Template Toolkit and HTML::Template can do
it by using the HTML::Template::Expr module. Maybe some AxKit expert
could explain how to handle it there.
We also deal with lots of numerics - some are quantities, and others
are values or interest rates - they need zero, 2 or 4dps when being
presented.
Same deal: TT has a formatting plugin, and HTML::Template::Expr gives
you access to sprintf or an arbitrary formatting function of your own.
So for
example if your savings balance has gone negative, the value should
be rendered as an error balance rather than a normal balance. In
HTML you might choose to display the cell with a RED background,
but this does not work in Excel, where a RED background prints as
black, so you can't just tell the view RED - you need to tell it
the reason and let Excel choose one of its limited bg colours.
A simple approach for this would be to have a data model that includes a
boolean flag for whether or not this balance is overdrawn. For example:
my $balance = {
value = -7,
overdrawn = 1
};
Note that the model object is making the decision about whether the
balance is overdrawn and no logic about that is going into the template.
Then in your template you say something like this:
[% IF balance.overdrawn %]
bgcolor=red
[% END %]
Or whatever makes sense for your target output.
Ok - so results from a collection of models are assembled and
passed to the view.
One model, made up of many data objects.
- not sure if I like this. I thought the whole point of the View
was to contain all the logic about things like HTML tags or Excel binary
representation etc, and as little as possible about other things.
That's right.
Exactly where in the MVC world, would I decide that column 3 which
contains a description should expand to fill 70% of the available
space and that column 5 which contains a possibly long name should
use the remaining available space, whilst column 1 which contains
a name should not be wrapped?
In the view. I'm not sure where your confusion lies here.
I guess I have talked myself round to thinking that the Controller
is actually the layout manager, in that it marshals results from
a set of models, decides how this collection should interact, and
then asks an appropriate View to render the result in a specific
interface flavour.
That's exactly what I'm saying, except that I don't see what your
layout manager is for. You should just pass some data to a template
(or maybe to something fancier for certain types of output like Excel)
and then the template makes all the decisions about how to show that data.
Have I talked myself out of HTML:Template route? Not sure, I guess
it depends on whether HTML::Template can be smartened up to
understand that I want Dates rendered in a pretty format, quantities
should be commified, cash values must have commas and 2dps, interest
rates should have 4dps and cells with an error attribute should have
a red background.
No problem, as I explained above.
- Perrin
Re: separating C from V in MVC
Barry Hoggard writes:
Do you have a favorite approach for writing the Model objects?
One solution is to create an interface for accessors, i.e. get,
which the views call on objects they need to access. Our controller
and model objects share this same accessor interface, which allows
the views to access control and database values the same way.
For example,
vs_form_field('UserAccountForm.RealmOwner.name', {},
[['-get_request'], 'task_id', '-equals_by_name', 'USER_ACCOUNT_CREATE'])
The first parameter to vs_form_field identifies the RealmOwner.name
field of FormModel UserAccountForm. The second parameter contains
optional attributes. The third param defines a conditional which
says: only display this row if the view is being rendered in the
USER_ACCOUNT_CREATE task. We use the same view in the user account
register and edit tasks.
The view doesn't allow you to change your User ID in edit mode. The
business logic doesn't allow edits either, but you still have to
control the visible state. You could do that with a model, but that's
denormalization. Rather than copying state, we go directly to the
source, the request object. The Request is not a model, but an
ordinary Perl object, which implements the WidgetValueSource
interface.
Originally, we didn't have this clear separation of WidgetValueSource
and Model. That change really helped us in the view code. There are
other WidgetValueSource objects (formatters, icons, etc.) and the
views access the data in the same way.
Perhaps you can accomplish this with hash references, but I find that
involves a lot of copying. Having a method call to an object allows
the object to control the behavior, e.g. dynamically computing
values. Not coupling it to a heavier Model interface gives you a lot
of flexibility. For the most part, all the views want is the values.
Rob
P.S. Nice to meet you, Barry.
Re: separating C from V in MVC
Perrin Harkins writes:
That's exactly what I'm saying, except that I don't see what your
layout manager is for. You should just pass some data to a template
(or maybe to something fancier for certain types of output like Excel)
and then the template makes all the decisions about how to show that data.
The layout manager is an important tool, which doesn't fit in with the
template model. It comes from widget-based GUI toolkits like Java,
Tk, etc.
Layout managers accept a declaration ('this cell is northwest', 'this
other one expands across the bottom', etc.). They interpret the decl
at run-time. It's like HTML, but more declarative. Some attributes
of our Grid manager are:
cell_nowrap - don't wrap the text in the cell
cell_align - gens valign and align from a single compass direction
cell_expand - this cell eats up the rest of the columns in the row
row_control - a conditional value to control whether row is displayed
cell_width - contains the HTML width= value (may be dynamic)
With Java's GridBag and other layout managers, you relate the cells in
some way and the layout manager does the right thing. Since this
particular layout manager is HTML, we relate the cells in a row-major
matrix. Since it's Perl, it's compact. Here's a simple example:
Grid({
string_font = 'page_text',
pad = 5,
values = [
[
String(Join([
'Please confirm that the following data is correct '
.'and press the bContinue/b button to ship the '
.'order',
])),
], [
String('Billing Address', 'page_heading'),
], [
$address_widget('bill_to', 1),
], [
String('Shipping Address', 'page_heading'),
], [
$address_widget('ship_to', 2),
], [
ImageFormButton({
image = 'continue',
field = 'ok_button',
alt = 'Continue',
}),
],
],
}),
Rob
Re: separating C from V in MVC
Rob Nagler wrote:
Layout managers accept a declaration ('this cell is northwest', 'this
other one expands across the bottom', etc.). They interpret the decl
at run-time. It's like HTML, but more declarative. Some attributes
of our Grid manager are:
cell_nowrap - don't wrap the text in the cell
cell_align - gens valign and align from a single compass direction
cell_expand - this cell eats up the rest of the columns in the row
row_control - a conditional value to control whether row is displayed
cell_width - contains the HTML width= value (may be dynamic)
Can't all of that be expressed in an HTML template? It seems like the
template should know enough about what kind of data it's displaying to
know how to arrange the tables. After all, it's not a template for a
generic table; it's a template for a table that displays specific data
with a structure that is pre-determined.
Usually when I see people doing this kind of thing it's because they
haven't expressed all the necessary information in their model. For
example, if you have a rule that says people's names don't get wrapped,
then you need to know which pieces of data are names. If that isn't
obvious from your data structure (i.e. person.name is always a name)
then you add some flag to your data structure like is_name, so that the
model can tell the view that this is a name. Then the view gets to
decide what special treatment to give that data.
Maybe there's a certain class of problems where the sort of layout hints
you're talking about are needed and I've just never had to deal with it.
- Perrin
Re: separating C from V in MVC
Rob Nagler wrote: Let's say, though, that you want the same template to render in a WAP, Opera, Konqueror, IE, NS, etc. The implementation of Grid handles this for you. For example, our code automatically renders style sheets for IE5+, but no other browsers. (This isn't in Grid, but you get what I mean, I hope.) The same template? How does the layout manager help with that? Does it modify the template? It would make more sense to me if this were a sort of abstraction to factor out common layout ideas from multiple templates. However, sometimes you have dense tables where you allow wrapping and other sparse tables where you don't. We have a really wide table for admins which allows them to see all EC info at a glance. It has to wrap all cells or it wouldn't fit on some screens. When the customer sees the payment reason, on their subscription page, it doesn't wrap. Two views of the same data. That doesn't require a layout manager though. Simple templating is fine for that, i.e. two different templates (views). - Perrin
Re: separating C from V in MVC
Perrin Harkins writes:
The same template? How does the layout manager help with that? Does it
modify the template? It would make more sense to me if this were a sort
of abstraction to factor out common layout ideas from multiple
templates.
I think we're miscommunicating. I'm talking widgets, and you're
talking templates.
A layout manager is a bit of a red herring in mod_perl. I was simply
trying to explain how they came to be and why they make sense. In
GUIs, the layout manager is responsible for placement when the window
is resized. In mod_perl, it plays a lesser role, because the browser
does most of the work (thank goodness).
Templates and widgets are pretty much the same thing (see discussion
at end). It's how you use them that makes a difference. We have a
String widget. You could just as well make a string template. It's
not natural in template languages to wrap every piece of text in a
string template, however.
A String widget/template allows you to control the rendering of all
fonts dynamically. If the String widget/template sees the incoming
request is from IE5+, it doesn't render the font if the font is the
same as the default font. The Style widget/template renders the
default font in a style if the browser is IE5+. This avoids the
stylesheet bugs in all other browsers and gives 90% of your users who
are running IE5+ a much lighter weight page.
It's cumbersome to do wrap all text in string templates, because the
calling mechanism is verbose. Most template languages I've looked at
only support named parameters.
Widgets can have named parameters, e.g.
String({
value = ['User.first_name'],
string_font = 'my_first_name_font',
});
but it is much more convenient to use positional notation:
String(['User.first_name'], 'my_first_name_font');
The way I like to think of this is that HTML corresponds to machine
language. Templates correspond to assembly language. Widgets
correspond to structured programming. You can program everything in
assembly language, it's just more cumbersome. This is why people
invented macro assemblers, but there is still a significant difference
between building a system in C or Macro-11.
This is why a layout manager is a natural concept to me. It's a
widget which does something with the results of other widgets. What's
cool about HTML is that you can do this post draw, i.e., after the
widget renders a child, it can look at the result to determine its
next action. For example, the String widget can escape the output of
its child. I haven't seen this in template languages and rarely in
GUI toolkits.
Rob
Re: separating C from V in MVC
I think it'll be great to present the current discussion as a tutorial, so others can make a better use of the ideas thrown here, rather digging in archives. This could be a great addition to our growing tutorials section for the new site we are working on: http://perl.apache.org/release/docs/tutorials/index.html Any takers? While we are at it, if you are interested in writing tutorials on all kinds of topics related to mod_perl but don't fit into modperl docs (dbi, sql, caching, high availability, cool tricks, world domination, etc.) let us know at the docs-dev mailing list (or contact me) and we will help you with the details. Thanks! __ 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: Getting AuthCookie to work on W2K
On Thu, 30 May 2002, Hill, Ronald wrote: Hello All, I am trying to setup the Apache-AuthCookie module and have run into a problem. Every time I try to login it just returns my back to the login screen. I can't get past the login screen!! (I have tried with Netscape and IE). Next I wrote a perl script to check things out. (same thing!!) according to the apache log file it seems that the server is not receiving the cookie but according to the LWP debug information it is sending it out!! Does anyone have any idea what is wrong? What have I missed? I've tried a simple example of AuthCookie on Win32, and it works, so it's not a compatibility issue in principle. One thing to check - is your login form set up in the way AuthCookie expects it (see 'perldoc Apache::AuthCookie') - username and password in parameters called 'credential_0' and 'credential_1', and also a 'destination' parameter set to the location where the user should be taken if the login is successful? best regards, randy kobes
