Survey Response Validation

[Scott Gray-2]

Hi All,

I need to do some custom survey response validation that happens in addition to the OOTB answer validation.  I was hoping to be able to use Survey.responseService but this is run asynchronously and looks to be more of a post processor.

Any thoughts about about adding a validationService field to the Survey entity?  The service would run before the SurveyResponse is committed but after the OOTB answer validation.

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

[Bob Morley]

Scott Gray-2 wrote

I need to do some custom survey response validation that happens in addition to the OOTB answer validation.  I was hoping to be able to use Survey.responseService but this is run asynchronously and looks to be more of a post processor.

Any thoughts about about adding a validationService field to the Survey entity?  The service would run before the SurveyResponse is committed but after the OOTB answer validation.

We would make use of such a feature.

Is there an opportunity to plug-in a server-side validation service on any ModalForm?  Has this been discussed before from you knowledge (excuse my lack of search).  The theory would be that your dynamically generated ModelForm instance could apply this validation service to the model.  The RequestHandler on post-back could determine the ModelForm and execute any defined validation service (if technically feasible).

This would allow programmatic ModelForms an entry point for server-side validation as well as system-wide server-side validation via model transformation.  It could also be used to separate/share validation from execution in our standard xml representation of the ModelForm.

[Scott Gray-2]

On 30/04/2010, at 4:29 PM, Bob Morley wrote:

>
>
> Scott Gray-2 wrote:
>>
>> I need to do some custom survey response validation that happens in
>> addition to the OOTB answer validation.  I was hoping to be able to use
>> Survey.responseService but this is run asynchronously and looks to be more
>> of a post processor.
>>
>> Any thoughts about about adding a validationService field to the Survey
>> entity?  The service would run before the SurveyResponse is committed but
>> after the OOTB answer validation.
>>
>
> We would make use of such a feature.

Glad to hear it, thanks.

> Is there an opportunity to plug-in a server-side validation service on any
> ModalForm?  Has this been discussed before from you knowledge (excuse my
> lack of search).  The theory would be that your dynamically generated
> ModelForm instance could apply this validation service to the model.  The
> RequestHandler on post-back could determine the ModelForm and execute any
> defined validation service (if technically feasible).

What you could perhaps do is make sure you use services as your request map events and then create a special request/event that you can call via ajax that will valid the parameters against the service definition by serializing the form and telling it what your target request is.  There is a seldom used child element to service -> attribute called type-validate which can allow you to do custom field level validation on incoming parameters.
You just need to call modelService.validate(parameters, "IN", locale) in your special validation request/event and you're done.

Regards
Scott

> This would allow programmatic ModelForms an entry point for server-side
> validation as well as system-wide server-side validation via model
> transformation.  It could also be used to separate/share validation from
> execution in our standard xml representation of the ModelForm.
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Survey-Response-Validation-tp2075211p2076492.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[Bob Morley]

On Apr 30, 2010, at 6:41 AM, Scott Gray wrote:

>> Is there an opportunity to plug-in a server-side validation service  
>> on any
>> ModalForm?  Has this been discussed before from you knowledge  
>> (excuse my
>> lack of search).  The theory would be that your dynamically generated
>> ModelForm instance could apply this validation service to the  
>> model.  The
>> RequestHandler on post-back could determine the ModelForm and  
>> execute any
>> defined validation service (if technically feasible).
>
> What you could perhaps do is make sure you use services as your  
> request map events and then create a special request/event that you  
> can call via ajax that will valid the parameters against the service  
> definition by serializing the form and telling it what your target  
> request is.  There is a seldom used child element to service ->  
> attribute called type-validate which can allow you to do custom  
> field level validation on incoming parameters.
> You just need to call modelService.validate(parameters, "IN",  
> locale) in your special validation request/event and you're done.
>
> Regards
> Scott

What I am getting at here is an ability to model a "validation  
service" as part of the ModalForm.  How it is implemented (sever-side  
vs. ajax callback) would really be secondary.  I like the ajax  
approach for the validation that you have suggested in the  
implementation ... I was just thinking if you were going to add  
validation logic to your survey you could expose that through an  
extension to the ModelForm (since that is what survey is creating  
dynamically) and then we would have an ability that could be leveraged  
in a number of spots.  This would be versus having a survey validation  
service that your survey handler happens to call first before the  
async execution service.

