[grails-dev] Grails Constraints & Scaffolding

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[grails-dev] Grails Constraints & Scaffolding

graemer
Guys,

I've been thinking about constraints and the proposed scaffold
artifact and I'm not sure whether it would not just be better to
include this information in the constraints rather than introduce
another artifact.

The whole point is simplicity and i think introducing another artifact
will just complicate matters and as other frameworks (notably RIFE and
Trails) include this information in the constraints i think we should
follow the same path.

Also we could do some really awesome things in combination with Grails
dynamic persistent methods. For example to configure a select field
for a many-to-one relationship (say company for User instances) you
could do:

@Property constraints = {
          firstName(blank:false)
          lastName(blank:false)
          company(fieldType:"select",inList:Company.findAll())
}

This would produce a select like:

<select name="company.id">
          <option value="1">First Company</option>
</select

By default the label would be created from thhe property name (for
example "firstName" would become "First Name". otherwise you can
change this by adding a key say "user.firstName.label" to the resource
bundle and it would use this:

Also by default it would call toString() on company to get the text
but you could configure it like.

@Property constraints = {
           ........
          company(fieldType:"select",fieldParams:[ "key":
"company.id", value:"company.name"],inList:Company.findAll())
}

This kind of thing would be impossible to do in Java frameworks and
could be really awesome

What do you guys think?

Graeme
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grails-dev] Grails Constraints & Scaffolding

Guillaume Laforge-2
On 12/11/05, Graeme Rocher <[hidden email]> wrote:
> [...]
> This kind of thing would be impossible to do in Java frameworks and
> could be really awesome
>
> What do you guys think?

I think that makes sense, rather than creating a special artifact.
That's a good idea.

It takes care of the order of the fields cleanly, it allows us to
choose what kind of component is best to view that given information.

Seeing the "select" string made me wonder whether we could somehow
support custom widgets as well? For instance, if we're to show a date,
and don't want a mere text field but rather a nice calendard popup
div? or some other custom non-standard component? Could we somehow
register different components?

--
Guillaume Laforge
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [grails-dev] Grails Constraints & Scaffolding

Dierk König
In reply to this post by graemer
I think that's a valid alternative.
I comes at the expense of mixing concerns but that's probably fine in
this scenario.

how about

@Property constraints = {
    firstName(blank:false)
    lastName(blank:false)          
}
@Property displays = {
    company(fieldType:"select",inList:Company.findAll())
}

or even

@Property displays = { builder ->
    builder.select {
        Company.findAll().eachWithIndex { comp, i ->
            builder.option(value:i, comp.name)
        }
    }
}

where we could have different builders for different visualizations
(MarkupBuilder, SwingBuilder, RCPBuilder, ULCBuilder, ...)

The general issue remains that the model needs some implicit
knowledge about the application (workflow and visualization).

cheers
Mittie

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]On Behalf
> Of Graeme Rocher
> Sent: Samstag, 12. November 2005 12:02
> To: [hidden email]
> Subject: [grails-dev] Grails Constraints & Scaffolding
>
>
> Guys,
>
> I've been thinking about constraints and the proposed scaffold
> artifact and I'm not sure whether it would not just be better to
> include this information in the constraints rather than introduce
> another artifact.
>
> The whole point is simplicity and i think introducing another artifact
> will just complicate matters and as other frameworks (notably RIFE and
> Trails) include this information in the constraints i think we should
> follow the same path.
>
> Also we could do some really awesome things in combination with Grails
> dynamic persistent methods. For example to configure a select field
> for a many-to-one relationship (say company for User instances) you
> could do:
>
> @Property constraints = {
>           firstName(blank:false)
>           lastName(blank:false)
>           company(fieldType:"select",inList:Company.findAll())
> }
>
> This would produce a select like:
>
> <select name="company.id">
>           <option value="1">First Company</option>
> </select
>
> By default the label would be created from thhe property name (for
> example "firstName" would become "First Name". otherwise you can
> change this by adding a key say "user.firstName.label" to the resource
> bundle and it would use this:
>
> Also by default it would call toString() on company to get the text
> but you could configure it like.
>
> @Property constraints = {
>            ........
>           company(fieldType:"select",fieldParams:[ "key":
> "company.id", value:"company.name"],inList:Company.findAll())
> }
>
> This kind of thing would be impossible to do in Java frameworks and
> could be really awesome
>
> What do you guys think?
>
> Graeme
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grails-dev] Grails Constraints & Scaffolding

