Susan, yes I use the Login snippet, but in this case I am adding extra fields in a custom table and these have to be added in to the create/update forms. I also make changes as I progress with development (and discuss with end-users), adding more fields where necessary.
The problem I am finding with many extras is that, while they are very good for their own specialist functionality, they each also come with their own quirks, bugs, documentation quality, style and location. This leads to a whole load of time spent researching ways of doing the same stuff. Coding with PHP & MySQL avoids a lot of that because documentation for each is standardised and in the one place. So often it is easier just to code from scratch as opposed to spending time researching how to mod a snippet.
I find it a bit surprising that so much effort is put into forcing developers to separate html from PHP code, while just anybody can dump an extra into a Package repository. There is a huge gulf in quality control here: many extras do not even have proper descriptions; there is no indication as to how well they function. The only rough guide is version number and number of downloads. I would love to see some kind of standardisation enforced upon extras authors too - in description, documentation and stated v proven level of functionality. Maybe some sort of sandbox area for new extras, combined with an easily-visible scoring system for users to score and comment. Extras should be demoted if they fail a target score level. This would allow developers to discriminate in how they elect to allocate their time on extras - choosing high-ranked ones for jobs that need done yesterday, and low-ranked ones only when you know you have time and willpower to test and provide feedback.
As for the existing API, this seems to have all shifted away from good old-fashioned function names to a very generic and data-model-oriented system which is starting to resemble SQL. Handy reference lists are now huge pages of fairly technical information. As you say in your page linked above Bob, the listed MODX Revolution objects are "generated from the MODX schema file" (in other words the database). It's a huge list! Is all the info necessary, or could it be made more compact and informative? We need a data dictionary now. (btw that page would be great if it had a link to another page that told you what to actually do with all the stuff that is referenced, and what they mean. The inclusion of lines such as "-- use getMany('CreatedResources') -- returns an array of modResource objects" is good, but it would be great if we could just have a getCreatedResources() function?). While this has created a very flexible API for certain types of developers, it is also less intuitive without effectively having to scan the entire database schema. I feel that this has left a huge gap that the old Evo API used to fill (and which Java and PHP still do): intuitively-named functions which relate to obvious entities in MODx; getters and setters that do what they say on the tin. Is it not possible to have (at least a key set of) these alongside the more flexible (but long-winded) getOne() and getMany() etc functions?
Maybe I'm just being blinkered and haven't read enough, maybe I just don't realise how much I have to relearn, but much as I love the idea of MODx, I just seem to have been a bit lost with it since having to move to Revo (due to server PHP upgrades). Maybe the system itself is brilliant, but it's the lack of coherent documentation (I keep going on about that I know). I don't intend to condemn anything, just to illustrate the experience of a modx user who doesn't build too may sites but also has to do a wide range of custom business-specific snippet development (ie not the same stuff over and over).
Any comments to illuminate modx/educate me are welcome
ps, one final question: I keep finding links to the "More on the Anonymous User Group" page, but I cannot find any trace of a lesser page on Anonymous User Groups. Can anyone tell me?
☆ A M B ☆
☆ A M B ☆
