Moodlerooms Framework

Moodlerooms Framework

Napisane bez: Howard Miller ()
Liczba ôdpowiedzi: 18
Ôbrŏz Core developers Ôbrŏz Documentation writers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Peer reviewers Ôbrŏz Plugin developers

Does anybody have any idea what the MoodleRooms Framework is? Well, that's not a good question - it's the Zend framework sucked into Moodle. The actual questions are why would you want to do that? 

We were asked by a vendor to install this software in order to implement a block and I'm a bit surprised and wondered what the story is. I can only assume that the single block started life as part of something considerably larger but as a way of implementing a single block it looks a little ridiculous. 

W ôdpowiedzi na Howard Miller

Re: Moodlerooms Framework

Napisane bez: Tomasz Muras ()
Ôbrŏz Core developers Ôbrŏz Plugin developers Ôbrŏz Plugins guardians Ôbrŏz Translators

I had a look at the efforts for creating MVC framework for developing Moodle plugins:

A framework like this would be very helpful in my opinion, the way most of the plugins are written is non standard and very often not optimal (code duplication, no front-end controller, no MVC separation).

I believe, however that such a framework would need to be created by HQ. Core activities would be re-written in a model way that others could copy. I think that new assignment module is a first step towards it.

cheers,
Tomek

 

W ôdpowiedzi na Tomasz Muras

Re: Moodlerooms Framework

Napisane bez: Tim Hunt ()
Ôbrŏz Core developers Ôbrŏz Documentation writers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Peer reviewers Ôbrŏz Plugin developers

It sounds like you want to re-invent the wheel for your hovercraft.

You can do MVC in Moodle today. We have views, but we call them renderers.

And you should already be structuring your code around classes (models) to do all the real work. Until now you would typically have defined the classes in locallib.php, but in 2.6 you will use class auto-loading and put them in the classes folder in your plugin.

That just leaves the controllers, which in the Moodle world would be the scripts like view.php. That script should process the incoming data, make the appropriate calls to instantiate and possibly update the relevant model classes, and then call an appropriate renderer method (view) to generate the output.

The student-visible parts of the quiz already do a reasonably good job of following this pattern.

So, to use MVC in Moodle, you don't need some hypothetical future framework. You just need to write code that does not suck today.

W ôdpowiedzi na Tim Hunt

Re: Moodlerooms Framework

Napisane bez: Howard Miller ()
Ôbrŏz Core developers Ôbrŏz Documentation writers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Peer reviewers Ôbrŏz Plugin developers

Next you'll be telling me Moodle is getting namespaces klaun

W ôdpowiedzi na Howard Miller

Re: Moodlerooms Framework

Napisane bez: Tim Hunt ()
Ôbrŏz Core developers Ôbrŏz Documentation writers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Peer reviewers Ôbrŏz Plugin developers
W ôdpowiedzi na Tim Hunt

Re: Moodlerooms Framework

Napisane bez: Howard Miller ()
Ôbrŏz Core developers Ôbrŏz Documentation writers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Peer reviewers Ôbrŏz Plugin developers

Great so I no longer have to count ../'s on my fingers then szyroki uśmiych

W ôdpowiedzi na Tomasz Muras

Re: Moodlerooms Framework

Napisane bez: Howard Miller ()
Ôbrŏz Core developers Ôbrŏz Documentation writers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Peer reviewers Ôbrŏz Plugin developers

Personally I think the whole MVC thing is overrated - but almost certainly better than some sort of random fumbling. But let's put that aside. 

In it's own way - Moodle is already a framework for developing plugins albeit not (quite) in the general purpose way  that the likes of Zend Framework and Symfony are. In some respects I think it's better - or at least more pragmatic. 

I guess my point - if I have a point - that I was very taken aback that someone would go to all the trouble of plugging in an entire MVC framework into a local plugin just to develop a single block. A little perverse perhaps? puszcza ôczko

Although, having said that, I doubt it was the original motivation. 

