Top posts
Latest articles
Web Development, idealistic or realistic
(No Ratings Yet)
Loading ...The building of a website is split up in several stages. The first is the design by a graphic designer, but this article isn’t about that. Then you have the developers. And there are two types. And they end up clashing, mostly not in a good way :).
So what two types am I talking about. Well you have the idealists that like to do most all by the rules. Which means intensive use of CSS and using DIV elements to build up the lay-out of the site. And then you have the ‘realist’. The group of developers that build using dirty tricks like tables for layout.
Now let me start with saying that both can get the same results. But the way that they do it is very different. So why do I call one a realist and the other a idealist. Easy the realist will achieve fast results. You can do almost anything with tables if you want to.
Having said that it’s also a dirty way. Tables are meant for displaying numbers, not entire websites. This is also the standpoint of the idealist that will try to do everything with DIV elements, which is doable but takes a lot more time.
Let’s play with a little example, I love examples! We have a simple website with two columns and a header. See nice little image to the side ;).
Now you can do this two ways. With tables (the realist) or DIV elements (the idealist). Both get the same result.
First the way of the realist:<table>
<tr>
<td collspan=’2′>Dark-Yellow cell</td>
</tr>
<tr>
<td width=’150′>
<table height=’300′ width=’100%’>
<tr>
<td>Yellow cell</td>
</tr>
</table>
<td width=’auto’>Red cell</td>
</tr>
</table>
The second way is that of the idealist. Which in my eyes looks a lot better and is easier to maintain.<style>
#container {
position: relative;
width: 100%;
}
#navcell {
width: 150px;
position: absolute;
top: 0px;
left: 0px;
}
#content {
margin-left: 150px;
width: 100%;
}
</style>
<div>Dark-Yellow Cell</div>
<div id=’container’>
<div id=’navcell’>Yellow Cell</div>
<div id=’content’>Red Cell</div>
</div>
You may have guessed it, but I personally love developing as an idealist. It’s so much cleaner. And a whole lot easier to modify the entire website by just changing a few stylesheets.
NetBeans 6.0 a first look
I’ve started playing around with the newest version of Netbeans lately. Now after a few weeks I think it’s time to write a little article about the new stuff, some of which I like and some of which I don’t
Why wait so long
You might be wondering why I’ve waited so long before writing the first article about the newer version. Well pretty simple. First of it’s still in development so I’m not expecting to much. And the second reason is that when you write something you’d better do it good.
Which in my case means using it for several weeks before dissing it. And now that I have lets see what it brings us.
Looks similar behaves different
First things first. If you’ve worked with older versions of Netbeans you’ll notice that the appearance hasn’t changed much. Could be a good thing, but then again if you hated the interface originally you will probably still do so now.
Enough about what is the same, after all that’s not really interesting now is it!
So let’s get on to the biggest change I found straight away. Netbeans 6 is better equipped to work with SVN. Which for me is a big plus as we work with that at work. In the previous version you could do some basic things. But now you can see which lines were modified in the file and what the modifications are. Did I already mention that I like that!
Threaded debugging improved
Another thing I sorta like is a minor change in debugging. When you are debugging a web project that has some threaded functions you encountered problems in the past. At least I did. If you mistakenly had a breakpoint at a line within the threaded part you would get interrupted during your debugging session. Netbeans simply jumped to the other breakpoint.
No longer. If a breakpoint is hit whilst in a different thread then the one you are debugging you get a nice warning. Asking you if you want to jump to the thread or continue debugging. Seriously this is so much better!
Is it all good or not
Just like with any new version a lot of problems get solved. But not all is good. I found that the autocomplete is so slow that it’s annoying. I even considered disabling it all together, but couldn’t find any way of doing that. It’s also sorta unstable. Take it from me it won’t crash, but you will get a lot of NullPointerExceptions.
Now I’m willing to accept that for the moment as it is still a development version. So lets wait to see what the finished product will bring.
Catching most PHP errors
When developing in PHP you may have encountered the following problem:
During an upgrade of the code, or just a minor bug fix, you have introduced new (non critical-error) code. This is causing PHP to crash and report ugly warnings to the user.
Well I think most developers of PHP have found this problem. One option, which is always done on live servers, is setting the logging level very low. Only critical errors are displayed. Though effective it’s far from perfect. I know I want to know when a page is creating problems, even if it is just a minor bug.
PHP has a nifty little feature that allows you to set a error handler, overwriting the default. By doing so you can catch all those nasty little errors before they go to the user. But what’s even better is that you can do anything with the information. The function to do this is called:
set_error_handler( “functionname” );
Sets the default PHP error handler to a custom function rather then the PHP default error handling.
Why is this useful, well let me give you a prototype of a function that catches the errors:
function handleErrors($errno, $errstr, $errfile, $errline)
{
switch ($errno)
{
case E_USER_ERROR:
Handler::Log(‘<b>User Error:</b> ‘. $errstr, $errline);
break;
default:
Handler::Error(‘<b>Unknown Error:</b> ‘. $errstr, $errline);
break;
}
}
So what does it do. Well it’s pretty straight forward. When an error occurs this function gets called. The errno is described at the PHP manual for set_error_handler. What I’ve done is calling a function on one of my classes. This specific class will construct an e-mail per page view and sent it if there are any errors.
But you’re free to do what ever you want with the errors PHP throws at you, from logging to a file to crashing output (if that’s what turns you on :)). Experiment a little!
PS: keep track of the fact that compiling errors will still cause the pages to crash
