Joomla Single Task Controller RFC

[Mathew Lenning]

Hello everyone. 

It's me again. 

I spent the last few months building a light weight course component and I plan to start building structured learning paths using the Joomla! documentation and YouTube. 

However while building the component I went off on a tangent and built out a single task controller systems that I though might be something to look into for Joomla! 4.

I've given up on learning git for the moment (I plan to try again once I get back to the states and buy some books), so I uploaded it to Google Drive for the time being

The idea is that instead of sending a task command that reads something like controller.task (I.E. articles.edit) , we change it to controller.subject (edit.articles).

If you look at dispatcher.php you'll see that the controller naming convention has also changed instead of MycomponentControllerArticles, it ends up being MycomponentControllerEdit. It also fallsback to the default which at the moment is Babelu_libControllerJoomlaEdit

I've done some preliminary testing and it works well, however I went a little overboard and build out the views and the models too, which I'm starting to regret (relearning how to build a component all over). 

Looking forward to everyone's input. 

[Herman Peeren]

Thanks for sharing.

Pfew, 28 controllers and an interface... I don't know very well what to do with that. Isn't this a good demonstration of something being very wrong with those one task controllers? What are the benefits of this compared to current and other solutions? What problem are we solving anyway?

Not to bash or be harsh, but just to reflect about: what the heck are we doing?

[piotr_cz]

There are some advantages:

If you play it well, controllers filesystem structure may look like REST paths and it may be easier to locate controller for specific task.

Besides, In the abstract controller I'm checking on the request method and using one controller for showing an item and submitting new one: using executeGet and executePost tasks. This may share same data like table access, form, etc.

If you don't like it, you may build own abstract controller on top of JControllerBase. There is already a pull request with JControllerCmsbase

[Mathew Lenning]

@Herman

Thanks for commenting! I realize that without seeing them in action it seems wasteful, but here is the catch. 

With those 28 controllers (don't really need the interface =^P), you eliminate the empty MycomponentControllerWhatevers and its partner MycomponentControllerWhatever that are currently required for every extension developer to create just to show their lists and forms in the administration area. 

I think that when most people think of single task controllers, they think "O.K. so I have 5 views in my administration area each with a list and form view. The list view has the standard CRUD plus publish, unpublish, orderup, orderdown, reorder, etc..."

Then they do the math.

5 views X 28 basic administrative tasks = WTF!.

Then they decide that single task controllers are waste of time and feel luck that they only need to create 1 empty controller for every list and every form. 

However the solution I've asked you to consider is a little different from the current status quote. I guess the closest thing it resembles is the visitor pattern (although only very loosely) 

  

Imagine only having to create controllers for Unique functionality, and leaving the CRUD to the core controllers (which we already do in a round about way). 

Then imagine that someone completely changes the way the edit controller works. Re-factors all the JControllerAddEdit functions and changes every one of their names to US English spelling.

The new release comes out and the forums are quiet. No pitch forks, no mobs, no extensions break, no one even notices the difference. Because the only class that was responsible for Adding a record and then returning to the edit screen was the JControllerAddEdit. Welcome to the land of single task controller.

To sum it up the problems I am trying to solve are:

1. Clear separation of responsibility

2. Reduction of duplicate code.

3. Reduce class inheritance as a method of code reuse.

4. Make it easy for me to turn ideas into extensions. 

 

The benefits vs the current solution

1. Improved stability (less BC break points)

2. More uniform behavior of all components (I.E. security checks, ACL checks, dispatcher events for core tasks)

3. Well structured pattern for implementing additional functionality (I'll be building import & export controllers one I've gotten the first set working in J2 & J3)

I'm sure there are more, but I won't know until I finish building a few components with the design.

Again thanks for the post. I really appreciate your input, as it give me an alternative view point to approach the idea from. 

[Hannes Papenberg]

I have my difficulties with the one-task-controller-concept, too. I
kinda understand what you are trying to do here, but I don't understand
how this is easier than a multi-task-controller. I actually don't even
see how this works with all features that we want/need.

I understand that you want to have clear seperation of responsibilities
here, but I would go the route of the decorator pattern. I see things
like checkin/checkout, publish up/down, versioning, etc. that you have
to plug into several areas of your component and thus I'd rather have
one base class, that implements CRUD and then decorators that (applied
in the right order) add one specific feature per decorator. Like the
checkin/checkout feature, versioning or changing the state of an item.

Hannes

> <https://drive.google.com/file/d/0B7NSGTBMVDlFUUpfZ0V5MmhRSXc/edit?usp=sharing> for

> the time being
>
> The idea is that instead of sending a task command that reads
> something like controller.task (I.E. articles.edit) , we
> change it to controller.subject (edit.articles).
>
> If you look at dispatcher.php you'll see that the controller
> naming convention has also changed instead of
> MycomponentControllerArticles, it ends up being
> MycomponentControllerEdit. It also fallsback to the default
> which at the moment is Babelu_libControllerJoomlaEdit
>
> I've done some preliminary testing and it works well, however
> I went a little overboard and build out the views and the
> models too, which I'm starting to regret (relearning how to
> build a component all over).
>
> Looking forward to everyone's input.
>

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cm...@googlegroups.com>.
> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.

[Mathew Lenning]

I understand that the concept is a little difficult to grasp at first, and Google groups probably not the best medium to explain it, but maybe an example would help. 

So lets start with the way it is currently done with multi-task controllers. I'm pulling this all from memory, so if I mess up some of the extends please mentally correct it. 

We have a single MVC triad for the administration area. The files are called

MycomponentControllerDetails extends JControllerLegacy

MycomponentModelDetails extends JModelList

MycomponentViewDetails extends JViewLegacy

With this we can produce an list of record in the DB and present them to the user. However if we want to add any administrative functions we need to add their singular counter parts

MycomponentControllerDetail extends JControllerAdmin

MycomponentModelDetail extends JModelAdmin

MycomponentViewDetail extends JViewLegacy

With that we have the 6 files needed to implement the current administration area. Of course you still need the front controller MycomponentController to act as a gateway into the component.

The big issues here are:

1. First 6 files to display 2 views of the same data

2. Both controllers will be for the most part empty. 

3. Inheritance binds us to the implementation (if it changes we have to change with it)

4. The details view has to know about the detail view or it cannot do anything.

5. Multiple routes to the same destination (I.E. index.php?view=detail or index.php?task=detail.display) 

But I think that is enough for this example. Then there is the fact that this must be repeated for every list/form in our extension, so an extension with 5 db tables requires at minimum of 31 files for standard admin controls (MVC only. tables/helpers/forms not counted).

Of course there is more than one way to skin a component, so you could override everything and make it so that 1 MVC triad pushes both the list and the form, but every change increases your technical debt and makes you more susceptible to compatibility problems in future versions.

Now lets look at my implementation of the single task controller. 

To implement the same administrative controls we first need to create our model and view

MycomponentModelDetail

MycomponentViewDetailHtml

We also need a front controller that extends the JControllerDispatcher class.

MycomponentController extends JControllerDispatcher (this is an empty controller)

That is it we now have all the files needed to use standard administrative functions. If we add more views we only need to create one model and one view for each (of course we need default.php and edit.php template files for each view that hasn't changed)

Also the view doesn't need to know about any other view/models to do its job. All it needs to know its name and the task it wants to perform. No more inflections. 

If the 28 task controllers I built were part of the core. We only need to build controllers for tasks not supported by the core (I.E. unique functionality) Or create our own versions for the ones we want to work differently.

Benefits of this method:

1. Since the controller only has one task, its cleaner less complicated and easier to maintain. (@see JControllerForm::save)

2. Since the controller is the authority on what doing a "task" means changes to the other tasks won't effect it and changes to it won't effect other tasks.

3. Since the controller doesn't know what kind of "subject" it is being past, it has to leave most of the heavy lifting to the model. 

4. Since the model does the heavy lifting any changes to the controller won't break functionality unless the controller changes the model functions is calling.

6. Reuse, reduce, and, recycle. Only build functionality that isn't already there.

There are more benefits, but I'll stop there for now and continue on with the way it works.

So in our view we have a add.detail task button when its clicked it submits the form (this is about the same as we currently do it).

When the form is submitted the mycomponent.php file is called.

In the mycomponent.php, we get the input and the app and then create an instance of MycomponentController passing the input, the app, and an optional $config array

MycomponentController extends JControllerDispatcher and is completely empty. 

If you look at dispatcher.php, you'll see how we get our task controller.

Then in mycomponent.php we call the execute function of the MycomponentController which just forwards the execute command to the task controller.

Last we call the redirect function of the MycomponentController which checks the task controller gets the redirect information and passes it to the application. 

I think I've explained it the best I can, but some how feel that the explanation is lacking. I think a working example would be the best way to demonstrate it. I'll build a Hello World component once I've finished debugging it in J2 & J3. 

[Amy Stephen]

On Tuesday, April 15, 2014 10:12:39 AM UTC-5, Mathew Lenning wrote:

Hello everyone. 

It's me again. 

I spent the last few months building a light weight course component and I plan to start building structured learning paths using the Joomla! documentation and YouTube. 

However while building the component I went off on a tangent and built out a single task controller systems that I though might be something to look into for Joomla! 4.

I've given up on learning git for the moment (I plan to try again once I get back to the states and buy some books), so I uploaded it to Google Drive for the time being

Very impressive, Mathew. Nice and clean. Single responsibility well executed.

Figure out how to allow components to inherit the classes and you have a great solution, there.

Need to have the framework team look at it -- in particular, Don.

You done good, sir!
 

[Mathew Lenning]

@Amy

Thanks! I'm glad you like it. I'm going to figure out this contributing thing eventually =^D 

Regarding the component inheritance, one of the major sellers for this method is that components won't have to inherit from the core controllers anymore, however if they want to override the functionality they could just create their own controller for that task, or even inherit from the core task controller and do some thing like.

public function execute()

{

  // some customization before the task

  if(parrent::execute())

 {

   // some customization if the task executes successfully

 }

 //some customization after the task is finished

 // this would even allow custom rerouting because all they have to do is define their route and call setRedirect()

}

Thanks again for the compliments =^D 

[Amy Stephen]

On Wednesday, April 16, 2014 11:38:00 PM UTC-5, Mathew Lenning wrote:

@Amy

Thanks! I'm glad you like it. I'm going to figure out this contributing thing eventually =^D 

Regarding the component inheritance, one of the major sellers for this method is that components won't have to inherit from the core controllers anymore, however if they want to override the functionality they could just create their own controller for that task, or even inherit from the core task controller and do some thing like.

Oh, wow! I thought it was a single component. That's really something, Mathew -- recommend posting in the framework list, too. Very impressive.

I'm sure between the group of us we could help you get started with github. Feel free to ping me on Skype if you want help. You can get books but as you get started, there aren't that many commands you need to know.

Again, very nice work. Clean code is always nice to see!
 

[Mathew Lenning]

@ Amy

I posted a link in the Framework group. I know I have to figure out Github eventually, but would prefer to do it when I get back in the states and settled. At the moment my contract with the Board of Education finished at the beginning of this month. So now I have to prove that I'm not insane and make this Joomla! Extension Developer thing pay the bills.

These single task controllers are definitely going to make life easier. Once I've released my latest creation, I'm going to build the hello world example. Then maybe you can help me get it up on github, so everyone can take a look. 

=^D

[Dmitry Rekun]

What I think is that may be we can somehow to support both ways allowing multitask controllers and one task controllers? Or it will be too much confusing for the devs?

Dmitry

четверг, 17 апреля 2014 г., 15:47:44 UTC+3 пользователь Mathew Lenning написал:

[Mathew Lenning]

@ Dmitry,

The truth is both ways have always been and will always be possible. The fact that I can run these controllers in J2.5 & J3 without skipping a beat is evidence of that, but I don't think the CMS should support multiple MVC architectures. There should be the Joomla! way and anyone that doesn't want to do it the Joomla! way should be responsible for carrying the technical debt for that decision either by maintaining the code themselves (as I'll be doing for these single task controllers for the time being) or by convincing the Joomla! project that their way is better (which I'm hoping I can do between here and J4).

One other selling point is theoretically HMVC should work with this design. Of course I haven't tested this theory, but once I get the hello world component built I might give it a try. 

=^D

[Mathew Lenning]

So I took a few hours today and converted the J3! Hello world component, so that it uses the single task controllers. I've attached the install package for babelu_lib and com_helloworld, so please check it out. 

I made the lib and the component separate packages on purpose, because it is very important to realize that if these controllers were in the core, then all you would need to create in order to deploy a new component is the contents of com_helloworld

Let me know what you think.  

[Mathew Lenning]

O.K. So after I posted I realized I didn't create the required config.xml for the options button that shows up in the list view in the admin area, so clicking that button won't be pretty. Just ignore it or add a config file, I'll make sure there is one in there when I put it up on github. 

=^D 

I'm off to bed. Looking forward to constructive criticism and suggested improvements.  

[Mathew Lenning]

Just an update, I've managed to get the controllers on Git https://github.com/Mathewlenning/joomla-cms/tree/Single-Task-Controllers

I renamed them to work with the directory structure. Also I'm going to put the JCmsModel's and the JCmsView's in the CMS directory. Within the week. 

One question I have for you seasoned contributors, do I need to send a pull request to start the RFC or do I make the pull request after I get enough people who like my idea? 

[George Wilson]

This looks really nice :) Just a few small things from a glance over - I presume this https://github.com/Mathewlenning/joomla-cms/blob/Single-Task-Controllers/libraries/cms/controller/update/copy.php#L49 shouldn't have that typehinting.

