The resource container Contents, included with a3gFramework is finished and ready to download from the project’s page at sourceforge. With this alone a3gFw has everything we need to write a simple Website with full content management capabilities.
There’s still more to come, not only new resources, but improvements to the framework’s core, which is still not ready for production use.
A renewed a3gFramework is coming with big changes and great news.
A whole new structure put more power in our hands, allowing us for doing more by writing less code, but without loosing control of what’s going on. We can always do things our way overriding default behavior. However, repetitive and common tasks such as back-end CRUDE operations are now completely built-in, including even the views.
Plus, these operations have now full multi language support: all we need to do is to write a few lines of code to let the framework know which are the language dependent fields, and the rest is taken care for us.
Application configuration has been moved from the database to an .ini file. We have purposely avoided to use a XML file to store configuration, because that introduces unnecessary complexity.
Creating tables have never been easier. The old .SQL file that required manual execution of the SQL sentences with PHPMyAdmin has been substituted for PHP code within the resource’s specific loader file (located directly under the resource’s root directory). We declare the tables that our resource needs to work and a3gFw’s back-end allows for easy creation of the table in the database with just a click.
a3gFramework started as a small classes library and became a framework; the first and only PHP framework with native support for REST architecture.
Its built-in scalable back-end system is another feature that none of the most popular frameworks offer (except for those that started as content management system and evolved, like WordPress).
The recently added hooks system provide high level of customization without having to edit core code.
And there is more to come…
Just a quick post to share a link that someone posted in a forum where you can find some exercices about diferent aspects of music theory.
http://www.teoria.com/index.php
Enjoy!
Well, one thing I learned since I started to learn Moonlight Sonata by Beethoven is that it is not an easy piece.
My beginner hands are not as fast as the piece requires them to be, so I have to play it even slower than the piece already is. Besides, in order to keep the proper melody I need to perform quick jumps from one position to another and, I am not yet able to achieve a fluid melody.
After weeks of studying music theory, learning note names their position in the staff, etc.; I finally got to a point where I needed the guitar in order to move forward in my learning process. So I spent several days looking around, learning about brands, models, etc.
I have to say that when I finally asked my wife to come to the store with me, just to look what was available, I was not yet sure about what I was going to purchase. All I knew was that I wanted a not expensive instrument, but capable of producing an enjoyable sound.
I got to the store and as soon as I went through the door I realized that I would not be able to leave without a guitar in my hands. The smell of the wood, the colors, all those guitars hanging there, the whole atmosphere was magical and I got as exited and happy as my one and a half year old daughter that was with me.
It is important to note that there were not many options in terms of brands in fact there were only two: Yamaha and Ibanez; but I knew this already thanks to my previous research. Since I had not thought about writing a post about this I didn’t take notes about models but I can say that I tried all three guitars under 200CAD and a Yamaha priced about 230CAD… just to hear the difference… and yes, there is a difference!
The good thing is that after all comments I had read about the Yamaha C40 I got really impressed about the sound when I “played” it. There I was, with exactly what I went looking for, a non expensive instrument with a sound I liked. I ended up spending 183CAD for the guitar, a foot stool and a hanger, all tax included.
Hello,
This blog, up to now, was intended to talk about programming stuff since that is one of my passions besides being my job. But being curious by nature I have many other interests, although I don’t have time to do everything… well, not if I want to do it right.
A couple of months ago for example I started to watch videos of performers playing several classical guitar pieces. This made me realize that I still have that taste for music and for guitar that I used to have twenty three years ago. So I decided to do something that I did not do when I should have done: study music theory and learn to play my favorite instrument properly.
So that is the challenge, learning music by myself and learn to play the guitar properly. One month after I made this decision I bought the guitar. I wanted a non expensive instrument capable of producing a sound that I could enjoy. After analyzing the purchase I decided to go for the Yamaha C40.
At the moment of writing this post three weeks have passed and I have learned two beginner pieces so far: Spanish Study and a version of Malaguena (none of these is me, I will share my own videos when I have them ready).
Recently I got Lbertango’s scores, I had the intention to learn it but I realized that I am not yet ready for it. So I decided to give a shot to a song I really like: Beethoven’s Moonlight Sonata… and that is what I am doing right now.
I don’t expect too many people to read this blog now that it has a more personal approach… or maybe all the contrary 
Have a nice day!
During my time as CakePHP programmer I was faced to the problem of writing a REST web service, which was not such a piece of cake after all. In fact, it required so much research that I begun to write a series of posts about how to write RESTful web services with CakePHP (series that I never finished because I stopped using that framework).
In this article I want to talk about the problems I found and offer a possible solution, because when something that should be natural and easy becomes tricky and the subject of many how-to articles it means that something is not right.
First of all: What are the problems that cause of the gap between most currently available PHP frameworks philosophy and REST?. In my opinion they are: the action oriented mind, the URL problem and the session problem. At the end I will offer one possible solution to this problem and an existing implementation.
We, programmers, are used to think in terms of actions: find, add, update, delete, calculate tax, show price, etc. This seems logical because that is how we do it in structured and object oriented programming. So lets say that we need to show some product’s information: we will write a function called view() that receives the product’s ID as parameter an displays its information. Now lets say that we want to solve this problem using some MVC PHP framework, we would do something like this:
class ProductsController {
function view($id)
{
$theProduct = findPorduct($id);
renderView("product", $theProduct);
}
}
Then we would write the following URL in our browser:
http://www.domain.com/products/view/321.
Anyone with some experience with at least one PHP framework will recognize all this (beyond simplifications) as more or less the way of doing it. I will be back to this example later, for now let me just say that this is OK, but it is not REST.
When I was writing the article about how to write RESTful web services with CakePHP I fell on many authors that claimed that REST was all about pretty URLs. For example, for these authors the following URL was REST:
http://www.domain.com/products/view/321
while this one was not:
http://www.domain.com/products.php?id=321.
The fact is however that it is all the way around.
I don’t want to get into the details of REST architecture here, all I will say is that a well formed RESTful URL must be a noun and not a verb; meaning that it must point to a resource and say nothing about the action performed on that resource; and once again: pretty URL have nothing to do this.
The other big issue we find when we analyze RESTful capabilities of major PHP frameworks is its full support for sessions. Sessions are also something that every Web programmer has gotten used to because it easily solves the problem of state persistence; but this way of designing Web sites does not play along with HTTP’s stateless architecture.
In many situations we need to have some sort of state persistence to keep track of users progress from one request to the other; the real issue here is that sessions solve this by keeping state information on the server and that is in fact what goes against REST. Such state persistence must be accomplished by using cookies instead. A well known example of a system using cookies instead of sessions for state persistence is WordPress.
So there, those are the major problems that make such a difficult task writing RESTful web services with most popular PHP frameworks. True it is that they offer mechanisms to create URL mapping which would allow for using well formed RESTful URLs, but at the end, all it does is to internally map a well formed RESTful URL into a non RESTful one. This could be seen as a good solution, but the fact is that it still ignores one fundamental aspect of REST architecture: HTTP actions.
As we know, every HTTP request includes an action among which the most well known are: GET and POST. But there are several others such as PUT, DELETE, and five more. These methods or verbs or actions are always sent in the request headers. So in the example above by sending the view verb in the URL we were in fact being redundant, because when we hit return in our browser the method GET was already being sent. Putting all this together we can see now that the URL http://www.domain.com/products.php?id=321 along with the HTTP method GET is all the server needs to understand what it should do, there is no need for a verb in the URL.
We have already seen three major problems that prevent us from using popular PHP frameworks to easily and naturally write RESTful web services. We have also stated that HTTP protocol methods plus noun oriented URLs are enough to properly process any HTTP request. What we have not yet discussed is if the problem we have is worth the cost of finding a solution; of course the answer to me is a bold yes, because once we have the tool (a framework that natively produces RESTful applications) and we get use to think in terms of HTTP verbs and noun oriented URLs, we have a whole new range of possibilities.
Since we don’t use sessions anymore we get rid of all its associated security problems. Sessions may still be necessary for some applications such as a shopping cart to remember cart content, but this could be done without caring about keeping that information safe since it is not critical.
Writing a RESTful web service would not be a problem anymore because the whole application would be a web service itself, capable of detecting what must be done on which resource and how information should be returned.
Plus, since we got rid of sessions we can be sure that an application may respond to requests coming from the same application as well as from those coming from external applications, provided the required cookies are sent along. This leads to the next important feature:
An application that usually have a mechanism to display a list of products could, with minimum changes, start to share that same information with external applications. This is so, again, because even the simple request that returns HTML code to a browser is a RESTful web service that may be easily extended to return the same information formatted as jSon or XML or even as a serialized PHP array.
I have had the chance to prove myself right in at least the last two points -because I have not yet been victim of hackers but this may just be a matter of time… no rush though-. Anyway, the point is that there is already a RESTful PHP framework under construction but fully functional and already being used successfully to build real applications. I am talking about the a3gFramework project.
a3gFramework revision 49 introduced a fantastic tool: short codes. For those who don’t know what these are I will explain a little bit:
In the context of a3gFramework short codes are a special sequence of elements inserted in a text that may later be processed through a new type of hooks: the shortcodes.
For instance, if we had a page and we wanted to insert HTML code generated in runtime by a callback function, we would have to insert a short code in the place we want the new HTML code to be inserted. Lets see an example…
First, we request for the short code to be applied on a text:
$theText = "This is the text and [[insert_word_here]] is the short code."; $theText = apply_shortcodes($theText); echo $theText;
How we get the text is not important, once we have it in a variable, we just send it to the apply_shortcodes() function. This function will take care of detecting the presence of a short code and replace it with whatever the hooked callback function returns. If the short code insert_word_here don’t have any callback hooked to it, then it will just be removed from the text and nothing will be shown in its place.
Now we define a callback function and hook it to the short code:
add_shortcode("insert_word_here", "insertWordHere");
function insertWordHere()
{
return "<em>here</em>";
}
The wrapper function add_shortcode() hooks a callback function to a short code by its name. In this case we hooked the function insertWordHere() to the short code insert_word_here. The short code and the function don’t have to be called the same.
The last thing to note here is that the callback function for a short code must return whatever we want to take the place of the given short code in the original text. So in this case, the [[insert_word_here]] will be replaced by the word here, giving as a result the phrase:
This is the text and here is the short code.
The concept of short codes applied to page content is fantastic, I saw it for the first time in WordPress. Today I was finishing a new page to promote Zen Cart services in Quality-Bits.com and I wanted to insert a little piece of HTML code at the end of the page that I would be using in many other pages, so I decided to introduce short codes in a3gFramework. And it works like a charm… see for yourself (http://www.quality-bits.com/page/services_zen_cart): the little banner on the right about osCommerce and the banner at the bottom with the button “Work with Us!” are both HTML elements inserted in run time into the page… pretty cool isn’t it?.
Finally! a3gFramework is available fro download at source forge.
The documentation will (I say will because there is nothing there YET) at the project’s wiki.
There are also forums for those who want to get involved.
Just a few minutes ago the answer to a question that I have been asking myself the whole year, came as an overwhelming empirical demonstration of the truth.
Before going to the question lets establish the context:
Before I started the QualityBits project I was working as a Web developer for John D. (not his real name of course). Almost from day one, we had this debate about how things should be done. Every chance he had he claimed that he was a hacker; which in this case meant that he didn’t have to understand the big picture of a given problem in order to fix it. His philosophy was -and still is- that trying to understand the whole thing, find the proper place and the right way to make the required modifications was OK but it would take too much time and would make customers angry.
He had a point there: we don’t want angry customers because angry customers tend to move to the next programmer in the list. However there was something about hacking the way out of problems that I didn’t like at all. Something told me that this could fix a given problem in the short run, but could bring bigger problems in the future. And this takes me to the question:
What is the best way to address a given programming problem: attacking the symptoms (John’s way) or trying to understand the system as a whole and “go with the flow”?.
The first way is faster and makes customers happy, but delivers a time bomb. The second way, could make customers angry but -if we are lucky and they don’t go away- we would be delivering not just a “hack” or a “fix”, but a system with consistent extended functionality.
The really bad news here is that in most -if not all- cases, the customers will never know the difference; because when the time bomb explodes, since they are happy with the hacker, they will believe any explanations about why things are not working anymore.
Obviously the answer would never come from John nor from myself. So I wrote Alex King -a man I look up to because he lives what I dream about, professionally speaking- looking for an answer. He did gave me a very good answer, but it was not the one I was looking for: I was looking for a black-or-white kind of answer.
So time passed by, I started QualityBits where I am free to go by my “do it properly” way with my first customer. Yes, things are taking longer than they would with the “hack it” way, but this is the ideal customer: patient and rational.
Anyway, today John called me because finally a bomb exploded. As his employee I was working on a site involving on-line payments for conference registrations. Conference registration were working already but the customer now wanted to use the payment gateway for membership renewals and other services they had. After ten hours of work on that problem and with a long to-do list, John decided to take care of the job because the customer needed the job done and I was burning in osCommerce-coupons-contribution-in-a-highly-customized-site-Hell.
After a quick talk and a couple of question-answer sessions, he “hacked” his way out of it in a few hours. I knew at that time that, the way he did things, conference registration could have problems but, since conference season was off, that would not be a problem in the short term.
Well, conference season is on again, and on-line registrations are not working on the site. I don’t work for John anymore in the same conditions I did but I am available for contract work so he called me to fix the problem. The bad news here are that there is no easy way to fix it if you want to do it properly. Of course, you could hack things out but…
At the end, I had my answer. Sadly it is not a black-or-white one. It is more like the one Alex King gave me when I asked him: “I think both approaches can work, as long as both the client and developer have the same expectations.”
Yes, he is right, however I am today more convinced than ever that I will never hack my way out of problems. If customers get mad at me because I am slow, then I will loose that customer. But those who understand that programming is not fire-fighting will stay with me and together we will build a good long term professional relation.
|
|
English
Español 