from CodeUtopia - The blog of Jani Hartikainen http://codeutopia.net/blog Author: Jani Hartikainen Date: May 26, 2012 at 08:55AM

This document defines formatting and style rules for HTML and CSS. It aims at improving collaboration, code quality, and enabling supporting infrastructure. It applies to raw, working files that use HTML and CSS, including GSS files. Tools are free to obfuscate, minify, and compile as long as the general code quality is maintained.

Collect, test, and experiment with interface pattern pairings of CSS & HTML. Pears is an open source WordPress theme, enabling people like you to get your own pattern library up and running quickly.

Grab the theme at Github.
Install the theme.
Create markup & style patterns.
Learn.

Basic
Domain Logic
Data Source
Object-Relational Behavior
Object-Relational Structure
Object-Relational Metadata
Web Presentation
Distribution patterns
Concurrency
Session State
Practical PHP Patterns: Visitor

Dependency injection (DI) in object-oriented computer programming is a technique that indicates to a part of a program which other parts it can use, i.e. to supply an external dependency – a reference – to a software component. In technical terms, it is a design pattern that separates behavior from dependency resolution, thus decoupling highly dependent components.
Developers of software strive to reduce dependencies between components for various reasons. This leads to a new problem, though: How can a component know all the other components it needs to fulfill its purpose?
The traditional approach was to hard-code the dependency. As soon as the database driver was necessary, the component would execute a piece of code that would load a specific driver, configure it, and call the necessary methods to interact with the database. If a second database must be supported, this piece of code would have to be modified or, even worse, copied and modified (violating the DRY principle).
The dependency injection offers a solution. Instead of hard-coding the dependencies, a component just lists the necessary services and a DI framework supplies these. At runtime, an independent component will load and configure the database driver and offer a standard interface to interact with the database. Again, the details have been moved from the original component to a set of new, small, database-specific components, reducing the complexity of them all. In DI terms, these new components are called "service components", as they render a service (database access) for one or more other components.
Dependency injection is a specific form of inversion of control, where the concern being inverted is the process of obtaining the needed dependency. The term was first coined by Martin Fowler to describe the mechanism more clearly.[1]

A better coding convention for lists and object literals in JavaScript

Style in jQuery Plugins and Why it Matters
1. A few "pro tips"
DRY = Don't repeat yourself
Use the jQuery API
Avoid premature optimization
Avoid over-avoiding premature optimization
2. Playing nice with others
Don't modify objects you don't own
Declare your variables
Use a closure
Use namespaces when binding event handlers
Use unique data names
3. Elements of style
Line length
Tabs vs. spaces
Crowding arguments or code blocks
Comments
Curly braces
4. In conclusion

Comments (0)

Find Ben on:

Videos
Articles
Network
Content
Resources

// make an ajax request right away
$.ajax({
url: 'ajax.php',
success: function(data) {
$(document).ready(function(){ //<-- Hey Guys check this out!
for(var i in data) {
$('.app-container').append('<div>'+data[i]+'</div>');
};
});
}
});

Having seen the Strategy pattern, it’s time to look at two related patterns, which use the same notion of a unified API to control a collection of (possibly) unrelated objects.

Both of these patterns give us the opportunity to turn our applications into something much “bigger” than we origionally planned, with minimal effort required to re-write code.

1)

The Adapter Pattern

The adapter pattern is conceptually a bit like an international power adapter that you take on holiday, so you can plug in your electric shaver or hairdryer to the local power supply.

You use an adapter pattern when you’ve already built a class to perform some task but now need to an alternative class (with perhaps a very different API) to perform the same function.

It’s similar to the Strategy pattern but where the Strategy pattern deals with hiding a set of algorithms behind a common interface, the Adapter pattern deals with hiding a collection of objects behind an interface.

Note: there are two variants of the Adapter pattern: the Object Adapter (which is what we’re talking about here) and the Class Adapter (which requires multiple inheritance, not supported by PHP).

It’s best demonstrated with an example. We’ve looked at the MVC Pattern.

Working, in general, from that example, which used MySQL as the target database, imagine now that we have customers for our “Products” application. Customer A says “I love it but I use Oracle”. Customer B says “I want to deploy you application in my N-Tier environment using SOAP to provide your application with data”.

