Possible to render the form on server side?

[hrj]

If JS is disabled client side, it would be great if the basic form can be pre-rendered and served directly through HTML. Form submission would also be supported without JS, and rely entirely on server side validation.

[adamw]

True, but then wouldn't it make sense to use a traditional web framework instead? One of the goals of Supler is to provide an easy way to use the best of both client- and server- side processing.

[adamw]

Ah, well this could make sense if you wanted to support both JS-enabled and JS-disabled scenarios, so the server-side rendering would be a fallback. Not yet supported, but I don't see why it wouldn't be. You just need a way to run JS on the server. SuplerForm.render() produces HTML so this could be sent over the wire to the client.

[hrj]

Is SuplerForm.render() in Scala or JS? If Scala, that would work great. Running a JS engine for rendering HTML on server-side, although possible, seems convoluted.

[adamw]

That's JS. So far we have only client-side rendering. Evaluating JS on the server side would be a bit of a problem (even not with the JS engine, as there's one in Java, but more with having a DOM), but then if you are aiming at a solution which works both when clients have JS enabled or not, I don't think there's a better way?

[hrj]

Yeah, I am working on a JS + DOM project and can vouch for it being a non-trivial problem 😄

Have you considered directly rendering the form's HTML in Scala? It would be duplicate effort for sure, but Scala makes it a little easier with its inline support for XML.

Also, with something like ScalaJS, the rendering code could be shared between server side and client side, avoiding the duplication.

[adamw]

We didn't consider it yet, but it's a young project, so we are open to suggestions ;). The frontend and backend parts are separate and communicate only with two types of JSON objects.

ScalaJS would definitely make sense for a hybrid backend/frontend renderer. One of the reasons I was reluctant to use ScalaJS was that using Scala for the backend might scare people away, let alone using a relatively new project like ScalaJS. Not to mention Supler being new as well ;)

[hrj]

Hi again!

Quite a few things have changed in the last few months (for the better).

ScalaJS was declared to be no longer experimental, coincidentally on the date of your last reply :)

I have been using ScalaJS in a recent project and so far it seems to work fine. Also, I had a similar need as this project to render HTML/XML AST. For that, I have compiled scala-xml for JS. It was pretty easy and it works great. Related issue tracker.

I am also using autowire + upickle to automatically weld the Scala-JS frontend with Scala backend. Works awesome!

So, I encourage you once again to make Supler pure Scala. It could then be used on frontend and backend seamlessly.

cheers,
hrj

[adamw]

I'm following Scala.JS development as well, however I'm not sure there's any real benefit for the end user going full-stack Scala. We want to be able to operate with multiple JS frameworks/libraries, without requiring Supler's user to use a particular one. Also, wouldn't using Scala.JS fix the communication format between the client&server?

[hrj]

You can think of Scala-JS as just a better way to write JS. The user of Supler need not even be aware of it being written in Scala-JS. However, for those users who care, having the rendering logic in Scala would help then render the form on server-side.

About the communication format, it is entirely up to you to decide. I don't think using Scala-JS would necessitate any change in that (unless I am missing something). I just mentioned autowire+upickle because they worked fine for me; it is not something dictated by my choice of using Scala-JS.

[adamw]

Sure, I agree that we could write the Supler-frontend in Scala.JS, but that wouldn't have any functional impact on Supler user's (developers using Supler) I suppose?

So definitely a possibility in the future, but I wouldn't say it's a priority thing to do :). But we want to add multiple renderers (web, mobile), so maybe a Scala.JS one will be easier to do then as well.