Sunday, September 28, 2014

Custom Error Pages

The default page when Bedrock encounters errors during the parsing of a page is error.roc and is distributed with the other core Bedrock files.  The page shows the developer the error and the contents of the page with each line numbered for easy correlation to the error reported by Bedrock.
Bedrock Error Page

You can customize the error.roc page if you'd like or replace it.  You probably don't want to spill code to users in a production environment.

To specify your own custom error page, set the BEDROCK_ERROR_LOCATION variable in the tagx.xml file to the fully qualified path of your own Bedrock file.

<scalar name="BEDROCK_ERROR_LOCATION">/var/www/html/error.roc</scalar>

Bedrock exposes the $ERROR object that has several methods you can use to report the error.

$ERROR.mesg() - the error message

$ERROR.line() - the line number where the error was encountered.

$ERROR.file() - the name of the file where the error occurred.

$ERROR.view_source() - an HTML representation of the source code.

Simple Example

This example uses the $ERROR object to display the error message, location of the error, and the file that was being processed when the error occurred.

<html>
<body>
<h1>Whoops! We're sorry, our slip is showing!</h1>
<pre>
message: <var $ERROR.mesg()>
location: <var $ERROR.line()>
file: <var $ERROR.file()>
source: <var $ERROR.view_source()>
</pre>
</body>
</html>

E-Mail Me the Error

Here's an example error page that will give the user a message and send an email to the developers notifying them of an error...I'm using the $SMTP plugin distributed with Bedrock to email the error message.

<html>
<body>
<h1>Whoops! We're sorry, our slip is showing...</h1>

<i>Thanks for your patience...our staff is on it!</i>

<plugin:SMTP localhost rlauer6@comcast.net rlauer6@comcast.net>

<null $SMTP.subject('A Bedrock Error has occurred!')>
<null $SMTP.header('Content-Type', 'text/html')>

<sink $SMTP>
An error has occurred <b><var $ERROR.file()>[<var $ERROR.line()>]</b>
<hr>
<b>REMOTE_ADDR:</b> <var $env.REMOTE_ADDR>
<b>SERVER_ADDR:</b> <var $env.SERVER_ADDR>
<hr>
<pre>
File: <var $ERROR.file()>
Line: <var $ERROR.line()>

<span style="color:red;"><var $ERROR.mesg()></span>
</pre>
</sink>

</body>
</html>

...and voila!  I get an email when an error occurs.



Saturday, September 27, 2014

Friday, February 7, 2014

Expanding the Use of Perl Plugins

The <plugin> tag allows you create Perl classes that provide specific functionality for your pages.  But what about using CPAN modules as plugins?  Most CPAN modules that have a new() constructor can be used as plugins.  One of my favorite CPAN modules is Text::CSV_XS so it was disappointing to find I had some issues with this one.

  <plugin:Text::CSV_XS>

Bedrock has had a limitation on using some CPAN modules because of the way Bedrock coerces lists into Bedrock array objects when invoking method calls on objects...until now.

Wednesday, January 1, 2014

Bedrock, jQuery and HTTP Status Codes

Using Bedrock to create AJAX components is trivial.  Name your Bedrock file with a .jroc extension and return your result.

<var --json $result>

Can it get any easier?  I just created a wiki page that shows how Bedrock handles exceptions for application/json files you serve up using Bedrock.   I also describe how you can customize the HTTP status code that Bedrock returns to the browser.

http://twiki.openbedrock.net/twiki/bin/view/Bedrock/BedrockStatusCodes

Monday, December 30, 2013

Chromebook - Acer C720 A Month Later

After a month of using my Acer C720 I can say that I am one darn happy customer. Apparently I'm not alone.

Friday, December 27, 2013

Coffeshop Productivity

Saw this article on FastCompany...could not agree more.  Working at a coffee shop can be a very productive experience.  After you read the article, I have a few tips of my own.

http://www.fastcompany.com/3005011/why-you-should-work-coffee-shop-even-when-you-have-office

Thursday, December 19, 2013

"Sinking" output

Bedrock is a templating language which means pretty much everything in your page is being output to the browser. Bedrock statements that are parsed and produce output, do so at the point where the tag has been placed. Makes sense...after all that's what a templating engine is supposed to do.

 Hi this is <var $name> from <var $company_name>.

So when you have a page that includes statements like:

<ul>
<sqlselect "select * from customer where name like ?" --bind=$input.q>
  <li><var $first_name> <var $last_name></li>
</sqlselect>
</ul>

...in the middle of your page, you might be surprised to see a lot of white space in the output.

That's because, while Bedrock interprets the tags and does not output anything as a result of non-output tags other than <var>, the Bedrock statements are on lines that include a new line and Bedrock dutifully outputs anything in your page that is not a tag.

One way to avoid this, is to avoid placing these tags on their own line.  Another way of eating white space is to use the sink tag.  Take this group of statements:

<null:foo $input.bar>
<if $foo --eq "bar">
  <null:baz "buz">
</if>

Bedrock will interpret these tags, but your output will contain 4 new lines.  Using the <sink> tag you can eat all of that white space.

<sink><null:foo $input.bar>
<if $foo --eq "bar">
  <null:baz "buz">
</if></sink>

The <sink> tag can scoop up the contents of the output in a variable as well.

<sink:hello_world>Hello World!</sink>

<sink> has one other magical property. It can also output the contents of the block to a handle.

<sink $fh>Hello World!</sink>

You can even nest <sink> tags.

<sink:foo>bar<sink>this is a comment</sink></sink>

Check out this link for more detail about the sink tag.