Yes. Disallowed Key Character, is a REALLY annoying error. It shows me absolutely NOTHING.

When you’re developing, you ought to modify this file:

system/core/Input.php

Modify the following function:

_clean_input_keys

And just above

exit('Disallowed Key Characters.');

Put in:

echo "Error string: {$str}";

So now, if you get that PESKY error it’ll show you where it’s failing.

Tags: CodeIgniter, pesky, PHP

Following my last post about social, Will Google Kill Social Completely I’ve come to a new realisation: it’s going to die.

Everyone and their dog is doing something in social these days. It’s a big market.

I believe that it’ll get to the point where people feel enough is enough. They’ll get sick of it and they will have their reasons for no longer thinking social is a big thing. It’ll probably be the painful realisation everything you’ve ever done is out there forever. Used to be when you made a real fool of yourself, you could start again with a new group of friends. That’s really no longer the case.

Think about all the kids that are on Facebook today, in 10 years they’ll all be getting into the professional industry and (hopefully) helping the planet go forth into the Future with a stride. However, if a simple search of their name is going to show everything they’ve ever done… how is anybody ever going to find a job? At least when most of us were young, and stupid we could actually learn and move on with our mistakes and not have it bought up every time at a job interview.

I really don’t think the social as we know it, is going to stay around very long.

If you’re trying to load more than one view in CodeIgniter, you may find it a bit weird.

For example, if you’re going to load 3 views at the same time within the same function, that’ll be fine. However, what happens if another function within that same controller wants to load a view?

It’s possible. You just need to put a

return false;

on the previous function.

Let’s explain it by simply showing you the code:

Class Something extends CI_Controller {
 public function __construct()
 {
  parent::__construct();
  $this->load-model('some_model');
 }

 public function step_one() {
  $this->load->view('some_view');
  return false;
 }

 public function step_two() {
  $this->load-view('some_view_more');
 }

Without the

return false;

part, then step_two view won’t load.

Hope that helps.

Tags: CodeIgniter, PHP, Views

Ever since the web was born, it’s been constantly changing. It started off as a text based medium for academics. Now it’s a global media powerhouse, creating entire industries. Yet the foundation of the web hasn’t changed. HTML isn’t even a correct description now, as most of the data is media.

Over the past few years there’s been a shift in the information schemas of the web. The Data Object notation is becoming de facto; AJAX, config files and data storage are all adopting it. For example the newer nginx uses a JSON like config files, vs Apache’s older XML files. Some bloggers have even claimed XML is dead.

Applying this paradigm to webpages is the next logical step; HTML is still using an ugly dialect of SGML. Hyper Text Data Objects or (or HTDO) are better in many ways:

• it’s more readable
• can be built by objects. OOP guys will love this: build up the DOM server side using objects (though you can still spit HTDO out as a string). Imagine adding a class to your input tag object, and they all change!
• reflects the DOM better. Inline tags could be a simple string:string relationship, while block level elements could be arrays of other objects. There are a few exceptions, for example it’s handy having anchors as block level elements.

Here’s a mockup of what it could look like:

{
        "title":"webpage",
        "meta":"charset:UTF-8",
        "stylesheet":"styles/style.css",
        "content":
        {
                "h1":"welcome to my webpage",
                "p":"this is my content",
                "a": {
                        "href":"/page2.htdo",
                        "title":"click me",
                        "link":"the next page"
                }
        }
}

Because the DOM can be built both server & client side, it would make for an interesting use of the _target anchor tag attribute. Imagine if you sent #selectorID as a tag, it sent with a header, and the server responded with only the HTML you needed? It would keep your URL intact but feel just as snappy as an AJAX request.

I’d love to see a DOM parser built as an extension in Firefox or Chrome for this experimental format. It might even fit in with Google’s “build a faster web” campaign.

There are a few disadvantages, for example <em>emphasis or bold</em> tags are more cumbersome. Also putting ID & classes on inline elements is a hairy problem if they’re strings only. Either you could wrap it in an id, have a CSS selector “string#IDname”:”string”, or have inline elements as arrays. For purity, I’d rather just warp the inline element.

Tags: concept, HTDO, HTML, meta

If you’re getting the following error when trying to activate an account using Django 1.4 and django-registration:

can't compare offset-naive and offset-aware datetimes

Then you need to update the source of django-registration manually.

The error file will tell you exactly what file to edit. In this case we need to edit:

registration/models.py

the full path to my file was:

/usr/local/lib/python2.6/dist-packages/registration/models.py

The next step is to import new timezone support:

from django.utils.timezone import utc

Next go to the bottom of the file, and find:

return self.activation_key == self.ACTIVATED or \
    (self.user.date_joined + expiration_date <= datetime.datetime.now())

And replace with:

 return self.activation_key == self.ACTIVATED or \
    (self.user.date_joined + expiration_date <= datetime.datetime.utcnow().replace(tzinfo=utc)) 

That should work now!

This is only a hack. I'm not even sure if it's correct. So if you do come across this and you can do better, please let me know.

Tags: django, django 1.4, django-registration, error, Python