As web developers, we often run into problems while handling various assets such as images, scripts and css files. To make it easier to access and call such assets from within the Code Igniter framework, here is an implementation of the Asset Library, which we have been using at Wallwisher. Hope you find it useful.

Structure

In parallel to the Code Igniter system folder in your implementation, place a new folder called assets. Inside this folder, feel free to describe new assets such as images, scripts, styles and others necessary for your implementation. You need the following files to implement the library:

1. Configuration File: to be placed in system/application/config/ 

   assets.php

2. Helper File: to be placed in system/application/helpers/

   assets_helper.php

3. Library File: to be placed in system/application/libraries/

   Assets.php

Examples

Here are a few examples which might help you in understanding the usage of this library:

1. $new_image = ‘.’.asset_url(’example.jpg’,'images’);
2. $CI =& get_instance();   $new_css = $CI->assets->get_asset_from_name(’css’,$name);

There is a lot of buzz about WYSWYG editors of all kinds. At Wallwisher, we have spent considerable time and energy in implementing a true WYSWYG feel, whereby there are no forms which require you to refresh the page.

With Wallwisher, a user can interact with the web elements to an increased extent than other web applications. With this increased interactivity, it is important for the elements to behave in a predictable manner, and the end result of each interaction to be what exactly what the user wants it to be. This is true WYSWYG, and Wallwisher hopes to continue down this path in the coming months!

Ever had trouble with JavaScript based drop down menus?Do not fear! CSS-Menus are here!Yes, you read it right, completely CSS generated drop down menus. We, at Wallwisher, always try to minimize the JavaScript on our home page, so as to reduce the loading time, and hence came to birth CSS-Menus, a completely CSS based drop down menu. You can see the effects on our live site, before looking into the code…So, let’s say you want to build a similar drop down menu, with the trigger text called “Click Here”, and three example links in the drop down. Here’s a sample code on how to do so…

 <ul class=”dd_menu”> 

    <li>Click Here</li> 

    <li><a href="http://www.example.com">Example 1</a></li>

    <li><a href="http://www.example.com" >Example 2</a></li>

    <li><a href="http://www.example.com">Example 3</a></li> 

</ul>

<style> 

    .dd_menu li { display: none; } 

    .dd_menu li:first-child { display: block; }

    .dd_menu:hover li { display:block; }

</style>

 As you will notice, by default the <a> tags in the main span are hidden. However, on hovering over the .dd_menu class, we display the .dd_link class, making all the <a> tags visible. This works perfectly in IE 7, Opera 9, and Safari 2. We sincerely hope this helps all developers out there, as it is so simple to use, and very elegant in the context of simple UI.

If you have or are working with various JavaScript files, you might have faced the same problems we have faced over the last few weeks, those of .js and .css files increasing the loading time of your website, and the constant irritation of minifying all those .js files. So, here are two steps which can solve both these problems:

Reducing the size of JS files

Use the JSMin filter, which removes comments and unnecessary whitespace from JavaScript files. It typically reduces file size by half, resulting in faster downloads. You can get this library at JSMin Library.

Reducing the number of JS and CSS files

At the point of loading all your .js and .css files, create an array containing the paths to all the .js and .css files. This would ideally be done in your controller. See example below:

$this->data[’js’] = array(’sample1.js’,’sample2.js’,’sample3.js’);
$this->data[’css’] = array(’sample1.css’,’sample2.css’,’sample3.css’);

Then at the point of calling your .js and .css files, simply call the following function. This would ideally be done in your view file.

<script src="<?=merge_resources($js,";",".js",true)?>" type="text/javascript"></script>
<link href="<?=merge_resources($css,"\n",".css",false)?>" rel="stylesheet" type="text/css">

This merge_resources function hashes the modified time of all your .js or .css files and stores a minified version with the name of the hash value. At any future call, it checks if a the hash values match, in which case it does not create a new minified file, else it creates and returns the new minified file. Here is an implementation…

function merge_resources($res_array,$delim=”,$ext=”,$jsmin=false)
{
    $jsmin=false;
    if(count($res_array))
       {
           $files = array();
           foreach($res_array as $r)
           {
               $files[$r]=filemtime( //insert path to the file $r );
           }
           $md5 = md5(serialize($files));
           $outpath = "//insert the path you want/$md5".$ext;
           $outfile = $_SERVER[’DOCUMENT_ROOT’].$outpath;
           if(!file_exists($outfile))
           {
               ob_start();
               foreach($res_array as $r)
               {
                   include //insert path to the file $r;
                   echo $delim;
               }
               $resdata = ob_get_clean();
               if($jsmin)
               {
                   include_once ‘JSMin.php’;
                   $resdata = JSMin::minify($resdata);
               }
               file_put_contents($outfile,$resdata);
           }
           return $outpath;
       }
}

While interacting with a website, how many times do you experience the mind-numbing request of pressing "OK" or "Cancel"?

We, at Wallwisher, hate the concept of this idea, of asking for user confirmation, when it’s simply not required. What is required is a notification, and there are other simpler ways of delivering them.

We like to use simple popup messages which fade away on their own, without the user having to click on "OK" or "Cancel". Let’s say in a chat room, the common rule is not to post more than 2 messages in a minute, to prevent spam, and allow fair distribution of contribution. If a user tries to post more than 2 messages, instead of popping up a dialog box informing the user of the rule, and asking him or her to press "OK", we would advise the use of simple fade away popup notifications.

See a sample implementation on Wallwisher Demo (post >3 stickies in under a minute).

As ardent users of the web, have you ever felt the frustration at static menus, giving you an option to "Sign up" even when you are on the sign up page ?!

Well, we at Wallwisher are true believers of cutting the nonsense out, and keeping the design very sensitive to the context of the page. We promote the use of

Context Based Menus…

A simple way of arranging Menu Items based on the page you are on. This is simply achieved by conditionally calling and displaying menu items depending on some key variables such as the state of the user (logged-in or not), state of the page (shareable or not), etc. Obviously, this entails a clear categorization of all links in the menu. You can see a sample implementation at Wallwisher Beta.

From the initial feedback gathered on the site, it seemed that randomly generated URLs were a big no no.. so here it is, support for FRIENDLY URL NAMES

So instead of some gibberish like wallwisher.com/wall/xyWedkf123, u can get wallwisher.com/wall/britneyspears080214 (if all britney related urls are not taken by us).

In fact, over the last 3-4 days we’ve made a lot of UI improvements like the accordion on the build page with clear error messages.

In fact, our goal is to be the most user friendly site on the Internet. Our benchmark? Wufoo.com. We really think the Campbell brothers and Kevin Hale of Wufoo have nailed it in terms of UI. Great going team Wufoo.. take a bow.. you are our inspiration.

Wow.. Wallwisher.com is finally live. It’s in private beta and I can’t control my nerves.. Would people like it? Would they find it useful? Would there be too many bugs? Jan 31 is the D-Day when the site will go live to the whole world. Until then is the testing and retesting time. Managing all the aspects of development by yourself is really not easy, but I’m enjoying it. 

This is the first post on the Wallwisher Blog while it is still residing at 127.0.0.1.

The site should be out of this dev environment pretty soon, hopefully by Jan 13, a good 9 days later than scheduled.

Right now just praying to God that people will like Wallwisher.

I know it is a very simple product offering a solution which can hardly be called a necessity - a wall for sending wishes.

What we hope to achieve though is that through Wallwisher people will have some kind of an e-ternal gift (an eternal gift on the web) which they can open again and again :).

Let’s see how far we go!!