Your point that Moodle plugins are written in a "non standard" way is a little depressing to me. I assume that you are asserting that MVC is some sort of "standard". Well, I suppose it is but not in a way I find terribly useful. Moodle plugins are now very standard - within Moodle - and they work. 

W ôdpowiedzi na Howard Miller

Re: Moodlerooms Framework

Napisane bez: Tomasz Muras ()
Ôbrŏz Core developers Ôbrŏz Plugin developers Ôbrŏz Plugins guardians Ôbrŏz Translators

Each developer writes plugin in a bit different way - simply have a look at few random contributed modules to get a sense of different "styles" developers follow. Of course they all work, I'm just looking for a way to improve the code by standardizing it. Saying to write the code that does not suck is not very practical advice uśmiych.

What other design pattern (style or however we decide to call it) would you use instead of MVC? I think that those days MVC actually is a standard for designing web applications.

cheers,
Tomek

 

W ôdpowiedzi na Tomasz Muras

Re: Moodlerooms Framework

Napisane bez: Tim Hunt ()
Ôbrŏz Core developers Ôbrŏz Documentation writers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Peer reviewers Ôbrŏz Plugin developers

MVC is not a standard. It is a pattern, one of many. Actually, some people would say that it is not even a pattern, it is vaguer than that. It is a basic idea that is the basis of a number of different patterns. For example there are different patters for how to implement views, controllers and models.

If you want to broaden your horizons in this area, the I recommend Patterns of enterprise application architecture by Fowler. It is a bit on the dry side, but the content is excellent.

W ôdpowiedzi na Tim Hunt

Re: Moodlerooms Framework

Napisane bez: Marcus Green ()
Ôbrŏz Core developers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Plugin developers Ôbrŏz Testers

Drier than the Sahara Desert after a very long drought and then a long period of being dried with something very very absorbent. Head First Design Patterns is a nice alternative for people who like their learning a little more pre-digested.

 

 

W ôdpowiedzi na Marcus Green

Re: Moodlerooms Framework

Napisane bez: Howard Miller ()
Ôbrŏz Core developers Ôbrŏz Documentation writers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Peer reviewers Ôbrŏz Plugin developers

Or just don't bother.

Well - that's not fair. Having had to mentor quite a few just-out-of-college developers over the years I may have formed a bit of a negative opinion about design patterns. Perfectly fine when appropriate for the job in hand but much too often applied with religious zeal to the detriment of the complexity, readability and maintainability of code. 

W ôdpowiedzi na Tomasz Muras

Re: Moodlerooms Framework

Napisane bez: Howard Miller ()
Ôbrŏz Core developers Ôbrŏz Documentation writers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Peer reviewers Ôbrŏz Plugin developers

Yes I know - "there's only one game in town" or so it would seem. 

Even within the confines of a well defined MVC framework different programmers will use it in very different ways. In Moodle 2.x we have a *very* well defined framework which is (IMO) at least as useful as any MVC framework I have seen. 

I am old enough to remember when MVC didn't exist (well, it did, Struts existed but that was just dreadful) and somehow we managed to write web applications. Usually simpler, shorter and more efficient ones. 

Don't get me wrong, I use Symfony 2 quite a bit outside of Moodle and it saves me a lot of time but I can't help thinking I am adding a huge layer of complexity (and learning curve for someone potentially), not taking it away. 

You know where you are with an old-fashioned require_once() gŏdka

W ôdpowiedzi na Howard Miller

Re: Moodlerooms Framework

Napisane bez: Anne Krijger ()

I'm not sure in what way MVC would be overrated.

Although the Moodle code is getting better there are still places where (part of) the view (AKA html code) is constructed in the code that processes a form submit.

With the renderers it becomes much easier to make a small change to the way something is displayed. But when I had to remove some icones from the standartd calander block I had to jump to a serious number of hoops to implement that.

So yes, being able to extend the model, change the flow (control) and/or the view, just by extending/overriding existing classes/renderers will make development a lot easier.

