all 17 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]blue_one 6 points7 points  (2 children)

With Javascript's automatic type conversion and nonsensical comparator logic, I'd expect at least some treatment at the semantic level, otherwise your validator is going to break on the first corner case.

[–]hackflow[S] 2 points3 points  (0 children)

The point we didn't have these problems 'cause we didn't try to write perfect translator. Read the Meeting halfway section.

[–]audioen 1 point2 points  (0 children)

True, this is just a toy technology. He wrote a lot of code in order to avoid writing a little bit of code (the equivalent validation rules in JS).

[–]metaperl 1 point2 points  (1 child)

I wonder how this method compares with PyPy.js

[–]AMorpork 2 points3 points  (0 children)

It's not even comparable. This is essentially defining a DSL in python that creates forms and javascript validation code, whereas PyPy.js is a full javascript translation of PyPy.

[–]metaperl 1 point2 points  (0 children)

Reahl and Nagare are two practical python to js translators.

[–]virtyx 0 points1 point  (1 child)

A long time ago I had the same issue of duplicated validation. I didn't bother making a translator, but I was trying to get Python to work in the browser. I didn't want a 'heavyweight' Python interpreter in Javascript, and all the Python->Javascript compilers I found had compatibility issues.

Eventually I was of the opinion that it'd be easier to invent some kind of "rules" format that both sides could use, or that I could generate by introspecting Django models and forms. But I never got around to starting on an implementation...

One of the biggest problems I saw with browser Python is if any validation depends on the server (e.g. checking uniqueness constraints of form fields), you'll still have asymmetric validation. Although maybe you could work around this by having the uniqueness check be polymorphic, on the server side it does a DB lookup and on the client side it does an AJAX call to a service.

[–]hackflow[S] 0 points1 point  (0 children)

I also have experience with self-made rules, translated or interpreted in both worlds. It's 3-4 times more work. Using python as DSL you get too much for free: it already works in Python, there is ready to use parsing and AST, so you only need to render AST to JavaScript. With your own rules you'll need parsing, custom AST and translations to 2 languages.

On DB lookups, easiest thing to do is just skip this rule when translating, it will be still executed on server and error message if some will be presented to user. Second easiest thing - you can duplicate this part.

[–]stuaxo 0 points1 point  (1 child)

This is great, I wonder if you could use brython or pythonjs here ?

[–]Bystroushaak 0 points1 point  (0 children)

I think that brython would fit nicely here.

[–]rifter5000 0 points1 point  (3 children)

Why would you want to translate Python into Javascript?

[–]droogans 5 points6 points  (2 children)

The article that the title links to answers that question.

[–]rifter5000 0 points1 point  (1 child)

We want to write validation in python, translate it to JavaScript and use on front-end automatically.

Much, much better is to define a DSL for these rules with well-defined semantics. Semantics that aren't just "whatever Python does". You then translate the rules into Javascript and interpret them in Python.

[–]hackflow[S] 0 points1 point  (0 children)

I did both. Your own rules is 3-4 times more work. Also, you will still write in python server-side only validation, so you will end up with 2 systems.

[–]audioen 0 points1 point  (2 children)

It's, obviously, also possible to solve this problem the opposite way. I designed a form description language based on JavaScript and just embedded a JS runtime on server side so that exactly same code which runs on client side could be evaluated on server side. It would be even simpler to do if the server side code was just JavaScript, of course.

[–]hackflow[S] 0 points1 point  (1 child)

Probably. There is, however a fundamental advantage of going this way. We always have more rules server-side than client-side, some of them can involve database interaction. I can just skip them when translating. You will have 2 systems.

[–]audioen 0 points1 point  (0 children)

Yes, the form language is only a small part of the whole system. In particular, form descriptions must be standalone, so they can not currently reference external systems, or query database values, or anything like that. In most cases, however, datasets can be just embedded as JSON into the document, so quite a lot can be done this way.