The objective of this post is to build toghether our first Pakyow application, "The Trend Factory". We will move forward step by step inspecting some of the main features of the framework.
If you want/need more detailed information about how Pakyow works you can check the Pakyow’s official manual.
01| Install Pakyow
gem install pakyow
02| Create the Application
pakyow new the-trend-factory
That will create the following application skeleton under the
app/ lib/ application_controller.rb views/ main.html pakyow.html config/ application.rb logs/ requests.log public/ favicon.ico config.ru rakefile README
03| Start the Development Server
cd the-trend-factory pakyow server
That will start your development server listening on
Now open your browser and go to
http://localhost:3000. You should get an Apache like
Welcome to Pakyow! message.
04| Create the Application Index
What you have just seen is the default content of the application index view.
Views are constructed starting form a Root View html file.
Root Views define the main structure by creating Containers.
Containers are html elements with a custom
The Containers will then be filled with its related Content Views.
Content Views are html files named as its target containers
id value. They can also define containers to be filled with the content of other Content Views.
pakyow.html is the default application Root View
This view defines a
wrapper and a
The framework will then try to fill them looking for their namesake Content Views under the
./app/views/index/ directories. It will actaully follow some sort of directory hierarchy, starting from the deeper directory and using the first matching file that it finds in there or in any of its parent directories.
./app/views/main.html exists but
./app/views/wrapper.html don’t only the
main container will be filled with:
The resulting html:
Now that we have a sence of how this works let’s edit the title to
The Trend Factory and create its homepage message.
Refresh the browser to see the chenges taking effect.
05| Creating a new Path/View
In order to let users post they trend messages let’s build a message creation view for them.
To enable the
message/new application path we need to create its Content Views directory:
We need a custom
main.html with a Container that will hold the message cration form.
Now we need a
form.html with the message form. We can create it either under the
./app/views/messages/new/ or the
./app/views/messages/ directory. Since is a message representation and is not really bounded to the message creation I will pick
At this point you should be able to hit
http://localhost:3000/messages/new and get the message creation form.
06| Process the request
Users will be posting messages so we will need a
Message model representation to handle them.
Note: Keeping the simplicity of the example we will store messages in memory (they will live as long as the server is alive, will be destroy after the server stops).
Let’s create our models under a
Now we need to create the Route, Controller and Action to handle the messages creation.
Routes are defined within the
routes block that lives on
Single routes can be defined following this pattern:
method path, controller, action
On our example we have a
post request using the
messages path and we will define a
MessagesController with a
create action in it.
Now that the route is defined we will need to create the
Skiping the discussion about organization and keeping things simple I will just say that Controllers can be define within the
./app/lib/ directory. Actaully the framework will autoload any file that lives within the
./app/lib/ directory or any of its children.
Actions can then be defined as
public controller methods.
This would be our brand new
At this point submitting the message form will create a post request that will go throug the
create action. Here you can interact with your classes and access the request information via the
Pakyow::Helpers methods [Available helper methods documentation Here].
To make it store the message we must make some changes over the controller:
We are succeessfully creating and storing the messages. How can you check that ? …
07| Render Stored Information
Let’s create a messages listing to render all the stored messages under the
Startign with its views we will need a
main.html under the
message.html with the message html representation. We may want to show messages on several sections of our application so make it a generic html creating it unde the
itemprop value is composed by the object class name and the object attribute that should be used to fill the element (
object_class[object_attribute]). This will be then used at the controller to bound the object instance with the html structure.
Note that we are just defining the html structure of a single message here. The list of them will be generated from the controller, using the message structure.
Once again we need to create a route for the messages index and an action to load the messages and handle the view.
There is a
repeat_for with a collection as param will copy and bind the target view for every collection member. On this example the
./app/views/message.html will be repeated for each message and filled with the message current values.
We are also using a
Message.all method there that we can easily define:
http://localhost:3000/messages will now hold the listing of the current messages and a link to the message form.
Try posting a couple of messages and see how they are added to the list.
08| Edit Objects
Editing messages will be a two steps process. Users will go to an edit page with a form in there where they will be able to modify the selected message. Submiting that form should update the message and take them back to the messages listing.
Since every message needs its own edit link a container needs to be defined for them.
Note: We will use tables so we dont’t get distracted with the CSS.
There we have a new span that will be filled with the following
edit_link content view:
There we have our link, whithout a defiened href, and an image as content.
Public files, such as images, can be dropped on the
./public folder. On our example we will need the following image file:
Util now we were using the html
itemprop attribute to make the framework fill the elements using a given instance method (
This works greate when displaying object’s attributes but doesn’t really fit if we need to render information with a custom format sice we may end up with a really dirty class full of useless methods.
Here is where Binders come to the rescue.
Binders are classes that can be bounded to our models and defien all these methods that will interact and return the fromatted object attributs.
Whenever a Binder is defined for an object and this is bound to an html element the framework will try to find the method in the binder first and then in the object class (
binder.method || object.method).
Let’s use one of them to generate our edit link href:
As you can see Binders should inherit from
Inside the Binder the bounded object instance can be called as
Note that the
edit_link method is returning a hash. The framework will use hashes to modify the html attributes based on its keys. On our example the link
href will be replaced with
We now need to define the message edit route and action:
Note that we are using a
Message.find method that should be returing the message for the given id (defined below).
Another remarkable call here is the
bind with an object as param will bound the object attribute values to the target view. On our example we are getting the message form and binding a message instance to it (auto fillng each of its fields).
bind is not able to match the html elements by their
name attribute we will need to add the
itemprop attribute to them too.
And here we have how our
Message.find method looks like:
You can now try how this works. Create some messages and then navigate to the messages listing page
Clicking any of the edit links should take you to the message edit page
The first step is done. Now we need something to handle the update process on the backend and redirect the user to the listing.
Time to create our messages
update route and action:
And another new
message.update, that will update the messages attributes given a
:atrtibute_name => :attribute_value hash:
And you are rady to update messages and see them updated on the messages listing page.
I think that is is enough for a first trip around Pakyow. Starting from here I will be posting a series of articles covering advanced features of the framework, inspecting the bakend and discussing the code organization for different types of projects.
Don’t be afraid of leaving your thought or contacting me if you have further questions or critics about the post.
If you have question, problems or want to share your Pakyow experience try to use its communication channels: