I would like to welcome anyone who wants to participate in brain-storming and helping with some testing of 4.2 into our new google group:
You can learn a lot buy learning fundamentals of Agile Toolkit. I’m starting from the very bottom layers of the framework, so join in quick!
I have asked few people in London, who was up to help me out with Screencasts. Few people responded who have some ideas they wanted to implement in Agile Toolkit. I was able to help them and recorded our sessions. I now have 8 hours of screencast footage, which I’ll be releasing to youtube.
Subscribe to my channel on YouTube to see the screencasts as soon as I publish them.
The first 6 one-hour sessions is about creating a simple Task Manager. Many thanks to Maurizio for his participations.
Screencast with me!
If you’ve got Skype and great idea for Agile Toolkit we could help each-other. I can help you move forward with your idea and I would get a material for a new screencast session. Please use contact form to send me your ideas.
As we nearing our deadline fro 4.2 release a lot of cool features have been added into development branch of Agile Toolkit such as:
- Completely new “TMail” implementation
- Completely new “DB” implementation based on PDO
- Completely new “DSQL” implementation
- Completely new “Model” implementation
- Completely new SMlite implementation
- Improvements in Site Debugging
The new implementations are functionally compatible with the 4.1 branch, although the do offer a number of benefits. In this article, I’ll highlight some of the new features about the new component implementation.
Another important feature of all the new modules is that they are are under heavy automated testing from the very start.
Author of Agile Toolkit
I first have learned about Object Oriented in the age of 10, in 1990. I have already mastered BASIC and was exploring the world of Turbo Pascal. My young mind couldn’t grasp the ideas of in capsulation and polymorphism so I asked my mom to help out. She took the book and carefully kept re-reading the introduction.
“Objects. Think Objects”.
Years later I have been eager to apply the Object Oriented principles everywhere: the games I wrote, the demo-scene productions, my copy of multiplayer user dungeon. When I settled in as a Web Developer and learned PHP3.0 I was disappointed at the poor implementation of the objects.
The birth of Agile Toolkit was as soon as the Zend Engine 2.0 alpha was released. I started to re-wrote the framework I had into a new, powerful language. From the first versions the most important distinctive feature of Agile Toolkit today have been embedded into the very core of the framework.
Rendering of the Runtime Object Tree
2-3 decades have passed since the concept of Object-Oriented User Interface have been launched on the desk-top computers. The realization that the elements you can see on your screen have many similarities even through the look differently defines every Graphics User Interface today. To understand this concept Imagine a “button” and a “input field” next to each-other.
Here a two object quite distinctive in their appearance are being rendered by the operating system by calling each object’s rendering function. The system may decide to force objects to re-render or skip rendering if they are not actually visible on the screen.
The exactly same idea is in the foundation of Agile Toolkit. Because I have been creating my own User Interface in Pascal and Assembler this was to me the best possible solution to interfaces in the Web Applications – implement them as a tree of visual objects generated during the run-time of your application and then rendering the necessary components.
Making Interface More “Webby”
Initial implementation of Agile Toolkit was only good to produce back-end administration systems as it was too in-flexible to do the requirements of the creative minds of our web-designers. Many UI Frameworks are destined with the same interface style, but Agile Toolkit was able to introduce a great breakthrough.
All the objects in Agile Toolkit, no matter how complex, are producing a valid HTML code based on object templates. This approach allows to easily change HTML behind individual or all objects and finally produce the great solution for website front-ends. However the default look and feel of Agile Toolkit application gives developers a great start.
With the increasing complexity of our projects, it became apparent that a Objective Model layer is necessary. It finally appeared in Agile Toolkit in 2008 as an optional component. The models in Agile Toolkit serve a different role than the Models of other ORMs and Frameworks. Instead of only offering DataBase engine transparency and populating classes from data structures models in Agile Toolkit introduce a new dimension to modeling – inheritance. You can understand the power of this when you can narrow down values in the drop-down field by simply setting the right model to the reference definition. SQL Databases could not implement such flexibility but a PHP framework can.
RoadMap for Agile Toolkit
Up till now, Agile Toolkit had been walking a different path than other frameworks. Their goal was to provide developers with “utility” or a wrench to do certain things better. Approach of Agile Toolkit is to build levels of abstractions from the very bottom up. I must admit, that I can solve any web-related task with Agile Toolkit, but if I must produce a solution in clear PHP I feel lost and confused.
The immediate road-map for Agile Toolkit is to improve the 3 strengths it has by making it easier to interact and build. The “Model Builder” is in the works, which provides a visual interface to building new model fields and actually generating a PHP file as a result. The syntax of Models is already extremely simple but it will be even more so with the builder.
Another initiative is the User Interface builder. This allows create pages and add objects on your pages with a drag-and-drop interface. Similarly the tool would be capable of outputting a valid PHP code you can then further modify.
The number of Views and Templates will be made available through an on-line repository. In a way this would be similar to WordPress extensions, but tho time you will be installing classes which will aid you in building an Interface. The available views could be either free or paid creating a possible new revenue model for developers. A good example for such an view would be a “Gallery”. You could add this to any application you’ve got and bind it with the model holding images.
I adore web applications, but today it is way too complicated to build a web application. The situation reminds me the “DOS” and with Agile Toolkit I am able to introduce a Graphical User Interface for The Web.
I’m pleased to announce the update of the “codepad”, which has been transformed into much more powerful Example browser and Object inspector.
One awesome tool I’ve created in the process is the right-side “inspector”. Inspector examines the current page and objects on that page looping through them and finding objects which were added by the example. You can then mouse-over the objects to highlight the objects on the page or click to see source code of that class.
Enjoy all the examples and I plan to add more examples (from http://demo.atk4.com/) soon.
Download and Install Codepad
Would you like to look further into how codepad works? You can get it from github:
git clone git://github.com/atk4/atk4-codepad.git
git submodule init
git submodule update
Add your own examples into page/* to share them with your friends. You can also “fork” codepad and push back some of your own examples if you would like to see them in the Codepad.
The question I get asked a lot is how to integrate Agile Toolkit with other frameworks.
One of the best qualities of Agile Toolkit is that it can be very nibble when you want to use it to fill the gap. So let’s scrap the whole page routing mechanics and simply create a SINGLE PHP file which would work on it’s own. For this, you will need to have most up-to-date Agile Toolkit (4.1.3).
I am working on a project, which features numerous places where it’s possible to select a client from a drop-down. I thought about creating a single class, which will work as a button, but would also contain the logic of actually adding the client through a form in jQuery UI Frame.
As a result, I’ve created a universal “NewEntry” button, which can be added anywhere like this.
This produces the following:
- Button is added next to the field
- When button is clicked, new dialog is displayed offering to add new client
- After form is submitted, dialog closes and new client is automatically selected in auto-complete field
- Works with any model, label and list of visible fields can be customized
Agile Toolkit is awesome because it’s simple. Sometimes it lacks a feature, but it’s simple to add this feature. Having all those features in the core would be an over-kill, so many features are not in there on purpose.
An example is this controller, which will make items in your Grid order-able. Here is the screenshot of how it performs:
This sexy interface is implemented as a stand-alone controller in Agile Toolkit in about 70 lines of code and small bit of HTML, no JS or CSS. But more importantly, it can be added to any Grid out there with just this:
Why is it important / cool?
- It uses standard interface and will look right at home inside your project.
- Relies on standard elements of Agile Toolkit.
- Simple enough for you to read through and understand
- Object-oriented so you can extend it to make it behave differently.
- Requires no change to Grid.
- Works with any model (just add numeric field “ord”)
Share your code!
When you develop your software, your goal is to get it done. This controller took me about 30 minutes to implement. To properly document it and share, it would take some more time.
I’m pretty sure it’s same for you. If you are developing with Agile Toolkit, you might have a few interesting bits out there. My plan is to make it super-easy for you to throw a link to your Github repository and then let others convert your code into the properly documented add-on. Instead of re-inventing it, they could clean it up and document.
This way we don’t have to re-implement every bit and we’ll have a great library of add-ons growing!
How to share.
First – put your code into github and make it public. Even if it’s your personal project, it won’t hurt.
I’ll be working on the section on www.agiletoolkit.org where you will be able to “share” some goodies you have in your code. Leave it to other devs to extract it from your code, clean it up and improve. Your contribution to Agile Toolkit community would be highly appreciated.