Re: [OT] About XML and Petal (was Re: templating system opinions (axkit?))
I suggest y'all check out Tapestry
http://jakarta.apache.org/tapestry
to see a really nice happy medium. It uses a templating language
similar to TAL but much more flexible (and useful, in my mind) than
rigid XML. All its templates can be used in things like Dreamweaver
and GoLive with getting munged. I also think that forcing templates to
be valid XML is a huge pain in the nuts and would drive most poor HTML
monkeys crazy. We're the developers, leave the XML to us... don't
force it on people who use photoshop for a living and have learned HTML
so they could be a "web designer" because it's just gonna confuse them.
And besides, we're perl developers... we should take one look at XML
and vomit at its disgusting syntax and unwieldy markup-heavy,
text-heavy guts. You can't beat pure perl for representing data
structures, or NeXT plists, for that matter. What's easier, this:
{
XML => "Sucks",
Perl => [
"Rules",
"Is Great",
"Is fun",
],
}
or this piece of nastiness
Sucks
Rules
Is Great
Is fun
Ok, so I'm not being totally fair, but you get the idea.
XML is a nice idea for certain things but I gotta agree with Andy...
keep it out of my web templates.
Cheers
Kyle Dawkins
Central Park Software
On Monday, Jul 28, 2003, at 12:27 US/Pacific, Jean-Michel Hiver wrote:
If you like a more straightforward approach, TT also lets you write:
$some_content
See, I knew there would be something that we would agree on! :-)
:)
But at the risk of breaking compatibility with some validators / XML
tools / etc.
It still looks like valid XML to me. Where is the incompatability?
Am
I missing something obvious?
And it is. However if you have, say,
then
it's not XHTML anymore (spaces / weird chars not allowed as
identifier...). I'm sure there's many more cases of nasty surprises.
There's also cases in which with TT or H::T you have:
[% IF expression %]
[% FOR other_expression AS stuff %]
... some stuff
[% END %]
[% END %]
Here the problem is obvious because the code is well indented. However
with TAL syntax this simply cannot happen.
Also, with TT you have to use the filter 'html' to XML encode your
variables. Petal does it by default, and you need to use the TALES
'structure' keyword to NOT encode.
This is because double encoded values are much easier to spot and debug
than badly encoded ones.
To summarize, I think Petal is more specialized in XML templating and
has the strength of a very smart, open specification written by the
Zope
people. Petal fills a niche across the XML and the templating world and
is certainly not a replacement for TT.
Actually, as Steve Purkis suggested on the Petal mailing list it would
be possible to implement Petal on top of TT. Maybe for Petal 2.00!
To conclude, and in order to satisfy my little ego I think both
libraries are deadly cool. Plus I would never have dreamed of the
author
of TT arguing about the pros and cons of TT vs Petal with me when I
started writing the library a little more than a year ago.
That in itself is a great reward :-)
Cheers,
Jean-Michel.
Re: Shroud+ Perl obfuscator....
Are you for real? Or is this some lame attempt at sarcasm? Andrzej posts to the list, SHARING some code he's written in case some people actually might use it, and he gets bitchslapped with some holier-than-thou rhetoric? Puh-leaze. Take your total bullshit somewhere else because you're about as constructive as Richard-f**king-Stallman. You may not know this, but people actually use perl for things other than one-liners. Commercial projects actually use perl, and oftentimes these commercial projects are sensitive and copyrighted. And occasionally, just occasionally, these projects actually want to have some level of security, for numerous reasons that I'm sure Andrzej could explain quite easily to us if he were asked. Andrzej: thanks for sharing your code with us. Kyle Dawkins Central Park Software On Friday, Dec 20, 2002, at 22:44 US/Eastern, Randal L. Schwartz wrote: "Andrzej" == Andrzej Jan Taramina <[EMAIL PROTECTED]> writes: Andrzej> I extended Robert Jones' Perl Obfuscator, Shroud into what I Andrzej> am calling Shroud+. I needed it to protect some rather Andrzej> extensive scripts I have developed for Inventory and Image Andrzej> Gallery management on client web sites. I just want to go on the record to say that I consider your action personally offensive and ethically questionable. A lot of people have worked very hard to bring you an open source platform to stand on. And now you spit in their face, by trying to pretend YOUR work is worthy of more locking up than the source code you are using to create your work. Sir, on their behalf, and my own as a contributor to the open source movement, and Perl in particular, you offend me. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
AUTOLOAD in mod_perl (was Re: When perl is not quite fast enough)
Perrin (et al... cc'ing this back to the list) Thanks for this information... it is confirming what I originally thought, so I don't need to change my code (yet). But I wanted to post it back to the list to everyone else can benefit from it. I personally tend to avoid AUTOLOAD, only because it is a piece of perl "magic" that can be super-confusing to developers coming to perl (and mod_perl) from other languages (um, Java) and I think there's a voodoo-level involved that's a bit high for my tastes. In the one place I use it, I don't generate anything, just trap calls to methods with AUTOLOAD and perform a lookup based on the arguments. If it really is that slow, maybe I'll even rewrite that to use something other than AUTOLOAD. Cheers! Kyle Dawkins Central Park Software On Tuesday, Dec 17, 2002, at 13:13 US/Eastern, Perrin Harkins wrote: kyle dawkins wrote: Sorry to mail you directly... can you just give me two cents on your comment below about AUTOLOAD, mod_perl and memory sharing? I use AUTOLOAD in one module to perform accessors and I wonder if there's a better way to save memory. AUTOLOAD is kind of slow, so most people put something in there to define their accessors as subs by manipulating the symbol table. It's easy, and Damian's book has an example. In mod_perl, you want any methods that you expect to be called to be defined in the parent process so they will be shared. I do this by building all of the accessors in a BEGIN block in my module which is called when I use it in startup.pl. - Perrin
Re: okay, I give, I'm stumped
Hey Greg et al.
I'd betcha your problem is almost certainly caused by your use of DSOs. If
you *really* want to prune your system down to see where your bug is, then
build apache and mod_perl statically. There was a very well-known bug that
caused DBI to segfault if it was run under a DSO. Please rebuild your
binary and then let us know if that was the problem.
Kyle Dawkins
Central Park Software
http://www.centralparksoftware.com
> Okay, I've been staring at this problem for close to 48 hours straight
> now and have finally narrowed it down to a set of lines of code.
>
> So let me first expand.
>
> I currently have a system running, with Apache 1.3.14 and Mod_Perl 1.24
> on Redhat 7.0 (yeah REALLY REALLY ancient) and Perl 5.005003. It also
> has mod_ssl, and several other modules loaded, but for the sake of the
> problems I am having, I completely removed those.
>
> This actually runs perl scripts that connect and talk to (yeah dig
> this), Postgres, Mysql, and Informix. The root of my problems, as I
> have finally found, is Informix.
>
> In our httpd.conf, we utilize a PerlScript directive to preload a bunch
> of environment variables, and other stuff at startup. The script is
> pretty nasty and harry, and buried deep within it happened to be a call
> to Informix.
>
> So for the record, the current system (ancient stuff) works.
>
> So the problems began. I decided to upgrade to Apache 1.3.26 and
> Mod_Perl 1.27 on Debian Woody (3.0) and Perl 5.006001. I also built all
> the other libraries, and than the fun began.
>
> At first, I just got seg faults attempting to start apache. But as I
> have said above, I have narrowed it down to a set of lines of code that
> cause it to fail.
>
> So if I build Apache 1.3.26 and Mod_perl 1.27 by themselves, using
> pretty straight forward options..
>
> Apache
> --
> CC="gcc" \
> CFLAGS="-g" \
> LIBS="-L/home/grumple/src/test/lib
> -L/home/grumple/src/test/system/lib " \
> ./configure \
> "--prefix=/home/grumple/src/test/system" \
> "--enable-module=most" \
> "--enable-shared=max" \
> "--with-layout=GNU" \
> "--disable-rule=EXPAT" \
> "$@"
> --
>
> and
>
> Mod_perl
>
> perl Makefile.PL PERL_USELARGEFILES=0 PERL_DEBUG=1 USE_APXS=1
WITH_APXS=/home/grumple/src/test/system/sbin/apxs EVERYTHING=1
INC=/home/grumple/src/test/system/include
> --
>
> and than my conf
>
> httpd.conf
> --
> AccessConfig /dev/null
> ResourceConfig /dev/null
>
> LoadModule env_module libexec/mod_env.so
> LoadModule config_log_module libexec/mod_log_config.so
> LoadModule mime_modulelibexec/mod_mime.so
> LoadModule autoindex_module libexec/mod_autoindex.so
> LoadModule dir_module libexec/mod_dir.so
> LoadModule alias_module libexec/mod_alias.so
> LoadModule access_module libexec/mod_access.so
> LoadModule auth_modulelibexec/mod_auth.so
> LoadModule setenvif_modulelibexec/mod_setenvif.so
>
> AddModule mod_env.c
> AddModule mod_log_config.c
> AddModule mod_mime.c
> AddModule mod_autoindex.c
> AddModule mod_dir.c
> AddModule mod_alias.c
> AddModule mod_access.c
> AddModule mod_auth.c
> AddModule mod_setenvif.c
>
> ServerType standalone
> ServerRoot "/home/grumple/src/test/system"
>
> PidFile/var/tmp/run/test.pid
> LockFile /var/tmp/test.lock
> ScoreBoardFile /var/tmp/test.scoreboard
>
> Timeout 300
> KeepAlive On
> MaxKeepAliveRequests 100
> KeepAliveTimeout 15
> MinSpareServers 2
> MaxSpareServers 10
> StartServers3
> MaxClients 256
> MaxRequestsPerChild 1000
>
> LoadModule perl_module libexec/libperl.so
> AddModule mod_perl.c
>
> ServerName grumple
> Port 6180
>
> Listen 6180
>
> ServerAdmin yeah@right
> DocumentRoot /home/grumple/src/test/www/htdocs
>
>
> Options FollowSymLinks
> AllowOverride None
>
>
>
> Options FollowSymLinks
> AllowOverride None
> Order allow,deny
> Allow from all
>
>
> DirectoryIndex index.tp index.htm index.html index.cgi
> AccessFileName .htaccess
>
> Order allow,deny
> Deny from all
>
>
> UseCanonicalName On
> TypesConfig "/home/grumple/src/test/system/etc/httpd/mime.types"
> DefaultType text/plain
> HostnameLookups Off
> LogLevel warn
>
> LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
combined
> CustomLog "/var/tmp/logs/test.access" combined
> ErrorLog "/var/tmp/logs/test.errors"
>
> ReadmeName
Re: [OT] WebObjects [Was: Re: separating C from V in MVC]
Perrin &al > > Once you use it, everything else > > sucks. There are no exceptions. > That's kind of a rude statement to make on this list, where all of these > people are offering free software and support to you. Ah, you're right; I actually never meant that as a slight against things mod_perl; I use mod_perl and I support it fervently. But mod_perl & WO are at two different places in the stack; WO is a rich framework, mod_perl is an all-powerful skeleton on which we *build* our frameworks. > It's been a few years since I last evaluated WebObjects, but it > certainly didn't seem like a panacea. It had a number of interesing > ideas behind it, but its insistence on trying to hide all the details of > the browser interaction made some simple things very hard, especially > since it tried to keep all of the state information server-side. The > problems it had with back buttons and multiple browser windows come to > mind Might have been a problem a long time ago but it's certainly not now. WO supports both its own kind of steroid-enhanced session tracking, which does create problems with back-buttons if you don't use it properly, but it also supports regular mod_perl-style request/response cycles that are perfectly fine with back-button/multiple-window/bookmarking tasks. > It also seems to encourage design where browsers directly request > a view, rather than calling a controller which chooses a view depending > on the outcome of processing. That could be just a shortcoming of their > introductory documentation though. Not quite sure what you mean here. The general WO request-response loop is 1 Process request 2 Perform action 3 Return response Step 3 is entirely dependent on the previous two, just like any mod_perl/CGI/php app. WO completely forces division of your C & your V and gives you a huge hand in separating your M from either of those. Anyway, sorry if anyone was slighted; I think the most perfect web development env would be a WO-style framework build on top of mod_perl (because who wants to use Java? Jeez) Cheers Kyle Dawkins Central Park Software
Re: [OT] WebObjects [Was: Re: separating C from V in MVC]
Drew is correct, EOF stands for "Enterprise Object Framework". However, it's not "part of" the WebObjects app server... it predates WO by a long time (I think it's about 9 or 10 years old) happens to come with WO but is completely separate from it. On Friday 14 June 2002 11:27, Drew Taylor wrote: > For those of you (like me) who didn't know what EOF is, it stands for > Enterprise Object Framework and is part of Apple's WebObjects app > server. Which has moved on to Java, and thus is OT. :-) But I've > heard many good things about WebObjects, so it's on my wish list of > technologies to investigate. WO is amazing, no two ways about it. Once you use it, everything else sucks. There are no exceptions. Kyle Dawkins Central Park Software
Re: separating C from V in MVC
> The Pet Shop has a grand total of 13 tables. > > How well does this approach work with 90 tables? How does it handle > arbitrary queries that may join 1-6 tables, with conditionals and > sorting of arbitrary complexity? Where I work we have over 90 tables and it works fine. We don't run a ticketing system or a huge e-commerce site but our servers are pretty busy and we have no performance problems. Our application layer does not contain a single line of SQL. The entire system is OO Perl and uses an OR-mapping system that entirely abstracts the tables and relationships between them. It works for us. Maybe it wouldn't for a bigger system, but I would also caution people to say that if you find yourself doing joins across up to 6 tables, you're almost certainly doing something wrong from the start and, basically, you're fooked because of shitty design, and O/R or R/O won't help you. > > We've found the O/R mapping to be an indispensable part of the > > system. Since all data is contained in objects, the views/widgets > > don't need to how the data is populated. They access all data > > through a single interface. This is how our system works too. Less code, fewer bugs (we hope!), faster development time. For us it's awesome; your mileage may vary. As for people claiming never to have seen an OR system that works, I suggest you check out EOF from NeXT/Apple. That puppy runs banks and insurance companies, and usually without needing a line of SQL. It's not perfect, but it's pretty friggin amazing. Each to his/her own. Kyle Dawkins Central Park Software
Re: separating C from V in MVC
Fran
> Out of these two, I would think that the first one is actually
> better. What if you have 300,000 watches and only 25 are stale, for
> example (numbers that are not all that far from the truth, in my
> case)? That'd be a lot of data I'd be slinging around in the 2nd
> example. Which is probably what you meant by "might be better". :-)
Jeff's example was very abbreviated to make a point. In your case, you
should think about two things:
1) the representation of your data
2) the fetching of your data
Since you could have a zillion watches, you could use something like
my $staleWatches = WatchManager::watchesWithStatus("stale");
This allows you to implement the "watchesWithStatus" method any way you
choose, and simply returning an arrayref of matching watches. Then you
can pass that arrayref to your View, which, as Jeff says, should apply
some transform to your data to produce your report.I realise this
is essentially what Jeff is saying but the key point is that you don't
need to have all 300,000 watches in memory... you can abstract the data
using a Manager (or Broker, or... ) so you hide the data store.
Cheers
Kyle Dawkins
Central Park Software
Re: separating C from V in MVC
Fran (et al)
I've stayed out of the MVC chitchat for a long time (very interesting
thread) because it's such a deep topic. But seeing as how Fran has
some concrete questions...
> 3. How do you prevent a Controller from just becoming another big if
> statement, or is this their purpose in life?
See Jeff's previous mail. Your structure is crying out for a dispatch
table; Jeff suggests building this out of a hash that defines what
actions to perform based on what your query values are. That's a great
place to start. GET RID OF YOUR BIG "IF" STATEMENT ASAP.
> 6. Do you need to create objects at all? Is OO a prerequisite to
> MVC?
No, but it makes it a lot easier in most cases. Passing objects between
the M, the C and the V is way easier than building crappy hashes by
hand and calling a zillion "param" methods.
> 7a. Is it insane to leave my SQL hard-coded in there? The queries
> don't change all that much, and it's nice to have the query in the
> same place as the processing of the result set so you can kind of
> "see" the structure of the result set better. This helps our
> less-experienced developers.
OK, strong words here. REMOVE YOUR SQL. Move it into a layer that
deals with the DB and vends consistently formed data (objects if you
can manage it).Your controller shouldn't know anything about your
DB, so create a class that essentially is every entry and exit point to
and from your DB, and have that keep the database handle as a class
variable. What's easier for your newbie programmers... your code as it
is now, or this:
sub doDoctorActivity {
my $tmpl = shift;
my @results = DataStore::objectsForDoctorActivity();
ViewManager::someMungingMethod($tmpl, \@results);
return $tmpl;
}
Think of how clean your code is with no more $dbh references or "ifs".
Think how many fewer lines of code you will have to maintain. Fewer
lines is good. Remember that.
It is a HUGE gain to isolate your DB entry points and place them in one
carefully controlled class.
I am often amazed at how blind some developers can be about SQL. Most
of the people on this list realise that mixing HTML and perl is bad,
and most of us can see why. But I am constantly depressed that not
nearly as many people appreciate that it is THE SAME FOR PERL AND SQL.
SQL intermixed with Perl is just nasty and you need to move it into a
limited space that you can easily control. Obviously, it's necessary;
you need your perl to talk to your DB. But it should be very very
carefully managed and moved somewhere where its impact on the source is
minimal. Right now I have the evil task of optimising a zillion lines
of bad perl code written by a company I used to work for. They have
asked me to come back and save the project... and it's a frigging mess
because of all the SQL. THere are so few places where you can cache
query results, for example, because there are pages and pages of crap
like
$sql .= " AND some_other_stupid_table.id =
another_dumbass_table.stupid_table_id";
if ($myAssIsBlue) {
$sql .= " AND some_table.my_ass IN ('BLUE','BLUISH','CYAN')";
}
ad nauseum. What a load of utter shite.
> 7d. Or do I -really- want an object/structure that represents every
> result set we need to get back from the database?
If I were you I would create a parent class that represents a basic DB
row and use that. When you need custom behaviour, subclass it and
bless the rows into the subclass. Adding an "Object Structure" can be
as simple as blessing your hashes that come back from the DB into a
class, remember that.
> 8a. What structures are used to pass back the data from the model
> through the controller to the view?
> 8b. The view is expecting HTML::Template style hashes and arrays, do
> I form these in the model (which seems to be too much knowledge of
> the view while still in the model) or does the controller convert it
> to the structures expected by the HTML::Template view?
> 8c. The model is getting DBI record sets from the db. I have to put
> this data into -something-, why not the exact format that
> HTML::Template view needs rather than process it twice?
Well, pretend you actually had objects coming back from your DB. Surely
your controller should pass those objects to your view as is...?
That's the whole point. Your view should be responsible for
displaying them. I have seen a lot of talk about HTML::Template being
a "View" layer. It's not. It's the bottom of the View layer. You
need to write the top of the view layer yourself, that takes your data
(objects, whatever) and vends it to HTML::Template in the right way.
Kyle Dawkins
Central Park Software
Re: Throttling, once again
Peter Storing the last access time, etc in a cookie won't work for a perl script that's abusing your site, or pretty much any spider, or even for anyone browsing without cookies, for that matter. The hit on the DB is so short and sweet and happens after the response has been sent to the user so they don't notice any delay and the apache child takes all of five hundredths of a second more to clean up. Kyle Dawkins Central Park Software On Friday 19 April 2002 11:18, Peter Bi wrote: > If merely the last access time and number of requests within a given time > interval are needed, I think the fastest way is to record them in a cookie, > and check them via an access control. Unfortunately, access control is > called before content handler, so the idea can't be used for CPU or > bandwidth throttles. In the later cases, one has to call DB/file/memory for > history. > > Peter Bi > > > - Original Message - > From: "kyle dawkins" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, April 19, 2002 8:02 AM > Subject: Re: Throttling, once again > > > Guys > > > > We also have a problem with evil clients. It's not always spiders... in > > fact > > > more often than not it's some smart-ass with a customised perl script > > designed to screen-scrape all our data (usually to get email addresses > > for spam purposes). > > > > Our solution, which works pretty well, is to have a LogHandler that > > checks > > the > > > IP address of an incoming request and stores some information in the DB > > about > > > that client; when it was last seen, how many requests it's made in the > > past n > > > seconds, etc. It means a DB hit on every request but it's pretty light, > > all > > > things considered. > > > > We then have an external process that wakes up every minute or so and > > checks > > > the DB for badly-behaved clients. If it finds such clients, we get email > > and > > > the IP is written into a file that is read by mod_rewrite, which sends > > bad clients to, well, wherever... http://www.microsoft.com is a good one > > :-) > > > > It works great. Of course, mod_throttle sounds pretty cool and maybe > > I'll test it out on our servers. There are definitely more ways to do > > this... > > > > Which reminds me, you HAVE to make sure that your apache children are > > size-limited and you have a MaxClients setting where MaxClients * > > SizeLimit < > > > Free Memory. If you don't, and you get slammed by one of these wankers, > > your > > > server will swap and then you'll lose all the benefits of shared memory > > that > > > apache and mod_perl offer us. Check the thread out that was all over the > > list about a month ago for more information. Basically, avoid swapping > > at > > > ALL costs. > > > > > > Kyle Dawkins > > Central Park Software > > > > On Friday 19 April 2002 08:55, Marc Slagle wrote: > > > We never tried mod_throttle, it might be the best solution. Also, one > > > thing to keep in mind is that some search engines will come from > > multiple > > > > IP addresses/user-agents at once, making them more difficult to stop.
Re: Throttling, once again
Guys We also have a problem with evil clients. It's not always spiders... in fact more often than not it's some smart-ass with a customised perl script designed to screen-scrape all our data (usually to get email addresses for spam purposes). Our solution, which works pretty well, is to have a LogHandler that checks the IP address of an incoming request and stores some information in the DB about that client; when it was last seen, how many requests it's made in the past n seconds, etc. It means a DB hit on every request but it's pretty light, all things considered. We then have an external process that wakes up every minute or so and checks the DB for badly-behaved clients. If it finds such clients, we get email and the IP is written into a file that is read by mod_rewrite, which sends bad clients to, well, wherever... http://www.microsoft.com is a good one :-) It works great. Of course, mod_throttle sounds pretty cool and maybe I'll test it out on our servers. There are definitely more ways to do this... Which reminds me, you HAVE to make sure that your apache children are size-limited and you have a MaxClients setting where MaxClients * SizeLimit < Free Memory. If you don't, and you get slammed by one of these wankers, your server will swap and then you'll lose all the benefits of shared memory that apache and mod_perl offer us. Check the thread out that was all over the list about a month ago for more information. Basically, avoid swapping at ALL costs. Kyle Dawkins Central Park Software On Friday 19 April 2002 08:55, Marc Slagle wrote: > We never tried mod_throttle, it might be the best solution. Also, one > thing to keep in mind is that some search engines will come from multiple > IP addresses/user-agents at once, making them more difficult to stop.
Host name lookups are Off but...
Hi all We have a mod_perl server that's under constant heavy load. In our Apache config we have switched HostnameLookups off using HostnameLookups off and for the most part, it seems to work. However, any check of the logs or /server-status shows that the server is *still* doing reverse-lookup of some addresses. Often, a number of apache processes show up as "D" in /server-status, and it's pretty clear that it's slowing things down. Does anyone have any idea what might be causing this? Could it be something in the mod_perl config? Nowhere in any of our code do we do hostname resolution and for the most part couldn't care less what host/ip people come from. Sorry if this is the wrong list but I have a sneaking suspicion there's something about our mod_perl config that's affecting it. RTFM's are welcome... I already tried but maybe I missed something. Cheers Kyle Dawkins Systems Engineer Central Park Software http://www.centralparksoftware.com *** IMPORTANT ! ** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please notify the sender immediately. Do not disclose the content of this message or make copies. This email was scanned by eSafe Mail for viruses, vandals and other malicious content. **
Re: [Maybe OT] Modular design - calling pages like a subroutine with a twist.
Scott There is a system that exists that is very similar to what you describe. It's called "WebObjects" and was developed by NeXT... it's now offered by Apple. The latest release is (unfortunately) Java only but previous releases (still available) were (Objective) C. Once you scratch the surface of WO, your head almost explodes because it's so astonishingly brilliant and far better than anything else available for rapid (web-based) application development. It is also very very firmly built on real OO theory, which cannot be said for most other web app environments. You build entirely self-contained web components that have no dependency on anything and can be reused in any app anywhere. Components are (well, by default) stateful. In other words, any objects and variables in your component are still there, living and breathing, when a form is submitted or a link is clicked on. Unfortunately it's not free. $699. And deploying it is quite complex... You could check out smartworker (if you can find it these days...), which has a vaguely similar philosophy. It's mod_perl and free. It was originally developed by me and two others... we got it into a rough shape and then it was taken over by a team of very talented developers who have managed to do some great things with it. Try http://www.smartworker.org to see if there's anything going on. Kyle Systems Engineer Central Park Software http://www.centralparksoftware.com - Original Message - From: "Scott Chapman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 15, 2001 11:42 Subject: [Maybe OT] Modular design - calling pages like a subroutine with a twist. > I'm very interested in making a modular site design but haven't > found the tools yet to allow this with the twist I'm looking for. > > Say I have a page that encapsulates some functionality, such as > sending a form then validating the contents that are returned. I'd > call that PageB. > > PageB could be more than one page or a page calling itself, etc. > > When PageA calls PageB, as soon as PageB finishes presenting > the form it doesn't stop but drops out the bottom and returns > immediately to PageA. There are commands in some of the tools > (Mason and soon Embperl - maybe others) to force it to stop there > but this doesn't make for the modularity I have in mind. > > PageB then gets submitted by the user and it either calls itself > (using conditionals to then do the data validation) or another page. > After things are validated Ok, I'd like to have it return right back to > PageA, just where it left off using a "Return" statement. Thus, > PageA could call a "PageB" and have it do all it's processing then > return, just like calling a regular subroutine. > > This would allow for much more modular/object oriented web site > design. The stateless nature of this beast may preclude this type > of functionality. My perl skills are medium at best and C is not in > my scope. I'm wondering: > > 1) is this possible? I expect that someone would have already > implemented this if it were possible because it is so much like > regular modular programming with abstraction layers. > > 2) are there any tools (preferrably perl) out there that support this > cleanly. I've worked with Embperl and glanced through the docs of > Mason, AxKit and TT and didn't see anything looking like this. > > Cordially, > Scott >
Re: Mod_perl component based architecture
Gargi On October 16, 2001 10:11 am, Gargi Bodke wrote: > i have been asked to suggest an architecture to seperate the business > logic from the html. > how is this done in modperl? i guess by using functions for the business > logic. > is there any other way? Absolutely; mod_perl fully supports OO programming and all of the techniques for separating business logic from display logic that you might use in, say, a Java-based web application will work fine in mod_perl. It's very very easy to build a MVC-style application with mod-perl, as a number of different mod_perl based platforms have shown (I always point out smartworker for this but there are many others too). Right now I have an enormous mod_perl based site. Its business logic is entirely separate from its application logic; there is not a single line of SQL anywhere in the application layer and it uses standard design patterns to solve many typical problems. All HTML components are reusable and embeddable in other HTML components. When it's used right, mod_perl is pretty much unbeataable. Cheers Kyle Dawkins Systems Engineer Central Park Software
Re: Augmenting CPAN with P2EE specs, was CPAN polution
Hi All I was reading all the posts about people whining about the state of CPAN (as people should... it's hard to tell what's going on in CPAN these days ;-) and the topic has drifted to this "P2EE" thing that's getting thrown around. I somehow feel vindicated: http://www.geocrawler.com/archives/3/182/2000/12/0/4779413/ I posted that nine months ago when I got frustrated about the total lack of consistency, symmetry and homogeneity in Perl classes. Even the shit that's built-in to Perl is a mess... who the hell wrote localtime()? Argh! It's almost as bad as the java.util.Date fiasco. Anyway, I am glad people are seeing that it's a problem. When it comes to laying down standards, though, we have a few hurdles to jump... who decides who is in charge of these "standards"? Perl gurus? But more often than not, Perl gurus aren't "engineers", they're "ex-hackers", and I don't think hackers should be deciding what goes into P2EE... But I think the basic idea of this "P2EE" --or whatever it's called-- is great. I think things should be mandated everywhere like named arguments for methods, naming conventions for variables/methods/packages, coding styles. APIs should be forced to be consistent across the board. Methods should be named completely and descriptively (jesus h. effing christ i can't tell you how many times I've seen methods named "do_it()" and "process_data()"... are these people high?). Methods should even be encouraged to describe their return value (like array_of_keys_sorted_by_name(%things) or something like that). All of this comes back the basics of simple, clear programming to minimise bugs and maximise resources. God, I can't tell you how many times I've had arguments with idiots who think it's OK to call a method "m". Like, $myObject->m($something, $somethingElse). I mean, what the f**k does that do? And their chief justification? Because it's easy to type. Well, uh, PISS OFF. OK, I'll stop ranting. :-) That's my 2c for the P2EE standards. Kyle Dawkins Software Engineer Central Park Software http://www.centralparksoftware.com
Re: WWWThreads
Wayne > Does anyone have any experience running WWWThreads under mod_perl? I > have just followed the installation instructions and at http restart I > get a lot of warnings as follows : Yes, we are running wwwthreads under mod_perl at a client site. Don't use Apache::Registry though: the wwwthreads source code is NASTY and you should use Apache::PerlRun to be safe. It worked for me without any trouble or customisation. Of course, now, our version of wwwthreads is heavily customised, but I remember getting it to work originally without needing to do anything special. Kyle Software Engineer Central Park Software http://www.centralparksoftware.com
Re: Not embedding SQL in perl (was RE: [OT] Inspired by closing comments from the UBB thread.)
Yeah! Go Gunther. This is one of the better articles on persistence... Scott Ambler has tons of good stuff on his site and I highly recommend it as a source for finding out about interesting techniques. What he describes is quite similar to the EOF link I put in one of my earlier posts. > You guys should definitely read the following: > > http://www.ambysoft.com/persistenceLayer.html > > > Oh another warning is that this is Java. Unfortunately, for better or > worse, I tend to find some of the best articles on OO design > abstractions to be Java ones these days. yeah, this is (unfortunately) true too. but it brings a point home: that it doesn't matter what language you use. doesn't matter if it's Java+JDBC or Perl+DBI. In the 10,000 foot view, it's the same shit, different pile. you still have to solve all the same problems using a different coloured (and perhaps slightly heavier) toolbox. kyle Software Engineer Central Park Software http://www.centralparksoftware.com
Re: Not embedding SQL in perl
Jon > I can see your arguement regarding SQL within one's code, but doesn't > your arguement fail to hold up if we assume that the SQL is fully > "compliant"? Well, yes and no. I was citing that example as *another* reason to keep SQL out of your application-level code. If you do, as Henrik suggests, write pure SQL92, then obviously you wouldn't need to wrap all your SQL in "ifs" like they did with wwwthreads... you could just switch out MySQL and switch in Filemaker Pro if it supported SQL92 and had a DBD module :-). I maintain, however, that SQL embedded in application logic is evil in all but the simplest of scripts. Putting it in middleware is mandatory; I don't take issue with that. > In other words, if the makers of WWWThreads had stuck with standard > SQL, rather than using any non-standard features of MySQL like last > inserted ID, wouldn't their code be useable on Oracle, for example > (assuming we changed the correct var to tell DBI we are using Oracle > now) ? Sure thing. Cheers Kyle Software Engineer Central Park Software http://www.centralparksoftware.com
Re: Not embedding SQL in perl
Original Message Subject: Re: Not embedding SQL in perl Date: Wed, 01 Aug 2001 15:56:00 -0400 From: kyle dawkins <[EMAIL PROTECTED]> To: Henrik Edlund <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Henrik Edlund wrote: >And while we are discussing "not cutting corners", those who still use >MySQL should switch to a real DBMS before they even think of abstracting >the SQL away from their Perl code. > >That people still use MySQL really shows how many lusers there are with >computers that try to develop real software. I said _try_. > >*sigh* > Henrik Not sure if you're aware of it, but that argument is pretty old. We're onto a much more interesting, new argument now. :-) Seriously though, you're right, MySQL is not a "real" RDBMS. No transactions, no foreign key constraints, no stored procedures. It is, however, free, and in use in a lot of places. And interestingly enough, in a way that makes the current argument even MORE important; writing SQL into your code (as per the current thread of discussion) will make it exponentially more difficult for you to move to a "real" RDBMS as Henrik urges you to. If you abstract DB access into a middleware layer, you will have a much, much easier time. By placing SQL into your application code, you are removing the flexibility of changing your persistence mechanism at a later date. And believe it or not, that's not as uncommon as you might think. I cite the example of wwwthreads here... it's a great BBS, runs under mod_perl, is fast, and has a DB backend. However, the source is LITTERED with SQL, and everywhere there's a line of SQL, the dude has to put an "if" conditional around it to check if the installation is using MySQL or something else, because MySQL has numerous features that are not found elsewhere (last inserted id, REPLACE command, LIMIT m,n)... so, twice the number of SQL statements in code that (in my opinion) should not have any SQL in it at all... It's all food for thought (I hope). Kyle Software Engineer Central Park Software http://www.centralparksoftware.com
Re: Not embedding SQL in perl
All > Joe Breeden queried: > > >>It would be interesting to know how other people have solved > >>that problem. > >>Currently, we are essentially using embedded SQL in our apps. > > I have found that stored procedures + perl module wrapper around the procs. > is a nice, balanced approach. Definitely; sotred procedures are hit-and-miss in a lot of environments. Remember that a large number of people in the mod_perl world can't use 'em because they (we) use MySQL. If one wanted to emulate this behaviour with MySQL, you would essentially clone the functionality of your stored procedures using Perl + DBI inside your persistence layer. That is a perfectly viable approach too, but a lot less efficient than stored procedures (many roundtrips versus one). > The procs. give a nice performance boost as they are precompiled into the > server (we use Sybase). I believe that they are more secure, in that you > aren't dynamically generating sql that might be 'hijack-able'. You are > providing a discrete amount of functionality. Placing the stored procedure > execution code in a perl module makes for easy/clean perl access from the > rest of the app. Moving to a new db isn't too terribly difficult in that the > proc names will probably remain as well as the parameters that you pass. > Also, how often do you move to another database in the life of a web app > anyway (at least in our corporate environment)? True, although I don't think it's uncommon to want to move from MySQL to Postgres, for example. I have also seen a lot of places move away from MySQL up to something like DB2 or Oracle when they get their "it-all-has-to-be-spent" venture capital infusion. Sigh. Kyle Software Engineer Central Park Software http://www.centralparksoftware.com
Re: [VERY OT] Inspired by closing comments from the UBB thread.
Tom et al. > >> Mixing HTML with Perl with SQL is bad and evil on every single possible > >> level. > > > > If however you work in a two person company where you have barely enough > > time to go to the bathroom let alone think about creating your own > > database abstraction layer for a custom application and "maintaining" > > code > > means changing a link once a month. Then by all means embed away, and > > take the quick development path over performance or maintainability. > > This is, in my opinion, circular logic. Perhaps the reason that you > barely > have enough time to go to the bathroom is that you're writing the code > the > wrong way. :-) H AH AH AH AH HA HAHAHAHAH brilliant > > On the other hand, if you are completely broke and work on a non-profit > > project and the only system you have is a P200 with 64M of Memory, then > > you may want to think about avoiding templating systems, and doing > > nothing > > but a single module with embedded SQL with Perl and HTML. > > Assuming they're paying you anywhere near a living wage, their money > would > be better spent on modestly upgraded hardware than having you fumbling > around with inefficient to maintain code. Tom, I couldn't have said it better myself. BTW. The project I am working on right now *is* for a small non-profit. We don't have a P200 but we have a single P3 machine doing all the work. We don't have huge fault-tolerant systems or UML models or Java Class Hierarchy posters on our walls, or a coding team in Bangalore working on our project. All this notwithstanding, I have time to go to the bathroom. I can even take reading material with me. I have been in the two-person startup before... and let me tell you, if you think that you should cut corners now, it's just going to bite you in the arse later. Just because we use free and/or open source tools to build our code, doesn't mean we can write crap. We have an obligation to do our duty to whomever we work for, and LEARN and apply that learning to our work. > > There is always more then one way to do it, and there's usually more > > then > > one right way to do it. Let's keep that in mind. > > Agreed. However, Perl + HTML + SQL isn't one of the right ways! :-) Couldn't agree more. Just because TMTOWDI doesn't mean that all of those ways are equal. Most ways suck, in fact. Cheers Kyle Software Engineer Central Park Software http://www.centralparksoftware.com
Re: [OT] Inspired by closing comments from the UBB thread.
All (and Perrin) > > If you wish to see one enlightened approach, please read this: > > > http://developer.apple.com/techpubs/webobjects/DiscoveringWO/EOFArchitecture > > /index.html as I said... *ONE* enlightened approach :-) I think you'd find that EOF (the persistence framework in that example) does exactly what you speak of below. Nevertheless, I absolutely agree that the implementation is very much dependent on circumstances. I just wanted to give an example of an object-layer that doesn't require any SQL... and like a said in my previous post, there are many ways to do this. Our current persistence layer uses a combination of an O/R mapper and objects that manage their own persistence. > I appreciate your kind words about my templating posts, but I don't agree > that an object-relational mapper is always the right answer for database > integration. Using objects to model your data, and having the objects > manage their own persistence through SQL calls is faster and easier for many > things, and it allows you to do things that can't be done with an O/R > mapper, like advanced SQL tuning (optimizer hints), aggregation of commonly > fetched data into one query, etc. You still get encapsulation of the SQL > behind the object interface, and your high-level logic doesn't need to use > any SQL directly. Concur, see above. > It would really be nice if someone could write an overview of the O/R > mapping tools for Perl. I know Dave Rolsky was working on one, but it's a > big job and he's busy with Mason. I've taken a look at many of them (Tangram? a few others) and haven't been impressed with any of them. I think part of the problem is that they're all being developed in a bit of a vacuum. But let's capitalise on the interest that this thread has generated to start a push for something that we can all use. I think even the dudes who embed their SQL in perl could be made to realise the benefits if we all started using a common framework. Thoughts? kyle Software Engineer Central Park Software http://www.centralparksoftware.com
Re: [OT] Inspired by closing comments from the UBB thread.
Guys guys guys Mixing HTML with Perl with SQL is bad and evil on every single possible level. For those who don't know how to split apart your perl from your HTML I suggest you read some of Perrin's recent posts. There are so many ways to do it, I won't even bother with talking about them here. As for SQL, I just wish people would expand their horizons a little and start doing a bit of reading. There are so many different ways to avoid embedding SQL in application code and I sincerely wish programmers would THINK before just coding... it's what differentiates scripters from engineers and I suggest everyone who embeds SQL in their perl for anything other than quick-and-dirty hacks start considering other options for the good of the programming community AND THE SANITY OF WHOMEVER HAS TO MAINTAIN OR ALTER YOUR CODE. If you wish to see one enlightened approach, please read this: http://developer.apple.com/techpubs/webobjects/DiscoveringWO/EOFArchitecture /index.html Fine, it's Java (yuk). Fine, it's Apple (yuk). But it used to be *NeXT* and it used to be *Obj-C*, both very very fine things indeed. One of the projects I am working on right now, for example, involves an awful lot of DB access. There is not a single line of SQL in our application code. It's 100% mod_perl. This is a gd thing. To be fair, if you want to talk to DB at all, you will need SQL somewhere; what I mean by "embedding SQL in perl" is embedding it *application* logic. It has no purpose there and you might as well be using some dumbass technology like CF or PHP because your code will be just as maintainable. I just implore readers of this list to start thinking more as engineers and less as script kiddies. We all love mod_perl and its power and we want it to succeed. We'll only get somewhere with it if we actually make the effort to write better code. Mixing SQL and perl is not better code. Cheers to all kyle Software Engineer Central Park Software http://www.centralparksoftware.com
Re: Ultimate Bulletin Board? Jezuz.
To all who responded to my original post about UBB: thanks. Thanks to all the great feedback, we have decided to punt UBB and are using wwwthreads instead. >>> you might want to look into vBulletin, it is used on a lot of different >>> sites is written in php with a MySQL back end and looks very similar to >>> UBB. >> >>yes, but as an engineer i can't condone the use of PHP, sorry... >You might want to consider WWWThreads (http://www.wwwthreads.com/). Code >is simple to read/understand, and it works out of the box under >Apache::Registry. ok, so now I am using wwwthreads and although the code is cleaner, it's still pretty ugly. there's SQL embedded all throughout the perl everywhere (who does this?! oh my god, are they on crack?), not to mention the HTML embedded all throughout the perl (are they on glue?), so it's pretty much a dog's breakfast of code and written by a script hacker who at least knew enough to write neat, well-commented rubbish. having said all that, it's much cheaper than UBB, far superior in overall design, and DB-driven... and it works beautifully, so i can't complain too much. :-) still makes my life miserable integrating it with an existing user-database... i wish programming were like driving; people should be licensed to program. cheerz kyle Software Engineer Central Park Software http://www.centralparksoftware.com
Re: Ultimate Bulletin Board? Jezuz.
Sander van Zoest wrote: > At mp3.com, we ran UBB for the first year or so and ended up totally > rewriting the bottom end to make it perform better and actually make it > semi-secure. Finally we ended up getting rid of it for some other in house > code. i am worried that i'm going to have to do that... > you might want to look into vBulletin, it is used on a lot of different > sites is written in php with a MySQL back end and looks very similar to > UBB. yes, but as an engineer i can't condone the use of PHP, sorry... >>2. any problems with it under mod_perl? I have it running fine under >>PerlRun but I am not so sure it'll behave under Registry. >> > > Our old version was written in perl 4 and definately wasn't able to be > run under mod_perl. We actually fork()/exec()'d like mad for the first > year, UBB looked nice, but is hell underneath. sigh... it's STILL perl 4. but it makes me glad to know i'm not the only person to struggle with this beast... cheerz kyle software engineer central park software http://www.centralparksoftware.com
Ultimate Bulletin Board? Jezuz.
hey all two reasons for posting this. i am tasked with the job of integrating "Ultimate Bulletin Board" (or "UBB", from http://www.infopop.com) into a client's site. they have an existing user database of many many thousands of users, and they want all these users to be able to read and post in the discussion forums provided by UBB. it's easy to install and easy to get to run under mod_perl. they provide source and you can modify it for your site. now, my reasons for posting to the list: 1. the quality of [perl] code in UBB is so phenomenally bad i can't believe people pay money for it. i can't believe it works (but it does). has anyone else ever "experienced" it? i guess i need a support group... it makes me cry and cuts me to the bone when i think that there are actually people out there who think that code like this is good. oh my god. it should be drop-kicked off the planet. 2. any problems with it under mod_perl? I have it running fine under PerlRun but I am not so sure it'll behave under Registry. i should just go bury my head in the sand. kyle dawkins software engineer central park software [EMAIL PROTECTED] http://www.centralparksoftware.com
Re: handler question
All This is an interesting idea, so I thought I'd add my two cents and say that you can already do exactly this with mod_rewrite. I guess it's useful to have a perl module that does it as well, but sometimes re-inventing the wheel is not worth the trouble. I can see the utility for people who haven't got mod_rewrite... but still, it's small, fast and works beautifully with mod_perl. >I have a nearly finished module which applies some regular >expression (specified in some config file) to the URI and puts the >stuff it found into $r->param (that means you have to use CGI or >Apache::Request to use it). > >e.g: http://www.somehost.org/stuff/order_byname/id0099.html >Regexes: >order=>'order_(\w+)' >id=>'id(\n+)\.html' > Something like this will do it: RewriteRule ^/stuff/order_([^/]+)/id([^\.]+).html$ /some/handler?order=$1&id=$2 [QSA] Just wanted to let everyone know. Kyle Dawkins Systems Engineer Central Park Software, Inc. http://www.centralparksoftware.com
Re: Weird caching problem in windows browsers (solved)
hey all found the problem and it had nothing to do with caching or browsers or OSes, but it's worth a mention here for future reference. for debugging purposes, i had use CGI::Carp qw(fatalsToBrowser); in my handler. for the most part, it was useful, except in this case. deep down in one of my classes, i was using eval to trap a potential error. in the situations where that error occurred, i trapped it, logged a warning, and continued to generate a response that I returned. it seems, however, the CGI::Carp was somehow thinking that an error had occurred and it was *changing* the response code from 200 to 500. So the browser was getting a Status of 500 but my page was being generated, so I didn't know there was anything wrong with it. I took out CGI::Carp and it all works. M. Side effects. Yummy. Kyle [EMAIL PROTECTED] http://www.centralparksoftware.com > hey guys > > i have a pretty big mod_perl system up and running and have run into a > weird problem with browser caching (or rather, not caching) on windows. > > i have a series of complex forms that submit to and are generated by a > mod_perl handler. each submitted form is validated and another form is > generated. in some cases, there are about three or four forms in the > sequence. for some reason, in windows, hitting the back button results > in both IE and Netscape giving "Warning: page has expired" error pages. > I have numerous places on the site that do this, and it's been working > fine all this time. Now, the new forms all cause the error, whereas the > old ones are still fine. I have been trying to figure out what's > different between the old ones that work and the new ones but I can't > really see anything. There are occasions with the newer ones where an > entire sequence of forms submits to the same URL, like this: > > > > so I wrote some code to generate unique URLs for each subsequent POST > and that still produces the same results. > > The weird thing is that if you refresh the page that produces the error, > it will "remember" that page from then on and never show the error for > that form again. > > Does anyone have any idea what might be causing this? I am stumped. > It's also extra tough to debug because everything works perfectly in > Linux so I have to run windows in VMware to even reproduce the error. > Ugh. > > Kyle > [EMAIL PROTECTED] > > >
Weird caching problem in windows browsers
hey guys i have a pretty big mod_perl system up and running and have run into a weird problem with browser caching (or rather, not caching) on windows. i have a series of complex forms that submit to and are generated by a mod_perl handler. each submitted form is validated and another form is generated. in some cases, there are about three or four forms in the sequence. for some reason, in windows, hitting the back button results in both IE and Netscape giving "Warning: page has expired" error pages. I have numerous places on the site that do this, and it's been working fine all this time. Now, the new forms all cause the error, whereas the old ones are still fine. I have been trying to figure out what's different between the old ones that work and the new ones but I can't really see anything. There are occasions with the newer ones where an entire sequence of forms submits to the same URL, like this: so I wrote some code to generate unique URLs for each subsequent POST and that still produces the same results. The weird thing is that if you refresh the page that produces the error, it will "remember" that page from then on and never show the error for that form again. Does anyone have any idea what might be causing this? I am stumped. It's also extra tough to debug because everything works perfectly in Linux so I have to run windows in VMware to even reproduce the error. Ugh. Kyle [EMAIL PROTECTED]
Re: Using modperl as an 'adaptor' front end to an app server.
Yo ho ho > > However, it wasn't a full implementation of the adaptor and didn't work with > > KeepAlive requests and so forth. > > Hmm.. given the source to the adaptor, and being able to turn debugging > on, it looks pretty simple. Absolutely... we'd need to sift thru the adaptor source and piece together something that emulates it. My version was purely to sniff traffic to see what was going between Apache and the WO apps. > > I have often dreamt of writing a drop-in mod_perl replacement for the WO > > adaptor... I have never worked anywhere where they didn't have trouble > > configuring the Apache adaptor, particularly if their webservers were running > > Linux. If you're interested in pursuing this, drop me a line and we can jam > > on the topic for a bit. I also know the guy who wrote the hairy C code and > > he might have some insight into how to reimplement it. > > Will do. Would that happen to be Steve Quirk? You got it. I am quite serious about getting it to work. WO 4.5 is a different beast from 4.0, though, with the introduction of wotaskd. Still, it's all XML-based so maybe we can leverage a lot of what's out there to get it up and running. Man, it'd be great to have a mod_perl adaptor. Minimise the number of postings to the WO mailing list about getting the stupid adaptor to work, at any rate. :-) Cheerz Kyle -- kyle dawkins [EMAIL PROTECTED]
Re: Using modperl as an 'adaptor' front end to an app server.
Daniel A wild guess here but are you talking about WebObjects? On Fri, 02 Feb 2001 01:28, Daniel Sully wrote: > Is anyone using modperl in a way that it acts as an adaptor/scheduler in > front of an app server in a 3-tier application environment? I wrote a perl adaptor last year to sniff the traffic that the WebObjects adaptor was sending to the application instances. I don't have the source any more but as far as I can remember, it was only a few screensful of code. However, it wasn't a full implementation of the adaptor and didn't work with KeepAlive requests and so forth. > Basically I have a vendor provided (with source however) adaptor that > takes incoming requests to the webserver, and passes that request onto > an any number of applications via a socket running on a different > server. It handles failover from dead app instances, however not very > well, and is a big pile of C code. It also has problems in that because > Apache is not multithreaded, one child copy of that adaptor that has > marked an app instance as dead can't let another child know about that > dead instance. I have often dreamt of writing a drop-in mod_perl replacement for the WO adaptor... I have never worked anywhere where they didn't have trouble configuring the Apache adaptor, particularly if their webservers were running Linux. If you're interested in pursuing this, drop me a line and we can jam on the topic for a bit. I also know the guy who wrote the hairy C code and he might have some insight into how to reimplement it. Kyle -- [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On Thu, 07 Dec 2000 11:33, you wrote: > On 7 Dec 2000, David Hodgkinson wrote: > > Development are two of the bibles. I have to say though, > > I've avoided the Design Patterns type books purely > > because of the C++/Java bias. > > you sure are missing out. I second that. You should lose your anti-engineering bias just because of your anti-Java/C++ bias. Design patterns have nothing whatsoever to do with Java and C++, and if you ignore them, you ignore solutions to problems that plague every developer. Design patterns are fundamental to everything we do, even if we don't know it. That's not to say that they will somehow solve all your problems, but a responsible developer should learn about as many problem-solving techniques as possible. Ok, I'll get off my soapbox now. :-) Kyle -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On Wed, 06 Dec 2000 05:52, Matthew Byng-Maddick wrote: > > 6. Engineering > > The Perl community is made up of a truly eclectic group of people, which > > is an amazing strength. However, it's also an amazing weakness: I get > > the impression that very few programmers in the Perl community spend a > > lot of time *reading* books on software engineering and techniques > > thereof... and > > I'm not convinced about this. Although from my limited experience, I'm not > very fond of them Hmmm, I'm not sure if you're talking about the programmers or the books. Ha. But seriously, I lose a lot of respect for people who don't continually study software engineering yet call themselves developers. Our craft is constantly evolving, and to ignore the material that's available to us to learn new techniques is completely irresponsible and it leads to some of the problems that we are bemoaning in this very thread. > > that lack of knowledge tends to bleed over into a lot of code out there. > > We have a HUGE problem in the community of the "coder superstar" > > mentality... > > yup. > > > which is very dangerous. Perl allows far too many tricks, and often code > > ends up totally unmaintainable and unreadable because some coding yahoo > > put in some glory-code. It happens in many languages, true, but Perl is > > the ideal environment for it. > > Not necessarily. You can get coder superstars who write maintainable and > understandable code. OK, terminology problem... I wouldn't call them "coder superstars" *if* they write maintainable and understandable code. Perhaps I should have called them "glory coders" instead. You're totally right, there are plenty of great coders out there who conform to coding standards and don't write tricky code. But what I mean is that there is an abundance of glory-coders in the Perl community because, in a way, the community encourages it. That doesn't fly in a large-scale project and greatly reduces the chances of mod_perl being adopted in the enterprise (IMHO). > > * We implement a "mode" under mod_perl, kind of like "use strict", that > > suddenly forces Perl to behave well from an object-oriented standpoint. > > By this, I mean taking some of the power away from Perl that causes > > trouble, like allowing anyone to write instance data on an arbitrary > > instance of a class... > > No. no no no. Forcing perl to behave as "Object oriented" is entirely the > wrong thing. This is why Java sucks so much. "Everything is an object" > (excepting, obviously, the language primitives). Perl is nice because you > can write it functionally or object oriented depending on the problem > you're trying to solve. Also this functionality is more core Perl than > mod_perl. Ok, you're missing my point but that's partially my fault for not explaining. First, let me agree: Java's "everything is an object" mentality sucks balls. And yes, Perl's duality of functional/OO is really nice. Taking that away is not what I am advocating... I think there should be the *option* in Perl to disable certain features that make Perl a dangerous language for OO development. First and foremost, the lack of true encapsulation is disastrous. There is no concept of private data because instance data is stored in a blessed hash (typically) that's open wide to the world. It makes it tough to create a true interface/implementation dichotomy that is important in the OO world. > > * We "homogenise" some foundation classes. This means we create a > > *suite* of classes that have consistent API, are designed together as a > > framework, and are easy to learn > > I think you need to get out of the "object-oriented-only" mentality. But > yes, sort of, agreed. U, remember, this thread is about mod_perl advocacy. In my mind, we will have huge problems encouraging enterprise adoption of mod_perl without some fundamental changes. No enterprise in its right mind would choose a platform that is not OO for any large project these days. Regardless of whether you like this or not (and I can tell that you don't), it's the truth... you said it yourself. In order to fight the Java juggernaut, we have to beat them at their own game. Perl has so many advantages over Java that that shouldn't be a problem, yet it is. Primarily, it's one of perception... Perl is a scripter's language, Perl is for hackers, Perl is great for sysadmin tasks... but it's also a technical one. Java has a set of foundation classes that everyone uses. They suck festering balls, but they're there. We can learn from that and build a set of consistent classes that allow developers to build web *apps*, not a shitload of scripts that kinda work together as glorified CGI, which is what we get all too often now. Yes, Java is a sorely broken language, but it's being adopted, partially because of Sun's hype but also because it offers enterprise developers real ways to encapsulate their business logic proper
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Everybody This whole call for mod_perl advocacy is definitely a good thing. But we're not going to get anywhere unless we understand the problem in detail. We can run around all we like talking numbers and touting the virtues of mod_perl but it's not going to actually do anything unless we address some fundamental issues. I don't claim to know the answers to these problems, but I do think I can at least start the ball rolling the right direction to get others thinking about what next. If we're on this list, there's a good chance we think we have a good understanding of mod_perl. Or at least a good understanding of the parts of the massive mod_perl beastie that we use. I use it all day every day but don't claim to know anything about Authentication, for example. I'm sure I could read the chapters in the eagle book and figure it out, but I don't know anything about it now. So, making that assumption, I want to bring up a few issues that I see as crucial. 1. We are worried that mod_perl is not being adopted as a server technology in enough places. This is actually TWO problems, not one, and to treat is as one is missing the point. There are TWO different kinds of developer out there. The first is someone who is probably not a programmer by trade, but has picked up CGI and/or PHP/ASP programming from a "21 days" book or by reading through examples. There are a number of reasons why *these* people have not jumped all over mod_perl... I'm sure we all know what those reasons are.The second group of people are *engineers* (or *developers*). These people need something different out of mod_perl. They need good docs, examples, stability, community support, and FOUNDATION CLASSES (more on this later) 2. Perl Let's face it, we love Perl, but a lot of people don't, because *they don't understand it*. Remember, a lot of people might have looked at Perl 4 when it was a disastrous hodgepodge and not looked at it since. Perl 5 is an infinitely better language than 4, but most people don't know that. In order for Perl to be acceptable in larger institutions with an already-established software engineering group, changes to Perl itself need to be made. See more below. 3. Installation/setup Ok, so if you have Linux, it's a piece of cake... download all the sources, follow the README's, and go. But what if you don't have Linux? Or you aren't root, and what if you need access to httpd.conf to keep changing stuff? And developers are going to need to cycle the server all the time, so they need the ability to do that, too... it's definitely a weak point. I can install any one of the Java-based web application frameworks and be developing immediately. 4. Isolation A lot of mod_perl projects (or even Perl projects in general) tend to be one-person shows... maybe I'm wrong, and I'd love it if people could correct me! But in my observation, we have a lot of programmers working in isolation. This is bad. 5. Foundation libraries Because of the open nature of the CPAN community, there are a lot of great modules floating around out there. However, there is no real API consistency in them, and this will cause newcomers to Perl a fair amount of trouble. Moreover, we're not going to get anywhere in the enterprise if people insist on using HTML templating systems that allow the embedding of code within HTML. It's straight up and down a total disaster and no right-minded software architect would ever consider it. which brings me to... 6. Engineering The Perl community is made up of a truly eclectic group of people, which is an amazing strength. However, it's also an amazing weakness: I get the impression that very few programmers in the Perl community spend a lot of time *reading* books on software engineering and techniques thereof... and that lack of knowledge tends to bleed over into a lot of code out there. We have a HUGE problem in the community of the "coder superstar" mentality... which is very dangerous. Perl allows far too many tricks, and often code ends up totally unmaintainable and unreadable because some coding yahoo put in some glory-code. It happens in many languages, true, but Perl is the ideal environment for it. --> SO <-- I hope you guys can give these points some thought. I could be "smoking grass" but I think I'm on target on most of my points and I'd love to hear what you guys think too. In the meantime, here are some ideas that might go down well (or not!): * We implement a "mode" under mod_perl, kind of like "use strict", that suddenly forces Perl to behave well from an object-oriented standpoint. By this, I mean taking some of the power away from Perl that causes trouble, like allowing anyone to write instance data on an arbitrary instance of a class... * We "homogenise" some foundation classes. This means we create a *suite* of classes that have consistent API, are designed together as a framework, a
Re: Trouble setting up mod_perl and name-based virtual hosts
Joe Your problem is with the RPMs that you're using (I bet). I am guessing you're using the pre-built ones that come with RH6.1, right? Don't be fooled... these are buggy. You solution is extremely simple and will only take a short time if you follow the instructions: 1. Use "rpm -e" to remove mod_perl and mod_php, then remove apache. 2. DOWNLOAD THE SOURCES for Apache 1.3.12 and mod_perl 1.24 3. Build them from the source tarballs. You probably want to enable "EVERYTHING" when you build mod_perl. Make sure you build a new apache executable with mod_perl statically linked in. This apache executable takes a bit more RAM but it's faster and way more stable. 4. To make sure that your new httpd has mod_perl built in, execute httpd -l and it should list its modules. If mod_perl appears, you're golden. 5. Remove all the LoadModule and AddModule stuff from your httpd.conf, restart apache, and if it doesn't work, I'd be very surprised... I had the same problem as you (although it was LinuxPPC2000). As did many others in the past (do a search for "SIGSEGV" or "core dump" or "segmentation fault" in the mailing list archives...), and it's a bummer of a bug because it doesn't bite you until you try something slightly difficult (uh, like "PerlModule Apache::DBI") and it explodes. cheers kyle -- kyle dawkins [EMAIL PROTECTED] - Original Message - From: "Joe Brenner" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 02, 2000 19:43 Subject: Trouble setting up mod_perl and name-based virtual hosts > > I've run into problems adding virtual hosts to a machine > where I've already got mod_perl working, but I'm having > some trouble pinning it down, because apache just seems to > die silently without giving me any hints in the error_log. > > It definitely does have something to do with an interaction > with mod_perl though, because if I comment out "AddModule > mod_perl.c" I can at least get apache to restart (though I > guess whether the vhosts are working is another question). > > Does anyone out there have some sucessful examples of > httpd.conf files for mod_perl+vhost sites that they can > point me at? (Sorry if the answer to this one is out there > somewhere, but I've been looking and having found it.) > > Here's my entire httpd.conf file, if anyone wants see it > (I'm running a RedHat 6.1 linux system, using perl 5.05, > mod_perl 1.21, and apache 1.3.9):
Re: Core Dump on "use DBI"
Dick et al. Sorry for the longish multi-quoted post but I wanted to just say for anyone interested that 1) Dick is not the only one having this problem, 2) Many search results on geocrawler for DBI and segfault or SEGV or SIGSEGV or "core dump" show that the problem is widespread 3) I couldn't find a decent posting anywhere outlining what to do to solve it. So I took a look at my system. I was using a LinuxPPC 2000 install on a PowerBook (I can't recommend this config more highly!), and had apache 1.3.12 and mod_perl 1.21, both installed as RPMs. I figured that mod_perl as an RPM might not be such a hot idea (remember reading about problems with mod_perl and DSO) so I downloaded fresh sources for apache 1.3.12, mod_perl 1.24 and whatever the latest perl is that ISN'T 5.6 (something like 5.005003, I recall). First I built perl and installed it, then apache, then mod_perl (which re-built Apache for me with mod_perl statically linked in). Everything works perfectly. And, strangely enough, a LOT faster. Weird. Anyway, to Dick and anyone else having this problem, I hope this helps. Kyle [EMAIL PROTECTED] > > Hey > > > > It's so weird that I read your post this morning and then > > this afternoon I immediately started having the same problem. > > > > I try to preload Apache::DBI at startup and it core dumps if I run with -X. > > > > Please, if someone emails you the solution, could you pass it along to me > > too? > > > > Many thanks > > > > Kyle > > [EMAIL PROTECTED] > > > > - Original Message - > > From: <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, September 19, 2000 17:45 > > Subject: Core Dump on "use DBI" > > > > > > > I am running Apache/1.3.9 (Unix) (Red Hat/Linux 6.2) and DBI-1.14. > > > > > > When I include a "use DBI" in the startup.pl file, Apache code dumps. > > > > > > A "use DBI" in cgi scripts works OK. However, as I need to pre-load a > > > few arrays with data to be shared by the child processes, I need to do > > > it in the startup file. > > > > > > Note: httpd only code dumps when run with -X. Without -X, it runs the > > > startup file ok, but seems to die before spawning any files, but in this > > > case, it does not print "Segmentation fault (core dumped)" and there is > > > no core file. > > > > > > Has anyone else experienced this? > > > > > > Thanks, > > > Dick > > > > > > P.S. Is there a DBI mail-list where I can also post this? > > > > > > > > > > >
