I ran into an issue recently with Dojo's ContentPanes. I was using them with a TabContainer, and had made them closable; however, user actions might re-open tabs that pull from the same source. This led to conflicts with dijit IDs that I had to resolve.
Most Dijits have a
destroyRecursive() method which should, theoretically, destroy any dijits contained within them. However, for many Dijits, this functionality simply does not work due to how they are implemented; many do not actually have any knowledge of the dijits beneath them.
ContentPanes fall into this latter category. fortunately, it's relatively easy to accomplish, due to Dojo's heavily object oriented nature.
I've been doing a fair bit of programming in Dojo lately, and have on occasion run into either inconsistent interfaces, or interfaces that simply fail to load in Internet Explorer. Several people have pointed out to me some optimizations to make, but, being a lazy programmer, I often forget to do so.
Yesterday, we released Zend Framework 1.7.5. It contains a somewhat
controversial security fix to
Zend_View that could potentially affect some use
cases of the component; I'm providing details on that security fix as well as
how to work around it here.
I use Linux on the desktop (currently Ubuntu), but occasionally need to use Windows for things like webinars, OS-specific testing, etc. I started using VirtualBox for virtualization around six months ago, and have been reasonably satisfied; Windows boots quickly, and everything "just works." That is, until yesterday.
I was given a linux VM image running a web server and some applications I needed to review. On top of that, I needed to do so over WebEx, so that I could share my screen with somebody else. This meant I needed the following to work:
I'm really not sure I understand these "seven things" or "tagged" memes, but I'm going to give it a shot, after Keith Casey did a drive-by tagging of me on New Year's Eve.
So, without further ado, seven things you may not know about me…
That time of year again — wrap-up time. Each year, it seems like it's the busiest ever, and I often wonder if it will ever slow down. As usual, I'm restricting myself to primarily professional activities out of respect for the privacy of my family.
The short, executive summary:
Read on for the gruesome, month-by-month breakdown.
The Model is a complex subject. However, it is often boiled down to either a single model class or a full object relational mapping (ORM). I personally have never been much of a fan of ORMs as they tie models to the underlying database structure; I don't always use a database, nor do I want to rely on an ORM solution too heavily on the off-chance that I later need to refactor to use services or another type of persistence store. On the other hand, the model as a single class is typically too simplistic.
In my last post, I discussed using Zend_Form as a combination input filter/value object within your models. In this post, I'll discuss using Access Control Lists (ACLs) as part of your modelling strategy.
ACLs are used to indicate who has access to do what on a given resource. In the paradigm I will put forward, your resource is your model, and the what are the various methods of the model. If you finesse a bit, you'll have "user" objects that act as your who.
Just like with forms, you want to put your ACLs as close to your domain logic as possible; in fact, ACLs are part of your domain.
A number of blog posts have sprung up lately in the Zend Framework community discussing the Model in the Model-View-Controller pattern. Zend Framework has never had a concrete Model class or interface; our stand has been that models are specific to the application, and only the developer can really know what would best suit it.
Many other frameworks tie the Model to data access — typically via the ActiveRecord pattern or a Table Data Gateway — which completely ignores the fact that this is tying the Model to the method by which it is persisted. What happens later if you start using memcached? or migrate to an SOA architecture? What if, from the very beginning, your data is coming from a web service? What if you do use a database, but your business logic relies on associations between tables?
While the aforementioned posts do an admirable job of discussing the various issues, they don't necessarily give any concrete approaches a developer can use when creating their models. As such, this will be the first in a series of posts aiming to provide some concrete patterns and techniques you can use when creating your models. The examples will primarily be drawing from Zend Framework components, but should apply equally well to a variety of other frameworks.
I've been playing a lot with Dojo lately, and have been very impressed by its elegant publish-subscribe system. Basically, any object can publish an event, and any other object can subscribe to it. This creates an incredibly flexible notification architecture that's completely opt-in.
The system has elements of Aspect Oriented Programming (AOP), as well as the Observer pattern. Its power, however, is in the fact that an individual object does not need to implement any specific interface in order to act as either a Subject or an Observer; the system is globally available.
Being a developer who recognizes good ideas when he sees them, of course I decided to port the idea to PHP. You can see the results on github.