On Jan 16, 2006, at 5:37 PM, mario ruggier wrote:
> On Jan 15, 2006, at 1:57 PM, Clark Evans wrote:
>
>> I have field validation code that currently is simple regex that I can
>> run both in javascript on the browser, and in python code on the
>> server. This has been working well. However, recently I've been
>> adding
>> data types that are a bit more complicated, and multi-input-field data
>> types that have an overall validity check. This doesn't work as
>> nicely with regular expressions -- but I'd like to keep my dual
>> client/server side checking. The two obvious solutions is to either
>> (a) duplicate your code in both javascript and python, or (b) write
>> your validation code in javascript and exec to spidermonkey. Neither
>> are great options.
>
> It seems to me that this, i.e. form validation, is really the only use
> case worth pursuing for such py->js functionality. And, instead of
> attacking generic py->js conversion, with all the problems as pointed
> out already, it may be more reasonable to just address this use case
> specifically. I mean, would it not be easier to just use a good
> validation library in python, replicate that functionality in
> javascript, and then have your form generating/handling framework to
> generate the glue js code along with the html to do the desired
> client-side checking calls, along with of course the python calls on
> the server. I.e. specify your form declaratively, and then have it
> validated automatically both on client and on server, using equivalent
> but manually produced validation libraries for each end.
> At this point I can't help mentioning this really nice generic
> validation module, spec.py, that is included in qp [1]. It allows you
> to specify data types of arbitrary complexity, with amazing
> expressivity, and automates the checking accordingly. It also builds
> on the types already available in python. Data specs can be simple,
> for example (using '_is' suffix convention to denote the type we want
> to constrain on the attribute):
>
> a_str_is = str
> a_some_str_or_unicode_is = string
> an_email_is = pattern('[EMAIL PROTECTED],3}$')
> a_string_or_int_is = either(string,int)
> a_list_of_int_is = [int]
> a_dict_strkeys_myclassvals_is = {str:instance('MyClass')}
> [1] http://www.mems-exchange.org/software/qp/
> Spec module is in qp.lib.spec, but has no dependency on the rest of
> the package.
That was well over a year ago... and it had got me to incorporate
exactly such a javascript validation equivalent into a python-based
server-side web framework... such that you declare (and always execute
on the server) your validation in python, and from which the exact
equivalent client-side validation is redundantly generated and executed
on the client, for a better user experience. The javascript library is
s simple version of the spec python module mentioned above -- it is
really an initial version, and nowhere as rich as the python
equivalent. It allows however to do validation tests such as pattern,
both, either (as in the samples above) ... or, in a form context,
EqualWidget (widget value must equal another widget's) or ShadowWidget
(status of this widget is bound to another one's). There is also Form
js code for full form checks. In this first version, the js Specs use a
simple and explicit test() method, while the python equivalents from
which they are generated use the more elegant python special method
__call__ (thus making the py Spec instances callable). For situations
where validation requires server-side logic or data, an ajax callback
may be declared on a form field...
This dual validation mechanism is built on top of the very able Form
module of the QP Web Framework (a python framework that is steeped in a
<http://gizmoweblog.blogspot.com/2007/02/2-million-page-views-day-with-
quixote.html> tradition). Anyhow, the validation mechanism is part of a
number of other extensions on this framework, of which probably the
most interesting for this list are:
Gizmo user interface objects, that may have a server-side and a
client-side component. The gizmo api is a simple pattern for
encapsulating user interface objects that know how to cooperatively
participate in the page generation process. Whatever you can imagine in
some combo of js. css and html, you can generate it and manage it
easier as a gizmo.
Gizmo Form, in which field types and the form object itself built on
the Gizmo api (are also Gizmos). As a small example of a Gizmo Form
showing a number of the features alluded to here, see the demo User
Registration form at <http://demo.gizmojo.org/register/>. The python
source code is embedded in the page, and do a view-source for the
automatically generated js... for the behaviour, play with some
values...
These extensions to QP are released at <http://gizmojo.org/>, under
LGPL. This (extension) framework embeds Mochikit, that is used to
facilitate all things javascript. MochiKit is actually used relatively
little, but i'd like to mention that without something like bind() I
would not have bothered to push the idea any further.
So, thanks a lot...
mario
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
