Re: ANNOUNCE: Bricolage 1.2.0
Basel, Freitag, 11. Januar 2002, 10:26:28 . *see original email below* Hello David Bricolage is a full-featured, enterprise-class content management system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete programming language support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. Do you provide a demo of Bricolage. Can I expect something similar to the Midgard Project on PHP? Best Regards Christian - [EMAIL PROTECTED] - . == beginn original == Date: Freitag, 11. Januar 2002, 04:06:23 Subject: ANNOUNCE: Bricolage 1.2.0 I'd like to announce the release of Bricolage 1.2.0. It will shortly be available for download from http://bricolage.sourceforge.net/. This release features several bug fixes and quite a few important new features. It uses HTML::Mason exlusively for its UI, and uses either HTML::Mason or HTML::Template for its templating architecture. Here's a brief description of Bricolage: Bricolage is a full-featured, enterprise-class content management system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete programming language support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. Here's a list of the changes from 1.0.2: VERSION 1.2.0 New Features * Added Context-sensitive, online help. [Sam] * Added separate interface for editing templates (via FTP). [Sam] * Added the ability to use HTML::Template Templates. [Sam] * Added ability for differnt Output Channels to function as different component roots for in Mason templates. This will allow for templates that can't be found in the current Output Channel to be searched for in other Output Channels. [David] * Added link to Event log to Find Story, Find Template, and Find Media screens. [David] * Added true previewing for media assets. Now, when you click their URIs to preview them, they will be distributed to the preview server(s) before redirecting the user to them, rather than just serving them up from where they live on the Bricolage file system. The latter can still be accessed under Download in the Media Asset profile. This will continue to be the preferred way to grab media files for editing and such, as it will not incur the overhead of distributing the media file. [David] * Allow only one template with a given name for a given category, element, burner and output channel. [Sam] * Added a Maintainer section to the About page. [David] * Updated About page to mimic the layout of the help pages. [David] Bug Fixes * Fixed a bug with local previews where a preview page could show up instead of the Bricoalge UI. Thanks to Sara for the spot. [David] * Fixed a bug where Mason component calls failed in previews when the PREVIEW_MASON directive was enabled. [David] * Changed default value for text area fields added via the form builder (i.e., in Contributor Type and Element profiles) to 0. The values 0 and always make the the new field unlimited in length. [David] * Fixed a couple of buttons to be proper case rather than upper case. [David] * Separated the filesystem destinations for assets burned for publication and for assets burned for previewing. This will prevent someone previewing and stomping all over a published version of an asset before the published version is distributed. [David] * Removed hard-coding of the local preview directory in httpd.conf and httpd-ssl.conf. Now using the values stored in PREVIEW_LOCAL, instead, to determine the proper directory. [David] * Added the DEF_MEDIA_TYPE directive. Bricolage will use the value in this directive to assign a Media Type to all file resources if they Bricolage can't figure it out from their file extentions. This fixes a bug where Bricolage would choke if it couldn't figure out the MediaType itself. [David] Enjoy! David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] === end original
RFC: Exception::Handler
Seeing through Dave Rolsky's Exception::Class and
Sig::PackageScoped has let me make the following module, called
Exception::Handler.
In fact I rarely use $SIG{__DIE__} for exception handling, but the
concept of the module would be a bit interesting. Especially
eval { };
if ($@-isa('FooException')) {
# ...
} elsif ($@-isa('BarException')) {
# ...
} else {
# ...
}
code like this can be greatly simplified.
Any suggestions welcome, escpecially from gurus of exception, Matt
and Dave ;) See t/*.t for typical usage.
http://bulknews.net/lib/archives/Exception-Handler-0.01.tar.gz
NAME
Exception::Handler - Hierarchical exception handling
SYNOPSIS
use Exception::Class
'MyException',
'AnotherException' = { isa = 'MyException' },
'YetAnotherException' = { isa = 'AnotherException' },
'FooBarException';
use Exception::Handler
MyException = \my_handler,
AnotherException = \another_handler,
__DEFAULT__ = \default_handler;
eval { MyException-throw }; # my_handler()
eval { AnotherException-throw; };# another_handler()
eval { YetAnotherException-throw; }; # another_handler() : hierarchical
eval { FooBarException-throw; }; # default_handler()
sub my_handler {
my $exception = shift;
# ...
}
sub another_handler { }
sub default_handler { }
DESCRIPTION
Exception::Handler allows you to handle exception with various subs each
of which registered for an appropriate class of exception. This module
can nicely work with Dave Rolsky's Exception::Class and Grahamm Barr's
Error module.
TODO
* Lexical handler, which may be done via local.
AUTHOR
Tatsuhiko Miyagawa [EMAIL PROTECTED]
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
SEE ALSO
Exception::Class, Sig::PackageScoped
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: Questions on note_basic_auth_failure and get_basic_auth_pw
The Sapphire Cat wrote: Documentation for these functions reads as follows: $r-get_basic_auth_pw If the current request is protected by Basic authentication, this method will return 0, otherwise -1. [snip] ok, that's unclear (and not 100% correct, either). I'd change it to: If the current request is protected by Basic authentication, this method will return OK. Otherwise, it will return a value that ought to be propagated back to the client (typically AUTH_REQUIRED). $r-note_basic_auth_failure Prior to requiring Basic authentication from the client, this method will set the outgoing HTTP headers asking the client to authenticate for the realm defined by the configuration directive `AuthName'. this looks fine as a high-level overview. Experiments have shown that in an AuthenHandler, get_basic_auth_pw will return AUTH_REQUIRED if the request is protected and the client did not send credentials. Furthermore, note_basic_auth_failure seems to have no effect on the realm name. [snip] So what does note_basic_auth_failure *really* do? it really does pretty much what it says, it's just that you are misunderstanding it :) note_basic_auth_failure sends the WWW-Authenticate header back to the client, using the value set in httpd.conf for AuthName. this ought to signify that the requested resource requires user credentials for the specified realm - what the client chooses to do with that information is up to the client, but most know how to implement Basic authentication by now :) you really need to look at the headers involved in this multi-step process to understand what's going on. (or see recipe 13.3 ;) Finally, I want to fix the get_basic_auth_pw documentation. Where should patches go for that, and in what format? send a unified diff of Apache.pm (based on the CVS version) to [EMAIL PROTECTED] if you agree with the above changes, I'll submit it for you if you want. --Geoff
Did Can't upgrade that kind of... come back ?!?
Hi, I have written a mod_perl handler that "require" other Perl modules; these modules use the pragma 'warnings' (i.e. 'use warnings'). When I start httpd I get this message in error log:Can't upgrade that kind of scalar (#1) (P) The internal sv_upgrade routine adds "members" to an SV, making ==3Dit into a more specialized kind of SV. The top several SV types are so specialized, however, that they cannot be interconverted. Thismessage indicates that such a conversion was attempted.Uncaught exception from user code: Can't upgrade that kind of scalar.If I eliminate 'use warnings' calls all is OK!Note that I have problems only for package required whenhttpd starts; infact when I process the request I, dinamically,require other packages (according to URI) which includethe pragma 'use warnings' and all is OK!!I looked up in the mod_perl guide and found in the section"Warnings and Errors Troubleshooting" that error'Can't upgrade that kind of scalar"was fixed in mod_perl 1.23.Currently I use httpd 1.3.22 and mod_perl 1.26 (and perl5.6.1)So what's wrong!?!Thank you in advance!! Marco Guazzone ICQ#: 107450046
Re: ANNOUNCE: Bricolage 1.2.0
On Fri, 2002-01-11 at 01:29, [EMAIL PROTECTED] wrote: Do you provide a demo of Bricolage. Can I expect something similar to the Midgard Project on PHP? Unfortunately there is no demo of Bricolage at this time. But you can start reading up on it and see some screenshots at http://bricolage.thepirtgroup.com/. I'm not familiar with Midgard, though it looks interesting. What differentiates Bricolage from other OSS CMSs, however, is its robust support for configurable workflows. Furthermore, its templates are written in HTML::Mason or HTML::Template -- that is, Perl. So you have a complete, robust programming language to work with. Thanks, David -- David Wheeler AIM: dwTheory Bricolage Maintainer ICQ: 15726394 [EMAIL PROTECTED] Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: ANNOUNCE: Bricolage 1.2.0
On 11 Jan 2002, David Wheeler wrote: On Fri, 2002-01-11 at 01:29, [EMAIL PROTECTED] wrote: Do you provide a demo of Bricolage. Can I expect something similar to the Midgard Project on PHP? Unfortunately there is no demo of Bricolage at this time. But you can start reading up on it and see some screenshots at http://bricolage.thepirtgroup.com/. Looks neat! I'm not familiar with Midgard, though it looks interesting. What differentiates Bricolage from other OSS CMSs, however, is its robust support for configurable workflows. Furthermore, its templates are written in HTML::Mason or HTML::Template -- that is, Perl. So you have a complete, robust programming language to work with. Any chance of supporting more template systems in the future, like TT and XSLT? -- !-- Matt -- :-Get a smart net/:-
Re: ANNOUNCE: Bricolage 1.2.0
On Fri, 2002-01-11 at 11:39, Matt Sergeant wrote: Looks neat! Thanks, Matt! Any chance of supporting more template systems in the future, like TT and XSLT? The templating architecture is managed via subclasses. So anyone who wants to add his/her favorite templating system is welcome to implement a new subclass. I encourage interested developers to join the bricolage-devel list on SourceForge. https://sourceforge.net/mail/?group_id=34789 Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: ANNOUNCE: Bricolage 1.2.0
On Fri, 11 Jan 2002, Matt Sergeant wrote: Any chance of supporting more template systems in the future, like TT and XSLT? Adding more Burners (brictalk for templating system) is definitely something we're interested in. If you'd like to give it a try there's a brief set of instructions in the Bric::Util::Burner docs: http://bricolage.thepirtgroup.com/docs/Bric/Util/Burner.html Look for the ADDING A NEW BURNER section. For general information about the templating system, see: http://bricolage.thepirtgroup.com/documentation.html -sam
Re: mod_perl framework + code reuse question
At 01:48 PM 1/10/2002 -0500, Perrin Harkins wrote: You can actually use subroutines without fear! Also, reducing the amount of magic (i.e. all of that package generation and eval stuff that Registry does) can help clear up confusion. And you can use __END__ and __DATA__. Good point. I started writing a handler and have something basically working. It's still pretty barebones, but I'm happy with it so far, and performance is good. It require-s the appropriate page module based on $r-filename, $r-path_info, and $r-document_root then calls that module's run method as a class method (both steps wrapped in separate evals). Apache::Reload is reloading both handler module and page module as needed. For file organization, I'm thinking of making all page modules start with a common namespace substring (e.g. Projectname::Page) to distinguish them from the support (model) modules for that site and moving them into the same directory tree that contains those support modules, then moving templates (currently in ./tt/*.tpl files relative to *.par scripts) into either that directory tree alongside the modules they are used by or into an entirely separate tree that only contains templates. The latter is probably better for sites that have some division of labor between coders and HTML designers, but that's not the case on this one. Thank you for all the help. Matthew Pressly
Re: mod_perl framework + code reuse question
For file organization, I'm thinking of making all page modules start with a common namespace substring (e.g. Projectname::Page) to distinguish them from the support (model) modules I like to name the top level modules SiteName::Control::* and the model modules SiteName::Model::*. Calling the modules Page makes it sound like each one corresponds to a single page, which is not always true, i.e. you might have an adress book module that generates many different pages (with different templates) based on the parameters passed to it. Glad to hear the handlers are working out for you. - Perrin
Re: push_handlers
Stathy Touloumis [EMAIL PROTECTED] wrote:
For some reason the call to 'push_handlers' does not seem to register the
'handler' with mod_perl correctly when used in the code below. It seems
that only a few initial requests will successfully be processed by this
handler. It then just seems to be bypassed. It only works when the
'push_handler' code is commented out and a Perl*Handler directive is added
to the apache conf file. Does anyone know why this is so?
Here is a snippet of code which is read in at server startup through a
'require' directive.
Apache-push_handlers(
PerlPostReadRequestHandler= \handler
);
sub handler { warn Hello World\n; }
As far as I know, push_handlers only works the the current request --
that is, the handlers pushed with it are cleared at the end of the
request.
It would seem that doing this at startup sets up the handler which
then gets used by the children and cleared after the first request
they serve. This would give you the symptoms you're seeing (each
child called once, and then it disappears). Try running httpd -X to
see what happens. There's also probably something in the guide about
it.
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
Re: Exception::Handler
For what it is worth - I would encourage you to check out the Error package
as well.
Rather than:
eval { };
if ($@-isa('FooException')) {
# ...
} elsif ($@-isa('BarException')) {
# ...
} else {
# ...
}
You would have:
try {
code;
} catch FooException with {
code for FooExceptions;
} catch BarException with {
code for BarExceptions;
} otherwise {
};
And you can throw exceptions with details on the nature of the exception:
throw FooException ( -text = You foo'ed at line bar, -value =
$line );
and in the try block:
try {
do foo;
} catch FooException with {
my $exception=shift;
print Uh oh, we have a problem with foo: . $exception-text;
};
Jay
- Original Message -
From: Tatsuhiko Miyagawa [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Dave Rolsky [EMAIL PROTECTED]; Matt Sergeant [EMAIL PROTECTED]
Sent: Friday, January 11, 2002 8:07 AM
Subject: RFC: Exception::Handler
Seeing through Dave Rolsky's Exception::Class and
Sig::PackageScoped has let me make the following module, called
Exception::Handler.
In fact I rarely use $SIG{__DIE__} for exception handling, but the
concept of the module would be a bit interesting. Especially
eval { };
if ($@-isa('FooException')) {
# ...
} elsif ($@-isa('BarException')) {
# ...
} else {
# ...
}
code like this can be greatly simplified.
Any suggestions welcome, escpecially from gurus of exception, Matt
and Dave ;) See t/*.t for typical usage.
http://bulknews.net/lib/archives/Exception-Handler-0.01.tar.gz
NAME
Exception::Handler - Hierarchical exception handling
SYNOPSIS
use Exception::Class
'MyException',
'AnotherException' = { isa = 'MyException' },
'YetAnotherException' = { isa = 'AnotherException' },
'FooBarException';
use Exception::Handler
MyException = \my_handler,
AnotherException = \another_handler,
__DEFAULT__ = \default_handler;
eval { MyException-throw }; # my_handler()
eval { AnotherException-throw; };# another_handler()
eval { YetAnotherException-throw; }; # another_handler() :
hierarchical
eval { FooBarException-throw; }; # default_handler()
sub my_handler {
my $exception = shift;
# ...
}
sub another_handler { }
sub default_handler { }
DESCRIPTION
Exception::Handler allows you to handle exception with various subs
each
of which registered for an appropriate class of exception. This module
can nicely work with Dave Rolsky's Exception::Class and Grahamm Barr's
Error module.
TODO
* Lexical handler, which may be done via local.
AUTHOR
Tatsuhiko Miyagawa [EMAIL PROTECTED]
This library is free software; you can redistribute it and/or
modify
it under the same terms as Perl itself.
SEE ALSO
Exception::Class, Sig::PackageScoped
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
RE: push_handlers
Makes sense, will look over the docs again.
Thanks,
Stathy Touloumis [EMAIL PROTECTED] wrote:
For some reason the call to 'push_handlers' does not seem to register the
'handler' with mod_perl correctly when used in the code below. It seems
that only a few initial requests will successfully be processed by this
handler. It then just seems to be bypassed. It only works when the
'push_handler' code is commented out and a Perl*Handler
directive is added
to the apache conf file. Does anyone know why this is so?
Here is a snippet of code which is read in at server startup through a
'require' directive.
Apache-push_handlers(
PerlPostReadRequestHandler= \handler
);
sub handler { warn Hello World\n; }
As far as I know, push_handlers only works the the current request --
that is, the handlers pushed with it are cleared at the end of the
request.
It would seem that doing this at startup sets up the handler which
then gets used by the children and cleared after the first request
they serve. This would give you the symptoms you're seeing (each
child called once, and then it disappears). Try running httpd -X to
see what happens. There's also probably something in the guide about
it.
Re: Exception::Handler
On Fri, 11 Jan 2002, Jay Lawrence wrote:
For what it is worth - I would encourage you to check out the Error package
as well.
Rather than:
eval { };
if ($@-isa('FooException')) {
# ...
} elsif ($@-isa('BarException')) {
# ...
} else {
# ...
}
You would have:
try {
code;
} catch FooException with {
code for FooExceptions;
} catch BarException with {
code for BarExceptions;
} otherwise {
};
And the fun potential for memory leaks with nested closures.
And you can throw exceptions with details on the nature of the exception:
throw FooException ( -text = You foo'ed at line bar, -value =
$line );
You can do that without using Error.pm's try/catch stuff by simply using
Error's exception objects or the Exception::Class provided exception
objects.
AFAICT, Tatsuhiko's module is designed to work with either of those types
of objects transparently, but it provides an alternate mechanism for
catching exceptions.
And anything inspired by my Sig::PackageScoped module scares me, but its
an interesting idea ;)
-dave
/*==
www.urth.org
we await the New Sun
==*/
formmail spammers
Hi all - I assume I'm not the only one seeing a rash of formmail spam lately. I don't have it on my system, but I get a handful of attempts at using it every day. This is the kind of thing I'm talking about: /cgi-bin/formmail.pl?[EMAIL PROTECTED],subject=Your%20site%20is%20great![EMAIL PROTECTED]=http://ivsoftware.com/cgi-bin/formmail.pl Is there anything out there along the lines of the anti- MSIISProbes/NIMDA/CodeRed modules that will stop this and report it up the chain? -- Mike Schienle Interactive Visuals, Inc. http://www.ivsoftware.com/
Re: formmail spammers
I assume I'm not the only one seeing a rash of formmail spam lately. Is THAT what it is? I have a Yahoo mail account which someone has been sending literally thousands of messages per day to, CC'ing lots of people on every one, and they all appear to be from some kind of compromised form mailer script. I'm open to any suggestions. - Perrin
the trick of using $SIG{__DIE__} with eval {} disregarding the $^S value
This is an interesting approach to using $SIG{__DIE__} together with
eval {} blocks, without relying on the value of $^S which sometimes goes
broken. I guess we should add this trick to the guide.
Original Message
Subject: Re: [ID 20020107.001] $^S is sticky
Date: Mon, 7 Jan 2002 15:15:58 -0500
From: Michael G Schwern [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
On Mon, Jan 07, 2002 at 02:52:02PM -0500, Christopher Masto wrote:
Is this supposed to happen?
$^S breaks a lot. I found both 5.6.1 and 5.005_03 to have broken $^S,
though for different reasons. I can't remember why 5.005_03's is
broken. If you peek inside Test::Builder you'll find this:
$SIG{__DIE__} = sub {
# We don't want to muck with death in an eval, but $^S isn't
# totally reliable. 5.005_03 and 5.6.1 both do the wrong thing
# with it. Instead, we use caller. This also means it runs under
# 5.004!
my $in_eval = 0;
for( my $stack = 1; my $sub = (CORE::caller($stack))[3]; $stack++ ) {
$in_eval = 1 if $sub =~ /^\(eval\)/;
}
$Test_Died = 1 unless $in_eval;
};
chris@lion-around:~$ perl5.00503 -e '$SIG{__DIE__} = sub { die @_ if
$^S; die caught die: @_; }; print start: $^S\n; eval { die death in
eval; }; print end: $^S\n; die death outside eval'
start: 0
end: 0
caught die: death outside eval at -e line 1.
chris@lion-around:~$ perl5.6.1 -e '$SIG{__DIE__} = sub { die @_ if
$^S; die caught die: @_; }; print start: $^S\n; eval { die death in
eval; }; print end: $^S\n; die death outside eval'
start:
end: 1
death outside eval at -e line 1.
In 5.6.1, the value of $^S seems to get stuck once it's been set.
This only happens if the $SIG{__DIE__} handler actually looks at it.
t/op/magic.t appears to be the only thing which tests $^S, and it
doesn't get $SIG{__DIE__} involved.
bleadperl is back to:
start: 0
end: 0
caught die: death outside eval at -e line 1.
if modified a little, it shows its the correct behavior:
$ bleadperl -e '$SIG{__DIE__} = sub { die @_ if $^S; die caught die:
@_; }; print start: $^S\n; eval { die death in eval; }; print $@;
print end: $^S\n; die death outside eval'
start: 0
death in eval at -e line 1.
end: 0
caught die: death outside eval at -e line 1.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
And God created Cat to be a companion to Adam. And Cat would not obey
Adam. And when Adam gazed into Cat's eyes, he was reminded that he
was not the supreme being. And Adam learned humility.
-- http://www.catsarefrommars.com/creationist.htm
--
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: formmail spammers
On Fri, 11 Jan 2002, Perrin Harkins wrote: I assume I'm not the only one seeing a rash of formmail spam lately. Is THAT what it is? I have a Yahoo mail account which someone has been sending literally thousands of messages per day to, CC'ing lots of people on every one, and they all appear to be from some kind of compromised form mailer script. I'm open to any suggestions. http://www.spamassassin.org/ Without a doubt, the best anti-spam solution around. -- !-- Matt -- :-Get a smart net/:-
Re: RFC: Exception::Handler
On Fri, 11 Jan 2002, Tatsuhiko Miyagawa wrote:
use Exception::Handler
MyException = \my_handler,
AnotherException = \another_handler,
__DEFAULT__ = \default_handler;
eval { MyException-throw }; # my_handler()
eval { AnotherException-throw; };# another_handler()
eval { YetAnotherException-throw; }; # another_handler() : hierarchical
eval { FooBarException-throw; }; # default_handler()
I don't like this for the same reason I don't like $SIG{__DIE__} - it
promotes action at a distance. In a 1000 line .pm file I *want* to have my
exception catching mechanism next to my eval{} block.
--
!-- Matt --
:-Get a smart net/:-