Also I can't find it now but you were using some directory separator constants somewhere which shouldn't be needed either

But I really look forward to going over this in more detail :) :)

Kind Regards,

George

[Mathew Lenning]

@George

Thanks for the proof reading! Converting all the names and pulling out all the Babelu_lib hinting was mind numbing, but hopefully with your input, we squashed them all.

Now I need to figure out how to tell Travis that the these controllers assume autoloading. 

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/a5nU71UKrw8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Mathew Lenning]

I've finished the project proposal for what I'm calling MVSC design. Its on google drive https://drive.google.com/file/d/0B7NSGTBMVDlFaEV4SG00Z3lLUTg/edit?usp=sharing

[Herman Peeren]

tl;dr: Mathew shows the advantages of Convention over Code, not of single-task controllers.

Convention over Code
With all his hard work Mathew shows the advantages of falling back to code in an underlying library or framework for common tasks. This principle, Convention over Code, is the basis of what was called the RAD-layer for Joomla: FoF. The main advantage is: less code in the specific extensions. That advantage can just as well be accomplished with multi-task controllers as with those one-task controllers. In fact, that is allready in Joomla (as FoF). Rewriting the core-extensions with FoF would give the same (or better) amount of code reduction as what Mathew wants to show. Of course it would even be better to have a native fallback to core code instead of a framework on a framework, as FoF does, but there is no need or advantage to use one-task controllers for that. So, needing less code for extensions by using core fallback code is very good, but not an argument to specifically use one-task controllers.

What is the problem that is solved by using one-task controllers? Let's first step back a bit and have a look what responsibility a controller has. MVC is mainly about splitting the data and logic (the model) from the way it is displayed (the view). The controller handles user input by getting the right model, setting its state and getting a view to render data from this model.

Single responsibility
Let's clear up another misunderstanding while we are looking at controller responsibilities. Above I described the responsibility of the controller. You see: it is not handling the task, but handling the user input. The model handles the task. The controller only triggeres the right task in a model. So, single task controller is not the same as single responsibility of a controller. Those two are mixed up in this discussion.

However, there is indeed a problem with Joomla-controllers having more than one responsibility. But it has nothing to do with handling of different task-variables. Except for handling the user input by getting the right model, setting its state and getting the right view to render this model, there are 2 more responsibilities handled by a Joomla controller:

1. in case the request is to change persistent values (create-update-delete, CUD) there are 2 consecutive things happening: first a model handles the changes and then the whole request is redirected to a new read-request. In that read-request the controller gets a model again (possibly even another one than the one in which the CUD-request was handled), sets its state and gets a view to render this model. This pattern of Post-Redirect-Get (aka Redirect-After-Post) is a very common pattern in web development; not Joomla-specific. http://en.wikipedia.org/wiki/Post/Redirect/Get . It solves some problems like duplicate form submissions. A redirect is  via the client; server-side the whole Joomla-stack is built up again! That is not necessarily bad, but for the discussion about single responsibility, keep in mind that the redirecting to a next URL is another responsibility that was added to the Joomla controller. If we  only  want to give one single responsibility to a controller, we should split those two.

2. since  ACL in Joomla 1.6 there is an extra responsibility put into the controller: to check the permissions. Here Joomla does something very odd: it redirects the whole request after splitting the task with a dot in it into a task and a view. See the book by Mark Dexter & Louis Landry page 238-239 to get a description how this works.  I'd call it a mistake, for it gives an unnecessary roundtrip to the client, building the whole Joomla-stack again ... for no valid reason. Request-handling takes twice as long as needed. I didn't see a correction of this unnecessary redirection in the controllers that Mattthew is proposing now, but I'd have to look closer at that to know for sure. It also is a matter of clear single resposibilities (but we probably have to refactor our ACL for that too).

Command pattern
An object with one execute-method, like those one-task controllers is an example of a command pattern, one of the 23 classic GOF design patterns. It can be useful, for instance to queue commands in a chain https://nooku.assembla.com/code/nooku-framework/git/nodes/develop/library/command/chain or in a workflow https://doc.ez.no/eZ-Publish/Technical-manual/3.8/Concepts-and-basics/Workflows or to communicate user input to a model that has richer behaviour than just CRUD http://verraes.net/2013/04/decoupling-symfony2-forms-from-entities/ . Any object with multiple methods can be spit in several (command) objects with only one method. The other way around too. It doesn't matter for the logic that is executed, it is only another code-format. Splitting methods off into a command object is done for a reason, to accomplish something. Like the examples I gave (a chain, a workflow, to communicate rich behaviour between a form and a model, etc). It is a nice design pattern, but only useful if you do it with a goal. And that is what I still haven't seen with those one-task controllers. What is the problem you want to solve by  putting those calls to methods of models and views in seperate command-objects?

[Mathew Lenning]

@Herman 

Thanks for the quote from the Gang of Four, its been awhile since I actually cracked the cover of that monster, but I do keep it my by desk just in case I get the hankering for some pattern practice. 

I'm also read with Mark Dexter and Louis Landry's book. Its a good read and a must for anyone that wants to bend Joomla to their will. 

I'm also very familiar with the current MVC implementation and the ACL system, but I'm unfamiliar with the second issue you mentioned. As far as I know there is no redirect associated directly with the ACL implementation. Rather the redirect that is associated with JForm::edit is the result of a routing anomaly that allows different formatting of the same variables to take separate routes to the same destination. That is number 3 on the below in problem hit list. The reason why it redirects after execution, is to prevent users from accessing the form directly and by passing all of the checks that are performed in the edit method. Since all controllers that inherit from any of the legacy branch are descendants of the base class which defines the display method, preventing the user from exploiting this routing loophole required the redirect in question. This too is resolved in my implementation without the need for JControllerLegacy::holdEditId, JControllerLegacy::checkEditId or JControllerLegacy::releaseEditId method and the added complexity that they bring. 

I think that the big picture has still been missed here and I'm not sure if I have sufficient communication skills to explain it adequately. I really believed that so many seasoned developers who have worked for so long with the current MVC would be able to read the code and understand, by its very nature, the implications of such a straight forward implementation. 

However I'm not one to give up easily. So I'll do my best to clarify the intention of this proposal and the problems it addresses more accurately. 

First the intention of this proposal is simplicity, clarity and freedom of choice. Although more consistent conventions are recommended, it is not required.

If you haven't had a chance to look at the pull request please do. 

Characteristics of the code

1.The the largest class in the entire implementation is 243 lines and that's the base class.

2.These controllers address most of the core tasks in 1,835 lines.

3.The longest method in all of them is 45 lines. 

4.There are no regular expressions 

5.When a nested conditional is used it is never more than one level deep. 

These characteristics mean that this code could be read by a 10 year old with no coding experience without buying the GOF design patters or Mark Dexter & Louis Landry books. 

It also means that if for some reason I'm no longer around, maintenance doesn't become an issue.

Of course there is still a lot of re-factoring that can be done to improve these controllers even further, but in comparison to the legacy branch, these characteristics alone are worth their weight in gold. 

However it is pointless to speak of solutions without discussing the problems, so I'll do my best to explain.

The problems that this controllers hope to address are as followed: 

1. Exposing controller interfaces in the view. Which also require the view to know which controller its using and what function within that controller. task=controller.task or to be honest about it task=controller.function (I also wanted to get rid of task mapping period)

2. The requirement of 2 MVC triads to implement list and form views of the same data and the need to hack the JController::getModel by default. 

3. The routing issue that allowed different formatting of the same variables to take separate routes to the same destination. "view=article&task=display&layout=edit", "task=article.edit"

4. The existence of any single method that spans more than 200 lines of code. @see JForm::save

5. Remove things like using plurals and singulars in class names, and the view.html.php naming convention. As well as the existence of multiple classes using the same name in views (view.html.php has MycomponentViewName, view.jason.php also has MycomponentViewName, etc...)

There are several more, but its 1:48 am here and I've been up since 5 a.m. (my kids are early birds) So I'm off to bed. I look forward to additional feedback.

[Mathew Lenning]

O.k. So I'm back. Sorry about all the typos, I was hanging on by a thread last night.

Now to get back to the problems that this system addresses:

Just to clarify number 5. on the previous problem list, I really didn't remove the capability to use plurals and singulars, I just removed the requirement to use two different controller task strings in the list view "articles.publish" and "article.add". This of course isn't directly related to the naming convention, its more an issue with the multi-forking in the JController hierarchy, but the point is it is an unnecessary waste of cognitive energy and an unneeded addition to the overall Joomla learning curve. 

