Great blog, great methods

Great blog functionality!

But I think user blogs just consume your time. I wouldn't do it if I were you.

I think it is better to use the energy to try lower the threshold for those wanting to use PHP classes.

I'll explain. I am no programmer. It is 20 years since I wrote code and I have forgot it all by now. But I would like to be able to integrate some PHP-classes in an existing open source PHP content management system (such as the excellent PHP-Fusion.co.uk). I would like to integrate for example the blog functions trackback, pingback and RSS feed. But then the PHP classes with all their interfaces and prerequisites need to be described very clearly, and with some integration guidance.

I am sure there are many like me around, that are not able to write code themsleves, but would be able to develop a system by configuring and integrating others' code modules if just the threshold was made low enough.

Think about that please. How can the PHP-classes, the code modules (functional objects) be better defined and described for easy integration with other PHP applications?

That is, more methodology work, less administration.

I am not sure if I understand your view.

There are some components in the PHP Classes site that can be published, like for instance the trackback protocol handling. Over time, I have published many of my components as classes in the site itself.

Other components, that I previously referred as application level components have a more complex structure, like the forums system and the blog system. A great part of the code is generated by Metastorage.

As I mentioned, I plan to release these application level components, very likely in a new site for spreading Metastorage generated components.

These components include use case classes written manually in PHP to implement business rules. I think I need to clean them a bit to make them independent of the PHP Classes site specific details. I think I will create base classes that are customized with sub-classes with site specific business rules.

Just let me know if this is not exactly what you had in mind.

Well, since I can't read and understand the code the documentation needs to be excellent - otherwise the classes/modules/objects/functions/etc are of no value to me. What it does, prerequisites, assumptions, all conditions for operation, input variables, includes, outputs, etc - everything must be well described. Otherwise the step is too great for me. With standard methods and clear and (even for a novice) understandable API:s, a greater number of people (like me) could have use of the classes. Class developers shouldn't assume that users can read code, but instead comply with methods and document very well. But how? Maybe it is not possible. If so, just forget it. (If code is manually written or not doesn't matter).

The blog functions was just an example (real one - I do need that functionality - but probably several guys are writing it for me at the moment so I'd better just wait and see).

Sure, that is why I sent the newsletter of January telling about consistent methodology that I use to develop application level components.

It explained how I have been implementing application use case classes with same API with 3 functions (initialize, process and output) and a few of publish variables to configure details of behavior of the classes and return status or error information.

The use of the same methodology make application development a mechanic task. Developers do not need to understand all the inner details of implementation. All they need to know is that simple 3 functions API and how to call it.

This is just one methodology. It is not only one nor necessarily the best, but if developers adopt the same methodology, it improves the chances of the developed components being adopted.