Steven Devijver-2
In reply to this post by graemer

On 12 Nov 2005, at 12:01, Graeme Rocher wrote:

> Guys,
>
> I've been thinking about constraints and the proposed scaffold
> artifact and I'm not sure whether it would not just be better to
> include this information in the constraints rather than introduce
> another artifact.
>
> The whole point is simplicity and i think introducing another artifact
> will just complicate matters and as other frameworks (notably RIFE and
> Trails) include this information in the constraints i think we should
> follow the same path.
>
> Also we could do some really awesome things in combination with Grails
> dynamic persistent methods. For example to configure a select field
> for a many-to-one relationship (say company for User instances) you
> could do:
>
> @Property constraints = {
>           firstName(blank:false)
>           lastName(blank:false)
>           company(fieldType:"select",inList:Company.findAll())
> }
>

I think we don't need to specify a field type, specifically for  
select. If we say:

     company({Company.findAll()})

that should be sufficient information to determine a select should be  
rendered. Also,
as far as I understand if the value is a method if needs to be inside  
a closure to be
allowed to re-run. I did the same for model data in SWF integration.
Also, the value of the field should always be the last argument  
meaning we don't have to
provide a key for the value.

With regards to rendering, I think we should use Groovy template to  
specify how each
artifact on the screen should be rendered. This would allow users to  
specify an optional type:

     company(type:"mySelect", {Company.findAll()})

Also, the value of the field should always be the last argument  
meaning we don't have to
provide a key for the value.


> This would produce a select like:
>
> <select name="company.id">
>           <option value="1">First Company</option>
> </select
>
> By default the label would be created from thhe property name (for
> example "firstName" would become "First Name". otherwise you can
> change this by adding a key say "user.firstName.label" to the resource
> bundle and it would use this:
>
> Also by default it would call toString() on company to get the text
> but you could configure it like.
>
> @Property constraints = {
>            ........
>           company(fieldType:"select",fieldParams:[ "key":
> "company.id", value:"company.name"],inList:Company.findAll())
> }
>

We can further extend the builder concept for constraints:

     company({Company.findAll()}) {
         key(company.id)
         value(company.name)
     }

This means a special company variable has to be made available
inside the scope of the company() method. With a little MetaClass
magic it should be possible to record the properties that are
being called.

> This kind of thing would be impossible to do in Java frameworks and
> could be really awesome
>
> What do you guys think?
>
> Graeme

Steven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[grails-dev] latest changes

Dierk König
In reply to this post by graemer
is there anything special we should test about your latest changes?

cheers
Mittie
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [grails-dev] Grails Constraints & Scaffolding

Dierk König
In reply to this post by Steven Devijver-2
> -----Original Message-----
> From: Steven Devijver [mailto:[hidden email]]
>      company({Company.findAll()})
>
> that should be sufficient information to determine a select should be  
> rendered.

yes,

    company { Company.findAll() }

actually. That'd be nice. Much better than my builder proposal :-)

> With regards to rendering, I think we should use Groovy template to  
> specify how each
> artifact on the screen should be rendered. This would allow users to  
> specify an optional type:
>
>      company(type:"mySelect", {Company.findAll()})

    company(type:'mySelect') { Company.findAll() }

Nice. That brings another issue to my mind.

The rendering of the company list may be different at different
places in the webapp.
E.g. in a simple edit screen you want to have it as select/option
while when listed as a search result, you would like to select
by clicking on a link in the result list.
Read-only views can also have different requirements:
in simple listings, a click on a company link may bring up the
details/edit view or may link to the company's corporate
website, i.e. do some very specific thing.
How would we handle such scenarios?

cheers
Mittie
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grails-dev] Grails Constraints & Scaffolding

Steven Devijver-2

On 12 Nov 2005, at 15:50, Dierk Koenig wrote:

>> -----Original Message-----
>> From: Steven Devijver [mailto:[hidden email]]
>>      company({Company.findAll()})
>>
>> that should be sufficient information to determine a select should be
>> rendered.
>
> yes,
>
>     company { Company.findAll() }
>
> actually. That'd be nice. Much better than my builder proposal :-)
>
>> With regards to rendering, I think we should use Groovy template to
>> specify how each
>> artifact on the screen should be rendered. This would allow users to
>> specify an optional type:
>>
>>      company(type:"mySelect", {Company.findAll()})
>
>     company(type:'mySelect') { Company.findAll() }
>
> Nice. That brings another issue to my mind.
>
> The rendering of the company list may be different at different
> places in the webapp.
> E.g. in a simple edit screen you want to have it as select/option
> while when listed as a search result, you would like to select
> by clicking on a link in the result list.
> Read-only views can also have different requirements:
> in simple listings, a click on a company link may bring up the
> details/edit view or may link to the company's corporate
> website, i.e. do some very specific thing.
> How would we handle such scenarios?
>

I think Grails should offer a library of HTML templates, for example  
different select styles, with or without AJAX.

In general, for configurational purposes Grails should use the Spring  
application context for setting up components:

<bean id="templates" class="java.util.HashMap">
    <constructor-arg>
       <props>
          <prop key="mySelect"><![CDATA[
<select name="<%= param.name %>">
    <% for (entry in map) { %>
    <option value="<%= entry.key %>"><%= entry.value %></option>
    <% } %>
</select>
          ]]></prop>
       </props>
    </constructor-arg>
</bean>

Steven

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grails-dev] latest changes

graemer
In reply to this post by Dierk König
I'm still testing a few things atm.. i committed what i did as i felt
it wouldn't have any impact but validation should be working shortly

Graeme

On 12/11/05, Dierk Koenig <[hidden email]> wrote:
> is there anything special we should test about your latest changes?
>
> cheers
> Mittie
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grails-dev] Grails Constraints & Scaffolding

graemer
In reply to this post by Steven Devijver-2
Like the ideas so far and agree with most my only comments are that
the templates should be in easily editable template text files that
get read-in to the spring config.. rather than embedded in xml which
is always nasty

Graeme

On 12/11/05, Steven Devijver <[hidden email]> wrote:

>
> On 12 Nov 2005, at 15:50, Dierk Koenig wrote:
>
> >> -----Original Message-----
> >> From: Steven Devijver [mailto:[hidden email]]
> >>      company({Company.findAll()})
> >>
> >> that should be sufficient information to determine a select should be
> >> rendered.
> >
> > yes,
> >
> >     company { Company.findAll() }
> >
> > actually. That'd be nice. Much better than my builder proposal :-)
> >
> >> With regards to rendering, I think we should use Groovy template to
> >> specify how each
> >> artifact on the screen should be rendered. This would allow users to
> >> specify an optional type:
> >>
> >>      company(type:"mySelect", {Company.findAll()})
> >
> >     company(type:'mySelect') { Company.findAll() }
> >
> > Nice. That brings another issue to my mind.
> >
> > The rendering of the company list may be different at different
> > places in the webapp.
> > E.g. in a simple edit screen you want to have it as select/option
> > while when listed as a search result, you would like to select
> > by clicking on a link in the result list.
> > Read-only views can also have different requirements:
> > in simple listings, a click on a company link may bring up the
> > details/edit view or may link to the company's corporate
> > website, i.e. do some very specific thing.
> > How would we handle such scenarios?
> >
>
> I think Grails should offer a library of HTML templates, for example
> different select styles, with or without AJAX.
>
> In general, for configurational purposes Grails should use the Spring
> application context for setting up components:
>
> <bean id="templates" class="java.util.HashMap">
>    <constructor-arg>
>       <props>
>          <prop key="mySelect"><![CDATA[
> <select name="<%= param.name %>">
>    <% for (entry in map) { %>
>    <option value="<%= entry.key %>"><%= entry.value %></option>
>    <% } %>
> </select>
>          ]]></prop>
>       </props>
>    </constructor-arg>
> </bean>
>
> Steven
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grails-dev] Grails Constraints & Scaffolding

Steven Devijver-2
+1

Regardless of where the template content is defined, I think putting  
the configuring in Spring makes sense. However, we have to think  
about extensibility from inside Grails.


On 12 Nov 2005, at 21:37, Graeme Rocher wrote:

