new rest2 webapp

[tombaeyens]

Huh, what is the rest2 webapp?

we're trying out a new rest style.  one that gives us better control.  we're not that happy with the indirect steps of the template rendering.  lot of things need to be right in order for it to work and we believe it could be done simpler.
so we're now trying out a simple servlet approach and building JSONObjects in the servlet that get streamed to the client.

the api should be fairly stable now.  rest api is not yet as there is already legacy in the original rest api.  so we want to combine 2 steps in one:
1) make the rest impl simpler
2) review the rest calls and sync them with the api as it is stable now.

but there is no final decision on this servlet strategy yet.   we're still in try-out mode.

[tombaeyens]

There are 2 reasons that are not addressed by freemarker templates:

1) Learning curve.  Erik included a quick intro, but it is key in a big project like Activiti to keep the number of technologies/languages that you use to a minimum.  If you're working 100% on UI, then it is probably worth investing time in that learning curve.  But we have a lot of people looking at the code and also, for the developers of the core engine, it's not worth investing learning curve as most of us will not have to write it.  But eventually that means we're stuck if we ever have to do it.

2) Less indirection.  If we have to trace why something is not as expected, then we have to follow two more levels of indirection of we use model + freemarker.  One time for building the model and another one for rendering the template.  Both these are replaced with just a single level of indirection that give direct search and refactor capabilities.

So the decision is that we'll go for direct domain model to JSONObject conversion in WebScripts and streaming that JSONObject directly in the response.

[davidcognite]

There are 2 reasons that are not addressed by freemarker templates:

1) Learning curve.
[…]
2) Less indirection.

Those same two reasons could be used to argue against ANY abstraction layer. The fact is that each technology is better for different tasks and it's the correct application of those technologies that makes a project easy to work with, not just the count of how many have been used.

Following those two arguments to their conclusion, are you planning on scrapping the webapps and having the Java print HTML, why bother with WebScripts at all? 😉

In all seriousness, I don't think that a non-standard WebScripts implementation which introduces an additional redirection layer (when the scripts defer back to Java for the rendering of certain types of content) is the way to keep things simple and decrease the learning curve.

[nils1]

Hi all,

even though I don't mind the freemarker templates, I think Tom has a point with his remarks. However, I'm surprised about the conclusions. The obvious solution, as I see it, would be to chose a more "main-stream" REST framework and see how it deals with content transformations. Instead we're going for a do-it-yourself approach and start re-inventing the wheel.

Is there a reason not to look into using a more widely known and popular REST framework? This has been brought up before in this discussion, maybe we could pick it up there…?

Another thought on the JSONObject approach: One of the main arguments that started this discussion was, that you want to be warned when you change something in the java code. Now, if we use JSONObject, our IDE might show errors or do the re-factoring automatically. But now we break the client instead. What exactly did we gain by that?

And finally, two thoughts on learning curve and levels of indirection:
1) do we really reach a better learning curve by hacking the webscripts frameworks built in content transformation mechanism?
2) Isn't the level of indirection introduced by the JSON transformation itself, independently of the technology used?

Cheers,
Nils

[erikwinlof]

@Joram:
Regarding the "abuse" of the WebScripts framework: As the name suggests its a scripting framework, now we're not using a single scripting language. We now hook in a "template engine" which actually is a java class. Im not trying to be a smart ass here, you might think its silly to mark these words, but the whole idea behind the framework is to simplify usage using scripting languages instead of java files.

A person that has used the webscript framework would surely be surprised the way we have used it and the learning curve would become greater since all webscript examples he would read wouldn't use a solution like this. Maybe this advocates for a different framework like David & Nils mentioned since this would be less confusing, even though I favor using what we have using freemarker.

@Tom:
Regarding "Indirection", I don't understand. We are still building the model and then using Java to render it instead of the freemarker so I don't think I have understood the reason why this becomes less indirect. Or are you afraid that strange this occur when freemarker "uses" the model and that they might be hard to solve?

@Nils
Unfortunately ( 🙂 ) we are actually NOT breaking the ui since the renderers are not using any automatic json creation, instead its manually creating the JSONObjects by doing: jsonObj.put("firstname", person.getFirstName()) so a change will not affect the ui.

Ok, last comment from me I guess you know where I stand, and maybe the decision was made 3 comments ago 🙂

Cheers everybody!

:: Erik