Re: Proposed API in 1.4 (and would like to backport to 1.3)

Hi Chris,

On Thu, Jan 16, 2014 at 3:20 AM, Chris Travers <..hidden..> wrote:

This is a fairly simple set of API's that would be handled by a LedgerSMB::Request module (which we'd make Form.pm and LedgerSMB.pm inherit for now). This would be for handling input declaratively. The API would be as follows:

$request->required($att1, $att2, $att3....);

would raise an exception if any attribute was not provided, This would allow us to more easily eliminate the low-knowledge errors provided to users like "required input not provided".

$request->required_series($start, $stop, $attr1, $att2, $att3)

This would generate names in the format of ${att1}_$start ..${att1}_$stop and require those.

The following would apply only to 1.4:

$request->number and $request->number_series with the same syntax above.

$request->date and $request->date_series with the same syntax above.

What do people think?

Well, we have gone over the idea a bit through gTalk before, but I wanted to state my response here as well. One thing I would like to prevent is to encode identical knowledge in multiple places - that's always a synchronization nightmare.

So, ideally, we'd invent a scheme where we can map the fields in the screens to fields in the database api, or better yet, to fields in the database. That way, the service could consult the database api and determine which fields will be required upon submission of the form.

Even better: if we can derive which fields are required, why not do that before we send the forms to the browser and use the "required" input attribute to have compliant browsers verify it for us without request overhead?

Now, of course, there's the problem of determining a model where we can derive the "requiredness" from the database model.

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.