validator merge (was Re: [...)

On Monday 15 September 2003 14:43, Michael Flanagan wrote:
> Alex Russell wrote:
> > On Monday 15 September 2003 13:45, Michael Flanagan wrote:
> >>diff -u -r1.133 netWindows.js
> >>--- netWindows.js	14 Sep 2003 01:26:01 -0000	1.133
> >>+++ netWindows.js	15 Sep 2003 18:40:41 -0000
> >>@@ -1247,6 +1247,7 @@
> >>+			this.addIncURL(this.widgetPath+"validators.js");
> >
> > I REALLY don't like this solution. validators.js is not a core file an
> > doesn't deserve to be loaded in every page. This is a band-aid and not
> > one I'm comfortable with. I'll try to debug the real problem this
> > evening.
>
> I'm not as convinced as you are. Before getting the why, I'll outline
> functionality I think was lost in the import.
>
> I use to be able to do the following to apply a mask to an arbitrary
> piece of data:
>
> __meta__.phone.apply(varUnformattedData);
> and
> __meta__.phone.remove(varFormattedData);
>
> AFAICT, the new __validators__ singelton doesn't provide any mechanism
> to arbitrarily call any of the registered validators. You have to
> instantiate it on the DOM Node and call DOMNode.changed(); if you want
> the mask applied. Seems a little heavy to me. Have I just missed where
> that functionality moved to?

The new __validators__ object is just a mapping to ctor names. Nothing more 
fancy than that. In fact, I toyed with doing away with it altogeather and 
folding it all into validator_widget.js (which I may still do).

The syntax you use above is a side-effect of having a pool of validator 
objects around (one of each type registered), and it's not one I'm opposed 
to. I guess I just wasn't a huge fan of all the registry overhead for what to 
me seems like a utility lookup.

> The primary reason I think __validators__ (with the functionality
> outlined above) should be included in the core files, is that it's a
> helper class that lets you apply format strings to arbitrary pieces of
> data.

I'm in favor of such a set of utilities. The validators as submitted would 
need some work to be that decoupled from nodes, which was my basic conundrum 
when integrating these: it's really hard to have it both ways without adding 
a lot of overhead, and I wasn't a fan of the parallel inline ctor dispatch 
system. I may have been over-agressive in my cutting, so perhaps there's a 
way to add the validator pool back without returning too much of the previous 
overhead.

How about something like:

__validators__.pool.phone.apply(...);

is that too wordy? Too verbose?

> Ya, you could include validators.js in nwWrapper.js so that it was
> loaded on every page, but we don't have to do that with tooltips.js or
> utility_core.js
>
> I know there's a boolean __config__.includeTooltips, but it defaults to
> true. If that's loaded by default, I see no reason why somthing that can
> provide just as much utility for formatting data isn't loaded by default.
>
> IMO, anyone using nw in some kind of serious manner where they're trying
> to reduce the screen refresh's as much as possible are going to be
> operating with direct DOM Nodes a lot. If that's the case, then they'll
> need to be doing formatting of data on the front end as upposed to on
> the server side. It's the amount of use I see the class getting that
> justifies its inclusion into the core files.

If we can figure out a way to get all the ctor crap out of validators.js, then 
I support such a thing. As is, though, anything that's defining 
widgets/behaviors and their ctors really doesn't belong in the core (sorry, 
this is just one of those BDFL gut calls). Comingling the validation and node 
behavior code seems less and less advantageous the more I think about it. 
Perhaps I'll give this some more thought.


Regards.
-- 
Alex Russell
[email protected]    BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
[email protected]  F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46

_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org