Hi Tron!
Thanks for your clarifications.
But this doesn't yet work for the official 1.1 release, I think.
At least the case of the generator failing on marked expressions.
I'm excited for the new release in that case :-)
>This, too, already exists: qx.locale.Manager.addTranslation().
Is the format of the map we supply here documented anywhere?
How is the plural case formatted in such a map, for example?
Does it remove the translations already available, or simple 'add to it' ?
>I would be interested to learn more about these use-cases.
In the past, one the qooxdoo developers asked me to clarify what I work on.
So perhaps, it's usefull to finally tell a little about that. Nothing too
spectactular though.
We maintain a generic data-centric application. Your typical back-office.
We use it as a CMS, for internal administration, pretty much anything you
would use excel or access for.
The general rule is: we have a set of models: from there the interface is
generated.
The 'build' version is model-agnostic. We supply the configuration (which
tables, which fields, which widgets) using json to the front-end and it
provides a nice interface.
The interface is tabs for each table, with a table-widget on the left, and
the record on the right, with a comment tree. There is a toolbar to
delete/create and quickly change the status of a record. (status is special
in this regard). The forms are displayed in qooxdoo-windows.
When I so model-agnostic, I mean, I can create backend models for a book
collection and throw in the same build-version of the client.
We've had a few iterations of this tool. I'm currently working on a new
iteration.
>I would be interested to learn more about these use-cases.
So to answer your question. Here are the typical use-cases where the rigid
translation support isn't flexible enough:
1. Generating forms based on information about the structure from the
backend. The form-labels need to be translated, but aren't marked in the
application. It's the backend that decides with fields to show, and tells
the application what the fields are called and what type of validation needs
to be applied.
Workarounds i've used here is:
- provide translated labels together from the backend when fetching
form-structures. Negatives: i have two places where there are translations
and i can't dynamically change the locale anymore.
- generate a static qooxdoo class with a big map that both marks the
translation, and allows for 'expression' based lookup. Downside: rebuild to
get translations. In this scenario that isn't a big problem, i'm often
running a database migration as well in these cases.
2. Having localisation needs both in the back-end as well as in the
front-end.
Workarounds:
- having two different localisation sets. Translate sets separately.
- don't use qooxdoo translations except for the default controls. Throw in
something manually, that uses a json database dump of the translations.
3. Needing the customer to be able to alter the translations on the fly.
Just like with any other CMS. The focus here is not the translation itself,
but the fact that the choice of words is something that needs to be
configurable. I haven't hit this one yet, because I haven't made a public
based qooxdoo site. (it's usually incompatible with SEO requirements
anyways) But I would hit it as soon as I would make a public site, and
typical customers have communication "experts" that reconsider every
publicly readable string of text every day. (don't ask me why). The
translation has to come from a database in this setup and part of the
application is managing the translations.
I think, some developers, like me, aren't using qooxdoo completely in line
with its 'philosophy'.
For example, I try to avoid duplicating model logic between the client and
back-end.
Imagine the typical case where you have to add a single field to a form.
- create a migration to add the field to the database schema
- add the support in the backend models (add backend validation)
- add the field to form code in qooxdoo (choose a widget)
- add model logic to the model in qooxdoo (new property, validation, etc.)
Although that gives a theoretical maximum flexibility, it's way overboard in
the abstraction fetish.
It's simply very expensive to work that way.
What we do, is simply provide a single field definition in the back-end:
# this is ruby code, just in case you are wondering
field :email, :regex => "###", :widget => 'qx.ui.form.TextField',
:required => true, :sql => 'VARCHAR'
It's a bit simplified from what we are really doing, (for example, we have
actual form types with are qooxdoo classes and which contain a factory
method for a form-widget and table-row-header)
But the idea is the same. From the above definition:
- we infer a database migration (comparing it with the current schema and
suggesting a migration script)
- a json file with the structure of all tables and their fields (this file
is loaded by the qooxdoo-based application)
- we get the same validation in both the client and the back-end
Then on the console:
rake gong:rebuild
And voila, we're ready. Go to the browser and press F5.
Since most of the complexity is in the qooxdoo-application, that part is
kept generic and is shared between projects.
As for translations, I think you can imagine the problem with using a .POT
file and marked strings.
Fortunately it sounds like, with the new release, I can use the localisation
support for my own strings as well.
And just create a json database dump that I feed to
qx.locale.Manager.addTranslation().
Greetings,
Ralf
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