So here we have two problems. For Oracle, simple database abstraction isn’t enough, because MySQL uses an SQL syntax which often varies significantly from Oracle. For example, imagine we want limit the number of rows we return from a SEL

The Observer Pattern
The observer pattern, also known as subject-observer and listener, is a more complicated but very prevalent and useful pattern. Anyone who has done event handling in Java knows this pattern, every kind of event listener is an observer to one subject or another - the keyboard, a window, a mouse, etc.

The pattern describes how to attach any number of observers to a subject, which can then act on events that occur involving the subject. For example, this pattern is available in the PEAR Log:: package, allowing you to monitor log data with an observer object and take action - such as sending an email page on any critical errors - on certain kinds of log messages.

Here's a simple usage of this implementation of the observer pattern:

The Observer Pattern is designed to help cope with one to many relationships between objects, allowing changes in an object to update many associated objects. It provides a powerful mechanism to extend our applications, in terms of how they respond to events, without needing alter existing (and working) code.

We’ll take a simplified look at how the observer pattern might be used in a typical PHP forum application then suggest other uses for the observer pattern

Under Observation

1) The Observer pattern is defined by the Gang of Four in Design Patterns as behavioural pattern - that is one we can use to modify the behaviour of our applications. It’s regarded as being so useful, that Sun bothered to implement it in the Java API (see Observable and Observer).

The basic principle behind the observer pattern is if you have some object, such as a Post object for a forum system, you can have other objects, such as a Mailer object, act as an observer and respond to any changes in the Post object, such as emailing relevant forums users that a new post has been added to the thread they were subscribed to.

Conceptually, the Observer pattern in something like a trigger in a database, which runs a stored procedure when a table row is modified for example (we won’t go too far with this analogy though).

Normally we might implement the mailing functionality in the Post object itself but what if later we want add further “events” to Post, when a new post is made, such as adding an entry to our forums RSS feed for example? And how many more things might we want to add in future?

The observer pattern provides us the mechanism to add such functionality without needing to alter the Post object.

The is easiest to see will some some example code.

First we define two interface classes; an Observable class which will be inherited by the Post class and allows it to become the subject of observation and an Observer class which will be inherited by the classes used to observer Post.

Most designers wireframe their designs in one way or another, even if it just involves them making quick sketches on the back of some scratch paper. Wireframing is an important part of the design process, especially for more complex projects.

Wireframes can come in handy when you’re communicating with clients, as it allows them to visualize your ideas more easily than when you just describe them verbally.

This guide covers what you need to know about website wireframes to get started.

For a while now, I’ve had a dream. My work in the last 8 or 9 years has been heavily focused around education, whether I’ve been commissioning and editing technical books to help people create cool stuff with technology, training new employees at the various companies I’ve worked for, or editing and writing tutorial articles to help people use Opera’s software. I am passionate about the Web too, and a big believer in open web standards. I wanted to do my bit to help make the Web a better place, and I think this comes back to education, whether that’s teaching people how to collaborate and have more respect for one another, or teaching them how to make their web sites work across platforms and devices, and be accessible to people with disabilities. Web standards are key to the latter, so I decided to try putting my time and energy into something that would help increase the adoption of web standards on the Web today and in the future. It has been floating around my head for a while now, but it has finally come to fruition at Opera—many thanks to my wonderful employers for paying me to do this! One of my dreams has finally been realised.

We have dozens of best practices to improve performances. We also have common practices to accomplish daily tasks. This post is about the most used JavaScript ArrayLike Object, aka arguments, and its performances impact over basic tasks.

Inside every JavaScript function an arguments object is available containing all the parameters passed to the function.

function aha(a, b) {
console.log(arguments[0] === a); // true
console.log(arguments[1] === b); // true
}

aha(1, 2);
However, it's not a good idea to use arguments for the reasons of :

performance
security
The arguments object is not automatically created every time the function is called, the JavaScript engine will only create it on-demand, if it's used. And that creation is not free in terms of performance. The difference between using arguments vs. not using it could be anywhere between 1.5 times to 4 times slower, depending on the browser (more info and bench)

As for the security, there is the POLA (Principle of Least Authority) which is violated when one function A passes arguments to another B. Then a number of bad things can happen including:

