Two days ago (technically yesterday early morning, but the two sort of blended together as I didn't sleep in a (successful) attempt to get my sleeping pattern back to something a bit more normal) I wrote about GoodLooking INT02. Today I decided to take a minute and write a demo.
Previously I provided links to the template and the live example. Now, instead, I provide a link to the demo. From there you can have a look at the running example, force it to do a reload and from there you can see the source of the template, of the sample application, of the code connecting the two and of the compiled template.
All of these are actually viewable without looking at the source thanks to two pre-tags around them and an htmlentities that was executed on them. It is important to note that even thought the compiled template is viewable this was, it was not made to be good to the eye - it is very ugly, generated php. Here's the link.
Showing posts with label The Good Suite. Show all posts
Showing posts with label The Good Suite. Show all posts
Monday, July 27, 2009
Sunday, July 26, 2009
GoodLooking INT02
I did some work on GoodLooking, my templating engine, again. And I finished a number of goals I had set for myself, and as such I finished the next version, INT02. Note that INT02 is not a release yet, not even an alpha release - INT stands for internal, which is the term I coined for the versions before the releases come along.
GoodLooking is a templating engine, which means it helps you to keep your php code seperated from your html. You'll have one file where you do your php programming and one which is the template. Then you need a couple of lines to tell GoodLooking which file to use, and what variables it should use, which can be in a third file, but can also reside in the same file as the programming logic.
Say you have a script that gets the user's first name, last name and birthday out of the database and put them into the variables $firstName, $lastName and $dateOfBirth. Now we write the following code to use LookingGood:
Compiling.
All of it worked, but it was slow. A few hundredths of a second does not appear to be too much, but in reality it is, if you are getting a number of views on your website per second and it's running on a host that's doing other things as well. A more complicated site than the ones I tested may really bog down a server if the work has to be done each and every time.
So, now it only does once, until you change the template, and then it does it once again. That one time it saves a file, which is basically a very messy php representation of your website, which means it is fast to go from there to your full website. And the messiness doesn't matter, because you are not going to see this code at all. For that matter, you are not going to notice the fact it is being compiled this way at all, as all you do is as I wrote above in the example, the engine fixes the rest for you silently.
A working sample is seen on my site. This is the template (view source to see it decently), and I simply put some constants into the engine, and here you see the result in real time.
INT02 does not have much functionality asides the mentioned yet and it has a funny perk, if you had a compile, it will show how long that took in the source, and it will always show how long the interpreting (from the compiled template to the result take) in the the source in html comments.
I won't make GoodLooking available just yet, simply because it is really advisable not to use it in its current state. However, if you really are interested despite that, let me know (for example, you could write a comment here). The next planned version is INT03, which will have one extra feature, after that there's INT04 in which I make a lot of changes and tie quite a few loose ends together. Then, when I feel I am satisfied with that, I will make an alpha version, which will be available.
Alright, thanks for your time (I can imagine, that was quite a read) and see you again some other time!
GoodLooking is a templating engine, which means it helps you to keep your php code seperated from your html. You'll have one file where you do your php programming and one which is the template. Then you need a couple of lines to tell GoodLooking which file to use, and what variables it should use, which can be in a third file, but can also reside in the same file as the programming logic.
Say you have a script that gets the user's first name, last name and birthday out of the database and put them into the variables $firstName, $lastName and $dateOfBirth. Now we write the following code to use LookingGood:
<?phpNote that instead of calling registerVar three times, we could also have called registerMultipleVars once:
$lookingGood = new LookingGood('template.tmpl');
$lookingGood->registerVar('firstName', $firstName);
$lookingGood->registerVar('lastName', $lastName);
$lookingGood->registerVar('birthday', $dateOfBirth);
?>
$lookingGood->registerMultipleVars(array('firstName' => $firstName, 'lastName' => $lastName, 'birthday' => $dateOfBirth));In either case we could have the following Template (in the file template.tmpl):
<html>This could lead to a page named "Hello Jasper!", with the following:
<:- this page is a sample page, and this text is a comment (disappears from result) -:>
<head><title>Hello <: firstName :></title></head>
<body>
<h1>Hello!</h1>
<p>Hello <: firstName; ' '; $lastName :>, my database tells me your birthday is at <: birthday :>.</p>
<: if (firstName == 'Jasper') :>
<p>Have a nice day, Jasper.</p>
<:end if:>
</body>
</html>
Hello!Or if you're your not me, but John Doe, you would get a page named "Hello John!", that looks like this:
Hello Jasper Horn, my database tells me your birthday is at 11/04.
Have a good day, Jasper.
Hello!Well, those are simple examples, but it does really show what the engine is about. So.. INT02, what's new?
Hello John Doe, my database tells me your birthday is at 31/03.
Compiling.
All of it worked, but it was slow. A few hundredths of a second does not appear to be too much, but in reality it is, if you are getting a number of views on your website per second and it's running on a host that's doing other things as well. A more complicated site than the ones I tested may really bog down a server if the work has to be done each and every time.
So, now it only does once, until you change the template, and then it does it once again. That one time it saves a file, which is basically a very messy php representation of your website, which means it is fast to go from there to your full website. And the messiness doesn't matter, because you are not going to see this code at all. For that matter, you are not going to notice the fact it is being compiled this way at all, as all you do is as I wrote above in the example, the engine fixes the rest for you silently.
A working sample is seen on my site. This is the template (view source to see it decently), and I simply put some constants into the engine, and here you see the result in real time.
INT02 does not have much functionality asides the mentioned yet and it has a funny perk, if you had a compile, it will show how long that took in the source, and it will always show how long the interpreting (from the compiled template to the result take) in the the source in html comments.
I won't make GoodLooking available just yet, simply because it is really advisable not to use it in its current state. However, if you really are interested despite that, let me know (for example, you could write a comment here). The next planned version is INT03, which will have one extra feature, after that there's INT04 in which I make a lot of changes and tie quite a few loose ends together. Then, when I feel I am satisfied with that, I will make an alpha version, which will be available.
Alright, thanks for your time (I can imagine, that was quite a read) and see you again some other time!
Friday, February 22, 2008
Cut and paste
It's been ages since I last posted anything (a month, really). So, anybody is reading this, you'd better get used to my irregular posting or stop reading here.
Monday I'll be cut up in pieces and the pieces will be put together again. By a qualified person, mind you.
Seriously, my nose is going to be set straight so I can get more air. And no more post-nasal drip. I'll not explain that last term, in order to prevent any potential readers, if you wanna know what it means, google it.
So, that's basically all I want to say - no wait, there's another thing. It's about lookingGood, the templating system I am building. I am not satisfied with it's name. I like the looking part, but I want a second part which I really put different verbs in front of, thus creating names for my other web products, ultimately leading to the the "Good suite" (if I would decide to stick with good anyway), I just think Good is to restrictive. So... I am thinking about a new name.
Monday I'll be cut up in pieces and the pieces will be put together again. By a qualified person, mind you.
Seriously, my nose is going to be set straight so I can get more air. And no more post-nasal drip. I'll not explain that last term, in order to prevent any potential readers, if you wanna know what it means, google it.
So, that's basically all I want to say - no wait, there's another thing. It's about lookingGood, the templating system I am building. I am not satisfied with it's name. I like the looking part, but I want a second part which I really put different verbs in front of, thus creating names for my other web products, ultimately leading to the the "Good suite" (if I would decide to stick with good anyway), I just think Good is to restrictive. So... I am thinking about a new name.
Wednesday, January 30, 2008
Giving it a name
I was doing some work on my Templating Engine again, and I wanted a name for a variable that nobody else would ever use. What's the usual way to do that? Right, include the name of your application. Easy enough, right?
The only problem I came across was the fact that I had no real name for the engine. So that's why I had to think of one. I came up with... LookingGood. It may or may not be the final name, it may or may not mean that I use similar names for my similar scripts (though I must say you can do a lot of things with the Good postfix).
Just thought I would drop that by - as I really want to be posting more I can just keep you informed (not caring whether you are interested or not :P) about such things. So, LookingGood is what I am working on right now. And maybe, just maybe all of you will be using LookingGood some day. (Probably not, though - this is just my project for my work, which others may use, but are not advised to.)
The only problem I came across was the fact that I had no real name for the engine. So that's why I had to think of one. I came up with... LookingGood. It may or may not be the final name, it may or may not mean that I use similar names for my similar scripts (though I must say you can do a lot of things with the Good postfix).
Just thought I would drop that by - as I really want to be posting more I can just keep you informed (not caring whether you are interested or not :P) about such things. So, LookingGood is what I am working on right now. And maybe, just maybe all of you will be using LookingGood some day. (Probably not, though - this is just my project for my work, which others may use, but are not advised to.)
Monday, January 28, 2008
Reinventing The Wheel? (To Run Myself Over)
I have been working on a templating system for quite some time now. It's one of the reasons I have not been posting. Shame on me for that, by the way. Anyway, there are probably people who are reading this and now wonder what a templating system is. Well, it's definition can differ slightly, but in this case it's a system that separates the layout from the programming logic completely.
Take for example the syntax of my templating system... anything normally typed is html and is not touched by the engine at all (okey, it's touched, but left in tact completely). Anything between <: :="" and=""> is handled by the templating system, however. Any value between the two script-delimiters (that's what they are called) will be printed to the output. So if the programming logic of a page gives the page access to a 'username' I can write "Hello <:username:>" to have it say hello Jasper to me and fill it with another name.
Besides printing values the scripts can be used to call functions, I planned two functions so far, include("page.html") and nameForCounter(varName), which can execute certain tasks. Include will insert a certain file in that location, and nameForCounter will assign a variable name to the counter of the topmost for or foreach loop (which I will explain more on later), giving you a handle to refer to it in the rest of your template.
The third thing a script can do is define a control structure. Planned of these are if, else, (possibly elseif as well), for, foreach and end ... . These work on script and plain text alike, if (statement) only considers the following content if statement is true, otherwise it will simply ignore it. An if anything that occurs before the next end if or else. Likewise else only considers the content if the last if evaluated to false - and it also ends at end if. for (value1 ++>/--> value2) will repeat the content enclosed by it and end for - starting at value1, increasing (++>) or decreasing (-->) it until value2 is reached. foreach (variableName in array). Array should be one of these variables supplied by the programming logic, but it has to be an array (surprise, surprise) then we will repeat the content (ended by end foreach, you guessed it) for each element the array has, the element always being accessible through variableName.
Multiple actions can be done in one script, in such a case they must be seperated by semicolons (;).
There is another kind of delimiter the engine recognises, <:- -:="" and="">. Anything between those two is regarded as a comment and will be removed from the document. Comments can be inside and outside script tags.
So that's what my engine is supposed to do - what does it have to do with reinventing the wheel?
(warning: technical terms - unexplained - ahead)
Now, while my syntax is different, there are other templating systems around already. None of them what I wanted though, simply take your template at real time and turn it in the website you want the users to see. I discovered this is for a reason, when making my own system. Because this costs way too much time and thus is very processor intensive. So what's the alternative? I looked into the source of the most notable templating engines, Smarty (it's open source as well, really). It simply compiles the userfriendly template to a (normally) unseen php script, which runs a lot faster, the first time a page is requested since it has been modified. I decided I would have to use a similar system to come closest to my wishes. Also I learned the trick of looking at the last time modified attribute of a file to see if it needs to be recompiled. However, when looking through Smarty's source code, it made me wonder what this new choices leave as reasons to actually make my own templating system.
It took me a while to figure out if I wanted to continue development of my engine, but I decided I would. Firstly, this script is mine, so other people may use it, but I can tweak it to my needs and make it the way I want to behave. Secondly, the syntax of my system is "better" (read as: I like it more). Thirdly, I will provide some functionality that Smarty does not provide. For now, this functionality would be: reading templates from a database and writing compiled files to a database. So yes, I will make my own system, and yes I have my reasons for it. Just drop me a line if you would be interested in using my system as well.
Now, for anyone wondering about the title, try googling that phrase. Say you would not find anything (which I cannot believe, but anyway) try finding the unrelated label for this post and look in that area.
Take for example the syntax of my templating system... anything normally typed is html and is not touched by the engine at all (okey, it's touched, but left in tact completely). Anything between <: :="" and=""> is handled by the templating system, however. Any value between the two script-delimiters (that's what they are called) will be printed to the output. So if the programming logic of a page gives the page access to a 'username' I can write "Hello <:username:>" to have it say hello Jasper to me and fill it with another name.
Besides printing values the scripts can be used to call functions, I planned two functions so far, include("page.html") and nameForCounter(varName), which can execute certain tasks. Include will insert a certain file in that location, and nameForCounter will assign a variable name to the counter of the topmost for or foreach loop (which I will explain more on later), giving you a handle to refer to it in the rest of your template.
The third thing a script can do is define a control structure. Planned of these are if, else, (possibly elseif as well), for, foreach and end ... . These work on script and plain text alike, if (statement) only considers the following content if statement is true, otherwise it will simply ignore it. An if anything that occurs before the next end if or else. Likewise else only considers the content if the last if evaluated to false - and it also ends at end if. for (value1 ++>/--> value2) will repeat the content enclosed by it and end for - starting at value1, increasing (++>) or decreasing (-->) it until value2 is reached. foreach (variableName in array). Array should be one of these variables supplied by the programming logic, but it has to be an array (surprise, surprise) then we will repeat the content (ended by end foreach, you guessed it) for each element the array has, the element always being accessible through variableName.
Multiple actions can be done in one script, in such a case they must be seperated by semicolons (;).
There is another kind of delimiter the engine recognises, <:- -:="" and="">. Anything between those two is regarded as a comment and will be removed from the document. Comments can be inside and outside script tags.
So that's what my engine is supposed to do - what does it have to do with reinventing the wheel?
(warning: technical terms - unexplained - ahead)
Now, while my syntax is different, there are other templating systems around already. None of them what I wanted though, simply take your template at real time and turn it in the website you want the users to see. I discovered this is for a reason, when making my own system. Because this costs way too much time and thus is very processor intensive. So what's the alternative? I looked into the source of the most notable templating engines, Smarty (it's open source as well, really). It simply compiles the userfriendly template to a (normally) unseen php script, which runs a lot faster, the first time a page is requested since it has been modified. I decided I would have to use a similar system to come closest to my wishes. Also I learned the trick of looking at the last time modified attribute of a file to see if it needs to be recompiled. However, when looking through Smarty's source code, it made me wonder what this new choices leave as reasons to actually make my own templating system.
It took me a while to figure out if I wanted to continue development of my engine, but I decided I would. Firstly, this script is mine, so other people may use it, but I can tweak it to my needs and make it the way I want to behave. Secondly, the syntax of my system is "better" (read as: I like it more). Thirdly, I will provide some functionality that Smarty does not provide. For now, this functionality would be: reading templates from a database and writing compiled files to a database. So yes, I will make my own system, and yes I have my reasons for it. Just drop me a line if you would be interested in using my system as well.
Now, for anyone wondering about the title, try googling that phrase. Say you would not find anything (which I cannot believe, but anyway) try finding the unrelated label for this post and look in that area.
Subscribe to:
Posts (Atom)