[Scott Gray-2]

On 4/05/2010, at 2:21 AM, Robert Morley wrote:

>
> On Apr 30, 2010, at 6:41 AM, Scott Gray wrote:
>
>>> Is there an opportunity to plug-in a server-side validation service on any
>>> ModalForm?  Has this been discussed before from you knowledge (excuse my
>>> lack of search).  The theory would be that your dynamically generated
>>> ModelForm instance could apply this validation service to the model.  The
>>> RequestHandler on post-back could determine the ModelForm and execute any
>>> defined validation service (if technically feasible).
>>
>> What you could perhaps do is make sure you use services as your request map events and then create a special request/event that you can call via ajax that will valid the parameters against the service definition by serializing the form and telling it what your target request is.  There is a seldom used child element to service -> attribute called type-validate which can allow you to do custom field level validation on incoming parameters.
>> You just need to call modelService.validate(parameters, "IN", locale) in your special validation request/event and you're done.
>>
>> Regards
>> Scott
>
> What I am getting at here is an ability to model a "validation service" as part of the ModalForm.  How it is implemented (sever-side vs. ajax callback) would really be secondary.  I like the ajax approach for the validation that you have suggested in the implementation ... I was just thinking if you were going to add validation logic to your survey you could expose that through an extension to the ModelForm
> (since that is what survey is creating dynamically)

I haven't had a good look in a while but I thought FreeMarker templates were used to render surveys?

> and then we would have an ability that could be leveraged in a number of spots.  This would be versus having a survey validation service that your survey handler happens to call first before the async execution service.

[Bob Morley]

On May 3, 2010, at 5:53 PM, Scott Gray wrote:

>> What I am getting at here is an ability to model a "validation  
>> service" as part of the ModalForm.  How it is implemented (sever-
>> side vs. ajax callback) would really be secondary.  I like the ajax  
>> approach for the validation that you have suggested in the  
>> implementation ... I was just thinking if you were going to add  
>> validation logic to your survey you could expose that through an  
>> extension to the ModelForm
>> (since that is what survey is creating dynamically)
>
> I haven't had a good look in a while but I thought FreeMarker  
> templates were used to render surveys?
>

This is from memory for me too; but I believe what happens is  
FreeMarker templates are used to create xml that represents a  
ModelForm.  The survey logic than instantiates an instance of  
ModelForm from this dynamically generated xml and (I think) stores it  
in the context.  When the survey is rendered the survey screen  
includes this dynamic form instance using the context:// notation and  
standard html rendering takes over.  I may have that context usage a  
bit wrong ... but I remember creating some ftl to handle additional  
field-types that I wanted to render as part of my survey.

I remember thinking it might have been better to instantiate a  
ModelForm and then set the appropriate attributes / fields / etc on  
it, rather than the FreeMarker usage and generate xml, and then suck  
that in to result to the same place ... an instantiated form  
instance ... but I never acted on that thought.  :)

[Scott Gray-2]

On 4/05/2010, at 10:09 AM, Robert Morley wrote:

> On May 3, 2010, at 5:53 PM, Scott Gray wrote:
>
>>> What I am getting at here is an ability to model a "validation service" as part of the ModalForm.  How it is implemented (sever-side vs. ajax callback) would really be secondary.  I like the ajax approach for the validation that you have suggested in the implementation ... I was just thinking if you were going to add validation logic to your survey you could expose that through an extension to the ModelForm
>>> (since that is what survey is creating dynamically)
>>
>> I haven't had a good look in a while but I thought FreeMarker templates were used to render surveys?
>>
>
> This is from memory for me too; but I believe what happens is FreeMarker templates are used to create xml that represents a ModelForm.  The survey logic than instantiates an instance of ModelForm from this dynamically generated xml and (I think) stores it in the context.  When the survey is rendered the survey screen includes this dynamic form instance using the context:// notation and standard html rendering takes over.  I may have that context usage a bit wrong ... but I remember creating some ftl to handle additional field-types that I wanted to render as part of my survey.
>
> I remember thinking it might have been better to instantiate a ModelForm and then set the appropriate attributes / fields / etc on it, rather than the FreeMarker usage and generate xml, and then suck that in to result to the same place ... an instantiated form instance ... but I never acted on that thought.  :)

