1.1 Development Thoughts

[brady]

My statement that XML was faster the active record came from the link I posted. That page said XML was faster because you didn't have to load the whole table(or something like that), I didn't know much about it, so I trusted them.

[cyberman]

#5. Versioning means that we can then handle a workflow system pretty easily.  Though, I'm not sure if this will be in the core, or as a module.

Think it should be realized as module - so it would be a lot easier to deactivate this function if not needed and core is not needlessly bloated and more lightweight. (In CMSms Forge there's such a module which can be rewritten for this)

OK ... I like modular structures. So every one can decide if he/she wants a big or a slim CMS.

Perhaps also permission system should be moved to a module (hmm, an advanced FrontendUsers module ). If I make a look at "Show Off" CMSms is used from many page owners himself and they don't need a permission system.

Another look at "Show Off" tells me that most pages of a website are static, so a real nice feature would be a much more efficient caching system than Smarty ones like this:

- on the first view every content block (or page) is cached  as a slim .zip file
- on next view it compares the date of cache file creation and the date of last content block modification .
- if content block / page is newer cached file will be deleted and a new one generated
- if not there's a very fast access to content block

I'm not a coder for real but this should be a lot faster than full smarty parsing every time.

[Ted]

Ahh I see Ted was inspired from the "ruby corner"  and the "bad joke" has some truth inside

Yes, that's very true.  Rails has kind of opened my eyes to a lot of improvements that could be made to streamline a system.  It's definitely affected how I handle other programming tasks as I go forward.

If there are some drastic changes - what's the reason to write an own ORM system and not use existing (and well tested) solutions like propel or ezpdo?

ezpdo does a lot of what I want, but it requires you to define the fields up front.  I'm not quite sure why, to be honest.  It's almost there...

I've also added a few things that I would need an ORM to handle.

For instance, I implemented a bunch of callbacks (before_save, after_save) that the content changes are now relying on, so I can't really get rid of them.

I also added a bit in that if there is a column called 'type' in your schema, it will store the name of the class, and upon retrieval, it will use that class type instead of the calling type.  This allows us to do simple polymorphism without any work from the parent class.

Again, I think ezpdo does this stuff.  But it's just a bit off of what I'm looking for.

*shrug*

Maybe we can write a test suite for my version of the ORM to make sure it's up to snuff...

Another look at "Show Off" tells me that most pages of a website are static, so a real nice feature would be a much more efficient caching system than Smarty ones like this:

- on the first view every content block (or page) is cached  as a slim .zip file
- on next view it compares the date of cache file creation and the date of last content block modification .
- if content block / page is newer cached file will be deleted and a new one generated
- if not there's a very fast access to content block

I'm not a coder for real but this should be a lot faster than full smarty parsing every time.

I agree.  I think I might just go and make a full cache option for pages.  It'll just cache the entire page contents.  Though, the issue comes with checking all the pieces that might go on a page to see if they've changed.  It might be good to make it just an "all or nothing" solution.  Either it caches the whole page regardless of any cms_modules or other smarty tags (all potentally being dynamic) or it works "normally".

[Pierre M.]

...Perhaps also permission system should be moved to a module (hmm, an advanced FrontendUsers module ). If I make a look at "Show Off" CMSms is used from many page owners himself and they don't need a permission system.

Nice idea, because it rocks KISS. Each feature only once and inside a specific place...

most pages of a website are static...

I agree... It might be good to make it just an "all or nothing" solution.  Either it caches the whole page regardless of any cms_modules or other smarty tags (all potentally being dynamic) or it works "normally".

Another nice idea. I can't resist to remember everybody my favorite thread ("Dynamically generated but statically served pages") where I recently asked "may be pages/templates could have a 'don't cache' flag to simplify ?". I think it it very compatible with the idea "pages/templates could have an 'agressively cache' flag" (which is the opposite flag).

PM

[brady]

I think the permission system needs to stay in the core. In is a basic feature you expect every CMS to have.

The more I think about it the better a custom ORM system seems. It would allow the dev team to have control over what features get added. This means that the system would have everything it needed, and nothing it didn't. In the end, this will make CMSMS smaller and faster.

[Ted]

The more I think about it the better a custom ORM system seems. It would allow the dev team to have control over what features get added. This means that the system would have everything it needed, and nothing it didn't. In the end, this will make CMSMS smaller and faster.

This is quite true.  That's one of the issues with using adodb (lite).  I know there are places that could use optimization or removing things we don't use, but then it becomes a fork and a nightmare to update when they decide to release a new version.

I think we'll stick with this for now and see where it goes... and so far it works, so I can't complain.

[cyberman]

I agree.  I think I might just go and make a full cache option for pages.

Great  - in my daily forum support I see too much threads with speed problems.

[brady]

This is quite true.  That's one of the issues with using adodb (lite).  I know there are places that could use optimization or removing things we don't use, but then it becomes a fork and a nightmare to update when they decide to release a new version.

Why not write your own DB abstraction layer,then? A small wrapper for ADOdb lite for modules that still need it, and you would be on your way. With the new ORM system it seems like you wouldn't need to many advanced functions, the ORM should take care of all that. So a simple wrapper around query and fetch related functions and your good to go. This could also help with speed problems. Another optimization would be to drop Smarty in favor of Template Lite(drop in replacement for Smarty).

[iNSiPiD]

Provided Template lite still contains the core features used in most CMS module display templates, this could certainly be a winner.

[cyberman]

Another optimization would be to drop Smarty in favor of Template Lite(drop in replacement for Smarty).

That's a great idea too - we've discussed it in german forum last time with result that some important functions are not implemented  .

Template Lite offers most of the features of Smarty but there are a number of features that are currently not supported. Some of these features will eventually be supported in later releases. This isn't a comprehensive list of unsupported features.

    * Template Lite does not support the include_php tag, security features, and error handling.
    * The following reserved variables are not supported: foreach. Example: {$templatelite.foreach.[something]}
    * Template Class Variables: $debug_tpl, $debugging_ctrl, $autoload_filters, $compile_check, $cache_handler_func, $cache_modified_check, $security, $secure_dir, $security_settings, $trusted_dir, $compiler_class, $request_vars_order, $request_use_auto_globals, $error_reporting, $compile_id, $use_sub_dirs, $default_resource_type
    * Template Class Functions: get_registered_object, register_object, unregister_object, register_resource and unregister_resource
    * The is token in the if/elseif/else is currently not supported.

[Ted]

Template Lite offers most of the features of Smarty but there are a number of features that are currently not supported. Some of these features will eventually be supported in later releases. This isn't a comprehensive list of unsupported features.

    * Template Lite does not support the include_php tag, security features, and error handling.
    * The following reserved variables are not supported: foreach. Example: {$templatelite.foreach.[something]}
    * Template Class Variables: $debug_tpl, $debugging_ctrl, $autoload_filters, $compile_check, $cache_handler_func, $cache_modified_check, $security, $secure_dir, $security_settings, $trusted_dir, $compiler_class, $request_vars_order, $request_use_auto_globals, $error_reporting, $compile_id, $use_sub_dirs, $default_resource_type
    * Template Class Functions: get_registered_object, register_object, unregister_object, register_resource and unregister_resource
    * The is token in the if/elseif/else is currently not supported.

register_resource is used through CMSMS in order to give use the glue to chain {content}, {cms_module}, etc.  We would definitely need that for template lite.

Why not write your own DB abstraction layer,then? A small wrapper for ADOdb lite for modules that still need it, and you would be on your way. With the new ORM system it seems like you wouldn't need to many advanced functions, the ORM should take care of all that. So a simple wrapper around query and fetch related functions and your good to go. This could also help with speed problems. Another optimization would be to drop Smarty in favor of Template Lite(drop in replacement for Smarty).

I thought about that, actually.  Maybe not for the whole system, but at least for the ORM.  I might research that a bit, though some of the extras you get from ADODB (like the date handling and param handling) are pretty invaluable and would be hard to give up or rewrite to be much faster.

[brady]

register_resource is used through CMSMS in order to give use the glue to chain {content}, {cms_module}, etc.  We would definitely need that for template lite.

Hmm, you're right, I can see how that would be needed, but why not add it yourself? It seems like this would be a HUGE speed increase.

I thought about that, actually.  Maybe not for the whole system, but at least for the ORM.  I might research that a bit, though some of the extras you get from ADODB (like the date handling and param handling) are pretty invaluable and would be hard to give up or rewrite to be much faster.

*taken from ADOdblite homepage
Date functions have been moved to their own module. When creating a new ADO Connection you will need to add the "date" flag if you wish to use any of these functions. The following is a list of Date functions. The Date Module will add approximately 240k to the libraries memory overhead. It is recommended that you do not load the date functions unless you absolutely need them because of the high overhead. When you have selected the Date Module it will also load the adodb-time.inc.php program in support of the date functions.

Maybe it would be beneficial to just give up the date functions?

I see the external libraries as an area for big improvements. Since they are out of the dev teams control they are hard to optimize. Maybe rethinking the choices would be a good idea. I can understand the choice to use both Smarty and ADOdb(lite), but they are huge libraries that try and cover functionality that most apps will never need. This leads to code that contains functions/features that will never be used. This, of course, slows things down. One option would be to start removing features/functions that aren't needed from the packages. This would lead to maintenance issues, though.

Overall, I think it is smartest to add features to smaller libraries(like Template Lite). I think this would lead to the least amount of extra "stuff", and the least amount of maintenance.

[Ted]

Yeah, you're probably right about the adding functions to template lite idea.  The maintenance could become an issue but as long as we're extending existing classes, it's probably not an issue.  I've already had to extend smarty to do some of my bidding as far as plugins that don't cache go...  maybe we can continue by extending Template Lite to add that one function (I don't think I need any of the others).

