Grails

Allow a template to use the controller's properties as a model when no model is explicitly defined

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 1.0.2
  • Fix Version/s: None
  • Component/s: View technologies
  • Labels:
    None
  • Environment:
    All

Description

When rendering a view, if no model is explicitly passed, the view will use the controller's properties as a model.

The same behavior should happen with a template when using the g.render() method on a controller.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Graeme Rocher added a comment -

This doesn't really make sense if the view is using a custom model, then way would the template use the controller properties?

Show
Graeme Rocher added a comment - This doesn't really make sense if the view is using a custom model, then way would the template use the controller properties?
Hide
Permalink
Jean-Noël Rivasseau added a comment -

I don't understand your comment. What is not clear? If no model is specified when using g.render(), use the controller's properties as the model. If a model is given, use it. It would work similarly to the mechanism we have now for the views.

Show
Jean-Noël Rivasseau added a comment - I don't understand your comment. What is not clear? If no model is specified when using g.render(), use the controller's properties as the model. If a model is given, use it. It would work similarly to the mechanism we have now for the views.
Hide
Permalink
Graeme Rocher added a comment -

Ok I see, but I'm not sure I agree with the change. I often use the same variable names inside a template as inside a view and it is great having them isolated from each other. We could add an inherit=true flag or something so that the binding is inherited, but I don't believe what you're suggesting is a sensible default. It would also likely break quite a few applications

Show
Graeme Rocher added a comment - Ok I see, but I'm not sure I agree with the change. I often use the same variable names inside a template as inside a view and it is great having them isolated from each other. We could add an inherit=true flag or something so that the binding is inherited, but I don't believe what you're suggesting is a sensible default. It would also likely break quite a few applications
Hide
Permalink
Jean-Noël Rivasseau added a comment -

Again, I don't understand. How could this change possibly break some existing applications? Currrently a model (or bean) is given to the template, so this new feature would not break anything. Even if no model is given, nothing breaks by passing a new model to the template.

Also, what do you mean by using the same variable names inside a template and inside a view? This should not pose any problem with this change... so either I am missing something, or we are not understanding each other. What I propose is:

class MyController

{ def myString def myaction = { String test = g.render(template: "/something/somewhere", model: ["myString": myString]) } }

if by default the controller's properties would be passed in, we could just write

String test = g.render(template: "/something/somewhere")

and have the same result produced

Show
Jean-Noël Rivasseau added a comment - Again, I don't understand. How could this change possibly break some existing applications? Currrently a model (or bean) is given to the template, so this new feature would not break anything. Even if no model is given, nothing breaks by passing a new model to the template. Also, what do you mean by using the same variable names inside a template and inside a view? This should not pose any problem with this change... so either I am missing something, or we are not understanding each other. What I propose is: class MyController { def myString def myaction = { String test = g.render(template: "/something/somewhere", model: ["myString": myString]) } } if by default the controller's properties would be passed in, we could just write String test = g.render(template: "/something/somewhere") and have the same result produced
Hide
Permalink
Graeme Rocher added a comment -

There is no scope / time to resolve these remaining lower priority issues for 1.2 so moving to 1.3

for 1.2 final only issues considered blocking will now be fixed

Show
Graeme Rocher added a comment - There is no scope / time to resolve these remaining lower priority issues for 1.2 so moving to 1.3 for 1.2 final only issues considered blocking will now be fixed
Hide
Permalink
Jean-Noël Rivasseau added a comment -

Hmm, why won't fix? I think I have explained relatively in length what I would like, and why it would make sense...

Show
Jean-Noël Rivasseau added a comment - Hmm, why won't fix? I think I have explained relatively in length what I would like, and why it would make sense...
Hide
Permalink
Graeme Rocher added a comment -

Just because you like something doesn't mean it will make it into Grails core. This would be a breaking change (both in terms of documentations/books and functionality) that the Grails team don't regard as worth it. And since nobody else has voted for this issue in the 2 years it has been open it seems no one else feels too strongly about it either.

Show
Graeme Rocher added a comment - Just because you like something doesn't mean it will make it into Grails core. This would be a breaking change (both in terms of documentations/books and functionality) that the Grails team don't regard as worth it. And since nobody else has voted for this issue in the 2 years it has been open it seems no one else feels too strongly about it either.

People

  • Assignee:
    Graeme Rocher
    Reporter:
    Jean-Noël Rivasseau
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: