There are some cases whose distinction can be interesting for a UI
(without much research, so it might not be accurate):
- Successful Web service call results:
  - Template output, no template or data-model errors
  - Template output that's cut at a point as it was too long
  - Failed data model building
  - Failed template execution (position can be interesting here on the
    long run)
- Service errors: I guess we just need the error message here.
- A bit of both: Long running template timeout. Usually it's the
  user's mistake... usually.

The *template* used by the current UI doesn't care about such details,
but what it displays was already assembled by code that also belongs
to the UI (i.e., to the JavaScript that processes the JSON response).
That logic is certainly simplistic currently, but then, UI-s can
change any time (and multiple different UI-s can co-exist), while Web
service API-s less so.


Saturday, August 29, 2015, 1:19:41 PM, Pradeep Murugesan wrote:

> Hi Daniel,
>  The thing I am trying to understand here is the need for all the 3
> fields of FreeMarkerServiceResponse for the UI.
> FreeMarkerOnline view while rendering the template just uses the 2 parameters.
> 1. Is there an error in the result 2. what is the error message
> <#if hasResult> <div class="resultContainer">           <label
> for="result">Result</label>              <textarea id="result"
> class="pure-input-1 source-code <#if errorResult> error</#if>"
> readonly>${result}</textarea>      </div></#if>
>
> So assuming we too need the same from Ajax requests
> I am returning the result & the error is found based on the status code of 
> the response.
> Kindly let me know your thoughts.
> Pradeep.
>
>
>
>
>> Date: Fri, 28 Aug 2015 22:51:52 +0200
>> From: [email protected]
>> To: [email protected]
>> Subject: Re: Rest Service for FreeMarkerOnline
>> 
>> The response should be JSON because we will need a few separate fields
>> there. If you look at FreeMarkerServiceResponse, you will see 3
>> candidates, but then you will find more, as the thrown exceptions also
>> carries information that's needed for the UI, as you can see in
>> FreeMarkerService.calculateTemplateOutput.
>> 
>> -- 
>> Thanks,
>>  Daniel Dekany
>> 
>> 
>> Friday, August 28, 2015, 9:57:58 PM, Pradeep Murugesan wrote:
>> 
>> > Sure Daniel,
>> >     I will change as per your comments.
>> >  A quick clarification regarding the json response can be like following ?
>> > { result: <output> }
>> > Pradeep.
>> >
>> >> Date: Fri, 28 Aug 2015 21:26:58 +0200
>> >> From: [email protected]
>> >> To: [email protected]
>> >> Subject: Re: Rest Service for FreeMarkerOnline
>> >> 
>> >> Friday, August 28, 2015, 7:53:45 PM, Pradeep Murugesan wrote:
>> >> 
>> >> > Hi Daniel,
>> >> >   I have made the rest service up @ a new path /compile
>> >> > The service takes the following json as input
>> >> > {    "template": "Hello ${user}",    "dataModel": "user=pradeep"}
>> >> > and then compiles the template and dataModel and returns the output.
>> >> > https://github.com/pradeepmurugesan/freemarker-online/commit/10de59ac0db0bf0f79ab28214f50c851a5610e20
>> >> >
>> >> > Please review the above commit and let me know if its ok.
>> >> 
>> >> The response will have to be JSON as well (not TEXT_PLAIN), but I
>> >> guess that was planned later.
>> >> 
>> >> The usage of the "compile" term is confusing here, as you actually
>> >> parse (aka. compile) and then "process" (aka. execute) here. The last
>> >> naturally implies the first. So I guess it should be, like, "run" or
>> >> "execute".
>> >> 
>> >> Also, all the web service operations should go under /api/, and the UI
>> >> outside it.
>> >> 
>> >> > Will
>> >> > Integrate with the UI. I have a questions though
>> >> > 1. Should I modify  in the same path as  "/" or keeping it in a
>> >> > separate path like "/compile" is fine ?
>> >> 
>> >> The UI addresses should remain /, and the current web service should
>> >> be under /api/run or something, I think.
>> >> 
>> >> > Also I will write unit tests once we finalize the path.
>> >> > Pradeep.                                          
>> >> 
>> >> -- 
>> >> Thanks,
>> >>  Daniel Dekany
>> >> 
>> >                                           
>> 
>                                           

-- 
Thanks,
 Daniel Dekany

Reply via email to