This is kind of a weird period in development.  I know that I'm breaking backwards compatibilty with some things as it is.  Should I continue down that road and make some big (though no doubt beneficial) changes?

[moorezilla]

Yeah... this is a really important question.

By backwards-compatible, do you mean in terms of content, modules, underlying technologies, or all of these?

For example, requiring php5 for a future cmsms release seems reasonable if it offers compelling advantages, and I can see eventually requiring a higher minimum for mysql version, but would the new fork make it impossible for existing sites to upgrade to a new version of cmsms without losing all of their content, or rather, having to reenter all of their content? If at all possible, I think it would be very important to offer an upgrade solution that changes existing database entries for use with the new cmsms version.

For modules, I imagine several had to make changes to be compatible with cmsms 1.0, which is natural. Would the module changes necessary for modules to be compatible with the next cmsms version represent rewrites of existing modules, or would the changes be minor. Probably a difficult question to answer, but if modules need to be changed significantly to be compatible, would there be some way to give module authors a head start? Along these lines, is there any way to choose a method for writing cmsms that would make module development 100% independent of the core, or is this in reality a pipe dream?

It's probably much better for cmsms the software product to abandon backwards-compatibility in lieu of cleaner, quicker-running code. I would just like to make sure that anyone who has a large existing site has a clear pathway for upgrading to the newer cmsms version, even if this pathway involves demands like, "thou shalt now use php5 and thou shalt upgrade your existing database to do x, y, or z." I just don't want to see a situation where people must choose between "stick with cmsms 1.02 or earlier," or "completely redo your site in cmsms 1.1 or later."

