This document explains calling a helper class passing $params for future use. The problem is, it doesn't mention where that $params is coming from. And what other data is available? Sovainfo (talk) 08:41, 6 May 2014 (CDT)
- So there probably should be a sentence saying $params is generated by us automatically. As this is a "simple" module tutorial - I really want to avoid going into the fact this is automatically generated by the JModuleHelper. I'd rather just say the thing with the params is created magically for you to manipulate. --Wilsonge (talk) 18:43, 6 May 2014 (CDT)
- Why would you want to avoid mentioning JModuleHelper::renderModule. The first thing that comes to mind is how should I know $params is available? Where to look for the other variables availabe. Or state them, would be nice to know $app is available!. Sovainfo (talk) 03:49, 7 May 2014 (CDT)
- Because it's a "simple" module tutorial. When I first developed modules (which scarily wasn't that long ago) I didn't care where all this stuff came from - it was just amazing that it existed. Again for simple module development I'm not sure that matters - with the $app thing for example I'd rather get people redefining it. Firstly as I said I don't think people for a basic "here's how to create a module" tutorial we need to involve JModuleHelper and also because I really think you should define $app yourself for your things so it's as standalone as possible! The only thing arguably you should need is the $module object (as that contains params + module title instance) or if you only need the params then just $params.
- Never mind. Hope that the J4 redesign will get rid of modules anyway!Sovainfo (talk) 19:34, 7 May 2014 (CDT)
Don't like "for page rendering"
Don't like "for page rendering", would say: while rendering the page. It completely puts me off, thinking the module is the procedure to render a page, which is handled by JDocumentHtml. Sovainfo (talk) 04:05, 7 May 2014 (CDT)
- In retrospect I don't like it either :P changed