thron7-2 wrote
>
>> I'm
>> super-impressed at the overall attention to detail and organization
>> expressed in the code and documentation. It'd be nice if the
>> documentation
>> was fleshed out a little more-- but hey, if you spend all your time
>> documenting you don't get to write as much cool code, eh? :-)
>
> John, thanks. It would be *very* helpful if you find any concrete issue in
> the documentation (ie. a piece of information missing, or some available
> information hard to understand) that you open a documentation bug for it.
> We are so deep into this stuff that we either not re-examine the
> documentation often enough, or, if we do, often fail to see the gaps and
> shortcomings in it.
>
Indeed, I completely understand and will be happy to help in that respect as
I get more knowledgeable about the toolkit. One of the things that I find
myself missing the most, perhaps, is code samples which illustrate how other
people have approached various issues using the toolkit. I do know there are
many demos, and a lot of contributed code already-- so please don't take
this as any sort of complaint by any means. Far from it, I am very impressed
with nearly everything I've seen with qooxdoo. Being able to look at other
people's code simply offers additional perspectives which can assist in
gaining understanding.
I think, now that I'm thinking about it-- what would be nice is a kind of
"cookbook", such as the "Perl Cookbook", and the like, where many common
tasks are outlined and approaches to solving the task using the code base
are compared and contrasted. Of course, that would be an effort in itself,
and probably one best left to the user community at-large. Do you have any
sort of online web structure that could support it? I guess it would sort-of
be a cross between a wiki and a faq??
In a similar vein, it's nice when the users can comment in context in the
documentation, such as on the PHP and PostgreSQL / MySQL documentation
sites. That way when someone is searching the manual looking for specific
information, additional opinions, examples and perspectives can be offered
by the user community in-context with whatever the documented concept is.
thron7-2 wrote
>
>> However, when I lifted the code from his example and plugged it into my
>> own, I keep getting console errors (which you can see in context on down
>> below) The first of which is appears to be the show-stopper:
>>
>> + Uncaught TypeError: Cannot read property 'constructor' of undefined
> Form.js:360
>> + qx.Class.define.members.__isModelSelectable Form.js:360
>> + qx.Class.define.members.addBindingOptions Form.js:136
>> + qx.Class.define.construct Simple.js:53
>
> Did you re-run 'generate.py source' in your project, before loading the
> app in the browser?!
>
Yes, that was one of the first things I tried (and several times). I have
learned that many small changes can be done without re-running
'generate.py', but whenever I have a problem loading or running, that's
always the first thing I try.
The code seems to be stopping at a point in the qooxdoo toolkit where it is
attempting to ascertain whether or not the model is "selectable"-- which
confuses me since I'm not sure how I would go about adding that (a Mixin,
I'd guess) but nothing in any documentation seems to suggest that I need
it-- and Martin's code sample, which I was comparing mine to, works fine
without it. In fact, unless I'm just overlooking something extremely silly
(which is possible, I'm good at that too :-) the only difference I can think
of between my code and Martin's code is that mine subclasses the Form
object-- and that doesn't seem to me like it oughta be the problem.
As an aside-- I will say, that I had some problems with the actual binding--
both in my code and in Martin's code-- due to the CAPTION NAME of the list
object. I had originally called it "Device Type" and had also specified an
internal name of "device_type". When it came time to bind, apparently the
routine keys off the object's CAPTION name instead of the object's ACTUAL
name-- is that correct? And if so, is there any way to use the actual name
instead?
When I remove the binding line ("formCtlr.addBindingOptions(deviceName, {
...") the code works fine. However, when I try to submit the form, this is
what I get on the back-end:
*qx.data.model.id"name[204-0]*
Which is not quite what I had in mind! :-)
I know I could cheat and ditch the model, but I'm trying to learn how to do
it the "right" way, according to the general scheme of the toolkit. I did
cheat with the tree-list and created custom versions of the treenode and
tree leaf objects which included a "tag" property. But I was okay with that
because it was a special case for a one-off situation.
thron7-2 wrote
>
>> I don't have a clue how to pronounce it
>
> That is actually quite easy: "Most people don't appreciate refined
> recipes, cooks do." :-)
>
> T.
>
Thanks for the tip. I've been pronouncing it like "Kudo"-- or more like
"Koo-doo"--- which I definitely have to extend to all you guys-- this is a
really nice toolkit. I know I've said that a number of times, but I spent a
couple of months meticulously studying what was available and Qooxdoo is
extremely useable. And I like it mostly because it skips nearly all of the
web / html and css BS and just let's me code.
John Whitten
--
View this message in context:
http://qooxdoo.678.n2.nabble.com/Having-problem-handling-selectBox-with-key-value-pairs-tp7581016p7581020.html
Sent from the qooxdoo mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
