Hi Chris
Sorry it took me so long to reply.
On 17 Jul 2008, at 16:48, Christofer Dutz wrote:
Hi Jeremy,
doesn't dojo load a i18n resource for the messages?
It does, but this may be perceived as a problem because CForms users
expect to supply all of their own i18n messages (and I personally find
some of dojo's language a bit un-natural).
I don’t think it should
be a problem taking over this or getting Dojo to load our i18n
resources ...
This is most likely possible, but I have not looked into it yet.
xml-i18n resources for cocoon would have been really nice for
this ... in
the worst case I think it should be possible (it even might already
exist)
to create a resource-file-generator, that simply converts these nasty
text-form resource files to neat xml and then translate this to Dojo
i18n
resources with a simple xslt.
Are you confusing java i18n properties-type bundles with Cocoon i18n
xml message files?
Transforming Cocoon's XML bundles to Dojo's json-based format should
not be too difficult.
With the other problems ... well I agree that they might be
tricky ... but
what would the challenge be, if everything was easy? ;-)
Well, we should start with the low hanging fruit :
regExp, min, max, email, mod10, value-count etc.
I was googling for a JavaScript implementation of the XReporter
expression language, but no luck yet ;)
I have never written an interpreter before :)
But I was thinking about a simple case like this :
<fd:validation>
<fd:range min="number1 + 1">
<fd:failmessage>This number should be larger than the first
number.</fd:failmessage>
</fd:range>
</fd:validation>
client-side (off the top of my head) :
var min = 0;
try {
with (this.form) min = eval("number1 + 1")
} catch e {
// could not evaluate expression
}
so 'number1' gets evaluated in the scope of this.form.
but it quickly gets nasty ......
The languages comparison operator is a single '=' not a double one :(
References to fields can be relative (../fieldname) etc. etc.
I think the main difference in my approach and the old Cocoon
approach is
not to reinvent the wheel. I never quite understood all the
double-implemention of widgets. But I have to admit the old Dojo was
missing
quite some stuff and I even had to bugfix quite a lot in the Dojo0.4
Stuff.
At the moment simply using Dojo and providing some very basic
JavaScripts
should be sufficient.
Well one of the problems is that there is a big mismatch between the
assumptions behind Dojo and CForms.
eg. number fields
Cocoon expects no smarts on the client, so a user would typically have
a converter for a form value to send a locale-formatted string
representation of the number to edit to the client :
value: 1234567.89
sends: 1,234,567.89 (en_GB)
1 234 567,89 (fr_FR)
etc.
Cocoon then expects the formatted value in return.
Dojo however, expects to send and receive un-formatted numbers,
performing l10n client-side.
This is not impossible to resolve, but it indicates some of the less-
obvious complexities :)
Thanks for your feedback
regards Jeremy
