Passing named parameter without the URL

[thron7]

Kenny,

maybe a bit of background info regarding this topic, if you have the time.

Within the qooxdoo world there are various different hierarchies where
you have parent-child relations. The topic you are hinting at is the
structure of framework widgets like the SplitButton. While
getLayoutParent() is the canonical method to traverse nested widget
structures, it's not always "you get what you see", since a complex
widget like the SplitButton employs other widgets and layouts itself,
not all obvious, and for a generic method like getLayoutParent() it is
not obvious whether an enclosing widget is the "logical" parent of the
one you're looking at, or just an implementation aid.

To amend for this, some complex widgets even expose their own hierarchy
traversing methods, like qx.ui.tree and its getParent() method. If you
applied getLayoutParent() to, say, a tree folder, you wouldn't get the
upper-level tree folder or the tree root widget. Rather, you'd get all
kinds of intermediate widgets that are used to implement the Tree
widget's look and feel.

Normally, you get to the "logical" parent eventually, e.g. when starting
from a widget nested into a Window widget, where you get to something
like the WindowPane before getting to the Window widget itself. In your
particular case this was probably even worse - you wrote it took you to
Menu and then to Application - since IINM a menu has to have the
Application as parent, in order to position it correctly within the
browser pane. You see, implementation details interfer with the logical
groupings. I wish there were a logical hierarchy traversing method that
worked intuitively across all widgets, but I'm afraid that's not the
case currently :-(.

HTH,
Thomas

Kenny Tilton wrote:

> My first qooxdoo trick is modifying the SplitButton example to have the
> button reflect the selected value:
>
>        menuItem.addListener("execute", function(e){
>   button.setLabel(this.getLabel());
>  });
>
> Where the anonymous function closes over the local variable button to
> know who to set. As an exercise in learning qooxdoo, tho, I wanted to
> find the split button instance by navigating up the qui hierarchy
> looking for such a beast:
>
> function getAscendantTyped(self,type) {
>    if (self) {
>       var par = self.getLayoutParent(); // not .parentNode it seems
>       console.log("getasc sees parents " + par);
>       if (par instanceof type) {
> return par;
>       } else {
>          return getAscendantTyped(par, type);
>       }
>    }
> }
>
> This (or something close, I have been cleaning it up since pasting it
> from my actual code) looks like it will work, but that "Layout" bit has
> me nervous. Yet I cannot find anything more promising.
>
> I got all excited about parentNode when I saw that used by getAncestors,
> but then I could not find anywhere in the source that getAncestors was used.
>
> So is getLayoutParent the way to navigate up a qooxdoo visual hierarchy?
>
> kt
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>  

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Kenny Tilton-2]

thron7 wrote:
> Kenny,
>
> maybe a bit of background info regarding this topic, if you have the time.
>
> Within the qooxdoo world there are various different hierarchies where
> you have parent-child relations.

<snip good stuff>

Yeah, I realized what was going on right away (been using/building
frameworks since the Think Class Library) and realized I'd need some
guru guidance. of course even better was finding the right widget!

 > I wish there were a logical hierarchy traversing method that
> worked intuitively across all widgets, but I'm afraid that's not the
> case currently :-(.

I think what you have is fine. I was rooting around looking for a
backdoor to get the split button to do something it was not meant to do,
that was my mistake.

I realized /that/ when I saw the next stop up after the menu was the
application, which is the way frameworks always organize "command"
menus, so I knew I had the wrong widget and went looking for the right
one (SelectBox).

Thx for the trouble you took with the detailed explanation.

cheers, kenny

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Petr Kobalíček]

Hi Darrell,

I'm not currently at home, but I have no problems with sharing my
transport layer (it's about 300 lines of code). I think that GET and
POST requests can work same way, it just differs where the parameters
are (in URL or in BODY).

My way is simple, for example JSON parameters:
{
  id: 1,
  lang: "en"
}
will be encoded as id=1&lang=en, escaped, etc... :) and passed to
qooxdoo request by setData() - it's really simple:)

Cheers
- Petr

2008/11/18 Derrell Lipman <derrell.lipman@...>:

