Grails Flex Scaffold (GFS) is a grails’ plugin that deals Flex code generation by scaffolding methodology, including support for presentation and service layers by providing embeded data in your domain classes as original Grails Scaffolding does with Ajax and HTML.
In the first version (GFS v0.1) we attempt to support some basic features in Flex’s CRUD generation staff (Relations, Validations, etc).
Inspired by our experience on Grails we thought it could be a very good idea the fact of adding RIA concept, in order to enhance the user experience.
This plugin DO NOT attempt to get down developers’ skill, instead It tries to make easy repetitive tasks we can find in a project and earn time for critical bussiness items.
In order to explain how this plugin works we are going to write some code for a dummy example app which contains three type of relations (one-to-many, many-to-one and one-to-one) between four domain classes.
1 – Grails Project creation
2 – Plugin installation (link:download).
3 – Generating domain class model
4 – Crud Company and Customer Generation
5 – Flex compilation
6 – It’s time to start up our app-server and navigate our application
In the first version (GFS v0.1), we put all our efforts in this kind of apps (relations, validations), and we didn’t mind about features as visual component suite and form (via metadata) settings. We have all this staff planned and more planned for future versions (we expect you to contribute your knowledge, questions or whatever you have to contribute).
In nearly future we will have Jira and Confluence apps in order to follow projects releases and bug reporting. On the other hand, we are going to open our SVN for annonimous checkouts, this way everybody will be able to view, modify, use, contribute or whatever you want to do with source code, beta versions,etc.
It is not our porpose to extend this post any more, but it really important for us to mention Marcel Overdijk who developed Grails-Flex-BlazeDS integration.
- many-to-one supports only inPlace:false (this declaration is not required because it’s setted as a default)
- one-to-many both cases are supported inPlace:false/inPlace:true.
- one-to-one supports only inPlace:true (this declaration is not required because it’s setted as a default).
- If relations are declared as inPlace:true, e.g: Customer <-> Address o Customer -> Phone, the included class (Address, Phone) must define the constraint diplay:false for property that is including “custormer(display:false)”. At this moment, this restriction is not valid in generation code time and ends by abort process
- Relations must ever be lazy:false if not, BlazeDS throws a LazyInitialization exception (in future versions we are going to support this feature with DPHibernate or similar).
- Front-End supported constraints:
- blank, email, size, minSize, maxSize, min, max, range, url, inList
- For each Front-End constraint, a Flex validator is generated. This avoids user to persist the entity without the need of Back-End validation.
- All other constraints (Grails constraints) follows Grails validation way, doing validation on Back-End side which have the responsibility of getting feedback about errors to Front-End. This kind of errors are supported by i18n.