> Like the ideas so far and agree with most my only comments are that
> the templates should be in easily editable template text files that
> get read-in to the spring config.. rather than embedded in xml which
> is always nasty
>
> Graeme
>
> On 12/11/05, Steven Devijver <[hidden email]> wrote:
>>
>> On 12 Nov 2005, at 15:50, Dierk Koenig wrote:
>>
>>>> -----Original Message-----
>>>> From: Steven Devijver [mailto:[hidden email]]
>>>>      company({Company.findAll()})
>>>>
>>>> that should be sufficient information to determine a select  
>>>> should be
>>>> rendered.
>>>
>>> yes,
>>>
>>>     company { Company.findAll() }
>>>
>>> actually. That'd be nice. Much better than my builder proposal :-)
>>>
>>>> With regards to rendering, I think we should use Groovy template to
>>>> specify how each
>>>> artifact on the screen should be rendered. This would allow  
>>>> users to
>>>> specify an optional type:
>>>>
>>>>      company(type:"mySelect", {Company.findAll()})
>>>
>>>     company(type:'mySelect') { Company.findAll() }
>>>
>>> Nice. That brings another issue to my mind.
>>>
>>> The rendering of the company list may be different at different
>>> places in the webapp.
>>> E.g. in a simple edit screen you want to have it as select/option
>>> while when listed as a search result, you would like to select
>>> by clicking on a link in the result list.
>>> Read-only views can also have different requirements:
>>> in simple listings, a click on a company link may bring up the
>>> details/edit view or may link to the company's corporate
>>> website, i.e. do some very specific thing.
>>> How would we handle such scenarios?
>>>
>>
>> I think Grails should offer a library of HTML templates, for example
>> different select styles, with or without AJAX.
>>
>> In general, for configurational purposes Grails should use the Spring
>> application context for setting up components:
>>
>> <bean id="templates" class="java.util.HashMap">
>>    <constructor-arg>
>>       <props>
>>          <prop key="mySelect"><![CDATA[
>> <select name="<%= param.name %>">
>>    <% for (entry in map) { %>
>>    <option value="<%= entry.key %>"><%= entry.value %></option>
>>    <% } %>
>> </select>
>>          ]]></prop>
>>       </props>
>>    </constructor-arg>
>> </bean>
>>
>> Steven
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [grails-dev] Grails Constraints & Scaffolding

Dierk König
In reply to this post by graemer
yep. the cdata section doesn't look very groovy.
I see two possibilities: text format like gsp or markupBuilder code

a) text format (gsp)

<select name="<%= param.name %>">
   <% for (entry in map) { %>
   <option value="<%= entry.key %>"><%= entry.value %></option>
   <% } %>
</select>

b) markup builder

select(name: param.name) {
    for (entry in map) {
        option(value:entry.key, entry.value)
    }
}

I expect you and steven to favour a) while I certainly favor b).
If I was left with a) I would most likely write:

<%
html = new MarkupBuilder(out)
html.select(name: param.name) {
    for (entry in map) {
        option(value:entry.key, entry.value)
    }
}
%>

So, as long as 'out' gets into the binding, I'm also ok with a) ;-)

cheers
Mittie


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]On Behalf
> Of Graeme Rocher
> Sent: Samstag, 12. November 2005 21:38
> To: [hidden email]
> Subject: Re: [grails-dev] Grails Constraints & Scaffolding
>
>
> Like the ideas so far and agree with most my only comments are that
> the templates should be in easily editable template text files that
> get read-in to the spring config.. rather than embedded in xml which
> is always nasty
>
> Graeme
>
> On 12/11/05, Steven Devijver <[hidden email]> wrote:
> >
> > On 12 Nov 2005, at 15:50, Dierk Koenig wrote:
> >
> > >> -----Original Message-----
> > >> From: Steven Devijver [mailto:[hidden email]]
> > >>      company({Company.findAll()})
> > >>
> > >> that should be sufficient information to determine a select should be
> > >> rendered.
> > >
> > > yes,
> > >
> > >     company { Company.findAll() }
> > >
> > > actually. That'd be nice. Much better than my builder proposal :-)
> > >
> > >> With regards to rendering, I think we should use Groovy template to
> > >> specify how each
> > >> artifact on the screen should be rendered. This would allow users to
> > >> specify an optional type:
> > >>
> > >>      company(type:"mySelect", {Company.findAll()})
> > >
> > >     company(type:'mySelect') { Company.findAll() }
> > >
> > > Nice. That brings another issue to my mind.
> > >
> > > The rendering of the company list may be different at different
> > > places in the webapp.
> > > E.g. in a simple edit screen you want to have it as select/option
> > > while when listed as a search result, you would like to select
> > > by clicking on a link in the result list.
> > > Read-only views can also have different requirements:
> > > in simple listings, a click on a company link may bring up the
> > > details/edit view or may link to the company's corporate
> > > website, i.e. do some very specific thing.
> > > How would we handle such scenarios?
> > >
> >
> > I think Grails should offer a library of HTML templates, for example
> > different select styles, with or without AJAX.
> >
> > In general, for configurational purposes Grails should use the Spring
> > application context for setting up components:
> >
> > <bean id="templates" class="java.util.HashMap">
> >    <constructor-arg>
> >       <props>
> >          <prop key="mySelect"><![CDATA[
> > <select name="<%= param.name %>">
> >    <% for (entry in map) { %>
> >    <option value="<%= entry.key %>"><%= entry.value %></option>
> >    <% } %>
> > </select>
> >          ]]></prop>
> >       </props>
> >    </constructor-arg>
> > </bean>
> >
> > Steven
> >
> >

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grails-dev] Grails Constraints & Scaffolding