> On Mon, Nov 17, 2008 at 5:17 PM, Petr Kobalíček <kobalicek.petr@...>
> wrote:
>>
>> Hi devs,
>>
>> I have only one thing about this discussion.
>>
>> I really don't understand, why setFormField() must use different
>> transport method. I wrote some time ago own transport class for our
>> app, because way that setFormField() works not worked for me well.
>>
>> Maybe in older mails is some more info, but the question is, is really
>> needed to switch transport by using setFormField() ? My way is that I
>> will serialize parameters and use setData(). This works fine and I
>> haven't encountered problem yet.
>>
>> Only disadventage is that uploading not works by this way, but for
>> uploading we have another solution, aren't we ?
>>
>> The requests and responses I'm using looks like this:
>>
>>          var req = new
>> bfly.io.remote.Request(this.provider.opt.address.remove, "POST");
>>
>>          req.addPostParameter("id", this.getId());
>>          req.addListener("success", function(e)
>>          {
>>            this.provider.query("$", /*force*/ true);
>>          }, this);
>>          req.addListener("error", app._onRequestFailure, app);
>>          req.send();
>
> Hi Petr.  The whole set of qx.io.remote.* is not ideal.  We know, and a
> number of us have discussed this in the past.  It does, however, work for
> most applications, and no one has gotten around to actually rewriting it.
> If you've written a replacement set of transport classes, I'd be interested
> in seeing them.  If you'd like to contribute your work, please either create
> a qooxdoo-contrib project with them or create a new bug and attach them to
> the bug so we can see what you've done.
>
> Thanks!
>
> Derrell
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7]

>> Using setParameter() specifically tells it to encode the parameters in the
>> URL.  I believe you're looking for setFormField().
>>    
> If you have form fields, then a different transport will be used.

This is true, but I strongly object against the XmlHttp transport being
restricted to GET and URL parameters. If this is really the case,
somebody has to open up a bug for it. XmlHttp transport has to support
POST and setParameters() working on the request body!

Side note: Jean-Baptiste, make sure you are using each request object
only *once*!

Thomas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Derrell Lipman]

On Tue, Nov 18, 2008 at 8:14 AM, thron7 <thron7@...> wrote:

>> Using setParameter() specifically tells it to encode the parameters in the
>> URL.  I believe you're looking for setFormField().
>>

> If you have form fields, then a different transport will be used.

This is true, but I strongly object against the XmlHttp transport being
restricted to GET and URL parameters. If this is really the case,
somebody has to open up a bug for it. XmlHttp transport has to support
POST and setParameters() working on the request body!

XmlHttp transport _does_ support POST.  That's not the issue.  The issue which has been discussed in depth in the past is that even with POST, it must be possible to add parameters to the URL.  You (and the reset of those in this discussion) are right that there *should* be a way to add parameters to the POST request body.  There's just no way to explicitly specify that currently.   This is just one of many issues that have been addressed in the past, that should be addressed in a rewrite of qx.io.remote.*

Cheers,

Derrell

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

On 18 Nov 2008, at 14:14, thron7 wrote:

>
>>> Using setParameter() specifically tells it to encode the  
>>> parameters in the
>>> URL.  I believe you're looking for setFormField().
>>>
>> If you have form fields, then a different transport will be used.
>
> This is true, but I strongly object against the XmlHttp transport  
> being
> restricted to GET and URL parameters. If this is really the case,
> somebody has to open up a bug for it. XmlHttp transport has to support
> POST and setParameters() working on the request body!
>
> Side note: Jean-Baptiste, make sure you are using each request object
> only *once*!
>

Yes, it's a brand new instance for each request.

> Thomas
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

On 18 Nov 2008, at 14:23, Derrell Lipman wrote:

On Tue, Nov 18, 2008 at 8:14 AM, thron7 <thron7@...> wrote:

>> Using setParameter() specifically tells it to encode the parameters in the
>> URL.  I believe you're looking for setFormField().
>>

> If you have form fields, then a different transport will be used.

This is true, but I strongly object against the XmlHttp transport being
restricted to GET and URL parameters. If this is really the case,
somebody has to open up a bug for it. XmlHttp transport has to support
POST and setParameters() working on the request body!

XmlHttp transport _does_ support POST.  That's not the issue.  The issue which has been discussed in depth in the past is that even with POST, it must be possible to add parameters to the URL.  You (and the reset of those in this discussion) are right that there *should* be a way to add parameters to the POST request body.  There's just no way to explicitly specify that currently.   This is just one of many issues that have been addressed in the past, that should be addressed in a rewrite of qx.io.remote.*

I didn't know it was discussed before, sorry ...

So, I do agree with you : parameter to the POST request body is a need.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7]

