Just read AppScout's post about how Facebook has announced their own version of OpenSocial, in an obvious move to compete with Google's initiative. I myself haven't done any developing for Facebook, but I wanted to put in my own two cents about what this could mean for OpenSocial.
It seems that Facebook, who already has a developer API in place, will win the race to get the API open to other Social Networking sites. This will push developers thinking of creating social network applications (SNAPPS) but waiting for OpenSocial so that their apps will be available on other networks in the direction of developing for Facebook. OpenSocial is in the sandbox/testing phase through Orkut, but not fully "open" yet.
Furthermore, developers who already create apps for Facebook will have little reason to even glance toward OpenSocial's direction. Facebook is just such a dominator in the Social Networking space. Granted, MySpace has announced their support for OpenSocial, which would be a draw as well, if it weren't for the fact that MySpace seems to be less of a site for SNAPPS than Facebook. Why is that? It's fair to assume that there will indeed be a great influx of programmers to develop for MySpace once OpenSocial is ready, though they will probably look a little different, as they will likely be geared toward a younger crowd.
If I were to start developing SNAPPS, though I am always very fond of open source initiatives and Google in general, I would be very tempted to go the Facebook route. It will be interesting to see how OpenSocial fares against this new initiative by Facebook.
12.12.2007
12.07.2007
Firefox is CSS-picky
It's a good thing, though.
Sometimes, when you are creating a layout in Firefox using CSS instead of tables (good for you!), and you are choosing to use position:relative; rather than the float property, you run into a problem where, if you have multiple links side by side, Firefox only allows the very last one to be clickable, and uses their heights as a sort of invisible mask to put over the rest of the links on the line (or, to be specific, within the same block-level element).
This occurs because, somewhere in your code, you probably have a block-level element tag that is missing the positioning style definition. That is, make sure all of your block-level elements have position:relative applied; it doesn't seem to cascade in the way to make sure your page elements will always have their own space to themselves, links being clickable and all.
Hope this clears some future headaches!
Sometimes, when you are creating a layout in Firefox using CSS instead of tables (good for you!), and you are choosing to use position:relative; rather than the float property, you run into a problem where, if you have multiple links side by side, Firefox only allows the very last one to be clickable, and uses their heights as a sort of invisible mask to put over the rest of the links on the line (or, to be specific, within the same block-level element).
This occurs because, somewhere in your code, you probably have a block-level element tag that is missing the positioning style definition. That is, make sure all of your block-level elements have position:relative applied; it doesn't seem to cascade in the way to make sure your page elements will always have their own space to themselves, links being clickable and all.
Hope this clears some future headaches!
11.27.2007
Cookies vs. Sessions
Hey there!
At one of my jobs I recently got into using GreyBox. I needed a simple-to-use popup tool to create a popup window when a user clicks on an item in the online store to add it to their cart. They would click "Add," a window would pop up, and they would select how many of the item they wanted. When they clicked 'submit,' the popup window would send that data to a PHP script via AJAX to another page.
This other page would then check some cookies. If the customerID cookie was set, it meant the user was logged in. If the orderID cookie was set, it meant whoever was logged in had a previously created, incomplete order. If the orderID cookie was not set, then a new order was created for the customer logged in, or a temporary customer named "guestXX", where XX is the same number as the new orderID that was generated.
This script worked just fine in IE7. Unfortunately, I don't have a setup readily available to test IE5.5 or IE6. However, in Mozilla some very strange errors would occur. When dumping the array $_COOKIE to debug, I would notice that after the GreyBox window sent the AJAX
request and processed the remote script, a new cookie was created, and for some reason the other cookies would not be output. This new cookie had a strange look, too:
Name: ASPSESSIONIDSASQTBAS
Value: BDINLFLBOLMLADEJFMELJFOM
Expires: Session
Looks suspiciously like an ASP session id to me! I went through and changed all the cookies to sessions, and it solved the problem. The scripts all worked perfectly fine.
I haven't determined whether this was because of GreyBox, which I believe is tied to ASP in some way, or simply a mismatch of AJAX and cookies, or a peculiarity of Firefox. But one thing is for sure: I'm a converted man. No more cookies for this fatty. Sessions for information that needs to be shared across pages during one user's visit, and database storage for the more long-term values.
(I was eating Oreos as I wrote this post.)
At one of my jobs I recently got into using GreyBox. I needed a simple-to-use popup tool to create a popup window when a user clicks on an item in the online store to add it to their cart. They would click "Add," a window would pop up, and they would select how many of the item they wanted. When they clicked 'submit,' the popup window would send that data to a PHP script via AJAX to another page.
This other page would then check some cookies. If the customerID cookie was set, it meant the user was logged in. If the orderID cookie was set, it meant whoever was logged in had a previously created, incomplete order. If the orderID cookie was not set, then a new order was created for the customer logged in, or a temporary customer named "guestXX", where XX is the same number as the new orderID that was generated.
This script worked just fine in IE7. Unfortunately, I don't have a setup readily available to test IE5.5 or IE6. However, in Mozilla some very strange errors would occur. When dumping the array $_COOKIE to debug, I would notice that after the GreyBox window sent the AJAX
request and processed the remote script, a new cookie was created, and for some reason the other cookies would not be output. This new cookie had a strange look, too:
Name: ASPSESSIONIDSASQTBAS
Value: BDINLFLBOLMLADEJFMELJFOM
Expires: Session
Looks suspiciously like an ASP session id to me! I went through and changed all the cookies to sessions, and it solved the problem. The scripts all worked perfectly fine.
I haven't determined whether this was because of GreyBox, which I believe is tied to ASP in some way, or simply a mismatch of AJAX and cookies, or a peculiarity of Firefox. But one thing is for sure: I'm a converted man. No more cookies for this fatty. Sessions for information that needs to be shared across pages during one user's visit, and database storage for the more long-term values.
(I was eating Oreos as I wrote this post.)
11.24.2007
Creating HTML emails from dynamic PHP files (or, a primer on output buffering).
Goddag!
This is my first post, and I wanted to share a solution to a problem I faced at work this week.
I was working on a PHP page that displayed an invoice that was to be sent to a customer from the admin section of the website, had the customer requested it.
The structure of the files were like this:
send_confirmation.php: contains a form with two input fields -- the email address of the customer, and the subject of the email. The form used a simple submit button to pass some POST variables back to the same page. Underneath the form, the file invoice.php was included, showing the sender what the customer would see in the email they received.
invoice.php: accesses various tables in the database to pull up the info of the particular order in question for the cutomer and displays the information using tables, inline style attributes, and tags to create an email-friendly-looking HTML invoice.
Here was the dilemma: I wanted to send the email using the contents of invoice.php as the body of the email. However, while invoice.php was included in send_confirmation.php, the contents displayed by PHP's include command weren't stored in a string anywhere, so I wasn't able to just pass invoice.php's contents along with the form submit.
My next thought was to just read the contents of the file into a string and pass that string to the mail function as the body of the email. I tried doing this, using file_get_contents. This worked; however, the email contained the actual PHP script of that file in its preprocessed form, not as it was to be processed into HTML code. After trying several permutations of this method to see if different functions would process the script and not just give me the contents of the file (saving it as a new file, etc.), I finally came across a set of PHP functions that did just the trick: the output buffer functions.
Essentially, this group of functions let you control how and when the content you want to output within a PHP script is output. For example, anything you pass to the echo statement in PHP is output. Anything from any of the print functions is output. And, content from statements like include and require is output. So, in order to control any of your output, you simply need to employ a few of these functions. Here's how I did it:
First, you have to "turn on output buffering." The code for this is quite simple: ob_start();
Until you do this, output will act normal; that is, your echo statements will be sent to the screen and your include statements will put the contents of the file there as you would expect them to. Once you call this function, however, your output will be stored in the buffer.
Once you have all the output stored that you want to control, you have some options. I haven't fully explored some of these, but taking a look at the functions in that category on php.net will give you an additional idea of what you can do to control the output stored in the buffer. As for me, I just wanted to call include "invoice.php"; and store the results of it into a string variable.
So after calling the include function, I used ob_get_flush, which returns the contents of the output buffer as a string, deletes the contents of the buffer, and closes output buffering. After that I simply needed to strip the whitespace from the resultant string (to avoid a ton of line breaks in the email) using
ob_start();
include "invoice.php";
$data = ob_get_flush();
$cleandata = preg_replace('/\s\s+/', ' ', $data);
Then just use $cleandata as the body of the email!
Until next time,
Auf wiedersehen!
----------------
Now playing: Evergreen Terrace - Wolfbiker
via FoxyTunes
This is my first post, and I wanted to share a solution to a problem I faced at work this week.
I was working on a PHP page that displayed an invoice that was to be sent to a customer from the admin section of the website, had the customer requested it.
The structure of the files were like this:
send_confirmation.php: contains a form with two input fields -- the email address of the customer, and the subject of the email. The form used a simple submit button to pass some POST variables back to the same page. Underneath the form, the file invoice.php was included, showing the sender what the customer would see in the email they received.
invoice.php: accesses various tables in the database to pull up the info of the particular order in question for the cutomer and displays the information using tables, inline style attributes, and tags to create an email-friendly-looking HTML invoice.
Here was the dilemma: I wanted to send the email using the contents of invoice.php as the body of the email. However, while invoice.php was included in send_confirmation.php, the contents displayed by PHP's include command weren't stored in a string anywhere, so I wasn't able to just pass invoice.php's contents along with the form submit.
My next thought was to just read the contents of the file into a string and pass that string to the mail function as the body of the email. I tried doing this, using file_get_contents. This worked; however, the email contained the actual PHP script of that file in its preprocessed form, not as it was to be processed into HTML code. After trying several permutations of this method to see if different functions would process the script and not just give me the contents of the file (saving it as a new file, etc.), I finally came across a set of PHP functions that did just the trick: the output buffer functions.
Essentially, this group of functions let you control how and when the content you want to output within a PHP script is output. For example, anything you pass to the echo statement in PHP is output. Anything from any of the print functions is output. And, content from statements like include and require is output. So, in order to control any of your output, you simply need to employ a few of these functions. Here's how I did it:
First, you have to "turn on output buffering." The code for this is quite simple: ob_start();
Until you do this, output will act normal; that is, your echo statements will be sent to the screen and your include statements will put the contents of the file there as you would expect them to. Once you call this function, however, your output will be stored in the buffer.
Once you have all the output stored that you want to control, you have some options. I haven't fully explored some of these, but taking a look at the functions in that category on php.net will give you an additional idea of what you can do to control the output stored in the buffer. As for me, I just wanted to call include "invoice.php"; and store the results of it into a string variable.
So after calling the include function, I used ob_get_flush, which returns the contents of the output buffer as a string, deletes the contents of the buffer, and closes output buffering. After that I simply needed to strip the whitespace from the resultant string (to avoid a ton of line breaks in the email) using
ob_start();
include "invoice.php";
$data = ob_get_flush();
$cleandata = preg_replace('/\s\s+/', ' ', $data);
Then just use $cleandata as the body of the email!
Until next time,
Auf wiedersehen!
----------------
Now playing: Evergreen Terrace - Wolfbiker
via FoxyTunes
Subscribe to:
Posts (Atom)