Steven Devijver-2
I guess we can support both.


On 12 Nov 2005, at 22:02, Dierk Koenig wrote:

> yep. the cdata section doesn't look very groovy.
> I see two possibilities: text format like gsp or markupBuilder code
>
> a) text format (gsp)
>
> <select name="<%= param.name %>">
>    <% for (entry in map) { %>
>    <option value="<%= entry.key %>"><%= entry.value %></option>
>    <% } %>
> </select>
>
> b) markup builder
>
> select(name: param.name) {
>     for (entry in map) {
>         option(value:entry.key, entry.value)
>     }
> }
>
> I expect you and steven to favour a) while I certainly favor b).
> If I was left with a) I would most likely write:
>
> <%
> html = new MarkupBuilder(out)
> html.select(name: param.name) {
>     for (entry in map) {
>         option(value:entry.key, entry.value)
>     }
> }
> %>
>
> So, as long as 'out' gets into the binding, I'm also ok with a) ;-)
>
> cheers
> Mittie
>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]On  
>> Behalf
>> Of Graeme Rocher
>> Sent: Samstag, 12. November 2005 21:38
>> To: [hidden email]
>> Subject: Re: [grails-dev] Grails Constraints & Scaffolding
>>
>>
>> Like the ideas so far and agree with most my only comments are that
>> the templates should be in easily editable template text files that
>> get read-in to the spring config.. rather than embedded in xml which
>> is always nasty
>>
>> Graeme
>>
>> On 12/11/05, Steven Devijver <[hidden email]> wrote:
>>>
>>> On 12 Nov 2005, at 15:50, Dierk Koenig wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: Steven Devijver [mailto:[hidden email]]
>>>>>      company({Company.findAll()})
>>>>>
>>>>> that should be sufficient information to determine a select  
>>>>> should be
>>>>> rendered.
>>>>
>>>> yes,
>>>>
>>>>     company { Company.findAll() }
>>>>
>>>> actually. That'd be nice. Much better than my builder proposal :-)
>>>>
>>>>> With regards to rendering, I think we should use Groovy  
>>>>> template to
>>>>> specify how each
>>>>> artifact on the screen should be rendered. This would allow  
>>>>> users to
>>>>> specify an optional type:
>>>>>
>>>>>      company(type:"mySelect", {Company.findAll()})
>>>>
>>>>     company(type:'mySelect') { Company.findAll() }
>>>>
>>>> Nice. That brings another issue to my mind.
>>>>
>>>> The rendering of the company list may be different at different
>>>> places in the webapp.
>>>> E.g. in a simple edit screen you want to have it as select/option
>>>> while when listed as a search result, you would like to select
>>>> by clicking on a link in the result list.
>>>> Read-only views can also have different requirements:
>>>> in simple listings, a click on a company link may bring up the
>>>> details/edit view or may link to the company's corporate
>>>> website, i.e. do some very specific thing.
>>>> How would we handle such scenarios?
>>>>
>>>
>>> I think Grails should offer a library of HTML templates, for example
>>> different select styles, with or without AJAX.
>>>
>>> In general, for configurational purposes Grails should use the  
>>> Spring
>>> application context for setting up components:
>>>
>>> <bean id="templates" class="java.util.HashMap">
>>>    <constructor-arg>
>>>       <props>
>>>          <prop key="mySelect"><![CDATA[
>>> <select name="<%= param.name %>">
>>>    <% for (entry in map) { %>
>>>    <option value="<%= entry.key %>"><%= entry.value %></option>
>>>    <% } %>
>>> </select>
>>>          ]]></prop>
>>>       </props>
>>>    </constructor-arg>
>>> </bean>
>>>
>>> Steven
>>>
>>>
>

Loading...