[FR] Transient fields

[serkandurusoy]

Since I see a natural evolution of astronomy to be a forms framework, I'd like the fields to have a selective:

• persisted
• transient

property where persisted is default but if marked as transient it becomes a part of the model and not saved in the db.

A practical use of transient fields would be form fields where we would like to validate, but only save a calculation or part of. For example, a form may consist of an address part where the user needs to enter areacode, areaname, district, province, city, state but evidently, only areacode is sufficient to deduce that whole set of fields. So I would not want to persist the whole thing, only the areacode.

This goes for the view as well, such that the user would be able to see the complete address information that is only derived from a few persisted fields.

Another example would be two fields, age<integer> and isAdult<boolean> where age needs to be persisted but isAdult is actully age>=18.

I know some of this can be done using methods, but I believe methods should be reserved mostly for mutators.

Actually, that kind of semantics goes for relationships as well, indicating that a field is actually a reference to another database object that is mapped by it.

This is actually not new, they are concepts from java's persistence api implementation. This is a very brief, but effective read: http://www.objectdb.com/java/jpa/entity/fields

PS: It also discusses @version which is used for optimistic locking of database records, and may be a good candidate to become a behaviour in astronomy.

[lukejagodzinski]

Thanks for this FR. It's good idea but it will probably be the part of the forms module instead of the feature in the model / schema. I'm going to introduce the Form class that will store class instance with all the persisted fields. On the level of the form you will define what fields (from schema) do you want to be visible as the form fields. You will be also defining list of transient fields. I hope it makes sens.

[serkandurusoy]

Yes it makes sense and it would actually cover the whole field if you also provided form states: create/update/view.

Also, regarding the definition of visible form fields, does this mean that a model and its form will have a one to one mapping? Are we going to be able to create multiple forms that use the same model fully or partially?

For example, we could have a form to create a user, but have a different form to update the user profile in which some information cannot be updated, perhaps not even displayed.

Considering such scenarios, and form states, I would rather see something like this:

• a forms module that can be used to create multiple forms and each form has form-scoped properties (style classes, attributes, form state etc) as well a list of the fields that are available to the form and for each field, properties such as readonly, visible, hidden, style classes, attributes etc.

[lukejagodzinski]

1. I've never heard before about the view form. I assume that you think just about displaying a document without possibility to edit it. I don't think that it should be a part of the forms module.
2. Yes, it will be possible (by default) to map one to one. However, you will be able to omit some fields or add transient fields (inputs).
3. Yes, you will be able to create multiple forms based on the same model. It's especially important when considering two forms types (create, update). You will be able to define two separate forms, one for creating and one for updating a document. Of course, you always can use one form for both tasks.
4. Yes, it will be possible to define some fields attributes. However, in the first version it will be simplified. I want to create base form package that we can build upon. Some people only need tool for binding their forms (created with any custom tool) with a model, so it's not reason to build complex tool. It's much better to add additional package if you need higher complexity.

[serkandurusoy]

1. It is a concept from java server faces (facelets) and JPA (java persistence api) where a view of a form can be created by automatically rendering text values instead of form controls.

2-4. :+1:

[lukejagodzinski]

Ok, I will think about it. If it will be desired feature I will implement it.

[serkandurusoy]

An easy v0.0.1 hack would be to automatically add the readonly attribute to all form fields/elements and add custom styles to override the form look&feel to make it look like divs.

select [readonly], input [readonly], textarea [readonly] {
  border: none;
  background-color: transparent;
  text-overflow: ellipsis;
  white-space: nowrap;
  overflow: hidden;
}

[lukejagodzinski]

Ok, I will take it into consideration :)

[lukejagodzinski]

Transient fields implemented and will appear in the 1.0 :). It was quite tough feature to implement however I'm happy that I gave it a try. During implementation I've noticed some problems with other elements that could have side effects in the future. "So I've killed two birds with one stone" :).

Wow, I've just noticed that you've proposed this feature July 23, it was almost 50 days ago. It took me a lot of time to get from the previous version to almost 1.0 :). But all main features are implemented. Now I have to add some tests and check if everything works correctly :).

[serkandurusoy]

Wow, great to hear that. I'm looking forward to giving 1.0 a go!