Archive for February, 2010

Creating an XML vocabulary for the UI

Saturday, February 27th, 2010

One benefit I’ve experienced is that you have tighter, centralized control over the markup generated for the UI when developing under an XML language for UI pages.

If you get 5 people coding forms in html, you’ll get 5 variations on the markup. Using XML instead, you can have tight control over what is and isn’t allowed.

<ui:form method="POST">
    <ui:field name="street1" />
    <ui:field name="street2" />
    <ui:field name="phone" />
    <ui:hidden_field name="id" />
</ui:form>

XSLT can be used to create the html you’d like:

  • automatically surround fields with fieldset element
  • automatically create submit buttons without having to declare them.
VN:F [1.8.4_1055]
Rating: 5.5/10 (2 votes cast)
VN:F [1.8.4_1055]
Rating: +1 (from 1 vote)

Warning: Unknown: Your script possibly relies on a session side-effect

Monday, February 1st, 2010

I came across this error a few times, enough to where I dug around and finally found the real fix to supress the error completely.

Warning: Unknown: Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively in Unknown on line 0

I was able to supress the error by properly unsetting a session variable:


  //replace this:
  $_SESSION[$field] = null;

  //with this:
  unset($_SESSION[$field]);

The warning is triggered by assigning to the $_SESSION super global directly. By using unset(…) we are not assign null directly.

VN:F [1.8.4_1055]
Rating: 10.0/10 (1 vote cast)
VN:F [1.8.4_1055]
Rating: +1 (from 1 vote)

Sending UI Messages in PHP

Monday, February 1st, 2010

I am using sessions to save UI messages that can be shown to the user after an action has been formed (ie: logging in).

My initial problem was that the message persisted, while attempts to unset the session message didn’t allow for any messages to be shown.

Here’s how I solved the problem:


class Application {
...
  public function getMessages() {
    $messages = $_SESSION['messages'];
    unset($_SESSION['messages']);
    return $messages;
  }
}

First save the messages from the session, then you can delete them out of the session so they don’t persist past the one request.

Here is how I set the proper success or error message in the login function:


public function doLogin($username, $password) {
  ...
  if ( $username == $user->username && $password == $user->password ) {
      $_SESSION['logged_in'] = true;
      $this->addMessage('You are now logged in.', 'success');
  } else {
     $_SESSION['logged_in'] = false;
      $this->addMessage('We were unable to log you in.', 'error');
  }

  return $this->isLoggedIn();
}

I’m using smarty templating for PHP; here is how I get messages into my layout template:


class Application {
  ...
  public function showPage() {
    ...
    $smarty->assign('messages', $this->getMessages());
  }
  ...
}
VN:F [1.8.4_1055]
Rating: 10.0/10 (1 vote cast)
VN:F [1.8.4_1055]
Rating: 0 (from 0 votes)