Saturday, August 29, 2015, 4:12:16 PM, Pradeep Murugesan wrote:
> okay..
> So almost all the errors we handle should go under Success right.
> Having a structure like this would help I believe.
> { error: true/false, outputTruncated: true/false, failureReason: String
> output: String}
That's for the HTTP 200 answers only, I assume. We miss the
information about which field the failureReason applies to. So, I
think, the cleanest and most flexible would be if we remove "error"
(it's confusing and redundant anyway) and "failureReason", and instead
add a "problems" JSON Object, in which the keys are the field names,
and the value are the error descriptions. It's like some simple form
processing answer.
And then there are the HTTP 5xx errors. There I think we can get away
with an "errorCode" and an "errorDescription" for now.
--
Thanks,
Daniel Dekany
> Based on the error flag we can decide what to display. Sorry If I
> am taking a longer time to get hold of things.
> Pradeep.
>> Date: Sat, 29 Aug 2015 14:34:58 +0200
>> From: [email protected]
>> To: [email protected]
>> Subject: Re: Rest Service for FreeMarkerOnline
>>
>> 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
>>
>