> So my question : how to have HTTP request parameter, not form field,  
> using the body of the request, not URL ?
>  
If POST and body parameter with setParameter() really fails (which I'm
not completely convinced of), as a fall-back, you can always construct
the parameter string yourself and set it with setData() (as Petr does in
his derived class).
> I remember from JEE API that you have a method like  
> request.addParameter(String name, String value) that can pass  
> parameter in the body of the HTTP request, not using the URL.
> I forgot the details ...
>  

Again, I feel this should work the same in qooxdoo with setParameter()
if the method of the request is POST (and still run over XmlHttp transport).

> So, I like the idea of having a req.addPostParameter("id", this.getId())
> but then, I don't understand the code around, see the comments in the  
> code : (question or comments before the line)
>
> Is it a specific implementation of some underlying transport layer ?
> If yes, how can you register new transport layer, how to you choose to  
> use it ?
>  

I believe this code uses Petr's derived request class. But I don't think
you have to resort to all kinds of new transport layers, nor trunk
version of qooxdoo. If POST and setParameter() don't work as expected
that's a bug in my view, and you can easily work around with setData()
in your own code.

Thomas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7]

> XmlHttp transport _does_ support POST.  That's not the issue.  The issue
> which has been discussed in depth in the past is that even with POST, it
> must be possible to add parameters to the URL.  You (and the reset of those
> in this discussion) are right that there *should* be a way to add parameters
> to the POST request body.  There's just no way to explicitly specify that
> currently.   This is just one of many issues that have been addressed in the
> past, that should be addressed in a rewrite of qx.io.remote.*
>  

Ok, now I get it. So I believe you'd agree that for the time being
setData() is the way to work around that limitation?!

Thomas


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7]

Jean-Baptiste BRIAUD -- Novlog wrote:

> Hi,
>
> As we talked about several issues, I split them into several messages.
> That one is about using SVN trunk of qooxdoo for developping a
> production application.
>
> I'm a little bit scared to use a source version for a production
> application but I'm still quite new to qooxdoo, so ... I'll follow
> your advice : would you advice me to use the trunk version in SVN ?
> In such a case, when will I know I could upgrade from repository
> without taking the risk of breaking my app with a broken trunk ?

No, you shouldn't be working against trunk for a production application,
that's exactly the point, and your concerns are completely justified.
Stick to released versions. Keep in mind that we have different breeds
of developers on this list. Some are very comfortable working with
bleeding edge software, and their approach to problems is therefore
understandably different, but not necessarily suitable for everyone else.

Also, using a source version of your app for deployment is not
recommendable.

Rather, since in another mail you mentioned you are using Petr's build
version of the qooxdoo class library, you should consider taking a more
professional approach to your development and put your code into a
normal build environment where you can properly work with a source
version, *and then* when all issues have been resolved create a build
version for production.

I have forgotten why you are using the pre-build version of Petr in the
first place. But I'm sure there will be multiple benefits for you from
working in a "normal" build environment, if only that we others can help
you much more easily since we know the environment, can give informed
advice and point you to proven tools and procedures to overcome issues.
The logging issue is only one in this regard. You cut yourself off from
a bunch of resources in taking the side track.

Thomas


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7]

Jean-Baptiste BRIAUD -- Novlog wrote:

> Hi,
>
> As we talked about several issues, I split them into several messages.
>
> That one is about the fact some call to io.remote.Request are not log
> in the debig console the same way other call are.
>
> I normaly use application/json but for testing purpose on the backend,
> I had to switch to text/html because the backend retrun in that case
> some more debug info and application/json make qooxdoo trying to
> execute that debug info.
>
> I'm using a build version, the one that Petr kindly made for me.
> Despite the enabled console, absolutly nothing was logged.
>
> Amazingly, 2 different requests to the same backend, with the same
> transport layer but with only one difference are not debuged the same
> : one of them use setFormField.
> That last one is not debugged while the other is nicely debuged with a
> tree like triangle that one could open and launch the request again to
> see the result.
> This is by the way a very very nice way to debug a HTTP request ...
> when it worked :-)
>

Actually, I'm not getting what you are doing here. Which kind of
debugging output are you talking about when you speak about the "tree
like triangle"? Are you using Firebug on the client? If so you should
see the requests (both the request and the response part of them) in
Firefox anyway, logging enabled in qooxdoo or not.