All very interesting :-) but if I look at genericsurvey.ftl for example, it's just generating straight up html

Regardless, what you're suggesting is an order of magnitude more work than what I've proposed so whether it's a nice feature or not, I won't be implementing it :-)

Regards
Scott

[Bob Morley]

On May 3, 2010, at 6:17 PM, Scott Gray wrote:

>>> I haven't had a good look in a while but I thought FreeMarker  
>>> templates were used to render surveys?
>>>
>>
>> This is from memory for me too; but I believe what happens is  
>> FreeMarker templates are used to create xml that represents a  
>> ModelForm.  The survey logic than instantiates an instance of  
>> ModelForm from this dynamically generated xml and (I think) stores  
>> it in the context.  When the survey is rendered the survey screen  
>> includes this dynamic form instance using the context:// notation  
>> and standard html rendering takes over.  I may have that context  
>> usage a bit wrong ... but I remember creating some ftl to handle  
>> additional field-types that I wanted to render as part of my survey.
>>
>> I remember thinking it might have been better to instantiate a  
>> ModelForm and then set the appropriate attributes / fields / etc on  
>> it, rather than the FreeMarker usage and generate xml, and then  
>> suck that in to result to the same place ... an instantiated form  
>> instance ... but I never acted on that thought.  :)
>
> All very interesting :-) but if I look at genericsurvey.ftl for  
> example, it's just generating straight up html
>
> Regardless, what you're suggesting is an order of magnitude more  
> work than what I've proposed so whether it's a nice feature or not,  
> I won't be implementing it :-)
>
> Regards
> Scott
>

Bah Mr. Gray!  I think what I was referring to was  
genericsurveyform.ftl.  Oh dammit!  I think this is something I must  
have implemented a year ago and only exists in our project LOL ...  Oh  
now it is coming back; we wanted to make use of party lookups (with  
ajax) and such in the forms, so it made sense to change the ftl to  
render a form and then leverage the standard form renderer.  I am so  
sorry; this was custom work I had done that I thought was OOB Ofbiz.

Any interest in it?  ;)

[Adrian Crum]

On 5/3/2010 3:27 PM, Robert Morley wrote:

>
> On May 3, 2010, at 6:17 PM, Scott Gray wrote:
>
>>>> I haven't had a good look in a while but I thought FreeMarker
>>>> templates were used to render surveys?
>>>>
>>>
>>> This is from memory for me too; but I believe what happens is
>>> FreeMarker templates are used to create xml that represents a
>>> ModelForm. The survey logic than instantiates an instance of
>>> ModelForm from this dynamically generated xml and (I think) stores it
>>> in the context. When the survey is rendered the survey screen
>>> includes this dynamic form instance using the context:// notation and
>>> standard html rendering takes over. I may have that context usage a
>>> bit wrong ... but I remember creating some ftl to handle additional
>>> field-types that I wanted to render as part of my survey.
>>>
>>> I remember thinking it might have been better to instantiate a
>>> ModelForm and then set the appropriate attributes / fields / etc on
>>> it, rather than the FreeMarker usage and generate xml, and then suck
>>> that in to result to the same place ... an instantiated form instance
>>> ... but I never acted on that thought. :)
>>
>> All very interesting :-) but if I look at genericsurvey.ftl for
>> example, it's just generating straight up html
>>
>> Regardless, what you're suggesting is an order of magnitude more work
>> than what I've proposed so whether it's a nice feature or not, I won't
>> be implementing it :-)
>>
>> Regards
>> Scott
>>
>
> Bah Mr. Gray! I think what I was referring to was genericsurveyform.ftl.
> Oh dammit! I think this is something I must have implemented a year ago
> and only exists in our project LOL ... Oh now it is coming back; we
> wanted to make use of party lookups (with ajax) and such in the forms,
> so it made sense to change the ftl to render a form and then leverage
> the standard form renderer. I am so sorry; this was custom work I had
> done that I thought was OOB Ofbiz.
>
> Any interest in it? ;)

I think there is some work being done to make the widget macros reusable
- so plain templates can use the widget goodies.

-Adrian