Framework, CMS - What Do I Really Want from a Web Application Rapid Development Kit

Submitted by kai on Wed, 2006-03-15 22:10. ::

Inspired by the blog What I Want From A Framework, I want to discuss what I want from a web application rapid development kit(WARDK) as a lazy developer. I am going to use PHP language as an example in my discussion, but the discussion can apply to other languages such as Java, Ruby, and Python.

Here’s what I want: the most important and common features (every web application that supports multiple users need to have these):

  • user management(CRUD operations on users, ban users, user group management), pluggable authentication(LDAP, OpenID, integration with other systems) OpenID)
  • user/application access control matrix(who/which group can do what to which modules)
  • user session management
  • plug-in system - can plug in new modules to provide new functionalities and work with existing modules
  • provide a hook for each module to provide searchable data and return the result set based on search query

Other important and nice features(many of these features can be supplied by a underlying framework):

  • support the use of a template engine that's not intrusive and strictly separates model and view(a user can use HTML editor to edit pages)
  • highly-customizable layout ( people may want to change the layout dramatically )
  • internationalization support ( a module for string translation )
  • Ajax support - eg: seemly calling the same client-side validation on the server-side validation as well (don’t just assume that you get away with client-side validation only)
  • highly testable and maintainable(component-based design, each component can be tested alone with its connecting components being mocked). PHP really gets the reputation as spaghetti codes where all things (logic, view) are mixed all together in a page.
  • encourage obsessive automated testing ( In another word, test-driven development)
  • encourage Participatory Testing –encourage others to participate in testing
  • security ( eg: provide data sanitization to guard against SQL injection, secure user session data)
  • dependency injection - don't tightly couple objects to framework-specific types.
  • plug in DB layer abstraction and data persistence tool(like Propel)

There are many great PHP frameworks out there that provide a great feature set to empower developers(edited: here's an article comparing different PHP frameworks):

But they are too high level. We still need to do heavy application "plumbing” on COMMON features. Ideally, each framework should provide a reference implementation of WARDK that can easily integrate with other tools (eg: Simple Test for PHP) to showcase its power.

Am I asking too much? Am I too lazy? Maybe what I need is just a CMS.

Indeed, my proposed feature list contains many features that already exist in Drupal.

David Jensen
Submitted by David Jensen (not verified) on Wed, 2006-03-22 14:16.

searchable data
I think it should be a little more robust than just searchable data. It would be nice for each module to be able to define advanced search fields in addition to the plain text. This way you can do a simple search or go to a auto-generated advanced search form.

template engine
Should have a built in one or easily swap it out for other template engines

db layer
I don't even want to consider the database on the same server instance as the php site. I'd like this all abstracted to another application server. That app server can run whatever. More php, python, java. So for that it would probably need ...

services interface
This would be your interface to your data. The implementation would be hidden from the consumer. Behind the scenes of the interface would either be local db code or a transport layer to make remote calls to an app server.

soap or other remote procedure calling
If SOAP RPC were available, it would make the above services interface simple to use. With SOAP you could use almost any other app server on the other end. (BTW, i'm not going to call this web services because I just want to use it for RPC).

Elixon
Submitted by Elixon (not verified) on Thu, 2006-03-23 08:32.

Kai, I like what you wrote. You hit the nail. I share the same point of view with you. I was very desperate at the time about the directions of many CMS developments so I decided to write my own.

I agree with every point of your list. And I'm actually driving to that direction with my project. But believe me, it took three years of hard development and I'm not still able to say that my project has everything you wrote. I'm adding slowly the features and many times I'm rewriting them from the scratch if they turn to be badly designed or I found radically better way (I know that I have the luxury to do so before there is too many modules dependent on the API, so I don't hesitate to do radical changes if needed...).

I can claim for now that I met only following:

  • plug-in system - can plug in new modules to provide new functionalities and work with existing modules
  • provide a hook for each module to provide searchable data and return the result set based on search query
  • support the use of a template engine that's not intrusive and strictly separates model and view(a user can use HTML editor to edit pages)
  • highly-customizable layout ( people may want to change the layout dramatically
  • internationalization support ( a module for string translation )
  • Ajax support - eg: seemly calling the same client-side validation on the server-side validation as well (don\u2019t just assume that you get away with client-side validation only) (For now only in administration, but the HTML front end is powered by the same idea as administration, so no problem)
  • highly testable and maintainable(component-based design, each component can be tested alone with its connecting components being mocked). PHP really gets the reputation as spaghetti codes where all things (logic, view) are mixed all together in a page.
  • dependency injection - don't tightly couple objects to framework-specific types.
  • plug in DB layer abstraction and data persistence tool(like Propel)

I add to your list:

  • Easy configuration and installation (ready)
  • Automated updating (planning)
  • Intelligent configuration-less caching system (self-tuning) (ready)
  • Ability to integrate existing functionality of existing pages (ready) or way to migrate existing content
  • Centralized Atom/RSS support in the platform or in the core module... (ready)
kai
Submitted by kai on Wed, 2006-03-29 13:48.

Elixon, Thank you for adding wanted features to the list.

Providing built-in support for cache management (cache selective data set with different cache policies) is very important for high traffic web applications that can afford staleness in some data.

Also, integrating with a logging solution(something like log4php) is essential(who doesn't need log files)

The main problem I have with many CMSs is their inabilities of separating content from view presentation by not using a “real template engine (PHP is NOT really a template engine). I know they all support themable look and feel. But that is different from separation of content and view.

I want something that provides a great set of fundamental features to make developing web applications fun and easy here I can focus on implementing the business logic.

Moshe Ginzburg
Submitted by Moshe Ginzburg (not verified) on Tue, 2008-05-13 15:16.

Thanks for an interesting article, however I meant that as long as Perl is not mentioned the entire point is missing.

Perl has been out there for ages which makes it less buggy, safer and with nearly infinite resources and support.

Otherwise, I for one would want:
1.) Cache
2.) Restore
3.) And a database which is universal compatible

You may find all these in the WebAPP multilingual Perl CMS from: http://www.web-app.net

Moshe. G

Post new comment



The content of this field is kept private and will not be shown publicly.


*

  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • WikiText is converted to HTML (supported WikiText formatting will show in the long tip format).
Verify comment authorship
Captcha Image: you will need to recognize the text in it.
*
Please type in the letters/numbers that are shown in the image above.