6. Fractured ACL scattered throughout the MVC. Checks in the controllers, models, and views all use different methods of achieving the same ACL check. 

7. Code irregularities like the use of JSession::checkToken or die(JText::_('JINVALID_TOKEN')) and JSession::checkToken() or jexit(JText::_('JINVALID_TOKEN')); caused by the fact that these things are peppered throughout the controllers.

8. Reduced dependency on helper classes. This is just my opinion, but the excessive use of such classes is basically a trick used to avoid having to actually implement a proper solution.

9. The need for the controller to distinguish between a "$view_list" or "$view_item" redirect.

10. The use of ternary if statements which serve no purpose but to make me think harder than I have too. 

Example from JForm::save

$this->setMessage( JText::_(($lang->hasKey($this->text_prefix . ($recordId == 0 && $app->isSite() ? '_SUBMIT' : '') . '_SAVE_SUCCESS')? $this->text_prefix: 'JLIB_APPLICATION') . ($recordId == 0 && $app->isSite() ? '_SUBMIT' : '') . '_SAVE_SUCCESS'));

11. Reduce the amount of knowledge the controller has about the classes it is working with. I.E. NO $form = $model->getForm or $table = $model->getTable in the controller.  

That is about all I can think of at the moment, I know there were more nags that motivated me to build these controllers, but the truth is that all of these things could be addressed in a multi-task controller MVC. 

What I don't believe is that multi-task controllers could be maintained to such high standards in a purely open source environment. 

This isn't a negative reflection on open source or the Joomla community, so please don't take offence.  

The true is that everyone in a community driven opensource project like Joomla comes in at different skill levels and belief systems. Although I might believe everyone has read "Clean Code" and therefore should see why nested conditionals and ternary if statements should be banned by policy. The reality is not everyone has read it, and of those who did not all of them were actually reading to make their lives easier.   

Combine this with the fact that when pull requests are made to they are usually considered only in the context of the change and not in the context of the class or the hierarchy.

And you get small changes over time that slowly degrade the original implementation until we end up with a Legacy MVC.  

On the other hand, single task controllers are almost criminally simple by their very nature, and follow a predictable pattern. 

So when a pull request that violates their nature or the pattern is reviewed, it doesn't take much thought for a maintainer to see the divination. (No Scrolling! yay)

Anyway, some how I feel like I'm chasing my tail here. So there isn't really much more I can say. So I guess I'll let the code speak for itself. 

[Herman Peeren]

+1 for working on improvement of Joomla's MVC
+1 for following Uncle Bob's good advices
-1 for the architecture, especially the use of one task controllers (see diagram) without a good purpose

[Herman Peeren]

Better image.

[Mathew Lenning]

@ Herman

Thanks for the diagram!  What program are you using for diagramming? I've been looking for one for a while, but all the good ones seem to be on MAC and I'm a PC.

On Saturday, May 3, 2014 5:25:50 PM UTC+9, Herman Peeren wrote:

Better image.

[Mathew Lenning]

I was just brain working the situation and I realized that I've been spending a lot of energy trying to convince everyone this system is better than a multi-task controller system, but I asked what advantages a multi-task controller system has compared to this system.

Could you please tell me what the advantages are? Thanks in advance. 

[Mathew Lenning]

Sorry yet another typo there.

  

but I asked what advantages a multi-task controller system has compared to this system. = but I haven't asked ...

[Herman Peeren]

This is in PHPstorm. Super-easy (just selected the cloned github directory and clicked "show diagram"). On the computer (I'm mainly on PC too) much better quality. Before I used PHP-storm I used BOUML for UML-diagrams. But the diagrams in PHPstorm can be manipulated later too. And very cool: just click on the class, F4 and you see the code. I often start with a class diagram like that when analysing code.

[Herman Peeren]

I've put that JControllerUpdateBase and children up, because it was lonely down, but probably it should be extended from JControllerSave. There is a typo now:
JControllerCreateBase extends JControllerJoomlaSave
Things like that are immediately detected when using an IDE.

[Herman Peeren]

Combinatorial explosions like under JControllerSave are probably best saved by a Strategy pattern.
BTW: Controllers can be seen a Strategy of Views. 
I'm looking at ways to divide some parts (like query-command-separation) and then combine the dispatchment of tasks to make the whole easier and more compact.

[Herman Peeren]

On Saturday, 3 May 2014 17:41:26 UTC+2, Herman Peeren wrote:

Combinatorial explosions like under JControllerSave are probably best saved by a Strategy pattern.

Typo: "best solved" instead of "best saved".

[Mathew Lenning]

Thanks for the keen eyes. These controllers actually came from a custom lib that I built for the Babel-U-Extensions family. They used to have names like Babelu_libControllerJoomla{TaskName}. I missed that one when I converted it over for the PR, if you see any more please let me know.

I actually use Eclipse PDT at the moment. I thought about using PHPStrorm, but since I build commercial extensions, it didn't feel right to use the free licence they offer for Joomla contributors and when I did the trial version, I didn't see anything that justified the extra expense. Of course the diagrams are a big ++, so I'll have to revisit this decision now that I'm a full time extension developer. 

As for JControllerSave branch, I though about a strategy pattern and tried a few variations, but the benefits didn't seem worth the added complexity. If it is easy to think about, it is easy to remember, it is easy to use and it is easy to customize. That is really my hope for the future of Joomla!

Thanks for brain working this with me! I'm looking forward to seeing your optimizations. 

[Herman Peeren]

On Sunday, 4 May 2014 03:50:36 UTC+2, Mathew Lenning wrote:

Thanks for the keen eyes. These controllers actually came from a custom lib that I built for the Babel-U-Extensions family. They used to have names like Babelu_libControllerJoomla{TaskName}.

 

 Yes, we saw in the files you shared on Google Drive in the first posting of this thread.

On Sunday, 4 May 2014 03:50:36 UTC+2, Mathew Lenning wrote:

I actually use Eclipse PDT at the moment. I thought about using PHPStrorm, but since I build commercial extensions, it didn't feel right to use the free licence they offer for Joomla contributors and when I did the trial version, I didn't see anything that justified the extra expense. Of course the diagrams are a big ++, so I'll have to revisit this decision now that I'm a full time extension developer. 

I have used Eclipse and NetBeans too, they are  allright and several handy extensions are available, but PHPstorm has so much more to offer and saves me so much time! Composer-integration, PHPunit-integration, GIT-integration, refactoring, many handy shortcuts etc. I have a personal license, costing 89 euros /year; worth every cent of it, dont want to work without it anymore (disclaimer: I have no shares whatsoever in JetBrains).

On Sunday, 4 May 2014 03:50:36 UTC+2, Mathew Lenning wrote:

As for JControllerSave branch, I though about a strategy pattern and tried a few variations, but the benefits didn't seem worth the added complexity. If it is easy to think about, it is easy to remember, it is easy to use and it is easy to customize. That is really my hope for the future of Joomla!

That is the right starting point: any refactoring, with or without a design pattern, should always make things less complex and easier to maintain.

Thank you for all the work you did so far. I like the passion you put into it. I hope you will keep an open mind to improve things, even if the outcome would be different than your proposal. If the result is better, we all win.

[Mathew Lenning]

You've obviously noticed I'm extremely hard headed! It is both a gift and a curse.

But you are absolutely right, if there is a better way and it stays true to the intent (clarity, simplicity and freedom of choice) then standing in the way would only hurt the community and that is not what I want. 

I'm sorry if I come on too strong. 

 

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

--

[David Fritsch]

Hey Mathew,

Thanks for starting this discussion and posting your code. I've been working through this a bit myself, and it was helpful to see how you implemented things!

Thanks,

David

[rolandd]

Hello all,

Just my 2 cents. My preference lies with multi-task controllers too, as single task controllers seems like more work to me. In the current setup of Joomla we need indeed too many files to create a view. This is one of the reasons I also use FOF as this allows me to display a view without any controller since the FOF base controller handles all. If I need something different, I can create a controller per view, no need for 2 controllers depending on singular or plural.

In addition, with FOF I can use one set of models for both frontend and backend, this also reduces the code needed to write and  the number of files.

To further make an extension leaner, I don't even need a view file since FOF has a base view that does all. Only if I need something different, I can create a view file.

Don't get me wrong, I don't want FOF merged with the Joomla! core, but I do believe we can get some niceties from it so Joomla! core will be more RAD.

[Mathew Lenning]

@rolandd

I'm assuming you haven't actually looked at the single task controllers. All of the abilities you described with FOF are available with the single task controllers, except not needing a view. 

The difference here is that if you need specialized functionality, you can build one controller and only one, not one per view. Not one per model, not one per component. Just one period. 

However, after arguing the point over and over again, I've tired of the whole discussion. 

Everyone keeps complaining that these will just cause them more work. But the truth is either they haven't looked at the code or haven't grasped the concept. 

I think I've done all I can to help you see, but until everyone stops thinking in legacy MVC, I don't think there is much point in continuing this thread.

Happy Joomla!ng 

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

--

[Beat]

On Saturday, May 3, 2014 5:41:26 PM UTC+2, Herman Peeren wrote:

Combinatorial explosions like under JControllerSave are probably best saved by a Strategy pattern.
BTW: Controllers can be seen a Strategy of Views. 
I'm looking at ways to divide some parts (like query-command-separation) and then combine the dispatchment of tasks to make the whole easier and more compact.

Hi Herman,

I like that Strategy pattern approach a lot. Btw. enjoyed a lot talking with you at JAB14! :-)

