mindplay.dk

Definitely, documentation should carry through to other files, same as for Page. As for Fuel, maybe you should deprecate it? Getting rid of existing usages in the PW codebase is probably a simple search-and-replace? ... use @deprecated on the old member, and @see to link to the new member - having two supported API points for exactly the same thing isn't good for comprehension. To the original subject, I've tinkering with a module that writes out stub PHP classes like this one: <?php namespace templates; /** * @property mixed $title Title (FieldtypePageTitle) * @property mixed $link Link URL (FieldtypeURL) * @property mixed $published Date Published (FieldtypeDatetime) * @property mixed $icon Icon (FieldtypeImage) * @property mixed $body Body (FieldtypeTextarea) */ class Post extends Page {} The module will write one of these to a designated folder whenever you save a template - in your template files, you can then use @var annotations to fake out your IDE, which will then be able to auto-complete for fields. I know this isn't very useful or interesting to someone who doesn't use an IDE, but working with others on a team, this will save time - since you'll be able to open up a template-file and know about all it's fields without digging through an admin-screen This is very experimental and too incomplete to post yet, but the stub above was generated with this module...

Aha - you can grab the form element via the form, by id! That'll come in handy, thanks I do think it would make more sense to have login via e-mail supported out of the box - logging in with username may be your personal preference, but it's just too exotic for mainstream. I forgot my username again today! If you offered an option to switch what field is used as the user-identity field, you could enforce uniqueness of that field, whether it's e-mail or username. That would definitely be safer and better than my hacky module. There's also going to be other issues with my module, like for one, the error-messages won't make much sense. If I were to go ahead and implement this fully and correctly, following your code-standards and everything, and I submit a patch, would you at least consider it?

I think, partially, you view this from the point of someone who knows the codebase inside and out - which is natural, since you wrote the thing. It's a relatively small codebase, and it's well-documented, so it's far from inaccessible to others. But someone who uses an IDE would be able to get up to speed much faster with better IDE support. Whatever enables static analysis - mostly more complete PHP-DOC annotations. It would eliminate a lot of code-browsing to learn about hidden/invisible properties. I know there's a lot of dynamics (magic) in PW, so not everything can be documented - but generally, anything that uses __get() and __set() could be completed, to the extend that this makes sense... for example, the "fuel" type could define properties for the built-in standard "fuel" objects. As we've discussed previously, class/file-name mapping also could be more consistent. Basically, open PW in Storm, and you will pretty quickly see countless things light up in orange or red scribble throughout the codebase - basically, where static analysis fails, the reader's analysis will fail too. For things that are indeterminate and can't be documented, you can often document with function-level annotations in the consumer-code what you're expecting - for example, in my code you can see me doing this consistently; in this particular example, it's pretty obvious what comes out of $this->modules->get('InputfieldText') but often class-names do not match property-names, and you have to dig to learn what comes out of this or that property...

I created a simple module that allows you to log in using your e-mail address rather than username: https://github.com/m...lAuthentication A couple of thoughts: This should be a built-in option in the login module, rather than an add-on - most sites have taught users to log in with their e-mail address. (I tend to forget what my username is - on most sites I don't have one!) The Session and ProcessLogin APIs need to be more extensible - for instance, to allow modifications to the form or fields. Modules like "login via Twitter" etc. will soon be something that people demand. I wish the build...form() methods in PW were more generally open to hooks...

