Fork Me on GitHub

Update 1.3.2-1.3.5 and move

September 5, Mon 7:02 pm

Updates for versions 1.3.2 through 1.3.5 have all featured bug fixes. There may only be one or two more 1.3.x releases before a final version marked for 1.4. Being that 1.4 is a stable release, 1.4.x releases will only feature bug fixes. All new features will be added in the development version 1.5.x.

Things scheduled for the 1.5.x release branch include:

With the release of 1.3.5, we moved from SourceForge to GitHub. This move was made because we feel that Git is much faster and easier to develop with than Subversion (in our opinion) and Git also offers the ability to define a remote to the Fabriq GitHub project so that users may issue a git pull command to update their copy of Fabriq.

If you are using Git to manage your Fabriq based website/web app, run the command git add remote fabriq git://github.com/willsteinmetz/fabriqframework.git to add a Git remote to the Fabriq project on GitHub. Whenever a new version of Fabriq is released, you can run the command git pull fabriq master to fetch and merge the latest update of Fabriq into your project.

We are also storing modules that are not part of the core such as the blog and Google Analytics modules on GitHub. To pull down a local copy of those modules to work with, navigate to your modules directory and clone the appropriate project. This will also enable you to run git pull to update to the latest release of each module when they become available. A full list of non-core modules is available on the Fabriq project page's README section.

Update 1.3.1

April 23, Sat 3:33 pm

Fabriq 1.3.1 introduces a big fix for the update and install actions of Fabriq possibly not pulling in the proper template.

Adding onto version 1.3's addition of modules, 1.3.1 introduces module events. Module events are used to enable modules to execute certain functionality when other modules trigger an event. Mutliple even handlers may be assigned to a single event. An example use of this is in the event of a module that provides photo album capabilities has a photo deleted, it can trigger an event that would be handled by another module that managed the photos on Flickr to also delete the photo on Flicker (please note, no module like this currently exists and this is just used for demonstration purposes).

The documentation will be updated soon with all of the functionality introduced in versions 1.3 and 1.3.1. The documentation pages will also be redone soon to make use of Fabriq and also stick with the same page layout as the main site.

Fabriq::link_to() to use or not to use?

March 27, Sun 10:35 am

Back in the days before the PathMap (and BaseMapping) core classes were added and the introduction of modules which brought forth the pathmap module, the Fabriq::link_to() function made perfect sense. In those days URLs for Fabriq sites/apps always only contained the controller and action and all of your other variables were query strings.

The BaseMapping and PathMap core classes were added to enable the beginnings of creating custom paths as well as write fully clean URLs. The BaseMapping has the core mapping functionality and the PathMap class extends BaseMapping and lives in the /app directory so that it can easily be added to.

A handy feature that was moved from the Fabriq class to the PathMap class was the build_path() function. By calling PathMap::build_path() and passing in a variable number of arguments, a URL is built for either clean URLs if they're turned on (which it is recommended that they are) or not clean URLs. This function came in handy for update actions where you also want to pass in the item ID that you're working on (ex: http://example.com/controller/update/123) in a form element's action attribute. While Fabriq::link_to() is used to build a complete link, you can build a more natural looking HTML link by using the PathMap::build_path() function for href attribute of an <a> tag.

So is it bad to use Fabriq::link_to()? In traditional controller and action only in the path circumstances, probably not, but it is recommended to use the newer and more versatile PathMap::build_path() function in an <a> tag's href attribute. At this point, there are no plans to depricate Fabriq::link_to(), but it could happen at some point in the future in favor of using PathMap::build_path().

Core requirements

January 13, Thu 4:44 am

jQuery has been included in every release to date and with version 1.3 will be required. All uses of jQuery inside of Fabriq framework core library will use jQuery by referencing the jQuery object and not the magic $ object so that you can still use other JavaScript libraries that make use of the magic $ object.

Version 1.3 also includes the CSS3PIE attached IE behavior to render some of the new CSS3 styling properties that are being used in new parts of Fabriq. For more on CSS3PIE, visit their website at http://css3pie.com/.

Both are stored in the appropriate place in the libs directory of the Fabriq install.

So why are both of these required for Fabriq as of version 1.3? Along with the start of templating and modules, 1.3 also includes a tiny JavaScript UI library. I know you're asking, "Why not just use jQuery UI?" We're not using jQuery UI for what we want to accomplish because we have very simple needs and a more customized interface than what is included with jQuery UI. Plus, our custom library is a lot smaller because we're not creating or using anywhere near as many widgets or features.

1.3 Modules

January 8, Sat 3:26 am

I'm not lying 1.3 really is being worked on and truly is taking a while to get to the point of being ready for release.

I wanted to post a quick blog about the three core modules being introduced in 1.3: roles, pathmap, and users

The roles module is used for creating and managing user roles and permissions.

The pathmap module is used for creating custom paths to pages in your site and is utilized by other modules. The pathmap module is useful if you have a URL such as example.com/blog/read/4 and want something more reader friendly such as example.com/awesomepost. When set up, both example URLs will take you to the same page. Other modules make use of the pathmap module if they expose pages (some modules may only expose functionality).

The users module is (obviously) used for managing users. It also handles logging in, logging out, registration, creating users, deleting users, banning users, re-enabling users, and password reseting.

All three modules are turned on and cannot be disabled because they are core modules for helping make development using Fabriq even faster.

The install process is being updated to make use of the framework for setting up a Fabriq website/web application. At the same time, an update function is being added to enable any core database changes and installing and configuring core modules.

1.3 Details

November 17, Wed 1:14 am

No worries about this development cycle being a long one. Lots of new functionality is being packed into this dev release including the start of both templating and modules.

Stay tuned here, Twitter, and Facebook for more details.

Version 1.3 (dev) details

October 31, Sun 9:16 pm

Dev version 1.3 will implement templating functionality in Fabriq. Developers will have the option to turn templates on or off at a global level for their applications as well as be able to turn them on for small areas rather than the entire app/site. The templating system will also handle partial templates.

1.3 may also include modules, but it's possible that implementing module functionality may be held off until the next dev version (1.5).

Blog Now Active

October 23, Sat 1:18 am

Preceding the release of version 1.2, a blog has been added to the Fabriq site. The blog will contain periodic updates about the framework, the site, and documentation.

In the coming days, we will also be posting a tutorials section as well an about page.

You can also keep up to date with us on Twitter at @fabriqframework or on Facebook.