|
Hi all,
Basic scaffolding is now implemented in Grails. To see it in action take a look at the blog sample up by doing grails init grails run-app and going to http://localhost:8080/blog/app/entry/list A very basic weblog implemented in Grails. But the cool thing about it is it demonstrates Grails non-templated approach to scaffolding. The controller is essentially this: class EntryController { @Property boolean scaffold = true @Property createComment = { def e = Entry.get( this.params["entryId"] ) def c = new Comment() c.properties = this.params e.comments.add(c) e.save() redirect(action:this.show,params:[ "id": this.params["entryId"] ] ) } } Note how there is only one action and it redirects to another action "show" which is a scaffolded action, the rest of the actions are scaffolded. At the moment only the server side actions are being scaffolded and you have to write the views by hand, but its a start... Phase 2 will be getting scaffolding of the views done and incorporating all of the stuff to do with constraints that was discussed. BUT before phase 2 can commence I have to start the Grails tag library as some aspects of the custom views will be dependant on this (validation, linking etc.) Cheers, Graeme |
|
This looks really cool, can't wait to give it a try.
Quick question , on the comments object : def c = new Comment() c.properties = this.params is it not possible to do : def c = new Comment(this.params ) And is do we have to use this.params rather than params? Sorry I'm new to grails, these might be stupid questions On 12/13/05, Graeme Rocher
<[hidden email]> wrote: Hi all, -- regards babelex http://babelex.blogspot.com/ #OpenSource means free to innovate# |
|
Sorry one other question, does the scafold = true mean it has added, new,delete (CRUD) operations? -- regards babelex http://babelex.blogspot.com/ #OpenSource means free to innovate# |
|
To answer both your questions..
At the moment when you do: def c = new Comment() c.properties = this.params It does type conversion from string request parameters into longs, integers, dates etc. We may add a dynamic constructor that does what you suggest too. On 14/12/05, Babelex <[hidden email]> wrote: > > Sorry one other question, does the scafold = true mean it has added, > new,delete (CRUD) operations? Yes it has added all the necessary server side code to do CRUD operations. As i said in my post you still have to write views yourself, but it is a start. The actions added are as follows: show,edit,update,delete,create,save,list Cheers Graeme > > -- > regards > babelex > http://babelex.blogspot.com/ > #OpenSource means free to innovate# |
|
In reply to this post by graemer
Congrats man.
On 12/13/05, Graeme Rocher <[hidden email]> wrote: > Hi all, > > Basic scaffolding is now implemented in Grails. To see it in action > take a look at the blog sample up by doing > > grails init > grails run-app > > and going to http://localhost:8080/blog/app/entry/list > > A very basic weblog implemented in Grails. But the cool thing about it > is it demonstrates Grails non-templated approach to scaffolding. The > controller is essentially this: > > class EntryController { > @Property boolean scaffold = true > > @Property createComment = { > def e = Entry.get( this.params["entryId"] ) > > def c = new Comment() > c.properties = this.params > e.comments.add(c) > e.save() > > redirect(action:this.show,params:[ "id": this.params["entryId"] ] ) > } > } > > Note how there is only one action and it redirects to another action > "show" which is a scaffolded action, the rest of the actions are > scaffolded. > > At the moment only the server side actions are being scaffolded and > you have to write the views by hand, but its a start... > > Phase 2 will be getting scaffolding of the views done and > incorporating all of the stuff to do with constraints that was > discussed. > > BUT before phase 2 can commence I have to start the Grails tag library > as some aspects of the custom views will be dependant on this > (validation, linking etc.) > > Cheers, > Graeme > -- "If you want to be a different fish, you gotta jump out of the school." -- Captain Beefheart |
|
On 14/12/05, Steven Devijver <[hidden email]> wrote:
> Congrats man. I'd even say that's awesome! And all that is purely dynamic! No useless template generation tricks. -- Guillaume Laforge Groovy Project Manager http://glaforge.free.fr/blog/groovy |
|
In reply to this post by graemer
On 13/12/05, Graeme Rocher <[hidden email]> wrote:
> Basic scaffolding is now implemented in Grails. [...] Since I've been playing a little with Grails and with scaffolding, I took the opportunity to expand a little the documentation: I've added some notes on the available scaffolded actions. Please correct me if I'm wrong. And while playing with the controllers, and also when I was thinking about a new tag for the tag library to output standard views for displaying and creating/updating/ beans, I was wondering what would happen if you want to display two forms for the same kind of beans? Is there, or would there be a way to prefix the form fields with some prefix associated with each form to differentiate them so that there's no clash between the two? My use case was about a little genealogy application: you might view three or more forms representing persons in your family: an individual in the middle, and above two other forms for the parents of this person. You could enter / modify those three persons at the same time in the same page. -- Guillaume Laforge Groovy Project Manager http://glaforge.free.fr/blog/groovy |
|
On 02/01/06, Guillaume Laforge <[hidden email]> wrote:
> On 13/12/05, Graeme Rocher <[hidden email]> wrote: > > Basic scaffolding is now implemented in Grails. [...] > > Since I've been playing a little with Grails and with scaffolding, I > took the opportunity to expand a little the documentation: I've added > some notes on the available scaffolded actions. Please correct me if > I'm wrong. > > And while playing with the controllers, and also when I was thinking > about a new tag for the tag library to output standard views for > displaying and creating/updating/ beans, I was wondering what would > happen if you want to display two forms for the same kind of beans? Is > there, or would there be a way to prefix the form fields with some > prefix associated with each form to differentiate them so that there's > no clash between the two? Surely you just wrap each in its own <form> tag each with its own submit button? Meaning there would be no conflict as only the form you're interested in would be submitted. > > My use case was about a little genealogy application: you might view > three or more forms representing persons in your family: an individual > in the middle, and above two other forms for the parents of this > person. You could enter / modify those three persons at the same time > in the same page. > > -- > Guillaume Laforge > Groovy Project Manager > http://glaforge.free.fr/blog/groovy > |
|
On 02/01/06, Graeme Rocher <[hidden email]> wrote:
> Surely you just wrap each in its own <form> tag each with its own > submit button? Meaning there would be no conflict as only the form > you're interested in would be submitted. Hmmm right... right... I probably didn't recover from my New Year Eve ;-) Yeah, simply using different forms is the way to go. Thanks for spotting that. -- Guillaume Laforge Groovy Project Manager http://glaforge.free.fr/blog/groovy |
| Powered by Nabble | Edit this page |