I don't think we're really coming from very different perspectives at all - I only recently (within a couple of months) became an IDE devout. Over the years, I have tried every PHP IDE there is - typical life-span: one week. Nothing I ever tried helped with best code practices, which is all I was after. Static analysis and automated code inspection is about program comprehension and design - and automated code-review, it's a start, and it really goes deeper than you might think. It can save yourself and others a lot of tired hours that you could spend solving more interesting problems. You define the code-standards yourself through a series of very detailed dialogs, and you choose from 100+ configurable code inspections what you think is right and wrong. So it's not about living up to some IDE's code standards or "someone else's" static analysis - you set your own standards, and the IDE just lets you know when you're not living up to your own goals. It's not about communicating to the IDE - it's about communicating completely and consistently to the person looking at the source-code. And sure, you can have a person do that - but not with the same degree of consistency as a machine, and not without getting tired I think you have have to try it to see what I'm talking about. Mind you, this comes from someone who used plain text editors for more than 25 years. I didn't suddenly change my mind for no reason

Couple of questions, trying to learn from your changes - thanks for posting the fork so I can see the diff. About InputFieldMarkup for the icons - won't this cause the icons to go in a separate group from the dropdown control? That's what I was trying to avoid - that was the only reason they were mangled together like that. As for the client-side, I see you were trying to use live() and bind() instead of on() - these are not at all the same as on() in newer versions, which performs much better, and provides a single, unified API call for all types of event management. I really hope we can have the latest version of jQuery in PW soon.

I didn't at all mean to imply that you were - I just wanted to clarify where I'm coming from. Appreciate all your time and constructive input!

I think working on ProcessWire in PhpStorm would teach you some things about your own codebase - static analysis currently cannot do much to help with ProcessWire development at all, and that's educational... as I'm hoping you will discover, when static analysis doesn't work on a codebase, that usually indicates that the codebase is not as easy to understand, or as well-documented, as it could be. When static analysis doesn't work, that means we have to interpret code, and memorize code structure - I would rather use my clockcycles on solving practical problems I imagine not many people will have anything to say in this discussion, or they probably would have already. But I did an interesting experiment with synthetic classes tonight, and will post some results once I have a working prototype...

Well, thanks, but I intentionally build for PHP 5.3 ... my attitude is very simple: I build software for the future, not for the past. If I wasn't using newer PHP features, I wouldn't be using PHP at all - PHP has been playing catch-up the last couple of years, and has improved, but it's not exactly state of the art anymore. I don't think we further the use of PHP by showing the world what PHP code used to look like... You don't have to agree, but that's my philosophy Yes, the module definitely needs configuration options, I thought about the default icon setting too. As for the icon selection, I just did the quickest thing I could do - I might extend it later on, but for now, it gets the job done. PS: forking on Github is always good!

Having the character limit (or any other password rules) at the API level seems wrong? It's validation for user input, and this isn't user input. (is this a general thing about PW Page objects that one should be aware of? it validates the model itself rather than the user input?)

@Soma you need PHP 5.3 for this module. @ryan thanks for the clarification - this probably should be part of a documentation page about module development? Regarding the two hooks mentioned by @Soma, yeah - I wasn't too sure about these, but what's the alternative? I went with $icon->addHookAfter('render', ...) in order to inject my own markup (the icon list) into the form... is there a cleaner way to do that? The hookAfterRender() method is there for two reasons: 1. So I could inject the initialization script-tag - is there a cleaner way to do that? 2. So I could add to $config->scripts ... init() seems like the right place to do that, but for some reason my script-tag would show up "too soon", e.g. before jQuery, so it didn't work... is there a better way to work around that? For the same reason, I'm not adding the CSS in init() - it shows up too soon, and my rules get overridden... I guess the underlying question here is, can you control the order of script and css embeds?

I use jQuery.on() everywhere - it's basically the standard for event-management in jQuery now. An icon font, hmm... I prefer to have a folder where I can drop in another icon when needed. I knew about the custom label setting, but I wanted something colorful you can distinguish from the rest of the content - I won't personally be using the label-feature on every template, just on certain templates to call attention to certain things. The style was lifted from Twitter Bootstrap's badge style - I'm not a designer, but it looks fine to me. I saw your color-picker and decided not to use it, as it creates more complications from having to either compute (or enter) a foreground color. I also decided I wanted a small preset list of colors because I'm not trying to turn the page list into a color symphony - a low number of colors that are easy to distinguish from each other. All conscious decisions. I was less conscious of API choices and PW conventions - I tried to grok what I could from existing plug-ins, but as said, a code-review would be appreciated, if anyone has the time/experience... (on that note, the documentation page really could use a chapter explaining hooks in depth...)