B calls A through arguments.callee - something A never intended when calling B in the first place
B overwrites some arguments and causes A to misbehave
While in these scenarios B looks a little malicious, it can actually cause trouble unvoluntarilly. Consider this example that illustrates the second case (B changing values behind A's unsuspecting back)

24 JavaScript Best Practices for Beginners
Tutorial Details
1. Use === Instead of ==
2. Eval = Bad
3. Don’t Use Short-Hand
Always Consider the Future
4. Utilize JS Lint
5. Place Scripts at the Bottom of Your Page
Better
6. Declare Variables Outside of the For Statement
Bad
Better
7. The Fastest Way to Build a String
8. Reduce Globals
Better
9. Comment Your Code
10. Embrace Progressive Enhancement
11. Don't Pass a String to "SetInterval" or "SetTimeOut"
12. Don't Use the "With" Statement
13. Use {} Instead of New Object()
Better
14. Use [] Instead of New Array()
Okay
Better
15. Long List of Variables? Omit the "Var" Keyword and Use Commas Instead
Better
17. Always, Always Use Semicolons
Better
18. "For in" Statements
19. Use Firebug's "Timer" Feature to Optimize Your Code
20. Read, Read, Read...
21. Self-Executing Functions
22. Raw JavaScript Can Always Be Quicker Than Using a Library
23. Crockford's JSON.Parse
24. Remove "Language"

This is an informal document to describe usage guidelines for exceptions in PHP5.

This document is targeted for package developers, although it will be relevant for anyone integrating PHP5 PEAR packages into their applications.

I would avoid the Singleton approach suggested by Flavius. There are numerous reasons to avoid this approach. It violates good OOP principles. The google testing blog has some good articles on the Singleton and how to avoid it:

http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-join-new-project.html http://googletesting.blogspot.com/2008/05/tott-using-dependancy-injection-to.html http://googletesting.blogspot.com/2008/08/where-have-all-singletons-gone.html

Alternatives

1) a service provider

http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html

2) dependency injection

http://en.wikipedia.org/wiki/Dependency_injection
and a php explanation:
http://components.symfony-project.org/dependency-injection/trunk/book/01-Dependency-Injection

This is a good article about these alternatives:

http://martinfowler.com/articles/injection.html

Implementing dependency injection (DI):

-I believe you should ask what is needed in the constructor for the object to function: new YourObject($dependencyA, $dependencyB);
-You can provide the needed objects (dependencies) manually ($application = new Application(new MessageHandler()). But you can also use a DI framework (the wikipedia page provides links to PHP DI frameworks). Important is that you only pass in what you actually use (call an action on), NOT what you simply pass to other objects because they need it. Here's a recent post from 'uncle Bob' (Robert Martin) discussing manual DI vs using framework.

Some more thoughts on Flavius's solution. I don't want this post to be an anti-post but I think it's important to see why dependency injection is, at least for me, better than globals. Even though it is not a 'true' Singleton implementation, I still think Flavius got it wrong. Global state is bad. Note that such solutions also use difficult to test static methods. I know a lot of people do it, approve it and use it. But reading Misko Heverys blog articles (a google testability expert), rereading it and slowly digesting what he says did alter the way I see design a lot. If you want to be able to test you application you'll need to adopt a different approach to designing your application. When you do test-first programming, you'll have difficulty with things like this: 'next I want to implement logging in this piece of code, let's write a test first that logs a basic message' and then come up with a test that forces you to write and use a global logger that can't be replaced. I am still struggling with all the information I got from that blog and it's not always easy to implement and I have many questions. But there's no way I can go back to what I did before (yes, global state and Singletons (big S)) after I grasped what Misko Hevery was saying :-)

The jQuery UI Widget Factory is a separate component of the jQuery UI Library that provides an easy, object oriented way to create stateful jQuery plugins. Plugins created using the Widget Factory can be simple or very robust as evidenced by the official jQuery UI widgets, each of which are built on top of the Widget Factory. This article will first look briefly at why you might want to use the Widget Factory, then present an in depth walkthrough of creating a stateful plugin using the Factory.

When I’ve talked about managing large applications in the past, I was criticized for going through many different options and then telling you that you can decide which one you liked the best. I suppose I might be afraid I’d make the wrong choice too, so in this article, I’m going to explain what I would use in my totally sweet large applications, but just know, there are lots of smart people who have different opinions.

This book, originally published by Prentice Hall in 1996, was taken out of print in 2001 and the rights to the book were subsequently returned to me by Pearson (the successor company to Prentice Hall). I have decided to make it available online in HTML format, and at the same time I have corrected several errata which were present in the printed editions of the book. It’s perfectly possible that I might have missed some, or even introduced some brand-new ones, as part of the process of transforming the text into HTML. If you spot any mistakes, please let me know so I can correct the master copy, which can be found at http://www.it.bton.ac.uk/staff/je/adacraft/.

Downloadable copies are available as http://www.it.bton.ac.uk/staff/je/adacraft/bookhtml.zip (in zip format for Windows systems) or as http://www.it.bton.ac.uk/staff/je/adacraft/bookhtml.tar.gz (a gzipped tarball for Unix systems). Each distribution also includes the complete set of examples from the book, both for Windows (adacraft.zip) and for Unix (adacraft.tar.gz).

I've been writing a book about the Zend Framework recently - I'm sure some of you have noticed :-). A while back I finished a draft of two chapters called "The Architecture of Zend Framework Applications" and "Understanding The Zend Framework". The first chapter is an exploration of the Model-View-Controller (MVC) architectural pattern and why it has become the defacto standard for adoption in web applications. The second explores how the MVC architecture relates to the Zend Framework's components, their design and interactions.

