bbweb/derby-ar

ActiveRecord style helper plugin for Derby

derby-ar's Issues

RPC does probably not work with Derby 0.8

Since channels was removed, the current (as of 0.4.0) version of derby-ar should not work with Derby 0.8 (or more specifically, Racer 0.8). This is a regression that should eventually be fixed.

Validation of local models

In order for validation to be useful (as pointed out by Pavel) it should be tied to the UI in some way. My thoughts are that it is quite common you'd want to validate some data before you save it to DB. Most typical create/update tasks in regular CRUD apps fall under this scenario. Unless you don't care about validating your data, this needs to be done before (or some complicated mechanism for reverting changes needs to exists) submitting it to the server. However (as also pointed out by racer-schema/Pavel, as well as Nate), it is not feasible because sometimes you don't actually know the outcome of the change beforehand (unless you create a complete, i.e. deep, copy of all data and apply the change, but that is very expensive).

Nate suggested to do custom code, but it seems that it would be nice to either be able to re-use schemas specified in DB/model -models (e.g. what has been possible since 0.1.0). Also, it would be nice to have a plugin to declaratively define validation for a set of fields, including default values, to keep code more DRY. Thus, it would be nice to be able to specify a schema for a specific local model and be able to validate/apply default values to this model.

Questions still to answer remain though. First off, do you want to validate all the time? In many scenarios, you'd want to start validation at a certain point and not from the start. For example, if you enter a registration form you don't want to have validation from the first key stroke (it would just invalidate the vast majority of fields straight away), but rather when you actually hit the submit button. However, after that you'd want to get the errors for each field, and then reactively (i.e. on each change to the data) validate the data to update the errors in the GUI accordingly. Further, this would probably differ from different scenarios. Thus, there would be a need to:

• Start validation
• Stop validation
• Do a one-time validation

(which can probably be methods automatically added to the model at hand)

Further, at some point one would want the default values to be applied. It seems the first time would be appropriate to apply default values. However, if the validation fails one would probably not want the fields to be filled in automatically with the default values for those fields that were not filled in (or?) Further, it might be wanted to actually have the default values applied before any validation has happened at all, to be able to rely on that for certain other dependent operations. The question is then, when is the data/object first really created? Sometimes it might only be connected to the GUI through paths but never actually explicitly created. One solution would be to apply it on get's, but that would be complicated when dealing with sub-paths (and in particular, complicated sub-sub-sub-paths).

Thus, it seems there would be a need to be able to "manually" trigger applying defaults.

Sensible defaults seems like needed for this as well. Possibly overridable by an options parameter?

It's not possible to add functionality to a non-DB-collection

Scenario:
You write a component for handling comments. In your component you have a list of comments, referenced to an underlying comments-collection - all fine so far! However, you have a form in the bottom for adding new comments, along with some operations (e.g. reset, validation, saving to DB) and such. Then it might be nice to wrap it into a "form" model object.