The Ewelike BlogWe’ve added some more functionality this week, and we think you’ll like it.
Biggest item for feedback is the new price display (it now fades in and out to show it’s updated) - tell us if you like it or if it’s just plain annoying.
More good news for today - again this is another thing that i presumed *everybody* knew about MySQL - but they don’t.
MySQL allows for slightly naughty but useful GROUP BY activities (for instance returning scalar values without using aggregations for columns that aren’t included in the Group By). Basically it returns a non-specified random value from that set so it needs to be used with a bit of intelligence.
Say we’ve got a Sale entity and a Product entity which has a SaleId. What we want is a query where we can show the product name, product RRP (recommended retail price) which are on the product table, and the number of sales from the Sale table (which relate to the product).
We could write this as a subquery but it would be inefficient when we need to select from some criteria that’s found in the Sale table. Instead we write it as a simple INNER JOIN with a GROUP BY.
SELECT p.productid, p.productname, p.rrp, COUNT(s.productid) AS NumberOfSales
FROM product p
INNER JOIN sale s ON s.productid = p.productid
GROUP BY p.productid
Now in most DBMSs this would fail as the product name and the RRP aren’t in aggregate functions and aren’t specified in the GROUP BY. So we’d end up wrapping each in MIN(p.productname), MIN(p.rrp) or adding them to the GROUP BY.
However, we know this isn’t necessary as the productname and rrp are associated with the productid, so the MIN aggregate function is just a waste of time. So for MySQL we can leave the original query and it’ll run nicely.
Another winning tool for MySQL users.
Disclaimer: this functionality is a tough one to fully comprehend in all circumstances - so use with care. Other DBMSs don’t allow this for a reason!
Ever wanted to get an aggregated comma delimitted list back directly from SQL? Sick of writing functions in every DBMS to handle just that requirement? Well MySQL gets rid of that issue.
Use the simple aggregation function GROUP_CONCAT (single argument of the column names) in a group and it’ll collect all the values it finds and comma delimit them.
Nice!
We’ve been experimenting over the past year with various Templating engines in PHP, and we decided on our winner: Smarty
Originally we’d planned to use the HTML_TEMPLATE_IT package from PEAR, but Smarty just gives us more power (and thus makes the templating cleaner). HTML_TEMPLATE_IT seems to be the templating system most illustrated in books and examples, so for many it’s a good choice.
Smarty will also allow us to cache pages and “compile” the templates into a quicker rendering form - both of which will be an advantage for us as this new application is released.
Templating allows the “presentation” to be seperated from the code and this is (almost always) a good thing. For a start there will be no more horrible echo statements all over the PHP code, secondly you can “include” templating files so that you have more consistent commonality between the pages. Best of all using this system means that you can quickly create an output HTML file from a template, this can then be used by your designers when they construct the CSS. This is especially important to me as design is not my strong point and we either hire in graphics people as required, or we use external agencies. When using external agencies they can have sample HTML (and the templates with a brief explanation) for them to skin, so they understand the structure and they have something concrete to work upon. If for some reason CSS can’t handle some of the HTML structure (this is amazingly still an issue as the CSS implementations for various browsers are still broken) then you can always amend the template if required. But, importantly design never holds up the development process, it works in parallel.
Using a templating system shouldn’t be overlooked for any site. Today, without changing a single line of code in PHP, we were able to add additional fields to a page, and change the structure of what was generated. Of course we don’t use the templating system for look and feel, instead that’s all done with the other front-end layer - CSS. This essentially creates a “two tier presentation tier”, something which Martin Fowler has written about in the past. It’s true power is that your back-end (that does the business logic) is seperated from how the front-end PHP works, which is again seperated from the templating system which then only has to use the data it is given. CSS can then take the templating system’s data and turn it into something visually appealling.
Lots of books advocate the “classic 3 tier” application structure (roughly; presentation layer, business logic layer, and data layer), don’t be pushed by this though as just 10 years ago a large number of publications would tell you how you need a 2-tier (also known as client-server) application structure - the 2 tier people turned out to have industrial-class blinkers on and didn’t notice all the issues it caused.
The truth is that the number of layers/tiers depends on the application you’re creating. A HelloWorld program needs 1 layer (and no more! 
), Fat client systems can work admirably as 2 tier applications (although you must bear in mind the issues with having fat clients, and bandwidth concerns), 3 tiers is normally the usual for anything web-based (CSS and the HTML generated are often seen as the same layer in this model as the two are so intricately tied and both contain presentation information). Our application uses 5 tiers - Database, Data Objects, Business Objects, Templates, CSS and all are well seperated by contracts between them - but that doesn’t make it a solution for all.
You can learn more about Smarty from the crash course on the smarty.php.net site. I’d encourage you to take a look even if you’re sure you’ll never need templating.
For many new PHP users my advice would be to build the templates first (in a similar manner to how design is performed using the Catalysis OO design method), that way you understand what pages require and how they act together. Best of all, it means that your templates can be simple and avoid (too many) UI tags - such as; p (for paragraphs of course), ul (lists) and tables, and thus just rely on the CSS to perform the rendering.For some this may be difficult as the resulting templated HTML is extremely ugly until the CSS is in place to style it appropriately. If you can live with the ugly but functional HTML while developing (which shouldn’t be a major problem - after all you are unit testing right? That way you’ll be sure you’re only debugging your templates, not the other php that gets it) then you’ll love Templates. Be a Smarty - download it today and have a go.
One of the things we’re doing with ewelike is connecting to webservices.
It’s trivial to open a stream or CURL to a REST querystring based API - just use sprintf and urlencode to put your parameters into the URL’s querystring and then call it. Even if you need to change the parameters you can easily iterate a hash array of name value pairs and put those into the querystring - it’s just easy.
So, why do some organisations insist on xml-rpc or SOAP webservices? Especially as they all take simple types anyway as arguments.
If you provide REST APIs then they’re trivial to write, and trivial to test in various permutations. They also have another advantage called “performance” because they’re about as close to the knuckle as you can get without opening a custom port and inventing some new protocol.
Let’s think about SOAP and what it’s doing on both sides;
On the client you’re instantiating/loading a library.
Then building some object representation of the data you want to send
That object representation is then serialised into xml (sometimes with an additional step which involves building the model using the DOM or similar)
The call is then made and the serialised xml is sent over the wire to the service.
The service’s web server then gets the call and the data. It redirects it to something that can handle the call.
Data is de-serialised and re-instanced into an object representation so it can be used.
The service does what it needs to and then serialises the data to send it back
The calling client takes the returned data, deserialised and then used
That’s a lot of work. REST cuts down on a few of these steps (and the API docs are far easier - plus there’s no need to stubs and proxies to handle the calls) and it just looks cleaner.
If you don’t believe me then download something like simpletest (we use it for more than testing just PHP) and build yourself a test rig for your web services. For REST you’ll be able to try legal and illegal calls and you’ll code it up in minutes. Try doing that for SOAP or xml-rpc.
Here the sermon ends….