Anyone see an option to turn on automatic subscriptions for things you post? I see an option to "Auto follow topics I reply to" - but that's not what I want...

I wrote my first PW module this week-end, and I was generally pleased - in about 5-6 hours through the day, I was able to learn (from the ground up) how to use the hooks and input-fields APIs, as well as writing a small but functional plug-in. If I had to compare this experience with my Drupal or WordPress module-writing experience in the past, I would say this is about 10 times easier to learn and do! One thing I find in general about PW however, is the IDE support is lacking - this is natural and expected, due to the nature of the PHP language, but I like to push the limits, so if you're interested... Help me brainstorm for ideas to implement IDE support for hooks? Of course, the obvious route is to implement IDE support in the IDE - this is the route that more IDEs seem to choose lately, for example Yii and Symfony has IDE support in a couple of IDEs by now. That's all well and good, but I would strongly prefer to find an approach enables static analysis - IDEs already parse and inspect code and PHP-DOC annotations, and in modern IDEs this ties in with powerful features like auto-completion, parameter/type-hints, documentation, diagramming, automated refactoring, and so forth. There must be some way we can leverage that existing IDE power? A couple of random ideas and hocus-pocus off the top of my head: - thin run-time code-generation in "autoloaders" - things like eval('class '.$magic.' extends '.$static.' { use '.$trait.' }') execute quickly. - static code-generation via stream-wrappers or autoloaders, modifying or generating code. - inline code-generation (via autoloaders) - altering sectioned areas in source-code (relies on eager saving and auto-refresh in IDEs/editors, e.g. PhpStorm) - class-name aliasing: use x as y... I actually attempted eval('use Foo\Bar as Fudge;') and I can report that it executes, but doesn't work - still worth pondering though, could work in combination with inline code generation. - PHP 5.4 traits can implement __call(), __get() and __set() ... doesn't provide any IDE support off-hand, but perhaps in combination with something else? - parsing PHP and/or PHP-DOC: could lead to interesting results in combination with another hocus-pocus technique. Please add to the list, if you're interested!

I thought it might be something like that. Any particular reason the autoloader couldn't be responsible for this? Anyhow, to return to the original subject - I've mostly built out a module (yay, my first!) that lets you add a colorful badge and/or an icon to a template, which will display on the page list. Here's a screenshot: The repository lives here: https://github.com/mindplay-dk/TemplateBadges Two known issues: I realized too late that ProcessWire uses an older version of jQuery - to test this module, you will need to replace the bundled jQuery with a newer version. I posted the issue here. ProcessTemplate::buildEditForm is not hookable - I haven't posted an issue for this, since Ryan said he will adds hooks as needed. With those two fixes in place, you should be able to test it out. Since this is my first, I would appreciate a code review and feedback from any experienced module developers!

What's the difference between $label = $this->modules->get('InputfieldText') and $label = new InputfieldText() ?

@soma Thanks, this is very educational! ... Teflon is my theme of choice, by the way - mainly because of the icons and navigation, lightning fast to work with... but as with PW standard theme, I find that once you have a lot of Pages on your sitemap, it starts to get harder to keep track of what's what. I'm going to attempt to add a label/color setting to Templates. I'll post my results here.

I spent a couple of hours tonight skimming through APIs, reading documentation, trying to understand how to extend the Template admin form... It appears that only the execute_() methods are hookable? Only the execute-methods have the triple underscores - so it's not possible to extend the Template form tabs, or add new tabs? For that to be possible, the build_Form() methods would need to have the triple underscores added, is that correct? Extending the admin forms is not permitted?