Currently the only way to request data from the APIs is to send the appropriate data via the "request" parameter. While this gives a lot of control it's also quite cumbersome to create a request. To make this simpler the requests should also support "direct parameters".
Examples
https://host.name/api/json/?m=categories&a=view&e=all&title=textView all categories that match the title "text".If the "m" parameter is set it should set up a Data object and setRequestValues, i....
The amount of control fields (that are always present in modules) keeps growing which limits the field names available. Introducing the underscore in the _stp field was an attempt to make them unique enough to not collide with "normal" field names people may want.
The problem there however is that it currently can't be used in the templates format class as that uses underscores to indicate marker types (e.g. _if). This can of course be changed but that would mean all templates requir...
Currently if 2 users edit the same information the last store will effectively overwrite the other one. At the very least the users should be made aware of this. A simple solution seems to be to create module that keeps track for each module which entry is added, edited and deleted in the last X minutes. This information can in turn be used to indicate to other users certain information is volatile. Note that JAS16MAR002 may also rely on this information.
Currently JAS doesn't deploy any protection against overloading of the system. It seems wise to add protection against brute force login attacks and mass adding of information. As JAS16MAR001 will probably already create a "temporary log" of what's going on this may be used for overload projection. Alternatively JAS16JAN006 may also provide a way to limit submissions.
The current MD5 file signatures allows end users to check whether the file is still in tact. However it doesn't garanty the file (and MD5) haven'/files/ field and API should support PGP signatures.
The password generator + validator should exclude certain characters from the character sets to avoid confusion and potential bugs, e.g.:capital i and lower l are confusing
capital o and zero are confusing
@ and : may ruin passwords in URL
As none of the values are per se incorrect it may make sense to just remove them from the generator but still leave them as "valid" values.
Typically any input should be trimmed, it makes sense to make this a default action which can be explicitly disabled. Instead of the current approach where it needs to be enabled explicitly.
When distributing plugins they often require static data to be setup to function correctly. While this can be handled in the postSetup function, it isn'/files/ in its storage directory which are loaded automagically.
So far to big issues arise:
The order in which the data is loaded is crucial. Mostly this is the order of the modules which is typically dictated by their references. However self-referencing modules also require the order of the individual entries to be correct.
...
Float and price fields should have round/floor/ceil field mutilations
Mutilate::round(number, precision=0, mode=false)
mode: normal, floor, ceil
if precision > 0 and mode = floor/ceil:
floor(number * pow(10, precision))/
pow(10, precision)
Data::addMutilationFormat_Template
A simple action which updates the "updated" time stamp and nothing else. Handy when needing to trigger recache of lister plugin sections when multiple modules are involved.
$d=Data::cache("module", "touch", "item");
$d->setValue("nr", $id);
$d->submit();
Only "forceUpdate" and ID fields will be checked and subitted, all other fields may not be checked to avoid potential errors. Storage object "edit" function should be used which should just update the relevant forceUpdate fields...