Open loicdescotte opened 12 years ago
Loic, this would be awesome! If you like at FieldTypeManager, it could ease this process. I coded it for anothr project, it is still in Java and need to be coverted to Kotlin.
It basically allow to associate different kind of string conversion and string parsing based on runtime type.
So it will allow to do handle what you want to do to by creatig a set of Formatter, and associate them with different types (look at how FieldTypeManager#initialize work).
Simply code a set of formatter for your tags and provide a different initialize method that register them. You can associate a tag to a the base type of a class hierarchy , so you can associate @number tag to jet.Number class, and it will be use for Double,Int ecc.
We coudl get the runtime type of a model using hibernate.Property class, and even enhance the property class to include information to improve html formatting and validation (look at how I implement Property?.header extension in View.kt)
The problem I have with the types is that if we create an empty form, there is no value in the input fields, so the required type cannot be inferred from values. That's why I created @number tag. My wish would be te create a unique tag, which would be able to transform itself into a text input or a number input, or a date input (with a calendar display) etc. depending of the fileld type defined in the Java (or Kortlin) model, thanks to databinding between model and form
You can get the type by using hibernate Property class, without using property values. e.g. to get the code property type of Quote class use
WelcomeModel[javaClass(), "code"]
which give you the Property class, and then you can use the Property instance in order to get the type of the property. I think this involve the use of reflection in order to get the actual type, but hibernate do the most of the work.
For tomorrow, I can code a helper method that return a property type giving as parameters an entity a class and a property name, so that you can choose the best html input for that type.
Il 16.07.2012 14:18 Loic Descotte ha scritto:
The problem I have with the types is that if we create an empty form, there is no value in the input fields, so the required type cannot be inferred from values. That's why I created @number tag. My wish would be te create a unique tag, which would be able to transform itself into a text input or a number input, or a date input (with a calendar display) etc. depending of the fileld type defined in the Java (or Kortlin) model, thanks to databinding between model and form
Reply to this email directly or view it on GitHub: https://github.com/parroit/kweb/issues/3#issuecomment-7004463
I 'll check tonight to be sure to understand well, but maybe it would be possible to make directly a typed input in the template .
For example, if we bind a Person model to an html template form, we can establish from the input fields type (via reflection) the types (name = String, age = Int etc.) without using hibernate meta-models, am I wrong?
In any case, having such an helper would be great, yes :)
Thanks
Ok, I code it. But your previous comment make me think that to decouple template module from persistence one would be prefereable.
The hibernate helper could be used as an option, and the Kotlin reflection will be the default one.
Also, maybe we could skip the use of reflection by using a generic method and Kotlin reification (if it work well at the moment)
Il 16.07.2012 15:24 Loic Descotte ha scritto:
In any case, having such an helper would be great, yes :)
Thanks
Reply to this email directly or view it on GitHub: https://github.com/parroit/kweb/issues/3#issuecomment-7005789
Indeed it would be better to decouple, mainly because some people may want to avoid using hibernate and would prefere to use some simpler sql helpers with a langage like Kotlin (like Anorm with Play/Scala)
I've pushed [https://github.com/parroit/kweb/blob/master/src/test/kotlin/kw/model/PropertyTypeTest.kt] Which include some test on getting property type via reification (which dos not work) and via reflection (this does its work well). You can take propertyType fun from this file that is what is working by reflection
Nice job!
Rewrite this module in Kotlin.
The module could even be improved : in Play2 it's impossible to know the type of the field we are handling in a tag (we manipulate only String values).
So we have to write
@number
for a Long and@text
for a String, as an example. If we can handle real Kotlin objects in the templates before rendering the response, we could infer the right tags from the type.