My personal preferences in my own research work nowadays is a "Zero specific controllers" pattern, completed by a flexible Router, and an optional "Custom Controller" when really needed (although I found that very specific controllers needs were often better implemented in the Model, but it's reassuring to have a way to override default Controllers if needed).

Explained a bit better: Most tasks in applications can be expressed in a Data-Model-Driven way, where the Controller logic can be automatically deduced from the Data Model. Even a good part of the Views can be deduced from a good Model. As a matter of fact, in Joomla's MVC implementation, the Model already plays a predominant role, and the Controllers are often very empty "copy-pasted" shells. That copy-pasting indicates to me that they can clearly have a default implementation which can be valid for most uses with a few exceptions, where Custom-Controllers should be usable, to which there is no reason to impose an architecture, as precisely they are custom.

I welcome a lot Matthew's efforts to simplify things, but I also think that the same simplification of default controllers can be implemented independently of being single-task controllers.

Herman's class hierarchy example shows clearly the complexity and inherent dependencies and couplings of such classes. Nowadays, better than Class Inheritence, using Interfaces brings a better solution imho.

Best Regards to all,
Beat
http://www.joomlapolis.com/

[George Wilson]

I welcome a lot Matthew's efforts to simplify things, but I also think that the same simplification of default controllers can be implemented independently of being single-task controllers.

Whilst I understand the single task controllers are contentious I think we should be more open to them. I think they certainly bring a number of advantages (disadvantages as well of course - but par for the course). I found this quite an interesting read as a proposal for example https://github.com/pmjones/mvc-refinement

Anyhow my real point is that my GSOC project was to implement the new MVC and so at least to start with I'm going to be trying to implement the single task controllers. If things don't work out we'll go from there.....

Kind Regards,

George

[Mathew Lenning]

The fact of the matter is that the legacy MVC has been a sore in Joomla's side for well over 3 years now. If you say that you can build a better solution then go for it. I look forward to seeing your "zero specific controllers" BTW you should post a like to that pattern def as a google search didn't reveal any relevant literature. 

The problem with the old default controller theory isn't that it can't be done. The problem is that anything other than the default ends up being the legacy MVC 2.0 

If you have 5 views and three of the five need the same specialized functionality then you create 3 custom controller and copy paste the code to each one. Or you create a base controller that has all the functionality in it and three empty controllers that inherit from it. 

I'm sure this all sounds familiar. At least to anyone who has built a component with the Joomla! MVC. If you've been FOFing it, then your opinion in this debate is questionable. Because we are not trying to work around the problems with the current MVC, we are trying to fix them.

Now take the same example above in MVSC. 5 views 3 of which need the same specialized functionality. This is achieved with one and only one custom controller. Now say down

the line we decide that this feature is so good that we want to bring it into the core. 

Default controller style, we edit the default and HOPE it doesn't break anything. Of course we have to refactor any controller that extend the default or they won't benefit from the improvement.

MVSC style, we rename the class to use the Joomla prefix and merge to staging. 0 chance of breaking anything and every component build for Joomla can use it instantly. 

Now let's look at this from a code quality point of view. 

Default controller style is susceptible to scope creep.

Eventually someone is going to think it is OK for the c

 

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

[Mathew Lenning]

Sorry my fat finger hit the send button some how.

Anyway the point here is that the problems in Joomla MVC are part of the pattern. Traditional MVC requires strict quality controls to maintain integrity. In other project is seems to work only because there is one person policing PR's and anything that doesn't adhere to their original intent is rejected. Joomla as a community driven project will never have that type of control over it's MVC because depending on the person merging and their interpretation of MVC the interpretation of the original intent can also vary greatly.

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

--

[Herman Peeren]

Mathew, we agree upon the current/old/default/legacy MVC is not good and needs a fundamental change. In fact that change started with the "new" MVC two years ago, that is elaborated upon and interpreted by your proposal. We also agree that FOF is only a temporary work around, not a fundamental solution. We never disagreed on those points. I suppose most developers are on that same track.

But if someone has critical remarks about your proposal, then you react as if they defend the old system. Which probably is not the case, as most of us agree that Joomla's old MVC is not good. We are looking for better ways. Your solution has some good aspects, but is not optimal. A very strong point however is that you took the trouble to work it all out in code, while we still stay in the realm of theoretical arguments. For me, and probably some others too, it is not just theoretical, but in a research phase: I'm trying out other ways in my own applications. But it is not yet ready for publication. In my current research I have no controllers at all, so that is quite the opposite of what you propose, but doesn't look like the old way either. So although I know that the ultimate argument is to come with good code, I had some remarks about your proposal and hope we can prevent this will be committed to Joomla too quickly, before other, better proposals are ready. This obviously needs a bit more time. Thank you for stimulating us, but please don't confuse working together on something better with defending any old system.

[Mathew Lenning]

I'm sure that everyone agrees that the legacy MVC has a problem. But when people say "multi-task" controller, they are in fact supporting the very root of the legacy MVC problem. 

It isn't a code problem, it is a design problem. So if your intention is to keep the design (MVC) and just change the code, we'll be having this conversation in another 3 or 4 years depending on how quickly the reinvented wheel deteriorates. 

As for getting this in the core, reality is even if it did get in, it wouldn't be long before someone decided to go Computer Science Major on it and do something elegant (A.K.A complicated for the sake of being complicated) and then bail when they realized it was unmanageable. 

The proposed MVSC design although only a first draft, not only eliminated ALL of the problems in the legacy MVC, it does so in such a way that regardless of what direction Joomla takes, it can be adapted without refactoring the components that utilize it.

You want more time to build your "better" solution. I just don't see why it took 2 years for you to get started. 

With every release more and more code gets piled on top of a foundation that you yourself admit is broken. Every new feature will have to be refactored when "THE" solution finally arrives.

So putting this off to some undetermined future where your research and speculation finally produces one possible solution, when there is a working solution (albeit a POC) on the table is very frustrating. 

And I find it insulting that your only arguments against these controllers are "I like my controllers to multi-task." and "well there has to be a better way."

I don't know who actually was the first person to suggest single task controllers, but I'm willing to bet He/She has moved on to another project by now. 

The problem with the single task controller has nothing to do with its design, implementation or possible limitations. Every pattern has pros and cons.

The real problem with single task controllers is that they are not what you're used to. That's it. Nothing more, nothing less.

Anyway, as I said before, I look forward to seeing your working POC and any others that my proposal has stimulated. Fear of the unfamiliar is a powerful muse indeed. 

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

[Bakual]

I think your trying to convince people with the wrong arguments. Like this one you mentioned here which just isn't true.

If we wanted to add for example a "download" task to our current legacy multitask controller, we could just add a "download" method to it. There is zero risk of breaking anything with that. Like there is zero risk with creating a new single task controller "download" with your proposal. Also inherited classes would automatically get that method and could use it right away in a multi class controller, no need to do anything. There is no difference in that regard. So your example is just a bad one.

Also the question of creating (almost) empty shells of controller files isn't tied to single-task vs multi-task. It depends on the upstream logic where Joomla will look for a task method. FOF actually does that to my knowledge already with multitask controllers. As I understand it (I don't know FOF well) it just assumes you need a "list" controller if you have a plural view and loads it automatically if no controller is specified. Or a "form" controller if you're going to edit an item. You don't need single task controllers for that.

That doesn't mean at all that single task controllers aren't useful and even less that I want to keep the legacy MVCs. Don't get that wrong. I just think you're using the wrong examples when you try to convince people of your idea.

An interesting advantage which I personally see is that it would be much easier to have mixed views. Like a list where you can edit something in it. Or an item view which lists related (sub-)items in it. That's not as easy to do with current controllers because you would have the extend two of them at the same time to get all needed methods. Of course that's not possible and thus you end up copy-pasting the methods into your own controller. With single task controllers that would be easier I guess.

However there are patterns which would make that easy for multi task controllers as well.

On the other hand I have currently full control over what tasks are available for a given view. Namely only those available in my controller. I will not have this control with single task controllers as each task is available for each view. It depends on the model then, basically moving controller logic into the model how I see it.

Personally, I don't think the problem is with your proposal itself. It's more in the way you communicate your idea. You tend to tell people who critice your proposal that they just don't understand it, or that they fear new things, and similar threats. That's not going to help your cause. Especially not when you never met those people and don't know them.

I had the pleasure to listen for example to Herman Peeren during JAB last month and I can certainly tell you that he doesn't fear new technologies and ideas. You'd better listen carefully to his comments and watch your words when discussing. If not for his experience and knowledge, then at least out of respect of the other (certainly older!) person.

Your trying to set a new fundamental way of how Joomla works, and if you truly want to achieve this, you need to get as much support for it as you can. For that you need to be polite to the potential supporters. Otherwise you drive them away before they even invest an hour to study your proposal, read this thread and review your PR.

Kind regards

Thomas Hunziker

[Mathew Lenning]

@Thomas,

First you were obviously offended when I said,

Honestly the reason you don't see the benefit is because you still haven't grasped the principal concept here. That isn't your fault, I obviously haven't communicate it's significance accurately.

In the Single Task Controllers RFC thread. That is unfortunate. Now I don't expect you to answer the next question on this thread, but ask yourself honestly had you grasped the principal concept at that point in the conversation?

I can tell by your last comment that you have grasped the principal concept at this point. My intention was not to offend you which is why I took full responsibility at the end of that statement. 

Now on to your comments. 

Thank you for the counter example. Indeed adding the download function to the default controller would give inherited classes the ability to use it, but your claim that it wouldn't break anything is contingent on the assumption that none of the inheriting controller classes in all of the extensions in the JED directory haven't already implemented a download function. If you can reasonably insure that is the case and always will be the case, then I'll admit my original argument was inaccurate.  

Also the question of creating (almost) empty shells of controller files isn't tied to single-task vs multi-task. It depends on the upstream logic where Joomla will look for a task method.

I disagree with this interpretation of the problem. Your interpretation assumes that the root of the problem is in the implementation, when in fact the root problem is in the MVC pattern. If it was indeed simply an implementation issue then the problems Joomla is experiencing would be unique to Joomla. However that is not the case, MVC growing pains are common through the industry. 

 I have currently full control over what tasks are available for a given view. Namely only those available in my controller. I will not have this control with single task controllers as each task is available for each view.

This assumption is also incorrect. If you inherit from any core base class, then you have no control over methods and tasks available to your view. Of course this limitation also applies to single task controllers. 

The difference between multi-task controllers and MVSC in this aspect is simple.

In a multi-task design any deviation from the default requires overriding the method, thus increasing the possibility that changes in the future versions will have unexpected and/or negative side-effects. 

While MVSC controllers simply ignore the core task controller once you've built your own. So changes the core controllers HAVE ZERO side-effects.

It depends on the model then, basically moving controller logic into the model how I see it.

Again this is the difference between your interpretation of  MVC and mine. 

In your interpretation, the controller is responsible for the "doing", so logic in the controller is acceptable. 

In my interpretation the model is responsible for the "doing" and the controller is just a glorified postal clerk delivering letter to person whose name is on the envelope. 

 

Personally, I don't think the problem is with your proposal itself. It's more in the way you communicate your idea. You tend to tell people who critice your proposal that they just don't understand it, or that they fear new things, and similar threats. 

I'm glad to know that the "problem" isn't with my proposal or the idea behind it, but rather the problem is me. 

However I do want to make a few points in my defense.

1.The only people I told "You just don't understand it" to were the people that didn't understand it at the time. I also made sure to take responsibility for the gaps in their understanding. 

2.Since no one has actually presented a valid argument as to why these single-task controllers won't work, I can only assume that their motivation are an emotional response based on human nature. 

3.I also didn't say that you fear new things, I said you fear "CHANGE". This isn't something to be ashamed of. I fear change too. It is human nature to fear the unknown.

4.I'm not threatening anyone here. A threat requires two parts, a) a demand from the speaker to the listen, b) an explicit or implied negative consequence if that demand is not met. 

You'd better listen carefully to his (Herman) comments and watch your words when discussing.

This is a good example of a threat. The "You had better" at the beginning implies that there are negative consequence predicated on failure to comply.

 

if not for his experience and knowledge, then at least out of respect of the other (certainly older!) person.

Please don't assume that simply because I disagree with Herman's arguments that I haven't been listening. This applies equally for all of the people that have been active here and in the PR. 

