Does inList constraint map values in view?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Does inList constraint map values in view?

Marc Palmer Local
Hi,

Sorry for all the activity, but Grails has me enthusing :)

Does the inList constraint provide a mechanism to map actual values  
to view strings for scaffolded and non-scaffolded setups? i.e. can it  
look up the values against i18n strings and provide both the  
permitted value and the "display string" version in the correct user  
language?

If not, this would be a great feature. For example:

String countryCode

def constraints =  {
        countryCode(inList:['fr','us','de'])
}

Obviously those are the values we want for the fields, but in forms  
we want the display string based on the viewer's language, such as  
"France", "United States" and "Germany".

Is this supported currently?

I appreciate there are issues about where to get the strings from -  
you don't want to define these strings for every controller or  
property name you define, so you need a way to specify this, perhaps:


String countryCode

def constraints =  {
        countryCode(inList:getI18NDisplayStringOrderedMap
('myapp.countryNames', ['fr','us','de']))
}

Obviously the inList constraint would need to be aware of this, and  
the display strings made available in the dynamic properties added to  
domain classes. Without this the views get pretty ugly, and have to  
know what the controller means by the possible values, and increases  
scope for error etc.

Vis ordering, you'd have to supply the map ordered, and as in the  
method above optionally sorted by display string rather than value -  
but in some applications you'd want to define the order of display  
strings by value - i.e. like those sites that list a bunch of common  
countries at the top of a list of alphabetically sorted countries.

Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Does inList constraint map values in view?

graemer
Its not supported at the moment, but I would say that it would be
preferrable to modify the select tag to support this by changing them
to do something like:

from.collect {  message(code:it) ? message(code:it) : it }

Which will attempt to evaluate the values as messages from i18n bundle
otherwise fall back to just displaying the text

Graeme

On 6/27/06, Marc Palmer <[hidden email]> wrote:

> Hi,
>
> Sorry for all the activity, but Grails has me enthusing :)
>
> Does the inList constraint provide a mechanism to map actual values
> to view strings for scaffolded and non-scaffolded setups? i.e. can it
> look up the values against i18n strings and provide both the
> permitted value and the "display string" version in the correct user
> language?
>
> If not, this would be a great feature. For example:
>
> String countryCode
>
> def constraints =  {
>        countryCode(inList:['fr','us','de'])
> }
>
> Obviously those are the values we want for the fields, but in forms
> we want the display string based on the viewer's language, such as
> "France", "United States" and "Germany".
>
> Is this supported currently?
>
> I appreciate there are issues about where to get the strings from -
> you don't want to define these strings for every controller or
> property name you define, so you need a way to specify this, perhaps:
>
>
> String countryCode
>
> def constraints =  {
>        countryCode(inList:getI18NDisplayStringOrderedMap
> ('myapp.countryNames', ['fr','us','de']))
> }
>
> Obviously the inList constraint would need to be aware of this, and
> the display strings made available in the dynamic properties added to
> domain classes. Without this the views get pretty ugly, and have to
> know what the controller means by the possible values, and increases
> scope for error etc.
>
> Vis ordering, you'd have to supply the map ordered, and as in the
> method above optionally sorted by display string rather than value -
> but in some applications you'd want to define the order of display
> strings by value - i.e. like those sites that list a bunch of common
> countries at the top of a list of alphabetically sorted countries.
>
> Marc
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Does inList constraint map values in view?

Marc Palmer Local

On 27 Jun 2006, at 11:12, Graeme Rocher wrote:

> Its not supported at the moment, but I would say that it would be
> preferrable to modify the select tag to support this by changing them
> to do something like:
>
> from.collect {  message(code:it) ? message(code:it) : it }
>
> Which will attempt to evaluate the values as messages from i18n bundle
> otherwise fall back to just displaying the text
>

I'd err on the side of doing this at least in part in the model, so  
that alternative view technologies don't mean you have to rewrite all  
this stuff again.

Of course the message lookup should happen in the view, but the  
indication of where the messages should come from should be supplied  
by the model/controller I think. It makes it more tricky I know.

Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Does inList constraint map values in view?

graemer
On 6/27/06, Marc Palmer <[hidden email]> wrote:

>
> On 27 Jun 2006, at 11:12, Graeme Rocher wrote:
>
> > Its not supported at the moment, but I would say that it would be
> > preferrable to modify the select tag to support this by changing them
> > to do something like:
> >
> > from.collect {  message(code:it) ? message(code:it) : it }
> >
> > Which will attempt to evaluate the values as messages from i18n bundle
> > otherwise fall back to just displaying the text
> >
>
> I'd err on the side of doing this at least in part in the model, so
> that alternative view technologies don't mean you have to rewrite all
> this stuff again.
>
> Of course the message lookup should happen in the view, but the
> indication of where the messages should come from should be supplied
> by the model/controller I think. It makes it more tricky I know.

I would say nearly impossible, the message lookup is based on the
locale, the locale is looked up from the request and the request is
only available in the controller/view

Graeme

>
> Marc
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Does inList constraint map values in view?

Marc Palmer Local
>>
>> Of course the message lookup should happen in the view, but the
>> indication of where the messages should come from should be supplied
>> by the model/controller I think. It makes it more tricky I know.
>
> I would say nearly impossible, the message lookup is based on the
> locale, the locale is looked up from the request and the request is
> only available in the controller/view
>

I mean the bootstrapping problem of what prefix to use when looking  
up the messages - as this should not be bound to the name of the  
property so that it can be reused. i.e. a country list should be  
defined once and only once in every language, but then if there were  
say multiple country fields (countryYouResideIn,  
countryYouAreMovingTo) you don't want to define these twice in the  
content.

Ergo I believe a prefix like "myapp.mycountrylist" should be supplied  
by the model and used by the view to resolve the inList values i.e.  
"myapp.mycountrylist.fr" to display strings.

Kind regards,
Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email