PHP Display Components

Just about every GUI language/framework has standard classes for displaying common datatypes. There are datagrids, sortable datagrids, paginated lists, searchable lists, input forms, display forms, etc. You instantiate them, set up some information about them, and connect them to your data source. Then you call some sort of display() method on the object, and it displays everything on the screen.

The reason I mention this is because PHP has nothing like this (at least not that I know about). In PHP, the View part of MVC is merely an HTML-based layout file with some markup in it to display your data. But isn't is possibly to create a set of components that generate the HTML on their own?

Obviously, we could all just continue to code the HTML in our Smarty templates, recreating the same functionality over and over again in "low level" HTML. On the other hand, we could create components at a higher level of abstraction, and when we figure out a better/cooler way to do that searchable+paginated list (maybe adding some Javascript), we do it once -- in the component -- and it works everywhere we're using it. That's much better than having to change HTML code everywhere we're displaying a list of data (um, a lot).

So what are the goals of these display components?

• Define a set of reusable components that handle the display of data on a web page and generate the HTML
• Concentrate the HTML/JS of your application in component code, out of sight
• Ability to easily create new components, or edit existing ones as needs arise
• Skinnable -- either set CSS values in the code, or assign a CSS file to the object (also allow for a default CSS file to be set sitewide)
  
• Allow you to stay at a higher level of abstraction, so you can get more done with less code

These seem like reasonable goals. They're not trying to shoot the moon ... and they don't seem to demand that you develop a certain type of application if you use these components. However, the problem of defining what components are necessary then quickly arises.

• Lists of data
• Paginated
• Searchable
• Sortable
• Header
• Footer
• Sidebar
• Input form
• Display form
• Calendar
• Date selector
• Single date
• Date range
• Time selector
• Single time
• Time range
• Popup dialogs
• Modal
• Non-modal
• AJAX
• Periodical updating
• Response to user action
• Connect a URL-defined data source to a component
  

That's a start, anyhow. More components are probably necessary.

There should probably be a general Page class, or something, that you would attach the other components to. The point of that would be to set pagewide CSS and only being required to call the display() method once per page.

In the interest of separating this from the concept of "scaffolds," I think the way it should work is that each component has a standard/default HTML template that it draws from, and the file it uses is an object variable. If you want, you should be able to create a brand new HTML template and make your component use it instead -- it would be nice to have that kind of flexibility.

Right now ... I don't know if this is feasible. I don't even know if it's a good idea. I'm sure people have tried to do this before, and I've never heard of the results. At the moment, my plan is to think about it for a while longer, and if I continue to think it's a good idea, it may be worth spending a bunch of time on to see what I can come up with. Could be interesting. (Let me know your thoughts, if you have any.)