Those points that have been made which are indeed aspects of this implementation that need to be address and are not more than personal preferences have helped improve babelu_lib substantially. These improvements haven't been included in the PR, because that wasn't the point of the PR. 

I've told Herman several times that I am very thankful for his input.

 

However if you are suggesting that  "I should accept someones input as the truth without contemplating the validity of said input because of their age, education level, or work history", then I will have to respectfully decline. 

I am not a "Yes Man", I spend a lot of time contemplating what people say and because I don't know who "you" are I have the ability to say what needs to be said. The idea that someones clout should be considered in such debates is just ridiculous. 

And finally,

Your trying to set a new fundamental way of how Joomla works, and if you truly want to achieve this, you need to get as much support for it as you can. For that you need to be polite to the potential supporters. 

First you are giving me too much credit here. This isn't my idea. As you mentioned yourself, there are already other single task controllers in the core. This implementation didn't just jump into my head one day out of the blue. It slowly formed from the hundred of conversations and debates that have taken place in this forum. It grew from the work done on other projects by people far more intelligent than myself and it materialized from the frustration that comes from trying to use the legacy MVC to do more than just CRUD. 

Although this proposal doesn't change the fundamental way that Joomla works, just the way we use it. 

If a prerequisite of its inclusion is that I learn to be a politician, campaign for support, and refrain from speaking my mind. Then the multi-taskers have nothing to worry about. As I've said before my hard headed nature is both a gift and a curse. 

Thanks for taking the time to post your response. 

[Herman Peeren]

I want to learn from this challenging communication. I will try to avoid anybody getting the impression being attacked. I like it when people have their own, not mainstream ideas and want to better communicate with them.

In my own components I'm not using a controller and use a Joomla plugin to dispatch the component, but I will leave that for another time. This is a discussion about the code Mathew provided. Let's see if we can contribute to its improvement.

In his POC I see several classes that do almost the same thing. I was thinking about how to refactor that. The repeating pattern I see in those classes is:

• check the permission: if (!$model->allowAction('core.bladibla'))
• get the input: do something with $ input, jform, $pk etc.
• execute the matching model-method
• set a redirection

I'm now playing with the idea of a mapper between actions, permissions and model methods: an Action2ModelMap object. If we have an Action2ModelMap $action, we can inject that in the constructor of a general ActionController. You then get a new ActionController($action), that can:

• check the $action->permission
• get the needed $action->input
• execute the $action->modelmethod
• set the $action->redirectionOnSuccess

Today I'm away and cannot work this out. But maybe it gives someone else some inspiration.

[Herman Peeren]

Two more thoughts before I leave for today:

• What I just called an Action2ModelMap object could better simply be called an Action object. Software modeling is about making complex things simple and Occam's razor should be the developer's primary tool.
• Does JControllerDispatcher need all the methods of JControllerCms or can we derive it from something higher in the hierarchy?

[Mathew Lenning]

@Herman

I cannot say for sure without opening up the IDE, but from memory there is nothing that the dispatcher needs from the base controller.

As for your other comment. I have been listening to your input and despite disagreeing with most of you assessment, I do agree that the save branch is a clumsy implementation. 

I'm experimenting now with the idea of task chaining as we've discussed in the GSoC board. But I haven't hit pay dirt yet.

I am against the idea of an action mapper. Because that is just added complexity that in my opinion adds nothing. 

The old adage "if all you have is a hammer then everything looks like a nail" applies equally to software programming. We can throw a million helper classes at every problem, but in this case I don't see the benefit is worth the added cost.

As is the design is infinitely expandable. This to me is a good quality. Adding a mapper would restrict if not eliminate that characteristic.

I believe the issue in the save branch can be resolved in the save branch or the dispatcher rather easily. Of course I cannot prove this until I've brain worked the solution.  

My design isn't perfect. This I know, but when compared to what we have (legacy) and what we don't (you and others POC) there is no contest. 

One thing that I haven't mentioned here is that MVSC doesn't prevent multi-task controllers. You could very easily implement  multi-task controller s the same way you do now using the JControllerCms base. 

The only difference is that the negative consequences of that implementation would be the developers problem and not the projects.

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

--

[Mathew Lenning]

Just one more observation here.

How come the majority of opposition to this proposal is coming from people who openly admit they don't use the legacy MVC?

While I'm glad you've broke free from the legacy, why not share your solution with the community?

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

On Jun 14, 2014, at 4:04 PM, Herman Peeren <herman...@gmail.com> wrote:

--

[Mathew Lenning]

Just wanted to make sure this conversation doesn't get forgotten.

Any progress reports on those multitask POC's?
Looking forward to seeing your solution Herman.

[Mathew Lenning]

After carful consideration I've decided to withdraw this proposal.

Since arguing for a solution that works NOW against a TO BE ANNOUNCED IN THE YET UNDETERMINED FUTURE solution that might work isn't a productive use of any of our time.

I've decided to let you all do your thing.

Herman Peereen, I do hope that you keep your word and provide the solution that you promised to create. After all accountability is JUST as important as memorizing GOF pattern definitions.

Happy Joomla!ng

[Andrew Eddie]

On Wednesday, 2 July 2014 14:44:00 UTC+10, Mathew Lenning wrote:

After carful consideration I've decided to withdraw this proposal.

Since arguing for a solution that works NOW against a TO BE ANNOUNCED IN THE YET UNDETERMINED FUTURE solution that might work isn't a productive use of any of our time.

Matthew, I'd encourage you to go with your gut instinct and "just do it". Cleaner patterns are needed - cleaner than both the current core and FoF (we need more than sugar). It's worth listening to Herman's advice but I'm still waiting for code examples he promised from many years ago :P The bottom line is that pull requests, not theorising, get considered for merging ;)

Regards,

Andrew Eddie

[George Wilson]

Andrew - I think you missed the point. Mathew until he withdrew that his proposal had a PR sitting on Github for nearly a month with his code on as well as an example conversion of weblinks to it ;)

Kind Regards,

George

--

[Andrew Eddie]

On 7 July 2014 20:05, George Wilson wrote:
> Andrew - I think you missed the point.

I don't think so - I sense a mutual level of frustration.

> Mathew until he withdrew that his
> proposal had a PR sitting on Github for nearly a month with his code on as
> well as an example conversion of weblinks to it ;)

A month is historically not unusual, and it's a big PR to review. All
I can say is I feel and share Matthew's pain.

Regards,
Andrew Eddie

[Mathew Lenning]

@Andrew

Thanks for the encouragement. You are correct that it wasn't really about the 1 month PR review. I figured something of this significance would take some time to move forward.

The frustration comes from the fact that this debate isn't about my code. The argument has all been single task VS multitask controllers, which was to my knowledge already decided by the community. 

I also find having copy/paste GOF quotes in every other reply to be very offensive. Who would have known =^P

However I haven't given up hope yet. It has become very clear that if I'm going to get anyone to actually read the code (not just look at the file structure or Git Diff), I need to convert a some of the core components. So that everyone can see what I see.

I would like to request that in next round of debates that full length quotes of GOF, or any other pattern catalog be substituted with page numbers. As code isn't the only thing that should be DRY. 

Thanks in advance. 

[Andrew Eddie]

On 9 July 2014 10:07, Mathew Lenning wrote:
> The frustration comes from the fact that this debate isn't about my code.
> The argument has all been single task VS multitask controllers, which was to
> my knowledge already decided by the community.

I hear you. Working in Node now has changed my perspective on this.
For what it's worth, I'd be looking at PHP Traits to decorate
controllers with behaviours (which probably means tending back towards
a multi-task controller - but I still think the work you have done is
not wasted).

> I also find having copy/paste GOF quotes in every other reply to be very
> offensive. Who would have known =^P

Yeah, it's pretty inane. I got the same reaction when we first
released 1.6 - "oh how terrible it is - look at all the duplicate
code". Well duh - the goal was to make all the code consistent and we
didn't realise how much duplication there was until we made all the
code consistent. A rather obvious chicken and egg problem but
whatever.

> However I haven't given up hope yet. It has become very clear that if I'm
> going to get anyone to actually read the code (not just look at the file
> structure or Git Diff), I need to convert a some of the core components. So
> that everyone can see what I see.

I think we are at a tipping point. My gut feeling is that new
architectural improvements are really wasted on the 3.x tree. From a
developers-driving-development point of view, the better path is to
start rebuilding the CMS from scratch under the banner of a 4.x dev
tree. I would ignore backward compatibility until the last minute.
Hopefully the code is so impressive, 3PD's will get on board and then
you start a project to provide a j3-to-j4 compatibility layer so dev's
write for j4 but can still market to j3.

Anyway, that's what I'd do but any attempt to sell that idea over the
past few years has failed :)

> I would like to request that in next round of debates that full length
> quotes of GOF, or any other pattern catalog be substituted with page
> numbers. As code isn't the only thing that should be DRY.

Don't get too hung up on DRY for the first pass (and just flat out
ignore people that are complaining about it). That, in my opinion, is
an optimisation you apply once you have the bones of the system
working, hopefully with everyone in awe of it's simplicity.

Regards,
Andrew Eddie

[Mathew Lenning]

I hear you. Working in Node now has changed my perspective on this.
For what it's worth, I'd be looking at PHP Traits to decorate
controllers with behaviours (which probably means tending back towards
a multi-task controller - but I still think the work you have done is
not wasted).

I don't have enough experience with traits to form an opinion on this approach, but the final determination for me would boil down to how easy it is to deviate from the default behavior.

Since we cannot possibly account for every use case, any approach must insure that it doesn't limit extension developers freedom of choice. I think this is one of the major problems with legacy MVC.

Doing anything, but the default, requires hackish type implementation that complicate the code for no other reason that to get past the unnatural limitation dictated by the MVC.

 

Yeah, it's pretty inane. I got the same reaction when we first
released 1.6 - "oh how terrible it is - look at all the duplicate
code". Well duh - the goal was to make all the code consistent and we
didn't realise how much duplication there was until we made all the
code consistent. A rather obvious chicken and egg problem but
whatever.

+1000 for someone that gets it. I've never built a perfect solution in one shot. POC are just to prove it can be done. I was hoping that once people saw what I was doing, a team effort would help smooth out the edges. 

I think we are at a tipping point. My gut feeling is that new
architectural improvements are really wasted on the 3.x tree. From a
developers-driving-development point of view, the better path is to
start rebuilding the CMS from scratch under the banner of a 4.x dev
tree. I would ignore backward compatibility until the last minute.
Hopefully the code is so impressive, 3PD's will get on board and then
you start a project to provide a j3-to-j4 compatibility layer so dev's
write for j4 but can still market to j3.

I feel the same tipping point as well. Either we evolve or we the project goes extinct, say for the die hard Joomla!sts. However any mention of decline in the popularity of Joomla is met with denial and delusion.

If we could get past that denial and accept that Joomla is losing ground, then we could move on to finding the reason that it is losing ground and address those issues. 

But instead, everyone seems content to live in their bubble and have faith that more features will save the day.   

I have mixed feeling about the idea of starting from scratch. While I know that that would probably be the path of less resistance, it would also require a seriously committed group of experienced developers who are dedicated to communicating on a weekly if not daily basis. Even then without the feedback loop from continual delivery or deployment or whatever its being called these days, hitting our mark would be extremely difficult.

As an extension developer, I would prefer a stagger development approach. I've attached a diagram that might clarify what I mean. It probably looks similar to what we are currently doing, but the difference would be that 3.x code does not change to accommodate 4.x code. And 4.x code isn't hampered by the BC commitment of the 3.x series.

Because there is not BC commitment, for the remainder of the 3.x series 4.x code it would only usable by core maintained extensions. However 3PD's would also be able to experiment freely, so long as they understood (and honored the rule) that it wasn't intended for public distribution. The benefit here is that the code could evolve naturally and 3PD feedback would expose areas of the design that need more flexibility.

In order for this to work, the project would have to communicate very clearly that 4.x code is a moving target and shouldn't be used in production. Also instead of setting some arbitrary release date for the 4.x series, we'd need to continue 3.x until the 4.x code is so impressive that no one (edge cases excluded) wants to use 3.x anymore. 

So long as we don't create dependencies between 3.x and 4.x the then when the transition comes, Joomla just drops the 3.x stuff from the release. Since 3PD's would have more than enough time to familiarize themselves with 4.x code base, and devise their own 3.x/4.x compatibility solutions, the project wouldn't have to worry about the compatibility layer. Also adoption rate for the 4.x series would be much higher from day one.

Of course this is the ideal scenario, which like most is easier said that done.  

 

Anyway, that's what I'd do but any attempt to sell that idea over the
past few years has failed :)

I would definitely welcome a 4.x playground in the main repository, even if its just for RFC's, having a place to discuss the future of Joomla would be nice.

Happy Joomla!ng

[Andrew Eddie]

On 10 July 2014 10:51, Mathew Lenning <> wrote:
> I don't have enough experience with traits to form an opinion on this
> approach, but the final determination for me would boil down to how easy it
> is to deviate from the default behavior.

I'm a bit the same, but the idea would be that you have a basic
component controller that handles, well, the basics. Then we need to
decide whether it's one controller per task, one controller per
"resource" (that is, for com_content, an article is a resource, a
category is a resource, etc), or one controller per "component" ... or
maybe a mix of each.

After that you can devise traits to handle different behaviours for
both controllers and models. So, for example, let's imagine we have
one-controller-per-resource. The articles controller in com_content
might look something like this:

class ContentArticleController extends ComponentController {
use PublishTrait;
use StateTrait;
use TagAwareTrait;
use ReorderTrait
}

In layman terms, that says extend my resource controller extends from
a basic Joomla ComponentController, and then it adds all the behaviour
to support resource publishing, changing state, tagging articles and
reordering (just to name a few). And theoretically that could be the
extent of the code. The CMS framework would take care of what those
traits mean and do. That's pretty slick if it could be pulled of.

> I feel the same tipping point as well. Either we evolve or we the project
> goes extinct, say for the die hard Joomla!sts. However any mention of
> decline in the popularity of Joomla is met with denial and delusion.

The problem is not so much popularity but that the experience that is
exiting via the back door is greater than the new blood coming in
through the front.

> As an extension developer, I would prefer a stagger development approach.
> I've attached a diagram that might clarify what I mean. It probably looks
> similar to what we are currently doing, but the difference would be that 3.x
> code does not change to accommodate 4.x code. And 4.x code isn't hampered by
> the BC commitment of the 3.x series.

I understand, but as I've been looking outside the Joomla ecosystem in
both the PHP and the NodeJS world, I've realised that our code is
woefully immature. To be honest, I think I'd just bit the bullet and
take the existing database schema for 3.x and wrap Laravel (maybe
Symfony if you wanted to take the approach of writing Joomla+Drupal
extensions) around it.

Now, that might require a product with a different name seeing as some
vocalists in the community feel they have a monopoly on what Joomla
means :P

> Because there is not BC commitment, for the remainder of the 3.x series 4.x
> code it would only usable by core maintained extensions.

Initially yes, but that's not my point. The point is to write the code
that makes sense with the technological horizon that is visible in
2014, not what ground-zero looked like when we released Joomla 1.5
(let's be honest, Joomla 3 is essentially designed to PHP 5.2
standards). After you get the design right, then you look at the cost
of backward compatibly and work out a bridging layer for the delta. We
know this works because this is exactly what we did with 1.0 to 1.5
and that worked better (in hindsight) than 1.5 to 1.6.

> However 3PD's would
> also be able to experiment freely, so long as they understood (and honored
> the rule) that it wasn't intended for public distribution. The benefit here
> is that the code could evolve naturally and 3PD feedback would expose areas
> of the design that need more flexibility.

I think people would buy the idea that 4.x is experimental with a view
that 5.x (being the child of 4.x) is what is intended for people when
3.x reaches it's used by date.

> In order for this to work, the project would have to communicate very
> clearly that 4.x code is a moving target and shouldn't be used in
> production.

What would be the problem of having a very long Alpha period? Could we
not commit today and say "Joomla 4 Alpha" is starting and that might
last for 12 months. During alpha, it is a moving target, then you get
to a point where there is a consensus and you say "ok, we are ready to
feature freeze and cut the betas".

> Also instead of setting some arbitrary release date for the 4.x
> series, we'd need to continue 3.x until the 4.x code is so impressive that
> no one (edge cases excluded) wants to use 3.x anymore.

More or less. That's going to happen naturally if you have Alpha's to
play with. Beta's are a signal that 3PD's should start paying
attention and that's when you start designing your bridging code for
3.x.

> So long as we don't create dependencies between 3.x and 4.x the then when
> the transition comes, Joomla just drops the 3.x stuff from the release.

Because the delta between PHP 5.2 and 5.4 is so large, I would just
assume that almost everything was going to be deprecated. I mean,
Joomla 4 is going to spend at least 6-12 months in a melting-pot alpha
state, and by the end of that time even newer things are available.

> Since 3PD's would have more than enough time to familiarize themselves with
> 4.x code base, and devise their own 3.x/4.x compatibility solutions, the
> project wouldn't have to worry about the compatibility layer. Also adoption
> rate for the 4.x series would be much higher from day one.

I get what you are saying, but my personal view is that the delta
between what 3 is and what 4 should be is quite large. Not to mention
4 really needs to address how we contend with themes based on
different CSS frameworks.

> I would definitely welcome a 4.x playground in the main repository, even if
> its just for RFC's, having a place to discuss the future of Joomla would be
> nice.

The https://github.com/joomla-projects/ repo would be the place. Just
have the PLT start an empty `joomla-4` repo and anyone should be able
to manage it from there. Have people fork that and start designing new
shells for the CMS using a number of different techniques. Make it a
competition if you like - the best one wins :)

If it was me I'd be looking at:

1. Rebuilding it in a mature off-the-shelf framework (Laravel is the
one I would seriously look at).
2. Consolidate the existing extension paradigm. Components should be
controllers and models only. Modules should do all the presentation
layer stuff. Plugins stay the same. Templates become themes and
address how to deal with modern day dependency hell. Languages may
need a revisit (.po is still not an option in my opinion though).
3. Become more "resource" centric that can support RESTful services
out of the box.
4. Adopt a mature ORM from the start.
5. Possibly expand beyond PHP (specifically Node).
6. Keep everything as modular as possible.
7. Cheat off the best bits that everyone else is doing :)

Pfft, about a days work you think?

Regards,
Andrew Eddie

[Mathew Lenning]

If this is a days work for you, then I am wayyyyyyy out of my league. lol

But I would definitely enjoy a little gamification. The heavy debates over MVSC for the last month or so have been no fun what-so-ever. 

Anyone else interested in a game of King/Queen of the CMS?

It might even be a good idea to break it down into specific bounded contexts and get back to the three tiered architecture (http://docs.joomla.org/File:JoomlaArchitecture0.png)

That would at least insure dependencies are limited to their tier. 

So I guess the only real question that needs to be answered before we could get tinkering is will the PLT give us an empty repo? 

[Matt Thomas]

While I can't representative the entire PLT, as we haven't discussed this specific topic, I would fully support something like this and would imagine other PLT members would as well. That being the case, I've initiated this request and hope to have an answer very soon.

Thanks all, this is exactly the kind of thing Joomla needs!

Best,

Matt Thomas
203.632.9322
http://betweenbrain.com/

Sent from mobile. Please pardon any typos or brevity.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

[Bakual]

However any mention of decline in the popularity of Joomla is met with denial and delusion. If we could get past that denial and accept that Joomla is losing ground, then we could move on to finding the reason that it is losing ground and address those issues. But instead, everyone seems content to live in their bubble and have faith that more features will save the day.   

Personally I strongly believe the main reason why Joomla looses some users to WordPress is the crazy upgrading we had between 1.5 and 1.6/2.5 and to a less degree 1.0 to 1.5. If you have to rebuild your site anyway and migrate the data, you can as well move to a new platform. It's not really more work. And if there is another platform which has a very strong B/C policy over years and an even bigger community, then it's basically a no-brainer to move to that platform (WordPress in this case).

That's why we adjusted the release strategy. We need to make sure the users get the safety that their money and time isn't thrown out of the window in 2 years. That's why we adopted SemVer to make our updates predictable and we are embracing backward compatibility. Imho that's a critical point for the success of Joomla in the future.

That being said I'm absolutely not against building a new Joomla from scratch. It well be the path we have to take sooner or later. But, and that is an absolutely important "but", we need to make sure the user doesn't note this. It must be possibly to update from the latest 3.x release to 4.0 using a simple button without majorly breaking the site. Using a legacy layer like in 1.5 would be one way. The other is to prepare everything in the latest 3.x release so up-to-date extensions will still work.

I don't see us doing the same thing again we did between 1.5 and 1.6. Breaking every extension and needing an external extension (JUpgrade, spUpgrade, ...) to migrate the data. That was a desaster and we're still trying to recover from that... Don't do the same mistake again.

Also on a sidenote: Don't expect extension developers to try and test the new Joomla until it's live and stable. There wasn't even good adoption for the 3.x STS releases, because they were STS. We don't even get good tests today with new minor releases. I know it's crazy but it's the way it is currently and I don't think that will change. Ideally yes, people should test out the new betas and report problems. In practice almost nobody does that. As sad as it is.
I'd assume with Joomla 4.0, you will get a lot of discussions about where to go and how the architecture should be done, but you will get no tests until Joomla 4.0.0 is released and then everyone will jump on you and complain that their extension broke :-)

[Bakual]

I don't see a single reason why we can't create a new repo in joomla-projects.
I wouldn't call it Joomla4 however. More something like Joomla-Next. It may well turn out that we need an intermediate step to get where we want. And the code in that repo will become Joomla 5 in the end. :)

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

[Andrew Eddie]

On 10 July 2014 16:07, Bakual <> wrote:
> Personally I strongly believe the main reason why Joomla looses some users
> to WordPress is the crazy upgrading we had between 1.5 and 1.6/2.5 and to a
> less degree 1.0 to 1.5.

Yes, but WordPress can't keep doing that forever. As soon as it's PHP
5.2 code stops being forward compatible, and that's going to happen,
it is going have to have the conversation about what to do with a
major upgrade.

For what it's worth though, since 1.6, the PHP code upgrades have been
very, very gentle. The template is the problem (2.5 and 3 aren't
compatible no matter how much we cheat to make the PHP run ok).

What would be really cool is to have the extensions designed in such a
ubiquitous manner that simply placing a special wrapper around them
allows them to run in WordPress, or Drupal, or ... :)

Regards,
Andrew Eddie

[Mathew Lenning]

Let's call the repo J-and-beyond

Joomla-next reminds me of Pepsi-next which personally I think tastes terrible.

Sincerely,
Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

> --
> You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/a5nU71UKrw8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.

> To post to this group, send an email to joomla-...@googlegroups.com.

[Bakual]

Let's start a discussion about how to name the repo now :-D

> To unsubscribe from this group and all its topics, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.

[Mathew Lenning]

Lol maybe a different thread =^D

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Matt Thomas]

To avoid any confusion, speculation, and hopefully minimize drama, a repository has been created at https://github.com/joomla-projects/icarus for this very purpose.

Thank you all for your contributions and dedication to the project. It will be exciting to see what the next chapter holds.

Best,

Matt Thomas

203.632.9322
http://betweenbrain.com/

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

[Mathew Lenning]

Awesome name! I feel so "special ops" right now. 

Let the games begin! 

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

[Matt Thomas]

I agree! Credit for the name goes to Tom Hutchison of the PLT. It's a great one.

I look forward to watching, and hopefully participating, in what is to come.

Best,

Matt Thomas

203.632.9322
http://betweenbrain.com/

[dgt41]

Build Icarus on top of Laravel? 

YES PLEASE!

Brilliant idea!

[Andrew Eddie]

Love it!

Regards,
Andrew Eddie

[wdburgdorf]

Please be very careful about how you communicate these developments, incl. naming. Please don't do it the way Typo 3 is doing it now: suicide. New Typo 3 called Phoenix. Old Typo 3 is ashes, new is not (yet) flying -> all dead.
Problem is, most users don't understand what's happening. So if it's badly communicated, user confused, looks elsewhere. Like, the other CMS, that is super popular, super simple, super powerful and has *no problems*, ever. Not all true, sure, but this is how I sometimes feel it's perceived by a non-negligible number of people (clients!).

[Beat]

Laravel has some brilliant ideas and some neat gems for sure. On the other side it is quite bloated with quite some "legacy" code due to wanting to implement things that were complicated before PHP5.4. If you study its inners, you will see that it's not as efficient code as we wish Joomla "Icarus" to be. I sure wouldn't call it a "mature" framework at this stage. It sure suffers also from framework-bloats.

So I'm all for taking some bits and pieces and ideas from Laravel, but I'm also to avoid its bloat at same time, and sure would do same from other major php frameworks, and also take a look at php5.4-based micro-frameworks. PHP 5.4 allows to do things with Closures, Traits and dependency injections natively in PHP 5.4, that require thousands of lines in dozens of libraries in earlier PHP versions, which e.g. Laraval and Symfony suport and are not needed anymore. I have looked at a dozen frameworks lately and didn't yet find a minimalist one yet that uses the native elegance of PHP 5.4.

So I'm saying great too, but not with closed eyes, and for sure taking in account guiding remarks from Thomas (Bakual).

Best Regards,
Beat
http://www.joomlapolis.com/

[Mathew Lenning]

The beauty of this game is we don't have to limit ourselves to any one option. Although it is just a thought bubble right now, personally I'm thinking of focusing on the UCM concept. 

I don't think I'll be using a third party framework, simply because most frameworks try to be everything for everyone. Which equals overly complex for no good reason.

I will of course be looking to them for inspiration in areas that are essential. 

For the time being can we just call this game the "Icarus challenge", so people don't misinterpret it's actual intent. Which is to have fun with the possibilities without the weight of "the future of Joomla" riding on it. 

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

--

[Andrew Eddie]

Beat, the idea is not to immediately jump in and poo-poo other
people's suggestions out of the gate (in return, I'll refrain from
elaborating why I completely disagree with almost everything you said
:P). Come up with your own solution and see how it stands with what
other people come up with.

Regards,
Andrew Eddie

[Andrew Eddie]

On 11 July 2014 22:27, wdburgdorf <laus...@gmail.com> wrote:
> Please be very careful about how you communicate these developments, incl.
> naming. Please don't do it the way Typo 3 is doing it now: suicide.

So what does communicating "carefully" look like? (I'm not aware of
what how Typo 3 did it)

Regards,
Andrew Eddie

[Andrew Eddie]

So, after a bit of research, I've come to a rather depressing
conclusion. I think using another, established framework is the way to
go, but for whatever major framework you choose, someone has already
built a modern (in terms of coding) CMS on top of it (for example, if
you chose Laravel as your framework, you'd be a fool to think of
reinventing October CMS from scratch). It would seem a waste of time
to build a better wheel that someone has already built. Or, we look at
merging with other projects. But I really can't see the value
proposition of modernising the code base into PHP 5.4 or 5.5 because
it's already been done a number of times.

We've really missed the boat in terms of showing that Joomla can lead
the way with modern coding practices and paradigms.

Regards,
Andrew Eddie

[Mathew Lenning]

After watching that demo video, I can say that Joomla! is definitely in trouble. 

Sincerely,
Mathew Lenning

Babel-University.com
406-626-3251
LinkedIn Profile

Regards,
Andrew Eddie

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/a5nU71UKrw8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send an email to joomla-...@googlegroups.com.

[Mathew Lenning]

After spending the day in October, I am positive that the tipping point we were discussing is much closer that I had originally thought. Less than 6 hours to duplicate 75% of my Joomla extension.

Laravel is definitely far more expressive than Joomla, but I think Joomla can still gain a competitive advantage on some key areas.