The logging hints Derrell sent you apply specifically to the *source*
version (as he said). Since you are working with a build version of the
library, try putting away with the "if (qx.core.Variant...." conditional
and have the contained code unconditionally. If that doesn't help I'm
not sure what to do since e.g. the qx.debug variant might be "burned in"
into the build version of library, so you cannot overwrite it.

Anyway, you should be able to debug your server communication with
Firebug nevertheless.

Concerning the mime type that your server sets for the response data,
stick with text/html until all communication issues are sorted out.

Thomas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Kenny Tilton-2]

Alexander Back wrote:

> Hi Kenny,
>
> On Tuesday 18 November 2008 Kenny Tilton wrote:
>
>>I was having trouble loading my page using my Lisp server. I saw dozens
>>of separate requests pulling in bits of JS, and then nothing, just a
>>blank screen.
>
> The "source" version of qooxdoo uses a kind of "inlcude" script which includes
> every necessary javascript file individually. These are the dozens separate
> requests. The "build" version however uses a single loader JS file to load
> another JS file which includes the whole application.
> I wonder about your "blank screen". Are there no log messages? What kind of
> logger do you use?

this.debug, which I understand is a NOP in a build version, so no
mystery there in hindsight.


<snip>

>>So...is it possible to mix my own "un-built" application.js with a
>>pre-built JS file of all the stuff? That would probably load fine amd
>>then (I guess) my logging code will work. Yes? No?
>
> It's better to use the generator to let you generate a customized "source"
> version of your application. This will enable logging for you and once you
> are ready for production you can generate a "build" version of your
> application.
> Did you start with creating your own application using
> the "create-application.py" script?

Yes.

> If so, you can simply execute
>
> "./generate.py source"
>
> inside your application folder to generate your own "source" version.

Right, that is what I am doing. The good news is that the source version
now loads OK even from my Lisp server (not sure what I did, but there
may have been an error I just was not noticing and fixed while thrashing
about), the bad news is that it is a little slower than I would like for
iterative development.

The ideal would be to have an option for the qooxdoo libs to be fully
mini-fied and my source (Application.js for now, but also others as I
divide code up) not mini-fied. Full source is still useful for rare
occasions where I need to see library source to debug a hard problem,
but esp. with qooxdoo's great runtime error reporting I wager that will
be a rare case.

I think Petr suggested learning qxbuild... perhaps that is now I could
get a semi-build going with some stuff mini-fied and some not? I'll
start poking around.

cheers, kenny

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

On 18 Nov 2008, at 14:54, thron7 wrote:

> Jean-Baptiste BRIAUD -- Novlog wrote:
>> Hi,
>>
>> [CUT]
>>
>> I'm a little bit scared to use a source version for a production
>> [CUT]
>
> No, you shouldn't be working against trunk for a production  
> application,
> [CUT]

OK.
> Also, using a source version of your app for deployment is not
> recommendable.
>
> [CUT]
>
> I have forgotten why you are using the pre-build version [CUT]
>
The goal is to make the build myself once every qooxdoo release and to  
work with it as a source version.

So, why do I stuck to source version rather than following the build  
process ?
Our application (made with qooxdoo) generate applications also made  
with qooxdoo.
So, in a sense, we already are a build system.
What happen, is that the qooxdoo build system is designed to be a  
build-time system, of course.
With us, that system will be used at run-time. This add extra  
complexity I don't want for now.
Also, my first tests in september shown that qooxdoo build take  
currently too much time and ressource (CPU).
Keep in mind that will run that on our server at run-time for our end  
user.
Finally, for our first version, I'm fine with that easy to use qooxdoo  
in one javascript file.
The price I'm ready to pay for that first version is a bigger file to  
load at startup.

Even if I fully (I think) understand all the power and advantages of  
that qooxdoo build system, I have to say that this was the biggest  
negative thing I found in qoxdoo.
Let me explain and be sure I really appreciate qooxdoo but we also  
have to face problems that new commers encounters has this might be  
one reason why people do not adopt qooxdoo after their first try.
I came for a javascript client framework and widget library and the  
first think I have to do is to deal with Python 'thing', that is  
really really disturbing and it deserve qooxdoo because it is the only  
approach documented and recommended. I think that we could let people  
just download and incude qooxdoo to apreciate it and later but only  
later let them know that a more optimized approach is possible.

With that approach "simple first, optimized later, if you want", I'm  
sure qooxdoo could be more choosen by javascript on client side  
developpers.
Think to some false competitor like JQuery, Dojo that are really not  
at the qooxdoo level for building application, you just have to  
include a js file to use it, nothing else.

