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}
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
>
