2.6 Roadmap #518
Comments
|
Personally I think if this is the path that is decided upon, work on 2.6 should be suspended and 3.0 worked on from scratch from the ground up. We can use things learned with the building of 2.6 to help rapidly prototype a new system. Of course use frameworks where it makes sense to help rapidly build the system.
Doesn't mean ALL code from 2.6 should be thrown out but starting from ground up does make better sense. If done transparently and with help and input from all of the experienced programmers I think this could turn out to be a true rebirth.
While true backwards compatibility could be a hard task, we could build out XMF to be able to support all operational capabilities so that old modules could relatively be brought up to speed and be able to run under either 2.5.9 or 3.
MVC would make matters much easier long haul.
I also would like to again suggest consideration of a system like Drupals Entity system build in as core for 3.0. It allows rapid prototyping of a new web site from scratch without modules for most systems. If done from ground up much of the system could be built to take advantage of such a system as well. The Drupal implementation of it seemed a bit "beta" class software to me but I feel this group could do a much better job.
…________________________________
From: Ricardo Costa <[email protected]>
Sent: Saturday, March 4, 2017 12:00 PM
To: XOOPS/XoopsCore
Cc: Subscribed
Subject: [XOOPS/XoopsCore] 2.6 Roadmap (#518)
I think Xoops could do so much more if it was using a MVC or ADR design. Blocks as Widgets, namespaces for modules, URL rewriting, this are all features that, IMO, require a shift to a new design.
I think we should not attempt to write this design from scratch and I also think that picking a library from here and another from there is not a good solution.
In the past we agreed on using Zend framework as the backbone of Xoops but, for several reasons, it did not worked well.
Today, and after much reading, I think Yii2 would be a good fit for Xoops. Not for 2.6, but for the next major version that would follow it.
What I am trying to say is that, if we do implement MVC in 2.6 series, we should first agree with which Framework we are planning to use in the future. For example, if we choose to use Yii2 (which I vote for), we should built our MVC using the same interface as Yii2.
I also would like us to consider releasing 2.6 without making any more drastic changes and remove the above mentioned features from the roadmap.
We should design Xoops 3 not having backward compatibility in mind, with the exception, perhaps, of the database structure.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#518>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAmcMOPhz6khUGdiShXicMPS6POMdBXdks5riZiQgaJpZM4MTJGO>.
|
|
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. |
|
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 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. |
|
Ok Richard, I agree with you. Let us go with ease.
I would like to see modules actions separated from views. I plan on making
a module that will extend XMF with new featrures and for testing ideas.
If not to late, I would like to have a way of adding a source for smarty
plugins on XoopsTpl. This module will need it for adding it`s own plugins
at run time. That way I'll not have to ask users to copy files to
xoops_plugins folder.
It could be done via setter method or preload, I believe.
Can it be done before RC?
Thank you.
Em 06/03/2017 03:56, "Richard Griffith" <[email protected]> escreveu:
… 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.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#518 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGFR70sASJjXxFaVp8rbExZ74Y7pmkmUks5ri4PUgaJpZM4MTJGO>
.
|
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 |
|
@geekwright Great, thanks! I had the idea that plugins_dir was a private method. |
|
I was the one mentioned "from scratch".
I more or less mean look at the whole package from fresh and look at what might be best to add to it. Of course start from a framework. But as my experience in writing my senior project shows. If we find the right combination of frameworks we should be able to build out a new system a whole lot quicker than revamping the old one.
While Richard has done A LOT of work on 2.6 I wonder if it would be quicker to look at starting from a different base (Group of frameworks) and build that up with the final goal of a much nicer system but maintain compatibility.
Not truly "from scratch" but look at what we are trying to accomplish, map out a good way to do it with the tools available to us and go that route. Reuse code where it makes sense of course.
To make old modules compatible should be relatively simple with a "Compatibility module" or some other such mode. With XMF leading the way. Of course where frameworks such as smarty are concerned we would be able to code with compatibility in mind.
I don't see a reason we couldn't still maintain compatibility.
With the vast number of Modules already in existence we would do good to keep things compatible as much as possible and that should be doable with some sort of "Legacy" module that would run as sort of a secondary "system" module but would use whatever system is in place.
I have seen this method in other systems and worked out nicely. I hate to see this stuff bogged down for the next 2 years while rewriting 90% of the code when could have started with a clean slate, tie a bunch of frameworks together with the end goal in site and build from the ground up. If done that way I do think we can maintain compatibility and still jump 2 or more iterations ahead of where we are headed now.
However having said all of that. I will be of limited availability so I can only act as a cheerleader at this point. I have faith you guys can sort it out and I hope to be able to be a part of it when my time opens up.
Good luck with 2.5.9! And hope xoops continues to evolve and grow!
Rodney
|
I think Xoops could do so much more if it was using a MVC or ADR design. Blocks as Widgets, namespaces for modules, URL rewriting, this are all features that, IMO, require a shift to a new design.
I think we should not attempt to write this design from scratch and I also think that picking a library from here and another from there is not a good solution.
In the past we agreed on using Zend framework as the backbone of Xoops but, for several reasons, it did not worked well.
Today, and after much reading, I think Yii2 would be a good fit for Xoops. Not for 2.6, but for the next major version that would follow it.
What I am trying to say is that, if we do implement MVC in 2.6 series, we should first agree with which Framework we are planning to use in the future. For example, if we choose to use Yii2 (which I vote for), we should built our MVC using the same interface as Yii2.
I also would like us to consider releasing 2.6 without making any more drastic changes and remove the above mentioned features from the roadmap.
We should design Xoops 3 not having backward compatibility in mind, with the exception, perhaps, of the database structure.
The text was updated successfully, but these errors were encountered: