JController Interface. Where are the new implementations?

[RC3 Media]

Im working on updating a component to be compatible with joomla 3, I have been going through the depricated list and exploring the framework to become familiar with changes. Im not seeing any implementations that would replace JController(now an interface) besides using legacy classes. JControllerBase doesnt implement any controller functionality and its the only implementation that i can find of a controller in joomla 3 12.1 framework.

Where have the controllers gone???

The new com_content is using the legacy controller so i may be jumping the gun on this one, if not can someone point me to where they are.

Do I have to code my components base controller to extend JControllerBase and add default functionality (add,save,delete,publish....etc).

I dont want to use any legacy classes in my upgraded component, and have no need for backwards compatibility(internal use only).

[RC3 Media]

I seems that in the 12.1 MVC controllers, the default content functionality(save,add,edit,etc) has been decoupled from the platform and is left up to the component developer. Read it here(the site says 11.3 but this is whats going on in 12.1):

http://developer.joomla.org/manual/chap-Joomla_Platform_Manual-MVC.html

Controllers became more specific, one controller per task, ability to chain controllers.  It looks like im going to be chopping up my old controllers task functions into their own classes.

Who here has upgraded a component without using legacy classes?

I think it would be nice to have a set of controllers that handle all the tasks in JControllerLegacyAdmin.
heres an incomplete list:
JControllerCMSChageState
JControllerCMSFeature
JControllerCMSAdd
JControllerCMSDelete
JControllerCMSDisplay
JControllerCMSCheckin
JControllerCMSSave
ETC.... all the functionality of the most priveleged class JControllerLegacyAdmin
I suppose they would go in cms/controllers.
You would extend them in your own components only needing to override the variable that stores the name of the model the task is being performed against.

[RC3 Media]

Just noticed that there are no controllers in Joomla 3 that use the new JControllerBase? Nothing to cheat from ;)

Alot of questions pop in my head!

Whys joomla not using this yet?

do we now have to manage what the controller used to manage in task mapping, perform task to class mapping in our components entry point file.

In 2.5 task requests have dot notation like '?option=com_mycom&task=controllername.task', since the only controller task is execute will we have to use a request variable "&controller=controllername" to ensure the request executes the correct controller. it would be silly to use "task=tasknameone.execute"
"task=tasknametwo.execute"

There used to be some kind of expectation of certain function names to look for because of the base class functions, now anyone can just name tasks whatever they like.

All that said I like the simplicity and HMVC capabilities of the new controller, its just too simple for use in the cms obviously cause none of the joom 3 components use it.

I know its Alpha but lets please start the discussion.

[Rouven Weßling]

On 24.08.2012, at 03:23, RC3 Media <rcel...@gmail.com> wrote:

> Whys joomla not using this yet?

No time. We've had more important fish to fry so far and the switch to the new MVC will take some planning. We'll probably use the installation as a scape goat first to gain some experience.

> do we now have to manage what the controller used to manage in task mapping, perform task to class mapping in our components entry point file.

If you wanna use the new MVC now, yes. You basically have to do it all yourself. It's not for the faint of heart.

> In 2.5 task requests have dot notation like '?option=com_mycom&task=controllername.task', since the only controller task is execute will we have to use a request variable "&controller=controllername" to ensure the request executes the correct controller. it would be silly to use "task=tasknameone.execute"
> "task=tasknametwo.execute"
>
> There used to be some kind of expectation of certain function names to look for because of the base class functions, now anyone can just name tasks whatever they like.

Eventually we'll have controllers for CRUD operations in the libraries. But not for 3.0.

> All that said I like the simplicity and HMVC capabilities of the new controller, its just too simple for use in the cms obviously cause none of the joom 3 components use it.

I wouldn't suggest using them for extensions yet. If you do you're kinda on you're own. That said if some people are willing to experiment with them that'd be quite valuable.

Best regards
Rouven

[elin]

The CMS has 37 components which all have to be refactored not to mention that third party components would all break.  Also at this moment you can't render things from new and old mvc on the same page.  The CMS has millions of users whose sites can't break so it can't rush into anything.

There are examples of how to use the new MVC in platform applications. Stefan's GSoC application shows how to do the controllers.  
https://github.com/stefanneculai/Web-service-API/tree/master/code/controller/v1/json

There are others too if you look in different people's repositories. 

If you want to start work on the needed classes for the CMS that would be great, just start sending pull requests. These would not go in the legacy folder they would go in the cms folder. The legacy folder is currently for things that will be removed in JCMS v4. 

Elin

[Rouven Weßling]

On 24.08.2012, at 15:18, elin <elin....@gmail.com> wrote:

Also at this moment you can't render things from new and old mvc on the same page. 

I don't think that's true. Thanks to renaming the classes to the *Legacy names I don't see why we can't combine them in one page load.

However one components should probably use only either the new or the old MVC and not mix the two.

Rouven

[elin]

Oh that makes sense, I was just going by memory of that long thread about this.

Elin

[reynaldo celaya III]

Thank you @Rouven this is actually great news that the new mvc & controllers are still in their infancy because i have a need for hmvc, nesting controllers, transaction aware, dependancy aware, overall more capable controller base classes for the cms.

@elin thats alot of contributing - 37 components.....unfortunately I have to be self serving in my contributions. I have great interest in improving the core platform and cms mvc because I have used joomla as a starting point for building services and applications not just websites. I hope i didnt come off as a complainer, i have the means funding and abilities to do something about it. Thanks for that link btw.

It seems like i will fork off in my own direction if i dont start contributing. Ill just use legacy for now in my component and start new development hand in hand with the CMS/platform developers.

Is there an existing RFC on the new mvc or list of desired functionality that the community as a whole would like to see?
For people familiar with using other frameworks, what desired traits/behavior do you find that these frameworks have that joomla is lacking?
If there is no existing list/discussion lets find out first who here is capable of discussing architecture.

Who is responsible for the current controller/model/view code in the platform 12.1?

I know there are a ton of other immediate projects so im not trying to get help other than direction from decision makers in the community.

For now Ill fork on git and await direction. Anyone have objections to me starting to build in /libraries/cms/controllers?

[Sam Moffatt]

The entire point of the *Legacy stuff was to support having them both
on the same page and with 2.5 being forwards compatible you could
rename stuff to *Legacy to be 2.5/3.x compatible. It is certainly true
that an unmodified extension expecting the Legacy versions of the
class with the old name will have issues if both load on the same
page, however adding 'Legacy' to the extends resolves the problem.

Cheers,

Sam Moffatt
http://pasamio.id.au

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/2CwuYysvyL4J.
>
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[elin]

The cool thing is that no one needs to do all of them, lots of people need to do pieces of this.  Right now most CMS people are more focused on getting through the next few weeks.

What I think we need if the goal is to migrate J3 all or part to the new mvc  (which may or may not be a reasonable goal, but if people think it is then great let's go for it) is to think about what child classes are needed to make migrating as smart and straightforward as possible.  So if you look at the legacy  folder model, view and controller subclasses like JControllerForm, we need replacements for them using the 1 task/1 controller pattern.  We also need models to replace JModelList etc.  it's really a library project that is needed before we can get too far along with actually moving the CMS components ... and it is the cms library project that is going to make it easy for all cms developers to switch when things are ready.

So you expressed an interest in the controllers, how about picking that as an area to focus on? Maybe work on building out a general save or delete controller for example? 

If you want to talk more about the platform itself the place to do that is on the platform mailing list. There is already a long thread that I clearly have mainly repressed the details of :P about it both on list and in the tracker. Louis and others explained a lot of the concepts in various places.

Also from the needs you are describing it sounds like you perhaps need to break out of the CMS and build directly on the platform, which is way easier and much more flexible if you are building something specific.  Encouraging people to be bold in  doing that is part of the point of separating the platform distribution off -- most web applications do not belong inside of a content management system--if you aren't mainly managing content think about if it really makes sense.

Elin

[reynaldo celaya III]

[reynaldo celaya III]

sorry i accidentally posted nothing that last post....

Im finishing up updating my real estate component to joom3 and will begin creating base controller classes.

[Donald Gilbert]

Today I began looking at the new platform interfaces for controllers, models, and views and ready through the whole platform manual. (It was a slow day at work.) That really opened my eyes to see just how these things could go. I really like the possibilities that are coming, but I do have a few concerns. Mainly, I just don't get why a controller can only have a single task, named execute. I mean, couldn't you have the execute method route to different save, apply, save2new, save2copy methods within the same controller, and still keep the desired functionality of the execute method either returning true on success or false on failure? At that point, the controller keeps it's job, which is routing the request to the proper parts of the model, and then passing the retrieved model data off to the view. I think that could work.

I started off with a dummy component today and this is what I came up with for basic folder structure and registering classes to the autoloader.

/components/

    - /com_profiles/

        - profiles.php // <---- contains call to JLoader::registerPrefix('Profiles', __DIR__);

        - /controller/

            - controller.php // <---- class ProfilesController extends JControllerBase (has the execute method and other "universal component methods"

            - list.php // <---- class ProfilesControllerList extends ProfilesController

            - detail.php // <---- class named ProfilesControllerDetail that extends ProfilesController

            - edit.php // <---- class named ProfilesControllerEdit that extends ProfilesController

        - /model/

            - model.php // <---- class ProfilesModel extends JModelDatabase

        - /view/

            - view.php // <---- class ProfilesView extends JViewHtml

As you can see, since we are using the registerPrefix of the JLoader class autoloader, the structure of the component is very similar to that of the Joomla Platform folder.

[Rouven Weßling]

On 25.08.2012, at 08:09, Donald Gilbert <dilber...@gmail.com> wrote:

> Today I began looking at the new platform interfaces for controllers, models, and views and ready through the whole platform manual. (It was a slow day at work.) That really opened my eyes to see just how these things could go. I really like the possibilities that are coming, but I do have a few concerns. Mainly, I just don't get why a controller can only have a single task, named execute. I mean, couldn't you have the execute method route to different save, apply, save2new, save2copy methods within the same controller, and still keep the desired functionality of the execute method either returning true on success or false on failure? At that point, the controller keeps it's job, which is routing the request to the proper parts of the model, and then passing the retrieved model data off to the view. I think that could work.

The idea is to have one task per controller. The name of that task is than part of the controller name. This allows chaining controllers easily.

Rouven

[elin]

Once you start really working with it the name/task linkage like a lot of the naming convention patterns in Joomla makes things much simpler and more obvious. 

You have to also keep in mind that it's kind of not the perfect fit with the content model of the cms which is why I'm way more focused on thinking about how J4 looks when we don't have a million com_whatevers for individual content types, we just have JContent and one save, one delete, one checking etc.  

Elin

[Donald Gilbert]

It seems really weird though to take away the job of the controller, which is routing requests to the model and then passing the retrieved data to the view, and basically turning the controller into a wrapper for the execute function. At that point, we should refactor the CMS to simple call functions, like, profiles_controller_execute() and profiles_controller_list_execute(). It doesn't make sense when you put it that way, but it seems to me that is exactly what's happening. But I've been wrong before.

Is there a roadmap for J4? I'd love to see it.

[Rouven Weßling]

On 26.08.2012, at 15:59, Donald Gilbert <dilber...@gmail.com> wrote:

> It seems really weird though to take away the job of the controller, which is routing requests to the model and then passing the retrieved data to the view, and basically turning the controller into a wrapper for the execute function. At that point, we should refactor the CMS to simple call functions, like, profiles_controller_execute() and profiles_controller_list_execute(). It doesn't make sense when you put it that way, but it seems to me that is exactly what's happening. But I've been wrong before.

I'm not sure I can follow you. The controller basically is the execute method. Just imagine all the task of something like JControllerAdmin are each in their own class. The responsibility of the layers doesn't change due to this.

Rouven

[Donald Gilbert]

That's what I am saying. The beauty of a class in php is that it encapsulates many methods, and (traditionally) routes a request to any one of those methods. With the "one task per controller" idea, you are basically removing the ability of the controller class to have any other methods besides execute, in essence eliminating it's functionality as a class. You could accomplish the same thing with a standalone function. (If I'm following your "controller basically IS the execute method" statement correctly.) That's why I am getting confused as to the reasoning behind the "one task per controller" idea.

Maybe I just need further explanation. I'm sure there's a discussion thread somewhere where this idea was proposed and accepted. I'd like to read that and see just what I am not understanding. Do you know where that would be?

Also, you said earlier you're looking forward to JCMS 4, which will drop com_whatevers altogether. I'd like to read the background on that as well.

[Rouven Weßling]

On 26.08.2012, at 23:03, Donald Gilbert <dilber...@gmail.com> wrote:

> Maybe I just need further explanation. I'm sure there's a discussion thread somewhere where this idea was proposed and accepted. I'd like to read that and see just what I am not understanding. Do you know where that would be?

The platform discussion can be found here: https://github.com/joomla/joomla-platform/pull/1120

Note that it derails quickly into a debate about the naming of the interfaces.

> Also, you said earlier you're looking forward to JCMS 4, which will drop com_whatevers altogether. I'd like to read the background on that as well.

That was Elin not me. She's referring unified content model we hope to use in the future. There has been a lot of debate about this one but the details are still up in the air. Off the top of my head I don't have a link though.

Best regards
Rouven

[Donald Gilbert]

Funny I actually made the last comment on that thread the other day, but I made it directly on the commit instead of in the discussion thread and had no idea what wealth of knowledge lay right at my fingertips. :) Thanks for the link.

---

After reading about half of that, I can see how the discussion digresses very quickly. :)

[piotr_cz]

Some examples of new JController usage
https://github.com/joomla/joomla-platform/pull/1259#issuecomment-6207480

[Viet Vu]

@piotr_cz 

Good link, thanks.

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

[Donald Gilbert]

Very good link and very helpful. I guess we'll see what the CMS plans to do with these great changes and we'll go from there.

[Andrew Eddie]

The new MVC comes into it's own with new, ground-up applications (for example, a web services platform).  In the current CMS and extension architecture, it makes sense to stick with a multi-task controller.  That's because different types of content are handled individually with different components.  In the future, maybe, all content is handled by one component, or something like a component, and that's where you get the economies of having one-task-per-controller (because you, for example, only have one "save" controller for all types of content).

The new controllers are also intended to respond to the router more directly, though, you can of course do whatever you like.  So, I would err away from thinking "dot notation" and do something closer to a web API practice, for example:

?options=com_foo&route=/do/something/cool/123

There is a new router class, albeit in the application package, that you could use to map the route to a controller.  Couple that with a REST ideology and it starts to become quite powerful.  But, yes, the controllers do tend to breed like rabbits, but that is not necessarily a bad thing.  Anyone looking at the code tree is going to immediately see what the application (or sub-application, being a component) is trying to do.  It becomes more or less self documenting because all your controllers represent the entry points for requests.  Compare that to trying to wade through nested switch ($task) blocks.

As Elin suggests, have a look at what Stephan has done.  It will give you an idea about what might be possible (and you should be able to clearly see what the application is capable of just by scanning the /code/controllers folder).  You'll also notice the folder and class naming of the controllers is tightly coupled, for obvious reasons.

The thing you also need to take into account is if you start using the new MVC, you are locking your extensions into Joomla 3 and above.  If you want extensions compatible with 2.5 and 3+, you'll need to stick with the legacy classes.

Hope that sort of helps.

Regards,

Andrew Eddie

[piotr_cz]

Others pointed out that it may take time until CMS will adopt new MVC.
Learning basing on existing code would be most convenient way, but I
can't see this happening soon. New MVC comes along with Unified
content model, new routers and other stuff.
We have to figure out ourselves: check existing examples (see first
elin's post), bits of documentation, pull the sleeves and experiment.

New stuff is quite a change in thinking for me but I believe this is
needed for a switch from CMS centered platform to multi purpose. New
stuff not being implemented in CMS has one advantage: there are
possibilities for some adjustments and tuning without breaking current
CMS.

[elin]

+1, I'd really suggest that the best thing it to be forward looking, learn to use the new MVC so we can build a totally amazing and ground breaking J4. Doing it piecemeal in the current CMS (except to the extent that things are backported from J4) to me just seems like an inefficient use of time. 

I facilitated the UCM session at the road map meeting at JAB which really turned into more of a J4  vision meeting.  We gave lightning talks before the meetings to more or less encourage people to come.  I asked Mark and Andy if it was okay for me to be opinionated in my talk and they said go for it, it will probably get people interested in talking.  So here are the slides I had, and if anyone is interested in participating in some  collaborative experimentation with the newer classes and the current eBaySF repo for JContent (I know, I know updates coming but that's what we have right now) with an eye toward getting ready for J4 please contact me and once J3 hits beta I'll email about it.

https://docs.google.com/presentation/d/1OG2GG3ZJ3dVVsoZTDGS1goxM34fo_2KL1RUIkdOOUnA/edit

Elin

[Amy Stephen]

No one should feel like they should ask for permission to share their honest opinions on Joomla. Let's just be open and know that alternative ideas and opinions should not be taken personally, in fact, that's kind of the point of community driven approaches.

I watched the video and agree with many observations about weaknesses in the application. I don't agree with some of the thoughts about solving those problems, but it was good to finally see recognition of concerns many of us were expressing during 1.6.

The project needs an *architect* to draft the data model and application elements. Someone with real world training and experience in application development could make a big difference moving forward. Maybe that's Louis? I don't know, but the blueprint of how the CMS is rebuilt should be entrusted to someone with these skills.

[hoochicken]

I'm planning an component. Is it recommended to use the old MVC of J! 2.5?
Or would you recommend using the new MVC for J! 3.0 (though the core not yet uses it)?

PS: I reread the whole thread that I find very interesting and tried to make a summary.

• 3.0 is not yet using the new MVC according to http://developer.joomla.org/manual/chap-Joomla_Platform_Manual-MVC.html due to lack of time
• The new MVC to come has one task execute() per controller; this might not seem very senseful now, but it is preparing J! to the new step of one main table.
• J!4 might have only one content table that directs to other components' tables.
• There are plans/wishes of displaying content not only in one "content", but also in other places. (https://docs.google.com/presentation/d/1OG2GG3ZJ3dVVsoZTDGS1goxM34fo_2KL1RUIkdOOUnA/edit?pli=1#slide=id.g1940a8d6_0_90 )

[Especially this last point I find very interesting. Content could be simply displayed e. g. in module positions via menu component(?). (Thus some modules (e. g. latest_articles) would become obsolete, as an article list could be displayed on a module position.) How ever the multi-content issue is handled, I like the idea of it. It would be a great step for J!.]

And by the way: Thank you all for your excellent work on J!

[reynaldo celaya III]

I'm planning an component. Is it recommended to use the old MVC of J! 2.5?
Or would you recommend using the new MVC for J! 3.0 (though the core not yet uses it)?

That depends on how much time you have to dedicate to refactoring your component, reacting to changes(possibly breaking changes) that will naturally happen when the new implementations are being created.

Personally i have been using legacy for now, just to finish up what i was working on, It will still look 3.0 taking advantage of bootstrap. This will buy some time while the community works on solidifying the new mvc (hopefully i can help).

Im all for being forward thinking and using the new MVC if it is a personal project, not a component for a paying client.

Does anyone know where the progress is with the new router? Thats the best place to start if your interested in the new mvc.

[Andrew Eddie]

You can use the old MVC, in which case you get all the benefit of the
existing classes like JModelForm and things like that (on which all
the components are currently built), or you can use the new MVC, but
you need to roll your own implementation of all those standard
classes. If you are happy with the 2.x way of designing components,
stick with it. If you are building a component that heads off in a
different direction, or you want to spearhead how new components
should be design from the ground up, then maybe the new MVC will be
more suitable. Unfortunately the answer really is "it depends".

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

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

> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/8NBaOIbsGygJ.

[piotr_cz]

Does anybody have ideas, how to make component for Joomla 3.0 with
backwards compatibility with 2.5?

Akeeba backup has had such stuff in past but I don't think if this is
really possible now, extending classes to JControllerLegacy for Joomla
3.0 and JController for J2.5. in once codebase.

[Andrew Eddie]

On 11 September 2012 18:13, piotr_cz <pkoni...@hotmail.com> wrote:
> Does anybody have ideas, how to make component for Joomla 3.0 with
> backwards compatibility with 2.5?
>
> Akeeba backup has had such stuff in past but I don't think if this is
> really possible now, extending classes to JControllerLegacy for Joomla
> 3.0 and JController for J2.5. in once codebase.

JControllerLegacy, JModelLegacy and JViewLegacy are in both 3.x and
2.5.x so that's your compatibility layer. It should be minimal
trouble to have a 2.5/3.0 compatible PHP codebase. The main problem
for 3.x extensions will be the different HTML markup.

1.5/2.5/3.x will be nigh on impossible without doing your own thing,
which some developers do (but then I argue why bother using Joomla at
all).

Regards,
Andrew Eddie

[piotr_cz]

Thank you.
I overlooked that around version 2.5.6 new MVC with compatibility
classes was merged into trunk.
I'll try to prepare HTML markup compatible with both 2.5 and 3.0 admin
templates.

On Sep 12, 7:07 am, Andrew Eddie <mambob...@gmail.com> wrote:

[Andrew Eddie]

On 12 September 2012 19:34, piotr_cz <pkoni...@hotmail.com> wrote:
> Thank you.
> I overlooked that around version 2.5.6 new MVC with compatibility
> classes was merged into trunk.
> I'll try to prepare HTML markup compatible with both 2.5 and 3.0 admin
> templates.

On that, I believe Michael has suggested that you prepare two sets of
layouts; one for 2.x and one for 3.x. Thinking out loud I guess you'd
probably design for 2.x and then use the postFlight trigger to
overwrite the layouts with 3.x versions; or possibly experiment with
_addPath. I don't think it will be a good idea to try and have one
set of HTML that works on both versions (you'll be on your own trying
to work that out).

[piotr_cz]

A good example of new MVC usage might be recent Joomla 3.0 Upgrade
Check Application https://github.com/mbabker/J30UpgradeCheck.
I just went briefly trough the code, and although this is a stand-
alone application, probably same pattern could be used in CMS.

[elin]

One of the interesting little twists of the new mvc+autoloader that might be useful to consider is that you also have the take the s off of a lot of your folder names so view instead of views and model instead of models.  Meaning that you could possibly have same named things in a folder called views and another called view.

Elin