Even developing a new block could be just extendeing the base block class and renderer and adding just those bits of code you need.

I'm hopig that creating a new question type will work in that way uśmiych

As mentioned before, I've been out of it a while, so not really up to speed with the latest improvements.

Anne.

W ôdpowiedzi na Anne Krijger

Re: Moodlerooms Framework

Napisane bez: Howard Miller ()
Ôbrŏz Core developers Ôbrŏz Documentation writers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Peer reviewers Ôbrŏz Plugin developers

I slightly regretted saying that after I typed it - not because I don't think it's true, more because I don't think I explained myself very well. 

I meant MVC as a design pattern to be religiously followed rather than a sensible separation of the system into discrete components. Thinking you *have* to use MVC for any web application leads you down a certain path that may not be the best solution. What Moodle has is a bit of a hybrid, and there's nothing wrong with that - however, one never did have to write horrible code in Moodle. (I'm not suggesting that I never did!)

W ôdpowiedzi na Howard Miller

Re: Moodlerooms Framework

Napisane bez: Jason Hardin ()

Howard,

I will let our devs get into the discussion about MVC and namespaces and their benefits/detractors.

What I can tell you is that we don't use the Moodlerooms framework for just one block. Every development project Moodlerooms has created that is not slatted to be integrated into Moodle core we have used the Moodlerooms framework.

We use it because it saves us significant development time across the life cycle of a feature. We have been using it since moodle 1.9 when renderers were just a twinkle in Moodle Core's eye.

W ôdpowiedzi na Jason Hardin

Re: Moodlerooms Framework

Napisane bez: Howard Miller ()
Ôbrŏz Core developers Ôbrŏz Documentation writers Ôbrŏz Particularly helpful Moodlers Ôbrŏz Peer reviewers Ôbrŏz Plugin developers

Yes - that's what I expected. I came across it in the context of being asked to run one fairly simple block. In that context it starts to looks a bit bizarre, but I really didn't think that was the original idea.

The McGraw Hill plugin if you are interested. The upshot is, I suspect, that we won't be able to use it due to the resource required to evaluate the MVC framework that underpins it. 

W ôdpowiedzi na Howard Miller

Re: Moodlerooms Framework

Napisane bez: Mark Nielsen ()

Hi Howard,

The reason why the ZF is in the MRF is mostly for legacy reasons.  We have some plugins that rely on it, but probably most could get away with the ZF fragment that is in core already. We don't use ZF for MVC and things like that.  We don't use it for most of our development.

The MRF is meant to be re-used amongst our plugins.  So, yes, it is very much overkill for a simple block, etc, but used across several plugins, it starts to make sense and save a lot of time.  I created the MRF because I started to notice that I had to copy/re-invent code that I had already developed in another plugin, while authoring a new one.  I have created around 200+ plugins in Moodle, so re-inventing the wheel for each plugin makes no sense and also using a framework cuts down on maintenance and standardizes the plugin so another developer can contribute more easily.

If I were to do it all over again today, I would try to make use of Symfony2 components.

Cheers, Mark

W ôdpowiedzi na Mark Nielsen

Re: Moodlerooms Framework

Napisane bez: Tomasz Muras ()
Ôbrŏz Core developers Ôbrŏz Plugin developers Ôbrŏz Plugins guardians Ôbrŏz Translators

re-inventing the wheel for each plugin makes no sense and also using a framework cuts down on maintenance and standardizes the plugin so another developer can contribute more easily

I have a very similar experience, each plugin contains a lot of of boilerplate code that could be extracted and managed under some kind of common framework. I would create a framework like this but I gave up on the idea of doing it by myself - I think it's pointless if not agreed by wider community, especially Moodle HQ. This is the reason that I've instead implemented generating templates of the code in  moosh.

 

If I were to do it all over again today, I would try to make use of Symfony2 components.

I would do the same, Drupal 8 made similar decision.

cheers,
Tomek