Re: web-based email
A quick search over at freshemat.net gives us acmemail: http://freshmeat.net/appindex/1998/10/20/908893955.html good luck Chris * Rudy ([EMAIL PROTECTED]) [991109 17:59]: I run a small ISP (www.monkeybrains.net) and would like to provide web-based email. I plan on using POP3Client.pm. Is there any code out there which already utilizes POP3Client for web-based email (I'd hate to reinvent the wheel for the n_th time)? I'd like to check it see common email functions and problems you have already solved. I'm leaning toward using POP3Client and EmbPerl. Rudy
Re: Access to userland objects in different phases
* Ken Miller ([EMAIL PROTECTED]) [000515 17:16]:
In the content serving phase I have a Database services object which
manages all access to/from the database. The DB::Services object is
created the first time the handler is hit; the $dbs is made available by
creating a symtab entry, so all my Mason components can get at the database
easily.
...snip...
I guess another way of doing it would be to turn the $dbs class into a
Singleton, and provide a class method to get at the instance:
DB::Services-set_uri( 'dbi:Oracle:' );
DB::Services-set_userid( 'foo' );
DB::Services-set_password( 'bar' );
DB::Services-set_options( { ... } );
my $dbs = DB::Services-get_instance;
get_instance() would create the backing object the first time, then
returned the cached object on subsequent calls.
I use Class::Singleton in mod_perl apps with *no* problem
whatsoever. In fact, it's pretty nifty to simply say:
my $obj = $class-instance;
anywhere in my application and have the object (whatever it is) simply
pop up.
Good luck!
Chris
--
Chris Winters
Internet DeveloperINTES Networking
[EMAIL PROTECTED]http://www.intes.net/
Integrated hardware/software solutions to make the Internet work for you.
Re: Template techniques
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [000608 11:07]: I'm curious Matt, as opposed to what?, reparsing the template each run? Clearly reparsing would be a big loser in terms of performance. But what other technique could be used..., hrm.., without direct control over the pipe, I really don't think it would get too much better than this. I mean, you could yank out sections and stuff it into an array that would be like: text, coderef, coderef, text, etc. Like in an ASP template you would parse the file, grab sections between % % and eval it as a code ref, and stuff it into your array. But this would probably not work specifically in ASP's case, but you might be able to pull it off in Embperl. (Unless the array itself could also point to arrays, etc.) Overall..., I think compiling it directly makes a lot more sense in 99.999% of template languages..., otherwise you'd end up putting too many restrictions on the template language itself. Hmm..., sort of an interesting question, what ways could be utilized in order to maximize speed in template execution. I thought about this a while ago, but after the fact I have to agree with Matt..., just evaling each template as a package, or a code ref would be a lot quicker, and if you could cook up another scheme, the resulting code complexity might not pan out to be worth it. The newest version of Template Toolkit (currently in alpha) supports compiling templates to perl code. See about 2/3 of the way down the the README at www.template-toolkit.org. Why reinvent the wheel? :) Chris -- Chris Winters Internet DeveloperINTES Networking [EMAIL PROTECTED]http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
Re: Using handler for index
This always worked for me: Location / SetHandler perl-script PerlHandler ModuleName /Location But maybe it worked for reasons I don't understand :) Chris * Drew Taylor ([EMAIL PROTECTED]) [000710 10:22]: darren chamberlain wrote: Drew Taylor ([EMAIL PROTECTED]) said something to this effect: Hi all, I am using an Apache Handler module to create my home page, using Location /index.pl SetHandler perl-script PerlHandler ModuleName /Location I have DirectoryIndex set to "index.pl index.html", but the Location directive is not being picked up for the index, so I get the default directory listing. Is there another solution instead of a RewriteRule to redirect "/" to "/index.pl"? Any thoughts would be appreciated. Calling /index.pl explicitly works correctly, right? Yes, /index.pl works properly. But since it's a "virtual" file, I have to just type it in. Replacing Location /index.pl with a FilesMatch "*.pl$" which sets the correct handler for .pl files should do it, and let mod_dir call index.pl itself. Well, the thing is "index.pl" really is Base::HomePage::Anystock. What I'm really looking for is a way to use a module as the directory index. I'm not terribly opposed to using Rewrite, but I'm curious if there is an alternative method. -- Chris Winters Internet DeveloperINTES Networking [EMAIL PROTECTED]http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
Re: Using handler for index
That's funny, because until a few weeks ago I worked with Rusty
(author of Scoop) :) And previous versions of Scoop were handling it
the way Drew mentioned, with an 'index.pl'.
Another alternative (which I prefer) has been discussed previously on
this list. Taking something like:
http://.../User/display/?user_id=7162
or:
http://.../News/edit/?news_id=9182
The handler specified in the Location / configuration takes the
request, breaks up the path info, looks at the first entry and maps it
to a particular module. The second item is normally a subroutine to
call, although that module can map it to whatever it wishes. (There
are, of course, mechanisms for ensuring that 'private' routines cannot
be called from the outside world.)
So the first will map 'User' to a module and call the -display()
method; the second maps 'News' to a module and calls the -edit()
method. GET (or POST) parameters are handled via normal means.
Works swimmingly so far :)
Chris
* David Veatch ([EMAIL PROTECTED]) [000710 11:10]:
At 10:33 AM 7/10/00 -0400, Drew Taylor wrote:
Chris Winters wrote:
This always worked for me:
Location /
SetHandler perl-script
PerlHandler ModuleName
/Location
Well, seems like I tried that, and then it ALWAYS used that handler. I
also have other handlers, and I _think_ the setup above overrode the
others. I'll give it a try again now. OK, I just tried it, and it
overrode everything else. :-(
I'm doing this... in a way inspired by Scoop (scoop.kuro5hin.org). The
handler accepts different query-string arguments to do different things...
if ($query_string_arg eq "this') {
do that stuff;
elsif ($query_string_arg eq "that") {
do this other stuff;
} elsif ...
Anything that doesn't match what I'm explicitly looking for will go back to
the default behavior.
In other words, the handler handles it, and Apache just sends it to the
handler.
--
Chris Winters
Internet DeveloperINTES Networking
[EMAIL PROTECTED]http://www.intes.net/
Integrated hardware/software solutions to make the Internet work for you.
Re: Using handler for index
* Frank Wiles ([EMAIL PROTECTED]) [000710 12:24]: What we do where I work is very similiar except the above URL would come out like: http:///User/display/7162 This works out well because whatever method you are calling probably already knows what input you're needing. The userid in this example. Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org Actually, I tried that. It looks nicer, but if I'm passing more than one parameter it got confusing to remember which order they should go in. At least it was confusing for me :) Chris -- Chris Winters Internet DeveloperINTES Networking [EMAIL PROTECTED]http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
Re: I'm missing something in Apache::Cookie
* Michael ([EMAIL PROTECTED]) [000915 17:29]:
H.
When I retrieve a cookie
%cookies = Apache::Cookie-fetch;
I get a hash that contains the name of the cookie as the key and a
scalar reference as the value.
Apache::Cookie=SCALAR(0xblah...)
Can't seem to unravel it to get at the
value. Using
%xx = Apache::Cookie-parse($val);
gives an apparently empty hash, yet retrieving the headers via
Apache::Table yields the correct results
Cookie=foo=bar
cook name val
foo bar
So what am I doing wrong with Apache::Cookie that keeps me from
returning the cookie value.
Michael
The following seems to work for me in nabbing all the cookies sent and
putting them into a hashref $cookies
my $cookies = {};
my $cookie_info = Apache::Cookie-fetch;
foreach my $name ( keys %{ $cookie_info } ) {
$cookies-{ $name } = $cookie_info-{ $name }-value;
}
HTH
Chris
--
Chris Winters
Senior Internet Developerintes.net
[EMAIL PROTECTED] http://www.intes.net/
Integrated hardware/software solutions to make the Internet work for you.
Re: Clean way of transfering Objects between childinit and request handlers ?
* Greg Cope ([EMAIL PROTECTED]) [000917 14:31]: Dear All I want to create an Object in a ChildInit handler and then pass it to request handlers. Its a DB Object / module and it does some initialiastion, it prepares a few statment handles and then stores them in an array for later execution. One solution is to create a the object in a child init handler and to store it in a package global - and then to use a type glob to referance it from other handlers by using that package global (detailed below). However this appears as a bit of a kludge and does not have any repect for encapsulation ;-). I feel there must be a cleaner way of doing this ? A read of the guide etc ... has not given me any clues. Any ideas appreciated. Greg Cope Hi Greg, Check out Class::Singleton for this purpose. Works great for me. Basically, the first time you create the object, do: my $obj = $object_class-instance( ... ); Every successive time you want the object, just call: my $obj = $object_class-instance; And you'll get the same object back. Initialization stuff (such as database connects, whatever) is put in the _new_instance() method, which is called when the object is created but not when the object is returned. The object is stored in the class itself, and Class::Singleton is actually a really simple module (probably a 10-to-1 ratio of documentation-to-code), but it's nice to have a consistent, standard way of doing things. Chris -- Chris Winters Senior Internet Developerintes.net [EMAIL PROTECTED] http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
Re: [slightly OT] cache refusal problem with IE, http headers
* G.W. Haywood ([EMAIL PROTECTED]) [000919 06:54]: Hi there, On Tue, 19 Sep 2000, Ime Smits wrote: Does anybody know of a tool to get a complete log on every piece of information communicated between browser and server? 'sfunny, I asked Josh the same question a couple of weeks ago... I think it's called a packet sniffer. I've had some success with the debug flag in the pppd "options" file but you've got to *really* want to know =:o 73, Ged. There's a nifty little GTK program that displays all headers to and from a client (and content too, if I remember right) -- just set it listening on a particular port and then tell your browser to connect to that port as a proxy. Super useful. it's called 'wsnitch' and it's at: http://www.geocities.com/denis_leconte/gnomewsnitch.html BTW: I found this after someone mentioned on the modperl list about three or four months ago :) C -- Chris Winters Senior Internet Developerintes.net [EMAIL PROTECTED] http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
Re: Why isn't PerlSetEnv working for me?
* Keith G. Murphy ([EMAIL PROTECTED]) [000926 18:43]: I'm running Apache 1.3.9 with mod_perl embedded, on Debian GNU/Linux. I have the following lines towards the end of my httpd.conf: PerlSetEnv PERL5LIB /usr/local/MyPerl/lib PerlRequire startup.pl Include perllocs.conf However, upon system startup, my startup.pl fails because it can't find a particular module in the @INC list. If I start Apache from the command line, it works. This is undoubtedly because PERL5LIB is set up in my /etc/profile, to the same path. I've looked at this until I'm crosseyed. Seemingly PerlSetEnv just doesn't work. Any ideas? Yes, I know the workaround: 'use lib' in startup.pl. But why? There's another workaround: in httpd.conf: Perl use lib qw( /usr/local/MyPerl/lib ); /Perl Pretty painless :) Chris -- Chris Winters Senior Internet Developerintes.net [EMAIL PROTECTED] http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
Re: simplest authorization possible, please
* Robert Friberg ([EMAIL PROTECTED]) [001007 03:28]: Hi all, I'm not really that lazy, I could probably find out pretty quickly from the excellent guide or the eagle book in my lap right now. It's just that I'm way behind schedule for an application thats due on monday :=) Any time saved will be greatly appreciated, I promised my daughter a biketrip today. Given this: Location /padm SetHandler perl-script PerlHandler Apache::padm /Location What is the fastest/simplest way to add basic authorization? I'm comfortable with hardcoded usernames/passwords in a handler for now. Many, many thanks in advance. There's nothing that says you have to use perl-based authorization just because you're using mod_perl. Doing it the simple apache way -- with htpasswd files -- would also be fine (and ez to setup): Location /padm AuthName "My Auth" AuthType Basic AuthUserFile "/home/httpd/myapp/auth" require valid-user /Location The file /home/httpd/myapp/auth is administered with the 'htpasswd' binary distributed with Apache. The Apache website has more info, examples, etc. Chris -- Chris Winters Senior Internet Developerintes.net [EMAIL PROTECTED] http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
Re: AARRRGH! The Apache Proxy is not transparent wrt cookies!
* martin langhoff ([EMAIL PROTECTED]) [001019 11:51]: hi, after a lot of struggling, I finally set my multilayered apaches up, and now I find that the proxy is eating my cookies along the way... HEELP! I am proxying through mod_rewrite commands, if that actually makes a difference ... martin Proxied cookies work ok for me, and I'm using mod_rewrite commands as well. Are you setting the domain correctly so the browser knows to send the cookie to the light-server? Chris -- Chris Winters Senior Internet Developerintes.net [EMAIL PROTECTED] http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
(fwd) RE: [dcpm] Zombies under mod_perl?
I think the mod_perl analogy Mark mentions here is hilarious! - Forwarded message from Mark D Wolinski [EMAIL PROTECTED] - From: "Mark D Wolinski" [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [dcpm] Zombies under mod_perl? Date: Thu, 2 Nov 2000 14:10:52 -0700 Message-ID: [EMAIL PROTECTED] X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Why, that makes so much sense, it could possibly work. :-) I love mod_perl. Much like my ex-girlfriend, it seems ready, willing and able to point out my inadequacies. Thanks Mark W ... - End forwarded message - -- Chris Winters Senior Internet Developerintes.net [EMAIL PROTECTED] http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
Re: how do I store/retrieve a hash through Apache::Session?
* Enrique I.Rodriguez ([EMAIL PROTECTED]) [001103 12:41]:
Maybe a silly question...
how do I store/retrieve a hash through Apache::Session?
This doesn't work...
# retrieve
%table=$session{table};
...
# store
$session{table}=%table;
What's my fault?
You can only store/read references:
my %table = (this = 'that' );
$session{table} = \%table;
...
my $table = $session{table};
foreach my $key ( keys %{ $table } ) {
print "$key = $table-{ $key }\n";
}
see 'perldoc perlref' for much more on references.
HTH
Chris
--
Chris Winters
Senior Internet Developerintes.net
[EMAIL PROTECTED] http://www.intes.net/
Integrated hardware/software solutions to make the Internet work for you.
Re: Win32 Proxy question
* Gunther Birznieks ([EMAIL PROTECTED]) [001114 00:42]: I believe that you are until the model completely changes under Apache 2.0... Until Unix Apache supports multi-threading, supporting it in windows pre-2.0 is not quite such a high priority I suspect. You should consider using ActiveState's PerlEx. Yes, it's commercial but development is free and the commercial license is not going to break any budgets (I think less than US$1000). The downside is that it's only an Apache::Registry clone. But if all you need is Perl spedup, it's a nice solution. THe plus is getting support from ActiveState. They compile all the Win32 modules so if you run into a multithreaded problem with a module then they can try hammering on it or even work on fixing it. In fact, I dare say that ActiveState has probably caused a lot of multithreaded module legwork to be done before mod_perl moves to that model which is a good thing. Since most modules will have already been fairly debugged when Apache/mod_perl 2.0 are out. I don't work for ActiveState or anything, but I'll second what Gunther said. And PerlEx is only $395, IMO a steal. I'm not sure why more people don't use this. (OTOH, if you can get away with how mod_perl currently works on Win32 then there's not much point in PerlEx.) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Article idea: mod_perl + JSP
* Nathan Torkington ([EMAIL PROTECTED]) [001212 22:09]: I think the 100% Java idea has had its day. Microsoft's .NET is a tacit admission that in the real world Microsoft will never own 100% of the market, so let's make things work better together. In that vein, I'd love to see an article on mod_perl and JSP cooperating. That is, a website that uses both and admits that each has its place. I know a lot of people don't like Java (I'm one of them), but mentioning JSP is the foot in the door to getting mindshare back from those folks who now think that Java is the only way. Anyone run such an installation? Anyone want to write about their setup and experiences? Nat Kind of off-topic but not really: I've recently moved from a job with 100% Perl to one with 80% Java / 20% Perl. One of the things I miss most is the Template Toolkit. (There are lots of other things too, but this keeps coming up again and again.) TT is just so amazingly useful and simple enough that I can't believe more people aren't using it. As for Java, I find it really hard to believe that JSP has caught on like it has. The syntax is *amazingly* clunky and leads me to believe that most people who write JSP use WYSIWYG editors to generate the code for them. (Not that there's anything wrong with that, but it gets my hackles up that catering to one group of folks raises the barriers for another.) "Clunky syntax" might seem like a trivial concern, but IMO it's not. It goes right to the heart of usability -- JSP does not make easy things easy. Since you can embed Java into the page, hard things are possible, but the wisdom of doing a lot of processing in the page itself is beyond me. (And generating web-interfaces from servlets is sufficiently painful that we don't need to discuss it -- haven't any of these smart Java people ever heard of heredocs?) In fact, entirely separate frameworks -- from the open source world there's WebMacro (www.webmacro.org) and the WebMacro spin-off Velocity project (jakarta.apache.org/velocity/), among others -- have sprung up to address JSP's deficiencies. But JSP has hooks in various editors (notably Dreamweaver) and has big money (Sun, Oracle, IBM...) behind it. Plus it has a published standard and (despite its syntax) is quite extensible. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Article idea: mod_perl + JSP
business to make money, after all.) Is that a legitimate reason? I think so, but it's certainly a grey area. With that said though, I still love Perl. Me too :-) It's frustrating to be doing something in Java that would take a much shorter time in Perl. But then there are things in Java that are simpler than Perl as well. Why is this (more or less) on-topic for mod_perl? Because you need to know your competitors. The stuff I've learned from Servlets, J2EE and (to a lesser extent) JSP will be making its way into the OpenInteract application server in the next couple of months. There's quite a bit of cross-pollenation that we can do and because Java is so well-known and marketable, I think it's important to talk intelligently about both. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Article idea: mod_perl + JSP
* Greg Cope ([EMAIL PROTECTED]) [001213 11:19]: Appologies if I am butting in - but what you apppear to say here is that you are using JAVA because its sex / marketdriods know of it, yet perl would be the quicker (and hence cheaper solution ?). Surley for this reason you should use perl and persuade the PBH of the cost benefit here ? Perl isn't always the quicker solution, and some would argue that in the big scheme of things it might not even be the cheapest solution. (Perl programmers aren't easy to find, although IMO if you get a smart programmer with good experience he/she can pick it up quickly.) Technology doesn't exist in a vacuum. Every decision we make as programmers doesn't just affect us, particularly in companies where technology is a product. The people who sell the product, the people who support the product, among others -- all these folks have no idea what Perl is. They know what Visual Basic is, they know what Java is (or they think they do). I would love to be able to convince each and every one of these people that Perl is better than Java and we should use it for our web-based projects. That's simply not going to happen. Does that mean they're "marketdroids"? Not necessarily -- they just want to do their jobs. In their view, Perl makes that harder because it's a hurdle (of many) they have to jump when selling the product. This has hit on a point - in that may people choose Java over Perl because its sexier, which becomes self forfilling, unless we (the perl community) persaude people that (mod_)perl is sexy Absolutely. I continue to argue for Perl wherever possible -- I'm in charge of building the intranet, which simply has to work, and I'm using mod_perl (among other things) to do the job. And if people ask me how the site works I'll be able to more effectively evangelize for mod_perl -- I'd be coming from a much different position than if I were simply arguing one language (or technology) against another. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Article idea: mod_perl + JSP
* Gunther Birznieks ([EMAIL PROTECTED]) [001213 19:50]: Well, for me we do Java because I know that there are a couple drivers. 1) I do know of situations were Java is a better/easier tool. 2) For us its not about what is sexy, but what will sell. By the time we talk to a company, the debate of Perl vs Java is over and they've already spent the money on Java infrastructure or training their guys on Java. There is very little commercial benefit for us to tout the benefits of Perl. me-tooyep/me-too One of the things I said earlier is that I think that the time it takes a good Java guy to develop something vs a good Perl guy seems to be about equal in terms of our real experiences (with Java being a bit longer). I think a *really* good Perl person can be faster, but that's just a gut instinct. Most of us mortals don't qualify. And then when it comes to maintenance (handover) the IT staff of the places we deal with are already trained in Java. This is huge, and the toughest thing to do anything about. Look how much money (marketing, conferences, magazines, arm-twisting, etc.) it took for Sun to get on the radar at large corporations, away from (or in addition to) various other languages. Not that money is the only thing -- I think Java is a pretty nice language, which helps acceptance -- but it's a HUGE effort. So I guess it's a matter of degree. I simply do love Perl, but I don't hate Java, I just merely really like it. I guess you could say I cheat on my Perl gf all the time. :) But unlike in life, I don't think a monogamous relationship with my language is actually very healthy. LOL! I think Chris' views may be similar. ... Yep, we basically said the same thing -- although mine was a little more disjointed and less complete :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
ANNOUNCE: OpenInteract Web Application Server
I'm jazzed to announce the public release of OpenInteract, an
extensible web application framework using mod_perl and the Template
Toolkit as its core technologies. But the README already does all the
heavy lifting:
WHAT IS IT?
=
OpenInteract is an extensible application server using Apache and
mod_perl built for developers but also to be manageable almost
entirely via the web browser. It includes:
- A robust system of components built on templates that can access
your data just about any way that you can think of.
- A very flexible separation of presentation and data access: you can
use one template for accessing data from different sources (e.g., a
listing of users from the system, from an LDAP server, from an NT/SMB
authentication controller, etc.) or you can use one set of data to
fill multiple templates.
- A consistent security mechanism makes it a snap to control security
for users and groups not only at the task level, but also at the
individual data object level.
- A simple user and group-management system that allows users to
create their own accounts and an administrator to assign them to one
or more groups.
- A convenient packaging system that makes it simple for developers
to distribute code, configuration and all other information necessary
for an application. It also makes the installation and upgrading
processes very straightforward.
- An integrated, database-independent method for distributing data
necessary for a package. You should be able to install any
package on any database that's been tested with OpenInteract. (Some
of this work must be done by the package authors, but OpenInteract
tries to make this as painless as possible.)
OpenInteract is available via CPAN in a bundle form
('Bundle::OpenInteract') for EZ install. SourceForge currently hosts
CVS and mailing lists at:
http://sourceforge.net/projects/openinteract/
Other information about the project (including press releases) is
available at:
http://www.openinteract.org/
OpenInteract is available under the same Artistic/GPL license as
Perl. Hope you find it as much fun as I do!
Chris
--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.
Re: ANNOUNCE: OpenInteract Web Application Server
* Perrin Harkins ([EMAIL PROTECTED]) [010206 22:43]: Hi Chris, I've been reading the docs for the last couple of days and it looks very interesting. It's great to see a well-documented open source project. I have a couple of specific questions, which I guess are really about SPOPS more than OpenInteract. Hi Perrin, Thanks for the doc comments! More work always remains First, how much control do I have over what gets loaded when in objects with dependencies? For example, if I have an object with relationships to other objects, some of which are expensive to fetch from the database, can I defer certain parts from loading until I actually use them? Nothing gets loaded until you do a fetch() on an object or on one of its dependent objects. For instance, in the standard user/group way of doing things: # Fetch the user object my $user = My::User-fetch( $user_id ); # None of the associated group objects get fetched until you ask for # them like this my $group_list = $user-group; That said, efficiency hasn't been at the top of the list yet. (Some basic caching hooks are there but nothing attached yet.) I'm following Andy Wardley's example with the Template Toolkit -- make it right first and fast second :-) Second, how hard is it to override the default load/save stuff in a SPOPS object in order to do some fancy SQL? I've had situations before with O/R mappers where I want to use some more complex SQL for efficiency reasons (optimizer hints, etc.) or to load a set of objects at once (like a tree structure). Is that possible with SPOPS? It's not too difficult. The SQL stuff for DBI SPOPS objects actually goes through two layers -- one dealing with more abstract notions of 'save()' and 'remove()' and the other dealing with more concrete INSERT/UPDATE/DELETE statements. The second one (SPOPS::SQLInterface) is quite flexible but at a lower level which should enable you to do custom statements. You can do as much or as little as you like -- passing a fully-formed SQL statement with a list of values to bind does the right thing. So if you wanted to modify how objects get saved but not removed, you should just be able to override the 'save()' interface of SPOPS::DBI and nothing else. But I haven't tried this yet :-) Finally, if I'm using a SQL database, what support is provided for evolving the data model? Do I have to change my schema and write conversion scripts every time I change an object attribute, or does SPOPS try to use some sort of "generic" schema? It's actually much simpler than that. Since SPOPS doesn't save any schema information in the database itself, all you have to do is add the field to your database (with an 'ALTER TABLE' statement or whatnot) and add the field name to the SPOPS configuration definition in the 'field' key. Removals are the same. And datatype definitions shouldn't require any changes at all, as long as the DBD supports datatype discovery sufficient for SPOPS to bind variables smartly. It's a more lightweight approach than Tangram or Alzabo but deals with most of the issues I've run across in a few years of web (etc.) programming. And just out of curiosity, are you familiar with any of the similar projects that others have worked on, like Iaido (formerly Iaijutsu) or Jellybean? I've looked into both of them at one time or another -- OpenInteract has been under construction for about a year and SPOPS (and ancestors) more another half-year before that. I'm jealous of Jellybean's self-sufficiency, of the cool apps built on Iaido so far and of the clean model of both of them. I hope to swipe (with generous attribution) as much as possible. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: [Templates] Re: ANNOUNCE: OpenInteract Web Application Server
* L.M.Orchard ([EMAIL PROTECTED]) [010207 00:07]: So, I'm trying to install OpenInteract now since from 50,000 ft it sounds a lot like what I was trying to do with Iaido. Using Template Toolkit for the presentation... abstracted data management... Need to look around more. I'd be more than glad to help you and maybe even have Iaido get eaten up by your project since I seem to have lost the momentum to sustain it by myself. There are a lot of neat things going in in Iaido, and still on my TODO list for it to get completely tossed, though. (Like, I really want to get that FTPd interface to the data store up and running again :) ) Anyway, having major problems getting past the oi_manage install_sql step so far, maybe I'll post to the -dev list or the bugs on sourceforge. It's probably early to talk about one project swallowing another :-) I'm certainly not shy about looking for great ideas wherever they are. And now that OpenInteract is out I hope to take a step back and look at other environments for inspiration. (Building some services on top of POE would be extremely cool, for starters.) One of the things OpenInteract has going for it is that a company (intes.net) uses it constantly and pays people to develop applications for it. I'm finding how difficult it is to do more programming after hours, even fun stuff like this. This is getting rapidly OT. Moving this onto the -dev list is a good idea. Thanks, Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: ANNOUNCE: OpenInteract Web Application Server
* Stephane Bortzmeyer ([EMAIL PROTECTED]) [010208 08:28]: On Tuesday 6 February 2001, at 21 h 57, the keyboard of Chris Winters [EMAIL PROTECTED] wrote: I'm jazzed to announce the public release of OpenInteract, an extensible web application framework using mod_perl and the Template Toolkit as its core technologies. Anyone compared it to Zope http://www.zope.org/? I'm hesitating. Hi Stephane, Sorry I missed the conversation earlier. Rotten time for the power to go out on my mail server... Well, everyone who has worked on OpenInteract would certainly be flattered by such a comparison. I think a lot of people have been inspired (and even made a little jealous) by Zope and the attention its drawn to Python. Competition is a healthy thing. :-) To be honest, I don't know as much about Zope as I probably should. However, after tooling around with it for a bit there were a number of lessons I've drawn. * Make it easy to develop custom modules. Like Zope, OpenInteract makes it pretty simple to write a self-contained module that implements some functionality, package it all up and send it to someone else to install on their server. * Make installation easy. Zope has an easier time of this because it's more self-contained, but it's extremely important for people to install the server without going through painful contortions. My experience with many other software packages has been this -- if I can get something running quickly, it's worth my while to look into it further. * Be consistent. In Zope, everything is (or is supposed to be) an object. We try to do the same thing. This makes certain tasks (like object/task security or relating entirely disparate things) possible and even pretty easy. Once you've got the mindset it also opens up interesting possibilities :-) * Even awkward browser-based tools can work. Using TEXTAREA boxes to create templates and pages is clunky but amazingly handy. And for most people it's all they need. People who know what they're doing can import templates to the database in their sleep, but don't design everything around them. I'm sure there are more similiarities and differences. (Along with strengths and weaknesses, but we can do that on the openinteract-dev mailing list. :-) I'd be interested in what people who know more about Zope think are its strengths and weaknesses. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
ANNOUNCE: OpenInteract 1.06
A new version of OpenInteract has been released. OpenInteract is an extensible web application framework built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. Quick change notes: - Move to a text-based package repository format -- GDBM is no longer required. - Add new tasks for 'oi_manage' to make upgrading easy and to allow websites to always maintain the most current version of the documentation. - Several bugfixes, including one which prevented MySQL version 3.22 and earlier from using the automatic SQL installation process. URLs: Download the source (also available on CPAN): http://sourceforge.net/project/showfiles.php?group_id=16810 Release notes/changelog (much more detailed than above): http://sourceforge.net/project/shownotes.php?release_id=25295 Sourceforge home (mailing lists, CVS, bugs, etc.): http://sourceforge.net/projects/openinteract/ Other home: http://www.openinteract.org/ Thanks! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
win32 mod_perl, libapreq questions
First: big thanks to Randy Kobes for making the mod_perl PPMs available. This is a huge help to getting mod_perl running on Win32. I've installed the mod_perl 1.25 + Apache 1.3.19 PPM without a problem, and the mod_perl stuff runs fine. (It's loaded as a shared object, which I guess is necessary for Win32 systems.) However, I found that when I wanted to use Apache::Request functionality (including Apache::Cookie), I got a message that ApachePerlModule.dll could not be found in the library path. Copying one of the ApachePerlModule.dll files from the Win32/mod_perl repository let everything boot okay, and basic mod_perl functionality is there. However, once I try to use Apache::Cookie I get the following error in a popup 'Red X' dialog: The instruction at "0xblahblah" referenced memory at "0x". The memory could not be "read" What can I do about this? Using something else to parse cookies is certainly an option (for the short term), but if there's a way around that I'd certainly prefer taking it :-) If I need to compile something (or try) I can do so, since this machine has VC++ 6 on it. (I'm used to unix systems where a compiler/environment is taken for granted :-) I can provide many more details about the system, setup, etc. if necessary. Thanks much, Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: win32 mod_perl, libapreq questions
* Randy Kobes ([EMAIL PROTECTED]) [010304 23:59]: Sorry about that - I forgot that the libapreq development version required the addition of hvrv2table in the mod_perl build that isn't there by default. The file http://theoryx5.uwinnipeg.ca/ppmpackages/mod_perl-1.25_1.3.19-libapreq.ppd contains this modified mod_perl build - this should fix the above problem. Excellent -- this seems to work perfectly! Thanks. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: [OT] JMS-like event framework for Perl
* Michael A. Nachbaur ([EMAIL PROTECTED]) [010310 14:25]: Since today seems to be "The Day of the Off Topic(tm)", I thought I'd jump in with my question. Is there a event messaging framework available for Perl, similar to JMS? I'd like to be able to have an object registered as a handler for certain "events", and have perl code throw those events causing the object to be run automatically (publish / subscribe model). I could probably implement something like this to finish my project, but I'd rather not do a one-off. Does anyone know of anything that can accomodate this functionality? If I'm the first one trying to modularize this, what features would you like to see? Hi Michael, Just to put another 2 cents in -- I have this exact same idea and interest. I setup a project on Sourceforge for it (sourceforge.net/projects/perlmq/) but haven't been able to put together an initial ideas document yet. (Real life intrudes.) JMS seems to me a good model to follow as well. Why not use all that hard work lots of people have already done? :-) My initial thoughts were to base both the client and server around POE. Messages would be standard objects but would have different types of payloads: scalar, hash, array, object, XML document. SOAP would be another way to request/send messages as well. There is a mailing list on the sourceforge site to which we can move all this discussion, if you'd like. (That way it will all be archived in one place :-) Thanks! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: is Apache::Request upload-fh lazy or not?
* Thomas K. Burkholder ([EMAIL PROTECTED]) [010414 04:28]: ... I'd like to write upload code that shows progress (via a fork and refresh header trick - don't worry about that). What I'm wondering is, by the time I get $fh above (or even by the time I'm in the handler for all I know) do I already have the entire file uploaded, or is it done lazily as reads are performed on $fh? I'm not very good at reading this XS stuff, but I looked at libapreq and from that I suspect it's all done up front. Is there any way to read it incrementally? Has anyone solved this problem before? I want to provide an upload function for my web app that shows the user periodic progress or maybe even allows them to cancel it part way through. Is this too much of a reach for http/mod_perl? AFAIK, the server doesn't even start processing the request until the entire file is uploaded. In the past (when it's absolutely necessary) I've popped up a tiny Javascript window telling the user to be patient (or whatever) while the file uploads. The returned page has an onload() handler which closes the window. It's not a progress bar, but it's something that hopefully prevents the user from getting impatient, clicking the browser's 'Stop' button and resubmitting the request. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Syntax errors across multiple virtual hosts with separate codebase
* Tommy Davis ([EMAIL PROTECTED]) [010502 04:11]:
We use a server-setup with a mod_perl enabled backend server. The server
only runs mod_perl and mySQL for about 5 virtual hosts.
...
Another problem is that the solutions uses diffferent databases. That
means we end up with 5 ttimes as many open db handles as we have
mod_perl processes.
We have worked around this by merging all databases into a single one,
prefixing the table_names with the former db-names and using a simple
abstraction layer to access the database.
I'm not sure how you create your database handles (in a central
location then passed around, or in each handler as you need it), but
in MySQL (as with other databases) you can execute a 'use dbname' to
start using a different database.
So your definition can be the same for all virtual hosts but you can
define a variable via PerlSetVar or in a configuration file that has
the database name. When you ask for a database handle you can then
create it using a common database name (e.g, 'mysql') and then
execute the 'use dbname' statement:
package MyServer::DB;
use strict;
use DBI;
my $DB_USER = '';
my $DB_PASS = '';
sub connect {
my ( $class, $dbname ) = @_;
my $dbh = DBI-connect( 'DBI:mysql:mysql', $DB_USER, $DB_PASS,
{ RaiseError = 1 } )
|| die $DBI::errstr\n;
$dbh-do( use $dbname ) if ( $dbname );
return $dbh;
}
We do something like this in OpenInteract and, for MySQL at least, it
works fine.
Chris
--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.
Re: Object - RDBMS mapping tools and mod_perl
* Ray Zimmerman ([EMAIL PROTECTED]) [010510 11:39]: I'm looking for a good package to use for Object - RDBMS mapping in the context of mod_perl and Mason. Something that will handled object inheritance and nested objects, etc. I'm aware of Tangram, Alzabo and SPOPS (not sure all these do what I need) ... are there any others? Any particular reasons why any of these may not play with with mod_perl/Mason? SPOPS plays very well with mod_perl -- it's an integral part of the OpenInteract web application framework which (currently) depends on mod_perl. If you wind up using it, there's some initialization you'll probably want to do at server startup and in the child init phase -- let me know if you're interested and I'll pull the SPOPS-specific stuff out of OpenInteract. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: [Mason] Object - RDBMS mapping tools and mod_perl
* Dave Rolsky ([EMAIL PROTECTED]) [010510 12:43]: ... I think the author of SPOPS is also a mod_perl user (I'm pretty sure he's posted to the mod_perl list in the past) so I'd expect it to play nice. Mostly one of the 'silent majority', tho :-) (Plus, we met at last year's YAPC -- sheesh, the memories on some people! ;-) (Sidenote: how many folks are going to YAPC this year?) ... I'm not sure exactly what the goal of SPOPS is, so I'll let the author speak for himself. (gee, that sounds like an invitation to get out the...) soapbox SPOPS is built to map objects to relational databases, or other data stores. If you're just getting/setting object properties and persistence (create/update/fetch/remove) along with relationships among the objects, you don't even need to write any Perl code. Just some fairly simple configuration info. Plus you can (if you wish) get per-object security for free. IMO, it also works quite well in an environment where you need to retrofit a framework onto an existing datastore, since SPOPS doesn't require special fields or tables (unless you're using security). /soapbox More upon request, or on the OpenInteract (sourceforge.net/projects/openinteract/) mailing lists. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Object - RDBMS mapping tools and mod_perl
* Ray Zimmerman ([EMAIL PROTECTED]) [010511 08:01]: Using Dave Rolsky's OO-RDBMS vs RDBMS-OO sort of description of Tangram and Alzabo, it sounds like SPOPS is more in the same category as Tangram, correct? That's correct. I think Tangram is more of a 'pure' object storage solution than SPOPS is, and, IIRC, Tangram also requires you to modify your table schema to use it. Anyone (including Chris) done a comparison of the two (SPOPS and Tangram) and willing to comment on strengths, weaknesses, differences, etc? That is an excellent idea and would be quite useful. I'll see what I can do in the (relatively) near future. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: forced win32 mod_perl
* Tom Gioconda ([EMAIL PROTECTED]) [010524 20:06]: My company, to my objections, recently decided to force all of our new servers to running only Win2k. I won't go into the details, but let's just say that in our standard hosting facilities, nothing runing Linux is allowed anymore. This kinds of screws my department, as we have just finished development on a Linux/Apache solution tied heavily into mod_perl for a support web site. This leaves me with few options: 1) Run Apache/win32 and mod_perl. 2) Run IIS 5 and use an ISAPI handler to hook into my perl code. Could anyone help me out here? The first option is bad because of mod_perl's reduced functionality on win32 in version 1.25 (no threads, to my understanding). Option 2 is evil because I'd have to figure out some way to get an ISAPI extension to call perl code in a multithreaded way, and I'd have to use IIS. Am I stuck waiting for Apache 2 and mod_perl 2 to get to a point where they'll work in a production environment, or am I simply screwed and have to work around my company's dumb decree? Any help would be appreciated, although no comments on my company's IT policies, please... :) ActiveState sells a (IMO) cheap solution for just this sort of thing: PerlEx. (http://www.activestate.com/perlex/) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: forced win32 mod_perl
* Tom Gioconda ([EMAIL PROTECTED]) [010524 23:03]: It was my impression that PerlEx handled the persistance and what not, but it wouldn't allow one to make a content handler using perl. I need some way of processing every html file through my TemplateHandler::handler method. The way I was doing this was telling Apache to use my method as the content handler, instead of Apache just return the results, I was processing the file and sending those results to the client. PerlEx only does the part that keeps the perl interpreter running, right? It keeps a pool of interpreters running, and I'd *thought* that you could make something akin to a content handler (by using the directory mapping stuff) but on second thought it doesn't appear so. (I haven't used it for quite some time...) If it does more, is there documentation that shows how this is done? I certainly couldn't find anything about content handlers on their sites. I hadn't realized you were so tied to the mod_perl way of doing this, my bad. I heard the magic words 'forced to move to Win2000' and my reflex kicked in :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
OpenInteract 1.07 released
A new version (1.07) of OpenInteract has been released. OpenInteract is an extensible web application framework built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. Quick change notes: - Works with Win32 (thanks to the work of Randy Kobes!) - Now supports PostgreSQL, Sybase ASE/ASA and MS SQL Server (in addition to MySQL) - Many bugfixes and general enhancements URLs: Download the source (also making the CPAN rounds): http://sourceforge.net/project/showfiles.php?group_id=16810 Release notes/changelog (much more detailed than above): http://sourceforge.net/project/shownotes.php?release_id=38867 Sourceforge home (mailing lists, CVS, bugs, etc.): http://sourceforge.net/projects/openinteract/ Other home: http://www.openinteract.org/ Finally, I'll be at YAPC North America talking about OpenInteract on the morning of June 15 (Friday). If you're around, stop by and say hi. Thanks! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: CGI::Cookie vs Apache::Cookie -- help?
* will trillich ([EMAIL PROTECTED]) [010617 23:04]:
mine is similar:
$r-log_error( qq(...id=$ID, sending cookie) );
my $cookie =
Apache::Cookie-new( $r,
-name = $cookie_name,
-value = $ID ,
-domain = $r-hostname,
-path = '/' ,
);
$r-header_out('Set-Cookie', = $cookie);
which sets a cookie value of SCALAR(0x863c9f8) instead of the
$ID string that shows up in the log, which is
...id=483dd0e2202accce6d4d3e07d976bfdc, sending cookie
in the original ticket example above, -value is a hashref:
-value = { ID = $ID }
instead of
-value = $ID
as the Apache::Cookie manpage suggests (a plain scalar value).
this worked just fine with CGI::Cookie (without the $r, of
course) -- can't get it to return the actual scalar value with
Apache::Cookie...
ideas? help!
From 'perldoc Apache::Cookie'
bake
Put cookie in the oven to bake. (Add a Set-Cookie
header to the outgoing headers table.)
$cookie-bake;
as_string
Format the cookie object as a string:
#same as $cookie-bake
$r-err_headers_out-add(Set-Cookie = $cookie-as_string);
HTH
Chris
--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.
OpenInteract 1.1 released
A new version (1.1) of OpenInteract has been released. OpenInteract is an extensible web application framework built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. Quick change notes: - New package 'results_manage' makes it simple to manage and persist generic search results and/or objects - Many packages use the new SPOPS iterators to return results, which should reduce resource consumption, in some cases dramatically. - Many modules were moved from the 'base' package to the core distribution, which will hopefully make the whole process more understandable -- and browseable via 'perldoc'. - Many bugfixes and general enhancements URLs: Download the source (also making the CPAN rounds): http://sourceforge.net/project/showfiles.php?group_id=16810 Release notes/changelog (much more detailed than above): http://sourceforge.net/project/shownotes.php?release_id=44382 Sourceforge home (mailing lists, CVS, bugs, etc.): http://sourceforge.net/projects/openinteract/ Other home: http://www.openinteract.org/ Thanks! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: [OT] Inspired by closing comments from the UBB thread.
* Joe Breeden ([EMAIL PROTECTED]) [010801 10:25]: All, In his closing comments about UBB Kyle Dawkins made a statement that got me wondering. He said there's SQL embedded all throughout the Perl everywhere (who does this?! oh my god, are they on crack?). This comment got me wondering about alternatives to embedding SQL in to the code of a program. Alternatives I see are to use stored procedures which would limit one to using a certain DB server (or to be proficient in many servers and write stored procedures for all server flavors which would mean one is a very busy Perl and SQL guru) or possibly storing the embedded SQL in some sort of external file structure accessible via storable, XML::Simple or some other means. It would be interesting to know how other people have solved that problem. Currently, we are essentially using embedded SQL in our apps. As others have mentioned, one way would be to wrap your records in objects and have access, queries, etc. be centralized there. plugSPOPS (Simple Perl Object Persistence with Security) does this for you and gives you object linking and high-level database independence for free. It's on CPAN./plug Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
ANNOUNCE: OpenInteract 1.2
The following message is a courtesy copy of an article that has been posted to comp.lang.perl.announce as well. A new version (1.2) of OpenInteract has been released to CPAN. OpenInteract is an extensible web application server built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. This is a substantial upgrade -- if you're upgrading from an old version, please read the 'UPGRADE' and 'Changes' files. - Now supports LDAP for use as an object store and authentication backend. Thanks to MSN Marketing Service Nordwest GmbH for funding development! - Beter Template Toolkit integration with a TT Provider and TT Plugin - Many bugfixes and general enhancements URLs: Download the source (also making the CPAN rounds): http://sourceforge.net/project/showfiles.php?group_id=50416 Release notes/changelog (much more detailed than above): http://sourceforge.net/project/shownotes.php?release_id=50416 Sourceforge home (mailing lists, CVS, bugs, etc.): http://sourceforge.net/projects/openinteract/ Other home: http://www.openinteract.org/ Thanks! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Template or XML = OpenInteract?
* BeerBong ([EMAIL PROTECTED]) [010915 07:43]:
We have also heard something about OpenInteract, which is based on
Template Toolkit - may be it would be simplier to use it?
It does sound like a possible good choice for your purposes, since it
combines a basic application structure with Template Toolkit integration
and
an object/relational mapping tool (SPOPS) for data management.
It seems to be interesting application.
We developed many content management systems for sites with more than one
access rights levels and more than one databases as storage of content
(MySQL and Oracle, if be precise).
May be we will use it, although it (SPOPS-0.50) don't want be compiled on my
home WinXP environment.
Errors while SPOPS make test
t\30_dbiok 4/18se of uninitialized value in string at
C:/TEMP/SPOPS-
0.50/blib/lib/SPOPS/DBI.pm line 634.
SPOPS::DBI::_save_insert (634) Insert failed! Args: $VAR1 = {
'db' = bless( {}, 'DBI::db' ),
'is_add' = 1,
'table' = 'spops_test',
'skip_cache' = 1,
'field' = [
'spops_goop',
'spops_id',
'spops_name',
'spops_num'
],
'value' = [
'oopie doop',
42,
'MyProject',
241
],
'return_sth' = 1
};
This probably depends on the database you're using as to why it
failed. We can definitely help out with this, but there are separate
mailing lists for this so we don't bog down the modperl list.
and if I make install, I get a similar errors while do
oi_manage --package=INITIAL install_sql
Ditto as above. I'll take this msg over to the list to see if we can
help out.
Chris
--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.
Re: Template or XML?
* Perrin Harkins ([EMAIL PROTECTED]) [010914 17:11]:
We have also heard something about OpenInteract, which is based on
Template Toolkit - may be it would be simplier to use it?
It does sound like a possible good choice for your purposes, since it
combines a basic application structure with Template Toolkit integration and
an object/relational mapping tool (SPOPS) for data management.
OpenInteract will probably do what you want, but one of its design
philosophies is to have the templates to relatively simple work and
handlers do the real data manipulation. So from the example in your
original message:
[% data=fetch({sql=SELECT MessageId, Subject FROM Messages}) %]
You might do something like
package MySite::Handler::Messages;
sub listing {
my ( $class, $p ) = @_;
my $R = OpenInteract::Request-instance;
my $message_iterator = eval { $R-message-fetch_group };
my ( $error );
if ( $@ ) {
$error = Cannot retrieve messages: $SPOPS::Error::system_msg;
}
return $R-template( {}, { iter = $message_iterator,
error_msg = $error },
{ name = 'mypkg::message_list' } );
}
And in your template:
--
h1Summary of messages/h1
[% IF NOT iter.has_next -%]
pSorry, no messages to display./p
[% ELSE -%]
table border=0
[% WHILE ( message = iter.get_next ) -%]
tr
td[% message.subject %]/td
td[% message.from %]/td
[% view_url = OI.make_url( base = '/Message/show',
message_id = message.id ) -%]
tda href=[% view_url %]View message/a/td
/tr
[% END -%]
/table
[% END -%]
--
So in your handler you have the option of ordering the messages as you
wish, screening certain ones out, etc. And the template can make
simple display decisions but doesn't do much with the data besides
display it.
One last thing: I'm not sure how large your application is, but for
small applications OpenInteract is most likely overkill. The only way
I'd write something simple (e.g., a guestbook) in OI is if I already
had an OI system installed and wanted to extend it.
Hope this helps,
Chris
--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.
Re: Using DOM to build your output documents
* Jeffrey W. Baker ([EMAIL PROTECTED]) [011003 19:52]: I'd love to hear any other experiences with using the DOM to build output from scratch. I'd also like to hear people's opinions on XML::DOM (I think it stinks and I've replaced it with a C DOM implementation). I can't speak to XML::DOM, but I used XMLC in Java to do this and there were aspects that were pretty nifty. In particular, building a list-type structure (table rows in particular) and then feeding it to a visitor process that modified the properites of each item worked really well. XMLC works by compiling an XML document to a Java class which you then manipulate. This was excellent for working with designers, since they didn't have code or looping structures or anything cluttering up the HTML. Just some ID tags the coders told them to use. IIRC, building things from scratch was a PITA. But that could have been my lack of experience with it too :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: eval error
* David ([EMAIL PROTECTED]) [011107 14:05]: Hello, I am getting this error message. Can anyone tell me what it is and how to get rid of it. (or if I need to worry about it) [Wed Nov 7 18:52:40 2001] [error] [Wed Nov 7 18:52:40 2001] Gateway00.pm: Apache/Gateway00.pm did not return a true value at (eval 146) line 3. Yep -- read the part in 'perldoc perlmod' about returning a true value from your module. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
[JOB] OpenInteract developer wanted
A company I've been working with asked me to post this job. You'd be working with a substantial (and growing!) OpenInteract system that I designed and built, which could be a plus or a minus depending on how you look at it :-) Feel free to ask me for details. Chris URL with full description: http://jobs.perl.org/job/97 Location: (USA) Pittsburgh, Pennsylvania Hours: Full-time, onsite Description: This position will join a team responsible for the development and maintenance of an interactive data management system for internal use. Position requires significant experience with intranet development using OpenInteract, HTML, Perl, SQL, and Apache/mod_perl. DB2 on AS/400 is also desired. Experience in a Win32 environment needed with possible Linux migration. Knowledge/Experience: BA/BS with minimum 4 years progressively responsible experience within administrative computing environment; demonstrated experience on a technical team; excellent analytical skills; detailed knowledge of database design and relational technology with demonstrable mastery Experience with OpenInteract, Template Toolkit, SQL, Perl and programmatically generated HTML very highly desired. Also: Apache/mod_perl administration, knowledge of MySQL and IBM DB2 on AS/400, C/C++, thin client or web driven applications development experience. Contact information: To apply or for information, send resume, salary requirements, references and a sample of your work (a small web-dbi script or something) to [EMAIL PROTECTED] No 3rd Parties please. Only US Citizens or authorized to Work for any employer in the US. P.S. Recruiters are 3rd parties, see above.
[ANNOUNCE] OpenInteract 1.35
A new version (1.35) of OpenInteract has been released to CPAN. OpenInteract is an extensible web application server built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. This is a substantial upgrade, with two new packages, support for the INI-style server configuration format and many changes to the server configuration. The new packages are 'object_activity' and 'base_page'. The first enables search and display of the object logging activity. The second replaces the 'static_page' package with support for uploads, aliases, and (crude but working) URL support. As always, the many other modifications in this release are listed in the Changelog (URL below). URLs: Download the source (also making the CPAN rounds): http://sourceforge.net/project/shownotes.php?release_id=63337 Release notes/changelog (much more detailed than above): http://sourceforge.net/project/shownotes.php?release_id=63337 Sourceforge home (mailing lists, CVS, bugs, etc.): http://sourceforge.net/projects/openinteract/ Other home: http://www.openinteract.org/ Thanks! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Installing mod_perl 1.26 on solaris 2.7
* James G Smith ([EMAIL PROTECTED]) [011129 14:11]: I have the 1.26 tarball untar'd and run the following command: % find . -name Request.pm -print It prints nothing. Is there supposed to be an Apache/Request.pm file somewhere? Apache complains that it can't find it on startup (I'm trying to use HTML::Mason). Apache::Request is a separate package -- IIRC you can install it from CPAN no problem. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
[ANNOUNCE] OpenInteract 1.30 released
A new version (1.30) of OpenInteract has been released to
CPAN. OpenInteract is an extensible web application server built on
Apache, mod_perl, the Template Toolkit and SPOPS object persistence.
This upgrade has some new features, feature enhancements and bugfixes
and is fairly substantial. However, there should be no upgrading
issues as in the 1.1 - 1.2 transition. Some of the larger changes:
- A new class (OpenInteract::CommonHandler) makes it very easy to
create common search/display/edit/remove tasks that act on data in a
database.
- Some simple template widgets are included, which make it easy to
centralize common visual elements.
- Template performance should be improved dramatically, since both
template caching and compiling work properly now
- A new package ('lookup') is included to enable editing of lookup
table data without writing any code at all.
As always, the 'Changes' file has many more items and details.
URLs:
Download the source (also making the CPAN rounds):
http://sourceforge.net/project/showfiles.php?group_id=57075
Release notes/changelog (much more detailed than above):
http://sourceforge.net/project/shownotes.php?release_id=57075
Sourceforge home (mailing lists, CVS, bugs, etc.):
http://sourceforge.net/projects/openinteract/
Other home:
http://www.openinteract.org/
Thanks!
Chris
--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.
Re: Mod_perl component based architecture
* Michael ([EMAIL PROTECTED]) [011016 15:37]: Are any of the packages mentioned particularly suited to client content management packages where the client can manage some limeted page content text/graphics but not really mess with the overall page layout and site content. I'm about to start researching this but would like input from the experts. OpenInteract (http://www.openinteract.org/) has page-editing (and template-editing) capabilities from the browser. Currently you need to keep all the content in the database to make this work, but I'm working on being able to edit content in the filesystem as well. I wouldn't call it a content-management system really, but users find it pretty useful to see a typo, click on 'Edit this Document', make the change and see it instantly. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Mod_perl component based architecture
* Bill Moseley ([EMAIL PROTECTED]) [011016 16:49]: I'm just bored with html forms. Seems like I do this kind of project too often -- read a record, post, validate, update... Even with good templating and code reuse between projects I still feel like I spend a lot of time re-inventing the (my) wheel. Will an application framework bring me bliss? I'm sure this is common type of project for many people. What solutions have you found to make this easy and portable from project to project? An application framework *can* bring you bliss -- but like a lot of solutions that do a lot you need to buy into how it does things or hope that it's flexible enough for you to change it. In addition, a framework should be able to encourage reuse because you can concentrate on the interesting things (what is the data? how does it act?) rather than the boring things (security, user/group management, templating stuff). The boring things are there to be used, but they're a given. Good frameworks should IMO also make it easy to package up the interesting things and keep them separate from one another, so you can run as many code-test iterations as you need in your development environment, bundle up the interesting code (object definitions, schemas, business logic, display logic) and install it to the production environment without much hassle. Chris PS - (plug plug) OpenInteract has as of 1.30 a new module (OpenInteract::CommonHandler) to make the typical search/display/edit/remove functinonality extremely easy. -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Mod_perl component based architecture
* Nick Tonkin ([EMAIL PROTECTED]) [011016 17:28]: ... I guess in general I favor independent component APIs upon which you can build, a la Apache::Session, rather than the monster Application Servers ... it seems that you get the same effect but with more control. Of course, I've had the luxury of afew years' experience; someone starting out may prefer a canned solution ... Sure, and you'd probably find that a lot of application servers -- at least ones in Perl -- do this as well. For instance, the OpenInteract session handling is exactly as you describe, a thin interface layer around Apache::Session. Templating is through Template Toolkit, etc. Leveraging the work of all the smart people in the community is, to me, a no-brainer. My view is that an application server makes all this stuff work together, consistently, and then adds functionality on top of it rather than in place of it. But if you've been working on and building up a platform for 4+ years that already does this, then there's very little to be gained and lots to be lost by moving to an application server. :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: User customisable website application?
* Russell Matbouli ([EMAIL PROTECTED]) [011209 19:44]: As the final year project for my degree, I'm implementing a user-customisable website application (aimed at multiuser websites) in mod_perl. Can anyone tell me if something like this already exists? My searches so far haven't turned up anything like this. Just to clarify what I mean by customisable - the user can log in and change their colour scheme, font, ordering of components, choose a theme... The sort of thing you see on some commercial websites. The application servers listed at the mod_perl site [1] should be a good start. (Altho I note that the recently announced OpenFrame [2] isn't on there.) Speaking for OpenInteract, I can say that this is definitely possible without a huge amount of work. The color scheme, font, theme etc. is already there, and the component ordering and such would be fairly simple to add in. Chris [1] http://perl.apache.org/#appservers [2] http://openframe.fotango.com/ -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
[ANNOUNCE] OpenInteract 1.37
A new version (1.37) of OpenInteract has been released to CPAN. OpenInteract is an extensible web application server built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. Upgrades should be easy, with one table schema change as noted in the 'Changes' file. OpenInteract now supports inheritable directory handlers, allowing you to create custom actions for directory index requests. You can also expire inactive sessions. As always, the many other modifications in this release are listed in the 'Changes' file. Source (also via CPAN): http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.37.tar.gz Detailed changes: http://sourceforge.net/project/shownotes.php?release_id=70689 Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: libapreq problem and mozilla 0.97
On Tue, 2002-02-05 at 20:43, Rob Mueller (fastmail) wrote: Just wondering if anyone has encountered this before and if it's been fixed in libapreq for the upcoming release. Basically, whenever I try and use Mozilla 0.97 with a file upload field on a form and don't select any file in the field, libapreq seems to hang on the $R-parse() call. Mozilla 0.98 seems to work fine, but 0.97 doesn't. While it's easy enough to just say upgrade, it's still annoying that it hangs a process for a while until our alarm goes off. ... This is a known (and amazingly frustrating) bug in Mozilla rather than libapreq. It affects browsers based on mozilla (Galeon, etc.) as well, but it's been fixed (as you noted) in 0.9.8. For more info: http://bugzilla.mozilla.org/show_bug.cgi?id=116210 Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
[ANNOUNCE] OpenInteract 1.38 released
A new version (1.38) of OpenInteract has been released to CPAN. OpenInteract is an extensible web application server built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. This is a fairly minor upgrade: you can now cache user, group and theme objects in a user session, which should make for fewer overall database requests. There are some flexibility enhancements in the CommonHandler and a small number of other minor enhancements and bugfixes. As always, the many other modifications in this release are listed in the 'Changes' file. Source (also via CPAN): http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.38.tar.gz Detailed changes: http://sourceforge.net/project/shownotes.php?release_id=76969 Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Apache::Session problems
On Thu, 2002-02-28 at 06:16, Domien Bakker wrote: Hello, I am trying to use Apache::Session to store http session information. The version number of Apache::Session is 1.54. It is running on Apache/1.3.20 (Unix) mod_perl/1.26 configured. ... Both methods resolve to the same error: [Thu Feb 28 11:46:39 2002] [error] Storable binary image v24.48 more recent than I am (v2.4) at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 351, at /usr/local/lib/perl5/site_perl/5.6.1/Apache/Session/Serialize/Storable.p m line 27 Does anybody knows a sollution to this problem, as far as I can see, all Apache::Session modules are up to date. This sounds like someone with a more recent version of Storable in their private lib has been testing sessions or something, since there's a mismatch of what is in the database versus the module trying to read the data. Be sure you've got the latest version of Storable installed. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Pipelinning Output APP Framework
On Fri, 2002-04-05 at 12:41, [EMAIL PROTECTED] wrote: I know alot of you must do this. I want build a simple APP framework to chain the output of all my content handlers, which would live in many different PM's for easy code management. for example: APP::Header APP::Footer APP::Content APP::Chemical_entry APP::... APP::Controller - would push_handlers based on uri and/or app logic - The result would be the entire html output in ( via print array ) WHY ( so that my content can: ) - pass named paired parameters to following handlers - modify previous content ( eg update html header code with a msg from main content handler ) Is any one doing something similar that could be used in a production enviroment ? - via memvory - via tie ( the list messages seem to bash this approach ) - some other method You might look at OpenFrame, they're doing neat stuff with pipelines. It's on CPAN and at http://openframe.fotango.com/ Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
OpenInteract 1.40 released
A new version (1.40) of OpenInteract has been released to CPAN. OpenInteract is an extensible web application server built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. OpenInteract now runs on Oracle -- with one minor caveat: sessions. Many thanks to Ben Avery [EMAIL PROTECTED] for patient debugging and installs. Package configuration customization is centralized now -- package upgrades won't overwrite changes you've made. And different session storage backends -- filesystem and SQLite -- are now available. As always, the many other modifications in this release are listed in the 'Changes' file. Source (also via CPAN): http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.40.tar.gz Detailed changes: http://sourceforge.net/project/shownotes.php?release_id=88422 Thanks, Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Storing blessed objects via Apache::Session
On Tue, 2002-05-21 at 16:16, [EMAIL PROTECTED] wrote: I was attempting to store a blessed object via Apache::Session, but when the session is returned, the hash is empty. I did some google searching and ran across a similar question: http://www.geocrawler.com/archives/3/182/2000/5/0/3823715/ I have not found any other information, and was curious if there was something special that had to be done for this to work? Any and all help would be most appreciated! I have the latest Apache::Session-1.54. Nothing special should be required -- I've done this with no problem using recent versions -- 1.50+ -- of Apache::Session. The only way it might be a problem is if you're trying to save a special resource in the session -- database handle, socket connection, etc. Are you sure basic sessions are working ok? Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Storing blessed objects via Apache::Session
On Tue, 2002-05-21 at 19:19, [EMAIL PROTECTED] wrote:
Chris Winters writes:
Nothing special should be required -- I've done this with no problem
using recent versions -- 1.50+ -- of Apache::Session. The only way it
might be a problem is if you're trying to save a special resource in
the session -- database handle, socket connection, etc.
Are you sure basic sessions are working ok?
Yes, the basic functions work, but I do have a DBH inside the object.
That might be it. To test just do something like:
$session{foo} = bless( { hey = 'there' }, 'My::Class' );
save it, fetch it and see what happens when you do a 'ref
$session{foo}'.
You might want to either rethink having the database handle in the
object -- retrieving it from a common central location, for instance --
or create a simple function to copy the object without database handle
and set it into the session.
Chris
--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.
Re: separating C from V in MVC
On Mon, 2002-06-10 at 13:29, Ray Zimmerman wrote:
So how is everybody else handling URL mapping? Do others group this
kind of data together with fonts, colors, etc? And where do you
define it?
As Perrin mentioned, OpenInteract does this by allowing individual
packages (distributable applications) to define the handlers they
support. A package does this by defining actions which at server startup
get collected into a data structure called the action table.
A single mod_perl handler catches all requests, looks up the URL in the
action table and dispatches the request to the appropriate handler. That
handler is free to pass on the request to other actions as well, since
every part of the system is able to lookup actions based on a key.
Entries in the action table can also be used as components --
displayable items that don't stand by themselves but contribute to a
full page. Examples include boxes, common search forms, dependent object
listings, etc.
Currently, here's what an action looks like, as found in the 'base_user'
package distibuted with OpenInteract:
$action = {
'user'= {
'class'= 'OpenInteract::Handler::User',
'security' = 'no',
},
'newuser' = {
'class'= 'OpenInteract::Handler::NewUser',
'error'= [ 'OpenInteract::Error::User' ],
'security' = 'no',
},
};
All information is available through a lookup to the action table.
One of the modifications I'm working on now will allow you to add more
information to the action and have it available in an object that is
instantiated by the dispatcher which then tells the object to run
itself.
Chris
--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.
OpenInteract 1.41 released
A new version (1.41) of OpenInteract has been released to CPAN. OpenInteract is an extensible web application server built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. This is a fairly minor upgrade -- a few bugfixes and refactorings, plus the ability to use a centralized repository for your custom templates so they will not get overwritten with package upgrades. As always, the other modifications in this release are listed in the 'Changes' file. Source (also via CPAN): http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.41.tar.gz?download Detailed changes: http://sourceforge.net/project/shownotes.php?release_id=104968 Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Mod_perl Application Development
On Sat, 2002-08-17 at 19:31, Jonathan Lonsdale wrote: I'm curious to know how people approach application development with mod_perl in situations where there could be dozens of distinct screens/interfaces. I'm currently using the HTML::Template system. Here's a few approaches I thought of: 1. Single monolithic content handler. Could be hard to maintain. 2. Distinct content handlers each with their own Location directive. Could be a pain to maintain the server config. 3. Take a small performance hit and use an Apache::Registry script for each screen to handle the content phase. Use 'PerlSetupEnv Off', $r and Apache:: modules and don't bother being backwardly compatible with CGI. There's a separate one that's used in OpenInteract: create a single content handler that uses some sort of lookup table to map requests to handlers. This lookup table can be maintained separately from the apache configuration and can generally be more flexible, allowing for application-level security settings, etc. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
[ANNOUNCE] OpenInteract 1.50 released
A new version (1.50) of OpenInteract has been released to CPAN. OpenInteract is an extensible web application server built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. This version changes how templates are handled -- they're no longer accessible from the database. Browser-based template editing is back, however, and you can edit templates without having them overwritten with package upgrades. Documentation got a minor (but needed) overhaul. Thanks to Ben Avery for help. Source (also via CPAN): http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.50.tar.gz?download Detailed changes: http://sourceforge.net/project/shownotes.php?release_id=107160 Thanks! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: large projects in mod_perl
* Calbazana, Al ([EMAIL PROTECTED]) [020828 09:04]: I am not sure of what app server products/projects are out there now for Perl (maybe some were mentioned earlier). The building blocks are definitely there. I am sure someone has assembled, or is assembling, them to serve as a turn key app server. I'd like to hear more about projects that manage session state across a web farm, allow for remote objects, transaction management, etc... This should be useful: http://perl.apache.org/products/app-server.html Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988
[ANNOUNCE] OpenInteract 1.51 released
A new version (1.51) of OpenInteract has been released to CPAN. OpenInteract is an extensible web application server built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. This version adds caching for the data generated by content handlers. This is in addition to the caching already provided by the Template Toolkit. Since this is retrofitting a feature planned for the next version into the current one, enabling caching is not a transparent change. But it's not a difficult one either :-) Source (also via CPAN): http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.51.tar.gz?download Detailed changes: http://sourceforge.net/project/shownotes.php?release_id=109677 Thanks! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: [OT] Perl vs. PHP..... but where is mod_perl?
On Fri, 2002-10-18 at 17:46, Tobyn Baugher wrote: As someone fairly new to mod_perl could you make a suggestion of a good alternative to Apache::Cookie? I was using it just because, like Apache::Request, it was *there*. The pure-perl CGI::Cookie works fine. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: [RFC] Apache::LDAP
On Sun, 2002-12-01 at 20:32, James G Smith wrote: ( Actually, the name is chosen to `rhyme' with Apache::DBI. There are no dependencies on Apache or mod_perl. ) NAME Apache::LDAP - provides persistent LDAP connections Does this overlap with the ResourcePool series of modules? Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
ANNOUNCE: OpenInteract 1.56 released
A new version (1.56) of OpenInteract has been released. OpenInteract is an extensible web application server built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. This is a fairly minor upgrade. There is a fix to the INI configuration reader, documentation updates to a number of packages, a fix so that the (rare) package repository corruption shouldn't happen, and a few other enhancements and bugfixes. Source: http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.56.tar.gz?download Detailed changes: http://sourceforge.net/project/shownotes.php?group_id=16810release_id=140942 I'll release it to PAUSE when the main CPAN mirror gets over its recent difficulties. Thanks! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Browser doesn't stop loading a page
Martin Moss wrote: Not much to go on I know, but has anybody ever had this problem? When I load one of my webpages the browser never stops loading, e.g. the page loads ok and I can see and interact with it, but the ie spinning globe still keeps spinning and the status bar at the bottom of the page still shows the page is loading something.. The process does seem to run and exit normally in my logs. I'm at a loss as to what is causing it. This only happens on one specific page on my server. Any ideas would be appreciated. IME this means you have an external resource (e.g., image, script, etc.) in the page that's not being loaded because the site is inaccessible or it's overloaded. Generally nothing to do with mod_perl :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: advice on implementing a controller manager
Xavier Noria wrote: I am writing an application following MVC with Perl Apache modules and the Template Toolkit. Apache is 1.x. I would like to have just one entry point to the application, which would play the role of someone who sets everything necessary up and forwards the actual request to a selected handler. From what I have read, looks like implementing that controller as a PerlFixupHandler which would use push_handlers() and pass things via pnotes() would be fine, but I am not experienced in mod_perl. Would you suggest a different approach? A word of advice: if you'd like to use it under different web environments, create your own system for registering/calling handlers instead of using the Apache API. That is, have a map of URL-to-class and have your controller find the class to execute based on the URL and call it directly. This is how OpenInteract does it and it's saved quite a lot of grief. It also makes for nice decoupling which is always a good thing. Of course, you could use OpenInteract as an MVC framework that uses the Template Toolkit, but that's a different matter... :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
[ANNOUNCE] OpenInteract 1.99_01 (2.0 beta 2) released
The second beta of OpenInteract2 (1.99_01) has been released to CPAN and SourceForge. The release: includes many documentation updates, has a totally revamped logging system using log4perl, supports multiple content generators, introduces content filters and has a bunch of other features, fixes and improvements. A detailed changelog is online [1], as are the HTML-ified docs [2]. And if you can't wait for your CPAN mirror you can download it immediately.[3] Thanks, Chris [1] http://sourceforge.net/project/shownotes.php?group_id=16810release_id=169294 [2] http://openinteract.sourceforge.net/docs/oi2/ [3] http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.99_01.tar.gz?download -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: templating system opinions
Perrin Harkins wrote: The one thing about TT was that I don't know if I really liked how it had a different syntax than perl. Plus, as far as performance, we did some specific coding to make it faster for Slash so our templates would be in the DB. That's an anti-optimization. Filesystems are faster than databases when all you want is to fetch a single item with a specific name. It's also a pain in the ass to edit things that are in a database, as opposed to just files. I agree -- filesystems have all these great new remote access protocols like ftp and scp. That's why I took this option (storing templates in the database) out of OpenInteract. Well, actually you can still do it, I just make it really tough :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Templating system opinions (CGI::Application in connection witheither HTML::Template or Template::Toolkit)
Eric wrote: That was really interesting to look at. OpenInteract is really impressive. I guess there is always a cost to having a big do it all type of system. That is what made me avoid Mason, it just blew my head off for complexity. Now it is true, I am looking for a bit more than what CGI::Application offers out of the box, but it may well end up being worthwhile to just extend rather than convert. I really appreciate the simple philosophy that HTML::Template and CGI::Application follow. OpenInteract definitely does more for you. But it also has (IMO) a fairly sophisticated way to distribute standalone applications -- including data structures, initial data, security settings, templates and (oh yeah) the actual perl code -- and plug them into another OI server. OI 1.x ties you to the Template Toolkit, but 2.x (a big improvement now in beta) allows you to use whatever templating engine you like. You lose a ton of functionality, but HTML::Template folks seem to like it that way :-) One question, how do you judge that OpenInteract is more established? Is does look like it is actively developed, but I never heard of it before, and I couldn't find much indication of how popular it is. Randal's 'far more established' may be premature :-) Taking a strict time perspective: from Backpan it looks like CGI::Application was first released to CPAN in July 2000, while OI was first released in February 2001. (I'd thought it was October 2000, but it's funny the tricks your memory will play.) As to other definitions of 'established' I haven't followed CGI::Application development to say either way. There have been more articles published on CGI::Application and it seems to have a larger userbase, partly because it's easier to get started with and wrap your head around everything it does. Classic trade-off :-) Good luck! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Templating system opinions (CGI::Application in connection witheither HTML::Template or Template::Toolkit)
Dave Rolsky wrote: There's a fine book about it. www.masonbook.com Just an unbiased opinion ;) Hey, I'd be happy to write a book about OpenInteract ;-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Application design patterns
Frank Wiles wrote: I too would like to would like to have a better understanding of how MVC can be applied to mod_perl. Maybe even HelloWorld sized example showing how all of the different components interact? No examples, but Andy Wardley sent a great email to the Template Toolkit mailing list a few months ago about MVC and web apps: http://lists.ourshack.com/pipermail/templates/2002-November/003974.html Also no examples but possibly helpful: I place the OpenInteract2 components in an MVC context (will be in next beta): http://openinteract.sourceforge.net/docs/oi2-snapshot/OpenInteract2/Manual/Architecture.shtml Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
ANNOUNCE: OpenInteract 1.60 released
A new version (1.60) of OpenInteract has been released. OpenInteract is an extensible web application server built on Apache, mod_perl, the Template Toolkit and SPOPS object persistence. This release includes a handful of fairly small enhancements, including the ability to force everyone to login before seeing any part of your site. HTTP redirects (vs. using icky META tags in HTML) are also supported, and under certain circumstances we now force the Apache child into a premature death. Source: http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.60.tar.gz?download Detailed changes: http://sourceforge.net/project/shownotes.php?release_id=178076 It's also winging its way around CPAN. Thanks! Chris PS: Most of these changes were actually in 1.59 but 1.60 was a release of the oops-fifteen-minutes-later variety. -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[ANNOUNCE] OpenInteract 1.99_03 (2.0 beta 3) released
The third beta of OpenInteract2 (1.99_03) has been released to CPAN and Sourceforge. (Release 1.99_02 was skipped for consistency.) This release includes: * Many documentation updates, including a full package development tutorial * Actions can store messages to be passed from the controller to the view, which combined with a decent templating system makes it a piece of cake to have error-aware input fields * API for management tasks has been modified to make adding tasks easier * Lots more tests (like anyone cares...) * Tons of assorted improvements and fixes throughout the system. A detailed changelog is online [1] as are the HTML-ified docs.[2] And if you can't wait for your CPAN mirror you can download it immediately.[3] Thanks, Chris [1]http://openinteract.sourceforge.net/docs/oi2/OpenInteract2/Manual/Changes.shtml [2]http://openinteract.sourceforge.net/docs/oi2/ [3]http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.99_03.tar.gz?download -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