I really hope that will not be interpreted as a troll, I do want to be  
constructive. I mounted my company and I've chosen qooxdoo, so now I  
feel "linked to qooxdoo" :-)

JBB.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

On 18 Nov 2008, at 15:18, thron7 wrote:

> Jean-Baptiste BRIAUD -- Novlog wrote:
>> Hi,
>>
>> That one is about the fact some call to io.remote.Request are not log
>> in the debig console the same way other call are.
>>
>> [CUT]
>> I'm using a build version, the one that Petr kindly made for me.
>> Despite the enabled console, absolutly nothing was logged.
>>
>> Amazingly, 2 different requests to the same backend, with the same
>> transport layer but with only one difference are not debuged the same
>> : one of them use setFormField.
>> That last one is not debugged while the other is nicely debuged  
>> with a
>> tree like triangle that one could open and launch the request again  
>> to
>> see the result.
>> This is by the way a very very nice way to debug a HTTP request ...
>> when it worked :-)
>>
>
>
> Actually, I'm not getting what you are doing here. Which kind of
> debugging output are you talking about when you speak about the "tree
> like triangle"? Are you using Firebug on the client?

Yes, I'm using firebug 1.2.1 with firefox 3.0.4
> If so you should
> see the requests (both the request and the response part of them) in
> Firefox anyway, logging enabled in qooxdoo or not.
>
I see it in firebug for all requests, except for requests that post  
form field ... but I don't know why.
For the request I see in firebug, I do not see the response by  
default. I see the URL.
If and only if I click on the line (on a small triangle on the left,  
like a tree), I then have a firebug button that allow to resend the  
request and see the response.
There is a warning that sending that request a second time could be an  
issue witch I fully agree.
> The logging hints Derrell sent you apply specifically to the *source*
> version (as he said). Since you are working with a build version of  
> the
> library, try putting away with the "if (qx.core.Variant...."  
> conditional
I didn't used the Derrell settings but the one provided by Petr :
     <script type="text/javascript">
         qxsettings =
         {
             "qx.application" : "novlog.ComposerBootstrap",

             // Mode ("build" or "debug")
             "qx.mode": "debug",

             // Theme class to use
             "qx.theme" : "qx.theme.Modern",

             // Resources and script uri. If you are planning to have  
qooxdoo in
             // special uri (browser path), you can specify it here.  
There is
             // no rebuild process needed while changing qxsettings  
here!

             // Resources uri
             "qx.resourcesUri": "/qooxdoo/resource",
             // Script uri
             "qx.scriptUri": "/qooxdoo/script"
         };
...
>
> and have the contained code unconditionally. If that doesn't help I'm
> not sure what to do since e.g. the qx.debug variant might be "burned  
> in"
> into the build version of library, so you cannot overwrite it.
>
> Anyway, you should be able to debug your server communication with
> Firebug nevertheless.
>
It worked the way I described but I just don't know if this way ios  
normal or not :-)
> Concerning the mime type that your server sets for the response data,
> stick with text/html until all communication issues are sorted out.
>
I switch to text/html when I need to debug the result of the backend  
but I'm using application/json otherwise since the server should only  
return json, is it correct ?
> Thomas
>
Did I thank you for all your help ?  Thanks !

JBB.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7]

> Right, that is what I am doing. The good news is that the source version
> now loads OK even from my Lisp server (not sure what I did, but there
> may have been an error I just was not noticing and fixed while thrashing
> about),

Good :).

>  the bad news is that it is a little slower than I would like for
> iterative development.
>  

So are you actually building static qooxdoo classes? I thought you would
do the generative thing on the server?!

> The ideal would be to have an option for the qooxdoo libs to be fully
> mini-fied and my source (Application.js for now, but also others as I
> divide code up) not mini-fied. Full source is still useful for rare
> occasions where I need to see library source to debug a hard problem,
> but esp. with qooxdoo's great runtime error reporting I wager that will
> be a rare case.
>  

I understand. And it's actually not that far away. You could build a
pre-build qooxdoo library, either using Petr's qxbuild or roll your own.
And then compile your classes in an "application-stuff-only" package,
which could be source or build, as you see fit. Then load one after the
other.

E.g., provided you had those two packages and an index.html, in it you
could say

  <!-- you need some inline stuff first -->
  <script type="text/javascript">
    qxsettings = { "qx.application" : "Application" };  // if that's