1. Low technical entry (Although October is a developers dream, the average Joe/Jane isn't going to be able to jump into it without some hardcore reading)

2. Superior ACL. Sander Potjer really did an amazing job on this feature.

3. Only one user system. ( October uses  a separate user system for front and back)

October wins on these points

1. Routing

2. Less opinionated implementations

3. Logical Ajax API (LOVE IT)

4. Clear coding standards with no exceptions to the rule (at least none that I've found yet)

5. Use of Yaml definitions for administrative lists, forms, component settings (you don't HAVE to code admin lists, although it is an option)

6. Extendable mail template system built-in

7. Clear concise documentation that isn't generated from doc blocks.

8. Twig

9. Markup

10. Distribution packages

11. Component selection on install.

12. Package Updater  

11. More than I can list reasonably 

To tell you the truth, it seems like October has implemented almost every feature I've seen debated to oblivion here in this forum, but haven't been able to implement properly because our legacy is holding us back.  

I think that Joomla needs to really figure out how it is going to compete with the next gen CMS.

 

These new CMS's are going to start taking talented developers from the Joomla pool, and once the talent is gone this or any other conversation is a moot point.

I'm sure there will be more than a few in deep denial screaming that Joomla is better than ever, but I think that has more to do with not looking at competing options that are becoming available. + Denial

 

[Roberto Segura]

As a lot of people can miss the discussion because the topic I've created a new thread:

https://groups.google.com/forum/#!topic/joomla-dev-cms/0VURcwpRu2I

And now using streetfighter words: fight!

[Mathew Lenning]

So despite myself, I cannot stand forcing my supporters to install yet another third party lib to use my components. 

So I decided to just throw my whole lib into a Joomla fork, so everyone can get the big picture. 

I started converting com_weblinks around 8 a.m. this morning and I have it working now. Save for batch and content history (because I didn't implement those features in my lib yet.)

I also removed the hard coded com_categories dependency with 3 lines in one of those unloved MVSC controllers. Here is what it looks like.

class Babelu_libControllerCategories extends Babelu_libControllerCms

{

public function execute()

{

$config = $this->config;

$this->setRedirect('index.php?option=com_categories&view=categories&extension=' . $config['option']);

return true;

}

}

Then in the weblink view I use:

'index.php?option=com_weblinks&task=categories' // used to be 'index.php?option=com_categories&extension=com_weblinks'

I didn't even have to touch com_categories =^P And now Joomla is free to replace com_categories, if/when it wants, without editing every component helper file. Even if you change the logic it doesn't matter. Why? Because the com_weblinks doesn't even know that com_categories exists. 

Anyway back to the IDE, I should have this finished by sundown.

[Andrew Eddie]

This may be a dumb question, but why don't we make the controllers
REST aware and add routing while we are at it. For example, having the
administrator recognise something like:

Show the weblinks list:
GET index.php/weblinks/

UI page to create a new weblink:
GET index.php/weblinks/new
Form sends POST index.php/weblinks

UI page to edit a weblink
GET index.php/weblinks/1/edit
Form sends PUT index.php/weblinks/1 and we use E-Tag for collision
control instead of check-in and check-out.

etc and so on.

I know this is diverting from the point of your proposal (single task
controllers), but the base controller could then become:

class AbstractResourceController implements ResouceControllerInterface{
public function __construct($router) {}
public function doGet() {}
public function doGetNew() {}
public function doGetEdit() {}
public function doPost() {}
public function doPut() {}
public function doDelete() {}
protected function initialise() { /* initialise the routes,
configure ACL, etc */ }
}

?


Regards,
Andrew Eddie

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/joomla-dev-cms/a5nU71UKrw8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> joomla-dev-cm...@googlegroups.com.

> To post to this group, send email to joomla-...@googlegroups.com.

[Mathew Lenning]

I definitely think RESTful should be a project goal, but that means changing the router right. 

The important point to this design was I didn't change anything, that wasn't already in my component directory. 

But if we are going to revamp routing, I would love to see something like 

JRoute::to(ControllerClass,array('option' => 'com_weblinks','id' =>$item->id));

[Mathew Lenning]

Regardless of this proposal or not, who ever coded the JLayout layouts, please re-factor so that you are not using the JViewLegacy interface in the layouts!

This just limits JLayouts capabilities for no good reason. 

[Andrew Eddie]

On 17 July 2014 13:13, Mathew Lenning <> wrote:
> I definitely think RESTful should be a project goal, but that means changing
> the router right.

It means making that a dependency for the CMS to support, while still
allowing legacy components (aka, what we have now) to work.

> The important point to this design was I didn't change anything, that wasn't
> already in my component directory.

Sure, but if we are going to change things, would it be better to go
for the best solution? (just asking)

> But if we are going to revamp routing, I would love to see something like
>
> JRoute::to(ControllerClass,array('option' => 'com_weblinks','id'
> =>$item->id));

No, what you do is throw away the route builder and always use the
correct routes in your output. You then register those routes to point
to a controller. We'd have to play around with a few ideas in that
regard (Don's had a few).

Does that make sense?

Regards,
Andrew Eddie

[Michael Babker]

Actually, the JLayout interface was copied from the "new MVC" JView interface only changing the render() method to accept data - https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/view/view.php

On Wed, Jul 16, 2014 at 11:21 PM, Mathew Lenning <mathew....@gmail.com> wrote:

Regardless of this proposal or not, who ever coded the JLayout layouts, please re-factor so that you are not using the JViewLegacy interface in the layouts!

This just limits JLayouts capabilities for no good reason. 

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

[Mathew Lenning]

It isn't the interface its the layouts themselves. 

root/layouts/joomla/edit/title_alias.php

<?php

/**

 * @package     Joomla.Cms

 * @subpackage  Layout

 *

 * @copyright   Copyright (C) 2005 - 2014 Open Source Matters, Inc. All rights reserved.

 * @license     GNU General Public License version 2 or later; see LICENSE.txt

 */

defined('JPATH_BASE') or die;

$form = $displayData->getForm(); //$displayData is instance of JViewLegacy

$title = $form->getField('title') ? 'title' : ($form->getField('name') ? 'name' : '');

?>

<div class="form-inline form-inline-header">

<?php

echo $title ? $form->renderField($title) : '';

echo $form->renderField('alias');

?>

</div>

It gets worse. root/layouts/joomla/edit/params.php

Takes the view, then passes the view to root/layouts/joomla/edit/fieldset after adding dynamically adding a  fieldset to it.

$displayData->fieldset = $name; //line 75

echo JLayoutHelper::render('joomla.edit.fieldset', $displayData);

Friends should not let friends send views to layouts from other layouts. 

Basically what this means is the dev either have to use the legacy or know/implement every interface that is being used directly by every layout and know/implement every class property called directly ($hiddenFeildsets, $ignore_fieldsets, $ignore_fields, $extra_fields, etc... etc..) or spend the day looking at the fatal error screen. 

Coupling new systems to legacy systems is sooooooooooooo not cool. 

[Andrew Eddie]

I did mention that the view layer needs a complete re-think (again)
going forward, didn't I? ;)

Regards,
Andrew Eddie

> You received this message because you are subscribed to a topic in the

> Google Groups "Joomla! CMS Development" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/joomla-dev-cms/a5nU71UKrw8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Mathew Lenning]

> The important point to this design was I didn't change anything, that wasn't
> already in my component directory.

Sure, but if we are going to change things, would it be better to go
for the best solution? (just asking)

To me the best solution is the one that solves our problems now, and doesn't limit our ability to change in the future.

Since MVSC 

1. Doesn't change the outer system 
2. Eliminates empty class definitions
3. Doesn't break B/C what-so-ever
4. Eliminates the insanity that is legacy MVC
5. And most importantly "It works now" 

It won't limit our options when someone finally gets around to building "The best" solution.

If we can convince everyone to stop building new features on the dysfunctional legacy and focus on creating the super solution then I'm down.

But if the verdict is "Ya that works, but we want the best solutions, so lets just keep using the root of all our problems (legacy MVC) to build more technical debt until the best solution comes around." 

Then honestly a fork is the only real chance Joomla has in my opinion.

[Mathew Lenning]

I was thinking about Icarus ( note my previous comments were for 3.x)

You said that we should use modules as views right, but why not consolidate the module/component concept and rethink page composition? Something along the lines of component anywhere.

Sincerely,
Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

> To post to this group, send an email to joomla-...@googlegroups.com.

[Mathew Lenning]

To be honest I would be happy if my design just became the new legacy in 4.0

At least we'd be refactoring to 4 from a reasonable level of complexity and a consistent structure.

Sincerely,
Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

> To post to this group, send an email to joomla-...@googlegroups.com.

[Andrew Eddie]

On 17 July 2014 14:42, Mathew Lenning <> wrote:
> To me the best solution is the one that solves our problems now, and doesn't
> limit our ability to change in the future.

I get that, but the reality is there are only a handful of us that
realise that code needs to change and are willing to do something
about it. 99% of the developer community doesn't care or is prepared
to make war against changes like this either out of shear ignorance or
for profitability reasons. I've also played the "change slowly,
slowly" game for years and each time it ends in shear frustration.

> Since MVSC
>
> Doesn't change the outer system
> Eliminates empty class definitions
> Doesn't break B/C what-so-ever
> Eliminates the insanity that is legacy MVC
> And most importantly "It works now"

I get that, but I think you risk it becoming another FoF (added but
not really embraced).

> It won't limit our options when someone finally gets around to building "The
> best" solution.
>
> If we can convince everyone to stop building new features on the
> dysfunctional legacy and focus on creating the super solution then I'm down.

Can/should/would that be what Icarus is?

> But if the verdict is "Ya that works, but we want the best solutions, so
> lets just keep using the root of all our problems (legacy MVC) to build more
> technical debt until the best solution comes around."
> Then honestly a fork is the only real chance Joomla has in my opinion.

I have no problem with the ideas, I just personally don't want to do
yet another bandaid.

Regards,
Andrew Eddie

[Mathew Lenning]

I can understand how you feel. You've been on this battle ground wayyyy longer than me.

But how can we evolve without changing. I see so much untapped potential within Joomla (the CMS), but until the legacy is in the past, any attempt to release that potential falls short and produces more debt.

As is Joomla is too complex to move forward. Every addition is painful, unstable, unpredictable and unsatisfying.

Things don't break with every update because the coders don't care or the testers didn't test. They break because the system is unpredictable.

Although my MVSC might be just another bandaid, it is predictable.

It takes customization out of the controller and consolidates it in the business layer.

It proves that you don't have to change much to see real improvement in the system.

It also doesn't threaten or exclude FOF or any of the other third party libraries that have been build to avoid the Legacy MVC.

As is we have single task and multitask controllers in the core. Copy/Paste as a convention, components using components as if they were part of the framework, component tables in the libraries, Symphony in a sub folder of the framework library folder, partially implemented observer/observer mapper paired pattern design (beat might have finished it by now)

Plenty of change, very little improvement. Building a component for Joomla that does anything but basic crud is still like pulling teeth.

Every time I brought this up in the past, I was told that code talks and BS walks (paraphrasing) So this time I came with code that was clean, to the point, and works. But apparently it isn't good enough because I used the single task concept that the community decided was the next MVC.

It makes not difference that single task controllers are already being used in the core. It makes no difference that this design overcomes the "breeds like rabbits" issue, or that it opens the door for better integration between components without creating explicit dependancies, or fits nicely with the UCM.

So there really isn't anything that I have to offer.

Sincerely,
Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

> --
> You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/a5nU71UKrw8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.

> To post to this group, send an email to joomla-...@googlegroups.com.

[Andrew Eddie]

On 17 July 2014 14:48, Mathew Lenning <> wrote:
> I was thinking about Icarus ( note my previous comments were for 3.x)
>
> You said that we should use modules as views right, but why not consolidate the module/component concept and rethink page composition? Something along the lines of component anywhere.

I would, but in order to run an Icarus extension in Joomla 3 (and I'm
suggesting we should be able to run these things in parallel to get
around the B/C issues), we need to support the current page paradigm
(which sucks but one step at a time).

Regards,
Andrew Eddie

[Bakual]

It's not really the fault of JLayouts. It's just that some layouts are not coded ideally. But that happens when different developers try to implement a new feature. Everyone does it a bit different. At first, it may sound handy to pass "$this" into the JLayout $displayData. But as you said it's not a good idea.

If you look at later implementations of JLayouts you shouldn't see that anymore.

Roberto Segura is the main developer behind JLayouts and he does a great job improving it. If you have ideas, make sure to contact him.

If you want to improve existing layouts, feel free to send a PR (and make sure it's B/C).

[Bakual]

Nobody wants to stick on the old MVC for the sake of it. The only reason it is still used is because the new one just isn't useable yet. Because currently every extension would have to rebuild the wheel more or less from scratch. While the old one is known and ready to be used (even with its known flaws).

That hopefully is going to change with Georges GSoC project this summer. I'm sure as soon as the new classes are ready and a standard has established with the core extensions, people will start using it. Speaking for myself, I will for sure change my extension to use it. Even if it is just to detect the new flaws and problems it will bring :-)

[Mathew Lenning]

That's the thing. I rebuilt the wheel for you. I also did it in such a way that you can choose the size and shape of the wheel, the color, all season or low pro the choice is yours. 

Did you even look at the models? The views? The table? The first conversion of weblinks had 36 changes. That was the minimum investment to convert (of course I cheated by dirtying the design with the interfaces the layouts expected)

I built out all the major functionality publish state, ordering, save, save2copy, save2new, delete, cancel, etc..., etc... 

I even threw in built in CSV import/export that works with the session list filtering already in the model and complete decoupling of com_categories from the view. 

I respect George, because he's the only one who actually looked past the  controller folder, but I see a lot of the old MVC in his current draft, which is why I'm trying again. 

After this attempt to help you see, if no one can honestly see the benefit, well at least I'll be well on my way to a fork. 

When dev's figure out that they can build extensions as they always have - insanity, in a community that respects their skills.

 I'm sure something good will come of it.

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

[Mathew Lenning]

Well JLayouts was fun. I'm sure there is probably some regression, but since I never used this feature, I cannot say beyond the stuff I purposefully excluded (batch, content history)

back-end finished

Files removals

com_weblinks/controllers/weblink
com_weblinks/controllers/weblinks

com_weblinks/models/weblinks

com_weblinks/views/weblinks/view.html.php

Files Added

com_weblinks/helper/sidebar.php

My wrist is killing me, so I'm going to call it a night. I'll finish up the front-end tomorrow night. 2 days per component * 28 = 56 days. Almost there right. 

[Søren Beck Jensen]

Mathew, are you coordinating this work with George? Just so he is not wasting his time doing the same in his GSoC project. Good work!

--

Soren Beck Jensen

Director

so...@notwebdesign.com

Phone: +34 958 82 82 01

Not Web Design is part of Jensen Technologies S.L.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

[Mathew Lenning]

No, this is using the lib I already built. I just threw it into the libraries folder and started converting.

George has a different approach, so adding these to the CMS lib would just get in his way. 

He'll probably be able to convert these a lot easier that the legacy MVC versions when I'm done. There are a few magic tricks in my lib that probably would have to be implemented in the core for him to get the full benefit, but he has a copy of the babelu_lib, so it won't be a surprise. 

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/a5nU71UKrw8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.

[Mathew Lenning]

Well it looks like my initial estimate was too optimistic. administrator = no problem, front-end = WTF

Looks like I'll be spending the next week (or five) rebuilding the category implementation. I'm really amazed that someone actually made this work.(Intended as a compliment)

Since there is no chance in hell of doing this B/C, I'm think a new component will probably be the best option. Since com_categories is taken, anyone have any ideas for a good name? 

Off the top of my head I'm thinking

com_category ( singular which doesn't fit the standard)

com_jcategories (closer)

com_sections (too J1.5?)

com_branches (too Arbor day?)