Hope that makes sense.

am

[Ted]

For example, requiring php5 for a future cmsms release seems reasonable if it offers compelling advantages, and I can see eventually requiring a higher minimum for mysql version, but would the new fork make it impossible for existing sites to upgrade to a new version of cmsms without losing all of their content, or rather, having to reenter all of their content? If at all possible, I think it would be very important to offer an upgrade solution that changes existing database entries for use with the new cmsms version.

My goal is to make an upgrade script to handle the transition.  However, because of the major changes in the layout of how content is handled, there will be no way to guarantee a 100% conversion.  I'm expecting it to work for just about everyone, but there will definitely be expections...

For modules, I imagine several had to make changes to be compatible with cmsms 1.0, which is natural. Would the module changes necessary for modules to be compatible with the next cmsms version represent rewrites of existing modules, or would the changes be minor. Probably a difficult question to answer, but if modules need to be changed significantly to be compatible, would there be some way to give module authors a head start? Along these lines, is there any way to choose a method for writing cmsms that would make module development 100% independent of the core, or is this in reality a pipe dream?

Modules won't change that much.  I will extend to ORM to work with them, but it won't be required.  I will probably rewrite parts of News to use it.  Modules that do have content types (Album, Cataloger, News) will require significant rewriting of some portions.  Everything else will pretty much stay as is, or have the module API methods modified to reflect the changes (which, by the way, is one of the best reasons to be using the internal methods for most of the module logic, even if it's a little strange sometimes).

And, no, having the module api without the core is pretty much impossible.  You can do it, but there are hidden variables and other pieces (return id's, adding id to most field names, etc) that really hinder doing it all from scratch.  Plus, after the ORM is in place and I have a few helper methods written, parts of module writing are going to become less time consuming to write... but will be linked to the core more.

It's probably much better for cmsms the software product to abandon backwards-compatibility in lieu of cleaner, quicker-running code. I would just like to make sure that anyone who has a large existing site has a clear pathway for upgrading to the newer cmsms version, even if this pathway involves demands like, "thou shalt now use php5 and thou shalt upgrade your existing database to do x, y, or z." I just don't want to see a situation where people must choose between "stick with cmsms 1.02 or earlier," or "completely redo your site in cmsms 1.1 or later."

Hope that makes sense.

Yup, sure does.  I definitely want to try my best to make sure that an upgrade path is possible.  However, this will be the farthest thing from a manditory upgrade (at least for a year or so), so it's not going to make or break the 1.1 release.  If anything, we'll get upgrades going for most end users, but there are chances of weird stuff happening.  Of course, it's still early in the development cycle.  It could change and become a very stable upgrade procedure before the 1.1 release.

Thanks