Modules, plugins & snippet optimisation ?

A comment block that follows a general rule, with a brief explanation of what the snippet does, and a list of optional or required arguments, with suggested values (0|1, true|false, etc) and defaults, if applicable. This way users will be familiar with how the usage instructions of the snippet will appear in any snippet.

Yes. When I talk about coding style, I don’t speak about comments but only about name of variables and functions.
Header comments is very important to make it standardized. As I indicate in a present post, one day, it could be used to be parsed and extract information about ressources. Also, it can make easy to learn used of this ressources.

I also think some coding rules should apply, such as using the MODx DBAPI, would be helpful to keep things working smoothly, even if changes are made to the MODx core or the DBAPI, the interface would remain the same.

I think it is very difficult to apply. So it can be an important reference.

It would also be very nice if everyone could use the same general arguments for the same purpose, having to figure out if the snippet uses &id= or &startDoc= or what??? to indicate the document to use as the base for the snippet’s operation is a real pain.

I think as you. But this is difficult because parameters depend of functionality of ressources. It a good idea not easily realizable.

Susan,

I agree with you on these points that you point out. It is very good idea to have a coding best practice specific to MODx when do development in MODx.

(scurries off to make a note about DropMenu and &startDoc ... very good point and don’t let me forget it!)

Another idea is for xhtml and css validation. I think also it is cleaner.
Javascript used by ressources should not be include directly in output code but called by a file reference. I’m not very clearly.
Another example :
I think that bellow will be avoided :

and that is better :


Honestly I do not know if it is possible to do it.

Hello!

I want to suggest using for the main MODx code as well fot plugins, snippets, etc. a very good database library for PHP. The best out there is AdoDB.
I am now helping on developing a link directory application, PHP Link Directory, that uses this library. My first contact with it was to write my old SQL queries, but after a while I can now save a lot of time and code using AdoDB. I must say, it’s not only fast, but also secure. For example you fill an array with the values you want to write to the DB, put one line of code and the library takes care for the rest, you don’t have to do hard charachter escaping or quoting and so on.

Just my 2 cents
Boby

Quote from: Boby at Mar 15, 2006, 08:45 PM

I want to suggest using for the main MODx code as well fot plugins, snippets, etc. a very good database library for PHP. The best out there is AdoDB.
I am now helping on developing a link directory application, PHP Link Directory, that uses this library. My first contact with it was to write my old SQL queries, but after a while I can now save a lot of time and code using AdoDB. I must say, it’s not only fast, but also secure. For example you fill an array with the values you want to write to the DB, put one line of code and the library takes care for the rest, you don’t have to do hard charachter escaping or quoting and so on.

Welcome to the community Boby.

I’ve done a lot of research and development over the past 4 months with various PHP db layers and object relational management tools. In fact, I already did a proof of concept, replacing the core of MODx with a Propel generated object model that uses Creole for persistence (which by the way, is much more secure than ADOdb, which I believe still get’s hit with security advisories quite often, or at least last I checked their was one forcing another upgrade). But without PHP 5.1+, opcode caching, and a super light-weight db layer to work with, it is almost impossible to achieve the kind of performance MODx does now with such a DB layer in place. PDO and SDO offer some great potential in this area for PHP 5.1+, but MODx is a PHP 4/5 application and will probably remain so until PHP 5 hosting is the industry standard.

Honestly after looking at all of the available options, including ADOdb, EZPDO, and many others, I truly think that MODx should take a factory pattern approach to persistence, simply implementing the code optimized for each target db separately, and having the MODx controller use the appropriate implementation based on the db configuration chosen. This will keep the core extremely lean and avoid the performance issues associated with every useful DB layer out there except PDO, though it will mean maintenance of the CRUD code for each db, though in most cases, I think such adjustments would be almost trivial in nature. It would also make it easy for developers to add their own optimized DB implementations for their needs, or override default persistence behavior easily.

BTW, we have a PHP 5-based project getting underway based on the prototype I built with Propel/Creole, though I will most likely be making use of PDO/SDO instead of Creole as we progress with that project. The ultimate goal of hiding all SQL from the developer, and making complete site definitions portable from one db platform to another, even when working with user-defined data structures/classes, it what I’m shooting for.

