Forums / Cotonti / General / Future Genoa

The way I've come to see it now is that basically we should scratch PDO, we simply don't need it and many people don't like it. It took me a while to get used to it, and personally the only important benefit I see is it's easy query preparation. Oh and I love chaining it's functions like $db->query(...)->fetchAll(). Of course there are other benefits, but those don't apply for the majority of users.

I think it would be good for Cotonti to make a decision about procedural vs objectoriented and stick with it, and although I personally prefer OO code, I'm in favor of procedural code for Cotonti. This is for several reasons:

• Having a mostly procedural but very structured codebase makes the system easy to use and modify for beginners.
• We can use the slogan 'procedural where possible, object oriented where necessary' as a marketing feat. I think the simplicity of the code is an important benefit we have over Wordpress and the likes.
• Historically we've had a procedural codebase, it's too big a change to go all OO. We'd lose a lot of users that way.

I'm not saying it should all be procedural. XTemplate has always been OO and that doesn't bother anyone. I think it's ok to write core APIs in an OO way if procedural just doesn't make sense. In the end we should focus on speed, ease of use and readability. XTemplate and Caching are two examples of features that must be OO to make any sense. As for CotDB, I'm happy to go back to sed_sql_queries, although it should be extended with some conveniences we have in PDO (but procedural). Perhaps we can move PDO into a plugin so advanced users can still use it.

On a final note, I don't see us scratching Siena itself. Probably we'll try to make it more backwards compatible with Genoa and go on with Siena. This is simply because Siena has a lot of minor improvements and fixes as well, which are not quickly backported. It would be like throwing away 2 years of work.

 

I don't think we should scratch PDO, I'd prefer providing wrapper procedures in sed_sql_* style. This way we get rid of the dilemma of MySQL PHP extensions (there are currently 3 of them: mysql, mysqli and mysqlnd; a choice between them is not trivial and is host-dependent) and also save PDO benefits for those who really want to use PDO.

As for prefixes, it isn't really such a waste of time. It's the easiest thing in plugin conversion really, because it can be done in 2 clicks with an editor which has "find and replace in files" function or with CDT.

So, rather than backporting big things like i18n and caching from Siena to Genoa, I'd like to make Siena more friendly to Genoa developers. I didn't dedicate enough much time to it before, but now that we know that it is necessary, I can significantly improve compatibility. So far this would include the following goals:

• Add support for Genoa/Seditio plugins by default. Surely not all of them will work, but I think 80% is a reasonable part.
• Provide procedural database API.
• Relaunch TPL tags database.

If you think that it is a good idea, we can find other drawbacks in Siena and add more goals to this list and then add it to our roadmap on Github.

think he means that they will bring Sienna and Genoa closer together, and merge/create one branch of it??

this weekend i will install a fresh version of siena and try it in most aspects i can think of.

then i maybe have some suggestions. for now, all that is just a big questionmark for me...

What exactly is a question mark? It's an advanced version of the Geona branch.. With a little less plugins due to it being new.

As a start, here's an overview of changes between Genoa and Siena in terms of architecture:

• Core modules (forums etc.) moved from /system to /modules - more about directory structure
• Siena has 'modules' and 'plugins', which together are called 'extensions'. They have the same structure and functionality, but modules are usually stand-alone pages, while plugins are used to enhance existing functionality (core, modules or other plugins).
• Siena uses PDO, which means SQL queries are done using $db->query() instead of sed_sql_query(). - more about the database layer
• Siena supports caching (10x faster pageload), but this is optional. - more about caching
• Siena has install.php, which automates a lot of the installation and upgrade procedure (also for extensions).
• Siena uses index.php as entry point for (almost) all requests. This means modules do not need their own file in root. Existing files are kept for backwards compatibility (e.g. plug.php). Extensions are now called using index.php?e=myext
• Siena has several collections of helper functions which we call APIs. They are the files in /system and include forms, caching, file uploads and extrafields. I especially like the Forms API, which makes extension development a lot easier. - some API documentation here (needs to be improved)

If you want to have a look at the Siena directory structure and files without having to download and extract the package, have a look on Github.

@Kingsley: It's no problem if you're not a pro developer, I once started as a newbie too. As long as you're enthousiastic about it, have no problem spending your time on it and you want to learn this stuff, you'll be ok. Trustmaster and I are here to help you if you have questions.

Yes, that sounds reasonable. By the way we already have those insert/delete/update/runScript methods in our CotDB wrapper. Similar functions exist in Genoa too.