By the time I'd finished both chapters I realised I had spent a lot of space explaining the Model, most of it discussing how the Zend Framework does not actually give you one. In fact, no web application framework offers a complete Model (for reasons I'll explain later). However nearly all frameworks manage to avoid making that perfectly obvious. Instead they continually link the concept of a Model to the related, but not identical, concept of data access. This is quite misleading.

This side of frameworks never gets a lot of attention. Yet it is a massive contributor to a whole class of problems in applications which attempt to utilise MVC by adopting web application frameworks. Further, I've always found myself better entertained by banging my head against brick walls than by trying to get the idea of a Model across to other developers. I'm not saying all developers are stupid or dumb, or that they don't get the concept in general, but all developers (PHP or not) don't quite link Models to the area of practice which justifies them - Object Oriented Programming principles.

In this entry I explore Models in terms of how developers relate them to Controllers and Views in applications and note a few strategies you can employ when using proper Models.

1. BackOffice for the BackOffice
2. Protected Items
3. Modules On/Off
4. System Logs
5. Duplicate Items
6. System Restore

What are interfaces?

The best description I could find so far is: An interface is a contract.

* An interface defines public methods that a class needs to implement
* An interface does not contain any code
* A class can implement multiple interfaces
* Interfaces can be used for type hinting

Basically if you see a class implementing an interface you know how to use it no matter how the implementation within the class is achieved.
What are abstract classes?

* An abstract class can implement methods (code)
* An abstract class can define abstract methods (no code)
* An abstract class can not be instantiated
* Classes can only inherit from one abstract class

And the difference is now what?

Abstract classes and interfaces are in some ways similar but they do each have their unique use cases.

The simplest rule is:

* If you write an abstract class containing only abstract methods you use an abstract class as an interface.

The Active Record pattern effectively prescribes to wrap a row of a database table in a domain object with a 1:1 relationship, managing its state and adding business logic in the wrapping class code.

An Active Record implementation is in fact a classical C structure aka Record aka associative array of data, with the addition of utility methods that encapsulate behavior that acts on these data. The most useful method is usually the save() one, which updates the database reflecting in the row the current state of the record. Thus, the Active Record transparently works with SQL queries and provides an higher-level Api.

Although Active Record is similar in implementation to the Row Data Gateway pattern, it is distinguished from it in the fact that it defines methods with domain-specific logic. The consequence of the presence of domain-specific logic is that generic implementations of Active Record provided by libraries must be customized to met the need of the object model. Typically this customization is done with a thin subclassing, which at least renames the library class with a domain name (like User or Post) and may specify metadata on the database table where the Active Records state is kept, if they are not inferred.

The Row Data Gateway pattern's intent is encapsulating a single row of a database table, and abstract away the mechanism used to access it and modify its data. Performance enhancements (such as delayed queries) and abstraction of the underlying SQL language are responsibilities of this pattern's implementation.

