2.6 Roadmap about xoopscore HOT 7 OPEN

from xoopscore.

There is a difference between MVC and framework. Xoops has some kind of MVC but the core is not fully based on a Framework. The 2.6 introduce Symfony component and if we want to modify the core I suggest to use Symfony component too.

from xoopscore.

Interesting thoughts.

One flaw in some of the thinking is that backward compatibility is optional. It is not going to be 100%, but it needs to be enough to allow a great portion of existing modules to work with minor changes. It is a pain in the ass. But, it is our saving grace:

Customers are more valuable than code.

The customer base, user base, or however you want to describe it, needs function. We will loose if we forget that.

We will use a generational approach. "2.6" will only be tuned to work with code which already worked well with 2.5.9. I'm not suggesting anything further than one generation back, but there has to be continuity. Modules need time to grow, just like core does. There has to be a path forward.

I also noticed the idea of "start from scratch" in there somewhere. Not going to happen (see customers > code.) Even without that constraint, the start from scratch approach is more likely to result in failure. Continuous refinement is more likely to produce positive results. Yes, we have some enormous technical debt, but when you scrap it all you end up with zero technical equity and zero market equity.

Starting to discuss which framework/libraries we are or not going to use is a bit premature. The question needs to start is what we want to accomplish. What are the requirements? Good design doesn't start with the libraries; the libraries are chosen (or written) to implement the design. If your requirement is you want Symfony, Yii, Zend, Drupal or whatever, there is a much shorter path to implementation than incorporating it into XOOPS.

Symfony makes some awesome components. I like to look to Yii and Aura for ideas. I am always on the lookout for quality reusable components. But those components fit into a design. If they prove limiting or problematic, they can be replaced. Eventually, I'd like to see XOOPS components in wide use.

I've been absorbed in making sure that the 2.5 series doesn't stop working before we get a new generation out. I've always had 2.6 in my mind, but to keep any semblance of market relevance we needed something that users can deploy now on a current stack. XOOPS 2.5.9 is just about to go RC, and my full attention will be back here.

I've got some very specific goals developed over time. I'll get some details out for discussion. I'll always be happy to listen to ideas, and give them consideration.

Let us consider what features we think XOOPS needs, and start the discussion from there, instead of picking a solution and then back fitting.

from xoopscore.

from xoopscore.

If not to late ...

It should already be possible.

One way would be to just use the Smarty::register_function(). That or one of its relatives should work in Smarty 2 in 2.5, or registerPlugin() is the equivalent in Smarty 3 for 2.6.

Or if a directory is a better fit, you should be able to add a plugin directory on the fly, too. The $plugins_dir is a public array in Smarty 2, so something like $tpl->plugins_dir[] = '/my/plugin/path'; should work. In v3 there is an addPluginsDir() method.

from xoopscore.

@geekwright Great, thanks! I had the idea that plugins_dir was a private method.

from xoopscore.

from xoopscore.