Closed serkandurusoy closed 9 years ago
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.
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:
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.view
of a form can be created by automatically rendering text values instead of form controls.2-4. :+1:
Ok, I will think about it. If it will be desired feature I will implement it.
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;
}
Ok, I will take it into consideration :)
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 :).
Wow, great to hear that. I'm looking forward to giving 1.0 a go!
Since I see a natural evolution of astronomy to be a forms framework, I'd like the fields to have a selective:
property where
persisted
is default but if marked astransient
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, onlyareacode
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>
andisAdult<boolean>
whereage
needs to be persisted butisAdult
is actullyage>=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.