Hello, guys!
Sorry, but I can't understand why next code isn't work:
Example 1:
font = new qx.bom.Font(20 , [ "Tahoma", "Liberation Sans", "Arial" ]);
font.setColor("red");
label1 = new qx.ui.basic.Label("bla-bla-bla");
label1 = setFont(font);
but "bla-bl
Hi All,
I've just moved up to Qooxdoo 1.5 in what was a very simple transition from
1.4. Congratulaions on another successful release :)
One thing I have noticed is a minor issue with the automatic parser
detection in qx.io.request.Xhr.
The switch statement that determines the parser to use
My qooxdoo application is a Chrome browser plugin. As such I have two
applications living in the same source tree. This is necessary as the
Chrome applications can consist of up to 3 separate HTML/JavaScript
applications dwelling in the same directory (one is injected directly
into browser tabs, o
> Why don't you use references instead of the id's. Those are JS object which
> can be handed around as references.
> This can be done before the model has been created e.g. in the stores
> manipulateData delegate. Thats the way it should be use, I would propose.
That was my initial implementati
I forwarded it to Martin for reconsideration.
T.
On 08/03/2011 05:25 PM, panyasan wrote:
>
> Christian Schmidt-18 wrote:
>> Hi Christian,
>>> Doesn't the #ignore() hint take wildcards? Should I open a bug for this?
>>
>> You are right, the #ignore() doesn't support wildcards. You can open a
>> en
Again thank you for your patience and taking your own time to review my
problem. You actually solved my problem by forcing me to do something I
should have done w/o asking the question.
As I was preparing to send you the code to review I took the smart table
demo and added my problem code:
Hey,
> when working with data from a relational database is really common to
> have a column that refer to the primary key of another table (a
> foreign key). Suppose, for example, to model a bug tracking system. We
> can have a task that refer a state:
>
> var states = [
> { id: 1, name: "Open
Christian Schmidt-18 wrote:
>
> Hi Christian,
>> Doesn't the #ignore() hint take wildcards? Should I open a bug for this?
>
> You are right, the #ignore() doesn't support wildcards. You can open a
> enhancement request for this feature.
>
Did that early 2010 and forgot to mention it here
On Wed, Aug 3, 2011 at 09:20, Fink, Andreas wrote:
> > OTOH, new code should not be setting CONVERT_DATES to true. It should
> instead be using the normal mechanisms in JSON parsers to convert date
> strings in some known format into date objects, and vice versa.
>
> I didn't see any so called no
Hi Derrel :)
> If the pseudo date literal is intended to be backwards compatible with what
> we had originally, then it MUST NOT be quoted, and, you're right, it is not
> legal JSON, but it solves the problem we wanted to solve: to allow passing
> dates in a manner that was very fast to parse o
Hi,
when working with data from a relational database is really common to
have a column that refer to the primary key of another table (a
foreign key). Suppose, for example, to model a bug tracking system. We
can have a task that refer a state:
var states = [
{ id: 1, name: "Open" },
{ id: 2
On Wed, Aug 3, 2011 at 07:16, Tristan Koch wrote:
> Hi Andreas,
>
> the pseudo date literal needs to be quoted as string. Otherwise the JSON is
> invalid. I guess you'll need to configure your backend to detect and handle
> the literals (probably a regular expression).
>
If the pseudo date liter
Hi Tristan and panyasan,
thank you for your answers. It's like I thought then, the release 1.5 is
incompatible with the actual rpc backend... or let's say the date conversion is
not working anymore.
I managed to get the Date conversion working again by editing the parser of the
qooxdoo Rpc back
Hi Andreas,
the pseudo date literal needs to be quoted as string. Otherwise the JSON is
invalid. I guess you'll need to configure your backend to detect and handle the
literals (probably a regular expression).
Regards
Tristan
Am 03.08.2011 um 09:55 schrieb Fink, Andreas:
> Hi all,
>
> I thin
I think the reason is because the non-standard date parsing has been
deprecated to make the specs more standard-conforming.
I found this idea interesting:
http://weblogs.asp.net/bleroy/archive/2008/01/18/dates-and-json.aspx
This could be integrated into the qooxdoo JSON parser without breaking
a
Hi all,
I think I misunderstood something or I'm the only one who use qooxdoo
and the Java Rpc backend with date objects :)
Since the release 1.5 I'm not able to get the conversion of date objects
working (without changing framework or Rpc backend code).
If I set the flag qx.io.remote.Rpc.CONVERT
16 matches
Mail list logo