your main app class
  </script>

  <script type="text/javascript" src="path/to/qx.js"></script>  <!--
this for the qooxdoo lib -->

  <script type="text/javascript"
src="path/to/yourappstuff.js"/></script> <!-- this for you app classes -->


To create the qx.js library you just need a tailored job for your
config.json file which I could send you.

To create the yourappstuff.js lib, you just have to limit which classes
go into the source/build job output. If you are working against trunk,
put these two job definitions in your config.json:

  "source" : {
     "=include" : [ "=${APPLICATION}.*" ]
  },
  "build" : {
     "=include" : [ "=${APPLICATION}.*" ]
  }

assuming your classes are under source/class/<name space>/. Otherwise,
you can just list their names in the array as strings.

This all is actually quite manageable. The hairy part is to synchronize
the two libs sufficently, since qooxdoo establishes e.g. global vars and
expects other things, in order to work properly and to tailor its
workings. There is a bit of convention involved, which the build system
manages out of the box, and which you have then to maintain on your own.
I don't have much experience with this approach, so it might take some
effort on your side to sort things out.


> I think Petr suggested learning qxbuild... perhaps that is now I could
> get a semi-build going with some stuff mini-fied and some not? I'll
> start poking around.
>  

Yes, I guess this would work. And as I said, you could create your own
"qxbuild" with little effort, which might give you more control over the
interface between pre-build lib and your own stuff. Let me know.

Thomas

>  

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Kenny Tilton-2]

Jean-Baptiste BRIAUD -- Novlog wrote:

> Even if I fully (I think) understand all the power and advantages of  
> that qooxdoo build system, I have to say that this was the biggest  
> negative thing I found in qoxdoo.
> Let me explain and be sure I really appreciate qooxdoo but we also  
> have to face problems that new commers encounters has this might be  
> one reason why people do not adopt qooxdoo after their first try.
> I came for a javascript client framework and widget library and the  
> first think I have to do is to deal with Python 'thing', that is  
> really really disturbing and it deserve qooxdoo because it is the only  
> approach documented and recommended. I think that we could let people  
> just download and incude qooxdoo to apreciate it and later but only  
> later let them know that a more optimized approach is possible.
>

I agree 100%. "Python required" was quite scary. I thought Python was
going to be preprocessing my source code and involved in every
iteration. I passed on qooxdoo and went on to Dojo and then YUI, came
back only because they came up short and because the original
recommender of qooxdoo was highly respected -- but he only said
"interesting", he was using jQuery.

Mind you, this is just a marketing faux pas, but if one is looking to
grease the skids for noobs I would offer a hello-world that includes a
build version of qooxdoo and then a separate Application.js and html to
include them both. It will be fast and they can edit Application.js at will.

All that said, as a Lisper I am accustomed to having the best tools all
to myself, so qooxdoo's small market share is fine by me. :)

hth, kenny

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7]

Jean-Baptiste BRIAUD -- Novlog wrote:

> On 18 Nov 2008, at 14:54, thron7 wrote:
>  
>> Jean-Baptiste BRIAUD -- Novlog wrote:
>>    
>>> Hi,
>>>
>>> [CUT]
>>>
>>> I'm a little bit scared to use a source version for a production
>>> [CUT]
>>>      
>> No, you shouldn't be working against trunk for a production  
>> application,
>> [CUT]
>>    
> OK.
>  
>> Also, using a source version of your app for deployment is not
>> recommendable.
>>
>> [CUT]
>>
>> I have forgotten why you are using the pre-build version [CUT]
>>
>>    
> The goal is to make the build myself once every qooxdoo release and to  
> work with it as a source version.
>  

Wait, wait. When you do a "build" version of the framework you have a
build version, not a source version. So how can you "work with it as a
source version"?

> So, why do I stuck to source version rather than following the build  
> process ?
> Our application (made with qooxdoo) generate applications also made  
> with qooxdoo.
> So, in a sense, we already are a build system.
> What happen, is that the qooxdoo build system is designed to be a  
> build-time system, of course.
> With us, that system will be used at run-time. This add extra  
> complexity I don't want for now.
>  

Ok, I get that.

> Also, my first tests in september shown that qooxdoo build take  
> currently too much time and ressource (CPU).
> Keep in mind that will run that on our server at run-time for our end  
> user.
>  

Yep, got it.