Quote from: OpenGeek at Mar 15, 2006, 09:11 PM

Honestly after looking at all of the available options, including ADOdb, EZPDO, and many others, I truly think that MODx should take a factory pattern approach to persistence, simply implementing the code optimized for each target db separately, and having the MODx controller use the appropriate implementation based on the db configuration chosen. This will keep the core extremely lean and avoid the performance issues associated with every useful DB layer out there except PDO, though it will mean maintenance of the CRUD code for each db, though in most cases, I think such adjustments would be almost trivial in nature. It would also make it easy for developers to add their own optimized DB implementations for their needs, or override default persistence behavior easily.

I’m totally agree to this. Honestly I prefer to implement database layer following this model, even though the disadvantage had been mentioned by Jason, but the benefit is a lot larger compare to the disadvantage.

Let say, how many people will actually use different database for one application? For sure each people will use only one, the abstraction only allow the end user to choose the target database before installing the system. If we talk about web application, which is a software that needs to be run by multiple users simultaneously, we need to talk about performance and efficiency. If we use the method described above, even though the maintenance time will take a lot of time, but the result will be worth it, considering each database have their own mechanism of dealing with data, query, indexing, and etc. If we optimize each database layer for specific database type, we basically have a good performance system to be used, but if we use the database abstraction out there, basically we can’t optimize the way how to handle the database connection and etc, which usually ended up the software has a mediocre performance.

I’m not saying that database abstraction is not the right solution, but the current technology is not ready for this this yet. If we take a good example of comparing MySql and some other major database player out there. Until version 4, mysql is still unable to support most of the sql language provided by most of database out there. So if we are talking about MySql 5, or maybe like Jason said, if we are targeting PHP5, I think it will be better, but for now, implementing database abstraction layer will just bogged down the system.

Correct me if I’m wrong. I’m open to public critiques or comments.

For the database abstraction, PHP functions exist already : dbx functions. It seems be interesting but I don’t know if PECL repository is used by hoster :

Note: This extension has been moved to the PECL repository and is no longer bundled with PHP as of PHP 5.1.0.

Quote from: Guillaume at Mar 17, 2006, 06:11 PM

For the database abstraction, PHP functions exist already : dbx functions. It seems be interesting but I don’t know if PECL repository is used by hoster :

Note: This extension has been moved to the PECL repository and is no longer bundled with PHP as of PHP 5.1.0.

Guillaume, dbx has been replaced in PHP 5.1+ with something called PDO (Persistent Data Objects). PDO promises to be the most efficient and lighweight persistence layer PHP has seen to date IMO, though there are a lot of varying opinions on this subject in the industry. In fact, I am evaluating PDO as the standard DB layer in Tattoo (a PHP 5 CMF I am working on, based on MODx), but, PDO is not implemented in PHP 4. And related to PDO is a PHP 6 effort called SDO (Service Data Objects), but we can talk about that later.

So what to do?

Well, how about implementing the PDO interfaces in PHP4? In fact, I found a PDO for PHP 4 implementation, already mostly completed (some of the more advanced features aren’t supported, like transactions and LOB handling, but we can fix that!) at phpclasses.org. Problem solved!

So what does this mean you ask? It means, coming soon, MODx may be using PDO as the default DB layer, and can utilize native PHP 5.1 PDO when available, falling back to our own custom implementation in environments where it is not (PHP 5.0.x and lower).

It also means there may be a proper object-oriented API available for MODx in the very near future, with all SQL hidden behind the object model. This will help protect further feature additions and optimizations to the core from requiring major changes to the way developers work with the MODx API’s. There will most likely be some changes required to existing components that are accessing data via direct SQL to get there, but we’ll make it as quick and painless as possible to get us to a robust RAD / prototyping framework. Stay tuned for more on this in a dedicated topic.

It means, coming soon, MODx may be using PDO as the default DB layer, and can utilize native PHP 5.1 PDO when available, falling back to our own custom implementation in environments where it is not (PHP 5.0.x and lower)

It a great new. I don’t know PDO but I will read PHP documentation. Thanks for the link.