KlasRegards,b) Architecture - once we have settled on the a, we need a plan. You don't start building or rebuilding a house with the bricks and mortar, you start with a plan what you are going to build and software is no different. Here we must settle on the mutiple levels that are often mixed:a) First decision to make - is this house old to the point it needs to be rebuild from scratch or does it make sense to just add new rooms and restructure it? I would say first, but this needs to be a common decision by those willing to invest time/knowledge/resources to implement the decision.Hi,please excuse me if I'm not using the right terms in bellow point, but in my opinion we need a bit more systematic approach to this thinking:1) basic scope: Are we building just for the web or are we going wider. I would say focus on the web and leave the rest to the others. Going for all is going for nothing (see framework's fate)2) basic application architecture - functional side of the application and its elements, how they work together to create a page, this is not to be mixed with the next point. This is what we call now components, modules, plugins etc...3) higher level (web) framework architecture (if we go for web in 2 it would be web framework architecture) - is it going to be pure MVC or are we aiming for hMVC or even parallell MVC (I'll try to explain this in separate post once I have the mindmap drawn..) and related decisions.c) Implementation - implementation plan all they way down to who will do what and when.4) low level framework for basic operations - materials to be used for implementation - are we going to build it ourselves or will we use one of the existing wheels like Symphony. I would say focus on2&3 and leave this to others.2014-11-06 23:32 GMT+01:00 Johan Janssens <jjanssens AT gmail.com>:Thanks JM for the info.I don't think the question is which changes from the CMS should be ported to the framework, but rather vice-versa, which code in the framework is useful for the CMS and can be ported without breaking BC. Any code that cannot be ported back is code bloat that should be removed.Again focus is key here.Johan
On Thursday, November 6, 2014 10:42:39 AM UTC+1, infograf768 wrote:
On 5 nov. 2014, at 03:41, Johan Janssens wrote:
> Hi Michael,
> I picked a few of the questions you raised, the rest of my comments I have put in between.
> 1. Has the Framework gone so far "off course" with what people want the CMS to do ?
> Good question, the fruit of the work done in the framework depends on the ability to use the framework code in Joomla. It can be argued that the framework can be used outside of the cms scope, but as we both know there are too many better alternatives already.
> The only possible way to answer this question is try to refactor some of the framework code back into the CMS and see if it still fits while maintaining backwards compatibility. If it does the answer is : "no it hasn't gone to far off course".
We have introduced some modifications in the CMS which have not been ported to the Framework.
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.