> Finally, for our first version, I'm fine with that easy to use qooxdoo  
> in one javascript file.
> The price I'm ready to pay for that first version is a bigger file to  
> load at startup.
>  

Fair enough.

> Even if I fully (I think) understand all the power and advantages of  
> that qooxdoo build system, I have to say that this was the biggest  
> negative thing I found in qoxdoo.
> Let me explain and be sure I really appreciate qooxdoo but we also  
> have to face problems that new commers encounters has this might be  
> one reason why people do not adopt qooxdoo after their first try.
> I came for a javascript client framework and widget library and the  
> first think I have to do is to deal with Python 'thing', that is  
> really really disturbing and it deserve qooxdoo because it is the only  
> approach documented and recommended. I think that we could let people  
> just download and incude qooxdoo to apreciate it and later but only  
> later let them know that a more optimized approach is possible.
>  

I understand what you are saying. The thing is that qooxdoo comes with a
"programming model". Roughly put, it targets application developers that
are heavily OO-slanted, wanting to produce rich-client, single-page,
performant, desktop-like GUI applications in an industrial style. Many
efforts within the project have this scenario in mind, and try to foster
it particularly. In order to achieve that, compromises are being made
that lead among other things to the up-front effort of setting up a
build environment. I mean, it's hard to cater for everything. And we are
particularly glad that we could reduce the set of a-priory requirements
from a Unix-like environment (until the 0.7.x releases) to Python-only
(with 0.8).

That doesn't mean you cannot use it otherwise, it's just not the
proposed way and not well supported.

Having said that, it's not cut into stone, but we just dropped the
"quickstart" deliverable (think: qxbuild) from the qooxdoo release kits
with 0.8. ... Other people will have to comment on that.

> With that approach "simple first, optimized later, if you want", I'm  
> sure qooxdoo could be more choosen by javascript on client side  
> developpers.
> Think to some false competitor like JQuery, Dojo that are really not  
> at the qooxdoo level for building application, you just have to  
> include a js file to use it, nothing else.
>
> I really hope that will not be interpreted as a troll, I do want to be  
> constructive. I mounted my company and I've chosen qooxdoo, so now I  
> feel "linked to qooxdoo" :-)
>  

I have no doubt about that. And I'm sure we'll get there eventually.
There are just so many things to do. But we have already moved in that
direction, just look at the "bom" skeleton template
(component/skeleton/bom). Maybe we will have even better support for
library-style development in the future, and meanwhile maybe we can fix
things providing proper documentation, because the means are all in place.

Thanks for sharing your point of view.

Thomas


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7]

Kenny,

>
> I agree 100%. "Python required" was quite scary. I thought Python was
> going to be preprocessing my source code and involved in every
> iteration. I passed on qooxdoo and went on to Dojo and then YUI, came
> back only because they came up short and because the original
> recommender of qooxdoo was highly respected -- but he only said
> "interesting", he was using jQuery.
>
> Mind you, this is just a marketing faux pas, but if one is looking to
> grease the skids for noobs I would offer a hello-world that includes a
> build version of qooxdoo and then a separate Application.js and html to
> include them both. It will be fast and they can edit Application.js at will.
>  

We had all that (see
http://downloads.sourceforge.net/qooxdoo/qooxdoo-0.7-quickstart.zip?modtime=1181064207&big_mirror=0)
IIRC, the package was dropped from later releases because we had several
people complaining they were confused by the number of downloads we're
offering and and by the question which one to choose. So we cut down to
the one we couldn't miss, the SDK.

Another reason was we were afraid of people starting to build heavy
applications on top of the quickstart package (which was really just
thought to give someone a quick start into trying out qooxdoo, as the
name indicates), and then leaving qooxdoo because they feel it is too
heavy and too inflexible (which are just trade-off's in using the
quickstart), never looking into the opportunities the SDK offers. - You
see, there is danger lurking on both sides of the road ;).

We also felt that with the build system everybody could create their own
"quickstart" if they so desire. It seemed just too much of a stretch to
properly support both styles of development. So we removed the package
from the public interface.

Maybe Andreas can say more about it.

Thomas

>  

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

On 18 Nov 2008, at 16:59, thron7 wrote:

