Hey,

I've just added an engine to add custom "modules" in the admin backend without using plugins and events, but rather Object Oriented components using inheritance and the normal LS workflow. It's provided with a HelloWorld example, and a detailed readme file :
github.com/LimeSurvey/LimeSurvey/tree/de...les/admin/HelloWorld

Before LS4 go live, I'll add a way to upload custom language files. The possibility to upload them via the admin interface and to use a XML manifest to define the menus/boxes will probably wait a later version of LS4.

I'm waiting for your feedbacks.

Wow, great thing! Thanks! Sounds promising and opens a lot of possibilities, eg. to add custom status info.

I like to have a
module page by Question groups
module page by Question
module page by Answer
module page by User
module page by Survey group

Like the surveyid=XXXX system

And allow to add this module link on «group overview» at minima (in a menu ?, list of link at bottom ?)

thank you orvil, yes it should open a lot of possibilities, and in a simple and clean way.

Denis. That's an interesting request, that will show the main differences between Object Oriented Modules based on inheritance VS Plugins based on events. As you know, that's the main change I want to do in LimeSurvey since years, and as you know, external coders who don't understand that difference are the ones who blocked me to do it since LS 2.5. Else, it will done since years. So I will take a bit of time to answer you as clearly as possible.


1. Layout is defined by view parameter


Very first thing, to avoid confusion:

The "surveyid" parameter in the aData array is not a way to select which controller is called (survey / question / question / question group etc). The controller is selected via the route in the url (for survey controller: index.php?r=admin/survey/, for question: index.php?r=admin/survey/question, etc ). The surveyid parameter is only a way to switch between the 2 layouts of the LimeSurvey admin interface. We have one full page layout, and we have the survey layout (with breadcrumb + left side bar). That's all. If there is a surveyid parameter, Survey Common Action will load the views to render the left side bar, the top bar, before calling the controller that will render the content in the central column. You can see its logic here:
github.com/LimeSurvey/LimeSurvey/blob/de...Action.php#L330-L342

Here the two layout files:
github.com/LimeSurvey/LimeSurvey/blob/de...uper/layout_main.php
github.com/LimeSurvey/LimeSurvey/blob/de.../layout_insurvey.php


So if you don't provide a surveyid in $aData, your views will be render inside layout_main. If you provide a surveyid in $aData, your view will be render inside layout_insurvey (the left bar / breadcrumb bar corner.)

without leftbar/breadcrumb layout:




with leftbar/breadcrumb layout:




2. Should I use plugin for everything or modules for everything?

Module is not really about quickly modifying the question / question group / user pages.If you just want a slight modification of a page, you can write a plugin (events on those pages). Events are perfect for those kind of small tasks. It can be coded quickly and easily. So a plugin based on event should be a very small piece of code doing a very simple task.

Object Oriented Module is more about creating entirely new pages for question / question group, etc, or about modifying deeply their rendering. It's about making a lot of changes, that will require a lot of code, that will be complex.

3. Can I still modify the question / question group pages with a Module?

I must check if it's already working (it should be the case), but a module is able to extend any core controller. So you can have your own Question / Question Group / User Controller that override the existing ones, or just override some of their methods, or (and I think that's what you want) just add new methods to those controllers with new views. Notice you can also modify an existing method in a controller, and then call its core view. Notice you can modify an existing method, render a module view, and from this module view render some core subviews.

So it's all about inheritance in the normal OOP way of doing, not an approach based on events modifying the logic/render flow on the fly. It's harder to write than just adding a small script based on events. But the result is much more solid, stable, easy to read, to understand and to maintain. It's very similar to what we're doing in LimeSurvey when we extend a Yii Class to modify it (just imagine how messy it will be if all the LimeSurvey Core Classes will be just plugins interacting with events in the Yii Core classes... :silly: : Well that the way we were taking by only allowing modification of the admin interface via events plugins)


3. Ok but how do I add a new menu in the question page to reach my new methods?

As said in the short tutorial: one of the main missing point is the menu definitions. It will be possible to add menus by defining them in the XML (just like in a joomla component). Then, you'll can add a menu link to one of your module action in the the top navbar, in the configuration menu, in the survey menus, in the question menus, in the question groups menu, in the token menus, etc etc .




I hope it make it easier to understand.
Again, I'm telling since years that using only events to extends limesurvey was a wrong way to do. My personal experience with Drupal 7 vs Joomla convinced me that all the hype around the observer alike pattern was wrong. I must say that the industry today is going to the same conclusion:
www.semaphore-software.com/blog/drupal-vs-joomla/ (again this article, after 4 years)
conferences.oreilly.com/software-archite...chedule/detail/77779

Pro with using XML for menu: Compatibility between versions.

Possible con: Localization harder?

XML will be loaded inside a table. Then module menus will be loaded and visible here:
?r=admin/menuentries/sa/view

Another idea could be to subclass Survey_Comman_Action into "Fullpageview" or "Surveyview". Then the class will decide which layout will be used. Just a thought.

yeah... That the way normal Yii layout system work. For LS5 I hope
Why don't you read the tutorial before asking questions? All that is mentioned in it

LouisGac wrote: XML will be loaded inside a table. Then module menus will be loaded and visible here:
?r=admin/menuentries/sa/view

Yeah, I think Markus solved the localization issue by using gT() in the install script. Maybe Denis can think of a solution for the module system, similar to how it works in plugins now?

LouisGac wrote: yeah... That the way normal Yii layout system work. For LS5 I hope
Why don't you read the tutorial before asking questions? All that is mentioned in it

Oops, sorry.

Oh, and also testability will increase if you feed the controllers a $request object instead of letting them read POST and GET super globals. This way the tests can create a custom $request object for each test, instead of hacking $_POST and cleaning it after, etc. Something to keep in mind.

LouisGac wrote: Module is not really about quickly modifying the question / question group / user pages.If you just want a slight modification of a page, you can write a plugin (events on those pages). Events are perfect for those kind of small tasks. It can be coded quickly and easily. So a plugin based on event should be a very small piece of code doing a very simple task.

Sample …

Do a complete different public view can be easy using twig and plugin.
BUT : you can add only one attribute.

I already thinking of improve account.limesurvey.org/limestore?view=extensiondetails&id=34 to create a dedicted page in question.
I can easily fill question attribute in modules or plugin or …
I can add question attribute

But i can not create (easily) a Question management page dedicated for this plugin.
Currently 2 ways
1. Add a text attribute
2. Create a js (hacked) function to open a dialog box to edit this attribute
3. Save as json
or
1. Add a text attribute
2. Create a js (hacked) function to open a complete new page to edit this attribute
3. Save as json

There 2 hack here
1. The js to open another page on attribute than can easily broke when update to minor API
2. The HTML page itself than can easily broke when update to minor API

Currently, i didn't check if PluginHelper->sideBody for survey still work. Hope it was except with some css and js.

external coders who don't understand that difference are the ones who blocked me to do it since LS 2.5.

Can you be more clear ? What portion of code ?
If you mean plugins : currently except little exception : plugin dev must do like they can … using hack if able (and this need control update at each minor API version). Since adding a Controller or a modules can not be done using API …