ProcessWire Module Generator

[Nico Knoll]

Hey,

as I often just copy someone else's (sometimes my own) modules structure as a starting point for a new module I thought there has to be a better way to archive that. That's why I created the "ProcessWire Module Generator":

modules.pw

If something missing? Or some more wishes for options or best practices? Let me know

Here's a screenshot:

[LostKobrakai]

You could automatically update extends/implements for Process modules. They're just extending Process. Also I'd suggest adding a placeholder name after the prefixes to avoid overwriting the base classes if one does not add his own name (e.g. ProcessName instead of Process). Also it would be nice if the form would adapt to show the options for creating a page automatically for Process modules.

[marcus]

Amazing tool, looks massively helpful! Thanks!

(Could we put your generator into a wireshell command, kind of like Mike suggested some days ago?)

[Craig]

This looks amazing! Thanks very much for putting this together

I don't have the Open Sans font installed locally. Would you be able to change to a stack that includes fallback to other Sans fonts, or include the webfont? At the moment it's a very unattractive Times  

[kongondo]

Nice one Nico!

Moved this to 'dev' instead....in fact don't know why it is off-topic at all? Better in Module/Plugin Development?

[blad]

Amazing tool. I Returned to processwire and I find this.

Even if you don't have the avatar you're supermom.

Good work

pd: I cant replace supermom with superm A n ¿?

Edited April 16, 2015 by blad

[Pete]

I think it's funnier that he's supermom

(I think that word filter is a leftover from when someone was posting links to all sorts of illegal film downloads a year or two ago).

[kongondo]

Wish: Nico, maybe remove the closing PHP tag in the generated file? Thanks

[DaveP]

[Nico Knoll]

@Lostkobrakai: Added all of your suggestions

@marcus: Of course! Let me know if I need to change something or if you want the source code

@Craig A Rodway: Fixed it.

@kongondo: It's written in PHP and doesn't use PW as backend. So I wasn't sure where to post. But probably module section would be the way to go. I moved it there now. And I removed the closing thing.

@blad: Thanks!

[adrian]

Wicked Nico!

I think this could really help us all get a standardized thing going on with our module development, including using strings as version numbers

What about an option to make use of the new module config possibilities: http://processwire.com/blog/posts/processwire-core-updates-pull-requests-and-more-2.5.25/#module-configuration-is-now-even-simpler

[horst]

Oh Nico, SuperMom, what a fine thing!

I have tested it and love it.

 - Now, after you have removed the closing PHP-tag, the closing class bracket is also missing }

 - I would remove the option for makin a module permanent. This would be only needed in very very special cases only.

 - my requires for PW and PHP are not shown in the getModuleInfo()

 - I have selected to make it a ConfigurableModule and to get a configpage as external file, but it seems it has not all needed code in its result.

I the attached zip is the generated code and a screenshot of my choices.

@adrian: yes, supporting the new module config possibilities would be nice, but than there is a logic needed in regard of the PW versions a module supports.

[adrian]

horst - agreed it will add a complication, but I think a worthy one - otherwise the lazy side of me is going to continue to use the old method, even though some other elements of my modules will likely require PW 2.6 anyways, just because it's easy to copy/paste from existing modules. I think Nico could do a great job of allowing the new option if you check that the module is only compatible with 2.6 anyways.

Also Nico, in your validation of fields I think it would be great to enforce camelcase where required. Should be easy enough to compare the entered string to its camelcase version to see if they are the same.

[horst]

Since PW 2.5 it is also possible to use a MyModuleName.info.json file instead of the integrated getModuleInfo() method.

 

With it, it is the same case as with the new module config possibilities. Both needs some logic, but worth to support it. (And now the logic can become an own function, because it will be used twice )

[Nico Knoll]

@horst:

- I added a json info option

- added the closing } again

- removed permanent

- PHP and PW requirements should be included properly now

What code is missing in your external config file?

[horst]

What code is missing in your external config file?

I'm not sure with it anymore.

The older or actually more common way is to implements ConfigurableModule, which has to lead into include a getModuleConfigInputfields() method.

But with the newer way (external ModuleConfigfile) I'm unsure if we need to implement ConfigurableModule too? If not, the generator needs a little logic to allow only one way.

And that with the default value types also is much better now!   very nice Nico!

	static public function getDefaults() {
		return array(
			"string" => "ABC",
			"boolean" => true,
			"integer" => 1234
		);
	}

[Nico Knoll]

I added the code samples at the bottom. Could you guys take a look at it and tell me if I did some mistakes? http://modules.pw/

[LostKobrakai]

Process module do not need to implement Module. Process already does, so the "extends Process" is enough. Also if I choose Process as type the tag for it's extend seems to be transparent or lighter in color. Edit: It's the disabled state… But then the x to delete should be hidden. 

For the FAQ you could add a line how to change the headline like here.

[Nico Knoll]

@lostkobrakai: I removed the x if disabled and added the headline to best practice. Removed "implements Module", too.

[LostKobrakai]

Great, one last thing: I don't know how you could do this, but from the interface it seems that one could choose multiple classes to extend. While previously selected classes get replaced if you try, it would be really great if it would be noticeable beforehand.

[LostKobrakai]

I just created a module with the generator and had the problem, that neither WireData nor Wire do have a init() function, therefore parent::init() failed. 

[Nico Knoll]

@lostkobrakai: Corrected it. That line is only for processmodules

[LostKobrakai]

Just found another thing, which could be improved. Automatically add "implements ConfigurableModule" if one selects "include configuration page". Or do I miss something here? 

Also want to say thank you here. It's really nice to have this and finally get my head around the json and external configuration settings It's a real timesaver as I'm working on lots of modules currently.

[Nico Knoll]

@LostKobraKai: It's already implemented. But if you select "use external file" ConfigurableModule will not be added to your main module.

[LostKobrakai]

Oh never mind, that was the part I missed