31 jQuery Snippets That Will Help Make You A JavaScript Pro

3362 ♻ Retweet
11,858
Delicous: 601
Buzz it

Posted on April 7, 2010 in: Web Development|Jump To Comments

Hey guys. Hopefully if you’re reading this you’ve discovered some of the true power jQuery has to offer and you’re now looking for ways to improve your JavaScript skills even further.

There was such a huge response to my last post on jQuery Snippets that I thought it only right to follow up with a fresh list that focuses on some of the more recent features introduced in jQuery 1.4.x. Because it’s always useful to have a second pair of eyes look over your code, I asked Paul Irish from the jQuery Team to take a look at all of today’s snippets and he’s included some useful optimizations to a few of the snippets which I’ve intregated.

Now, if I only we could fit Paul into a useful Browser plugin, all my articles would be just as sensible ;) The snippets from today can be applied to a wide range of projects so remember to bookmark the post if you find it useful so you can easily come back to it anytime you want. So without further adieu, I give you today’s 31 Snippets that will help make you a JavaScript Pro.

jQuery makes using JavaScript easy even for most designers because of it’s huge community and supply of really useful plugins. Using plugins is great for sure but knowing a bit more of what is going on behind the curtain can make you more powerful than you would expect. Digging into the coding details may not be that simple but with the good examples, tips and tricks in this article you should have a good chance.

The collapsible content area widget is fairly simple — a couple of HTML elements controlled with minimal CSS and JavaScript — but when we were researching our book, Designing with Progressive Enhancement, we discovered that many common approaches to creating collapsible content fail to incorporate accessibility features. Happily, there is a way to build collapsible content with progressive enhancement so it delivers an optimal accessible experience for sighted and screen reader users alike.

The code example described in this article is one of the 12 fully-accessible, project-ready, progressive enhancement-driven widgets that accompanies our new book, Designing with Progressive Enhancement.

I’m wrapping up my first jQuery UI widget (see multiselect on GitHub) and thought it would be useful to share some notes I took on the widget factory & widget development in general. I personally found development on the factory to be quite enjoyable; a lot of functionality is available right out the box (custom events, ability to change options after initialization) and idioms you might not otherwise consider, like widget destruction. Furthermore, it imposes a clean object-literal development structure with public and private methods, making it much easier to start a project or maintain other’s projects.

Ryan will explain the key concepts you should understand to design and implement UI for your apps. He’ll cover screen-level details like language and visual techniques as well as deeper topics like modeling and best practices for coding templates and helpers.

It’s not uncommon for “star” programmers to be an order of magnitude more productive than their colleagues. I believe that a large part of that productivity gap comes not from doing tasks faster, but from not doing them at all. Good programmers make the machine sweat instead.

On websites that have a lot of pages, breadcrumb navigation can greatly enhance the way users find their way around. In terms of usability, breadcrumbs reduce the number of actions a website visitor needs to take in order to get to a higher-level page, and they improve the findability of website sections and pages. They are also an effective visual aid that indicates the location of the user within the website’s hierarchy, making it a great source of contextual information for landing pages.

Let’s face fact folks: not too many developers plan their JavaScripts. Instead we quickly write something that works, and submit it. We come up with variable and function names as we go along and in the end know that we’ll never have to see this little bit of script ever again.

The problems start when we do see our script again, or we get scripts from other developers, that were built the same way. That’s why it is good to keep a few extra steps in mind when it comes to saying “this is done, I can go on”.

So here’s an eight step plan to show you what can be done to make your scripts easier for the maintainer. Yes, some of the steps may be very obvious to the jet-set, well travelled and seasoned JavaScript developer, but it can’t hurt to remind ourselves of their virtues.
Furthermore, I dare any one of you to look at some older code and test it against them – I am not ashamed to admit that at times I looked at code and uttered expletives about the person responsible, only to find out later on that it was in fact me a few months back. Scope and feature changes together with looming deadlines and budget cuts breed bad code; it is a fact of software development.

Working with progressive enhancement in mind for a long time, I found that the following rules all made a lot of sense and have quite an impact to the final product in terms of maintainability, size of code and general sturdiness:

1. Separate as much as possible
2. Build on things that work
3. Generate dependent markup
4. Test for everything before you apply it
5. Explore the environment
6. Load on demand
7. Modularize code