Nico Knoll Posted April 16, 2015 Posted April 16, 2015 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: 32
LostKobrakai Posted April 16, 2015 Posted April 16, 2015 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 Posted April 16, 2015 Posted April 16, 2015 Amazing tool, looks massively helpful! Thanks!(Could we put your generator into a wireshell command, kind of like Mike suggested some days ago?) 4
Craig Posted April 16, 2015 Posted April 16, 2015 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 1
kongondo Posted April 16, 2015 Posted April 16, 2015 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? 1
blad Posted April 16, 2015 Posted April 16, 2015 (edited) 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 1
Pete Posted April 16, 2015 Posted April 16, 2015 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). 4
kongondo Posted April 16, 2015 Posted April 16, 2015 Wish: Nico, maybe remove the closing PHP tag in the generated file? Thanks 1
Nico Knoll Posted April 16, 2015 Author Posted April 16, 2015 @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! 5
adrian Posted April 16, 2015 Posted April 16, 2015 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 2
horst Posted April 16, 2015 Posted April 16, 2015 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. 1
adrian Posted April 16, 2015 Posted April 16, 2015 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. 1
horst Posted April 16, 2015 Posted April 16, 2015 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 ) 2
Nico Knoll Posted April 17, 2015 Author Posted April 17, 2015 @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? 2
horst Posted April 17, 2015 Posted April 17, 2015 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 ); } 1
Nico Knoll Posted April 17, 2015 Author Posted April 17, 2015 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 Posted April 17, 2015 Posted April 17, 2015 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. 1
Nico Knoll Posted April 17, 2015 Author Posted April 17, 2015 @lostkobrakai: I removed the x if disabled and added the headline to best practice. Removed "implements Module", too.
LostKobrakai Posted April 17, 2015 Posted April 17, 2015 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 Posted April 19, 2015 Posted April 19, 2015 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 Posted April 19, 2015 Author Posted April 19, 2015 @lostkobrakai: Corrected it. That line is only for processmodules
LostKobrakai Posted April 20, 2015 Posted April 20, 2015 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. 1
Nico Knoll Posted April 20, 2015 Author Posted April 20, 2015 @LostKobraKai: It's already implemented. But if you select "use external file" ConfigurableModule will not be added to your main module.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now