> Jean-Baptiste BRIAUD -- Novlog wrote:
>> On 18 Nov 2008, at 14:54, thron7 wrote:
>>> Jean-Baptiste BRIAUD -- Novlog wrote:
>>>
>>>> Hi,
>>>>
>>>> [CUT]
>>>>
>>>> I'm a little bit scared to use a source version for a production
>>>> [CUT]
>>>>
>>> No, you shouldn't be working against trunk for a production
>>> application,
>>> [CUT]
>>>
>> OK.
>>
>>> Also, using a source version of your app for deployment is not
>>> recommendable.
>>>
>>> [CUT]
>>>
>>> I have forgotten why you are using the pre-build version [CUT]
>>>
>>>
>> The goal is to make the build myself once every qooxdoo release and  
>> to
>> work with it as a source version.
>>
>
> Wait, wait. When you do a "build" version of the framework you have a
> build version, not a source version. So how can you "work with it as a
> source version"?

Sorry, I'm not sure about the vocabulary, I mean the goal is to do  
myself, once every qooxdoo release, what Petr quidly did for me when I  
was too young with qooxdoo.
So, I don't know the name of what I'm doing, I just know what I'm  
doing ;-)

>
>
>> So, why do I stuck to source version rather than following the build
>> process ?
>> Our application (made with qooxdoo) generate applications also made
>> with qooxdoo.
>> So, in a sense, we already are a build system.
>> What happen, is that the qooxdoo build system is designed to be a
>> build-time system, of course.
>> With us, that system will be used at run-time. This add extra
>> complexity I don't want for now.
>>
>
> Ok, I get that.
>
>> Also, my first tests in september shown that qooxdoo build take
>> currently too much time and ressource (CPU).
>> Keep in mind that will run that on our server at run-time for our end
>> user.
>>
>
> Yep, got it.
>
>> Finally, for our first version, I'm fine with that easy to use  
>> qooxdoo
>> in one javascript file.
>> The price I'm ready to pay for that first version is a bigger file to
>> load at startup.
>>
>
> Fair enough.
>
>> Even if I fully (I think) understand all the power and advantages of
>> that qooxdoo build system, I have to say that this was the biggest
>> negative thing I found in qoxdoo.
>> Let me explain and be sure I really appreciate qooxdoo but we also
>> have to face problems that new commers encounters has this might be
>> one reason why people do not adopt qooxdoo after their first try.
>> I came for a javascript client framework and widget library and the
>> first think I have to do is to deal with Python 'thing', that is
>> really really disturbing and it deserve qooxdoo because it is the  
>> only
>> approach documented and recommended. I think that we could let people
>> just download and incude qooxdoo to apreciate it and later but only
>> later let them know that a more optimized approach is possible.
>>
>
> I understand what you are saying. The thing is that qooxdoo comes  
> with a
> "programming model". Roughly put, it targets application developers  
> that
> are heavily OO-slanted, wanting to produce rich-client, single-page,
> performant, desktop-like GUI applications in an industrial style.

Exactly what I perceived from qooxdoo.

> [CUT]

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

On 18 Nov 2008, at 17:28, thron7 wrote:

> Kenny,
>
>> [CUT]
> Another reason was we were afraid of people starting to build heavy
> applications on top of the quickstart package (which was really just
> thought to give someone a quick start into trying out qooxdoo, as the
> name indicates), and then leaving qooxdoo because they feel it is too
> heavy and too inflexible (which are just trade-off's in using the
> quickstart), never looking into the opportunities the SDK offers. -  
> You
> see, there is danger lurking on both sides of the road ;).
>

I would not be afraid of people that would like to leave after trying  
qooxdoo.
Due to the hight quality of qooxdoo and people here, I'm convinced  
this is unlikly to happen massively.
On the other hand, I'm afraid that not enough people could give  
qooxdoo a try because of they feel it is too hard just to try.
That is maybe pure marketing but this is the real danger.

For me, the danger is far away now I was able to give qooxdoo a real  
deep try without bothering with Python, build, optimization, size and  
other stuff I was even not aware it could be good or bad since I just  
didn't know qooxdoo.

> We also felt that with the build system everybody could create their  
> own
> "quickstart" if they so desire. It seemed just too much of a stretch  
> to
> properly support both styles of development. So we removed the package
> from the public interface.
I understand, I even feel I could in a near future give a serious  
study to that build. I have to admit that for absolutly no reasons, "I  
don't like Python" but I now feel that I won't have to learn it to use  
qooxdoo.
>
>
> Maybe Andreas can say more about it.
>
> Thomas
>
Anyway, I just want to express one more time that I'm very happy that  
I had discovered qooxdoo.
Now, I'll go back to my qooxdoo code ;-)

>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel