Hi Thomas,
On Sep 16, 2009, at 01:13 , thron7 wrote:
> Hi J-B,
>
>> The reason (maybe bad, let's clarify that) is the Java backend for
>> that application.
>> Will I be able to launch RPC request on a qooxdoo application
>> launched
>> from the file system ?
>
> No, but to have proxy/mock objects to decouple the client from the
> server
> is good engineering practice, just think of unit and regression
> testing.
> You would want to be able to test the client independent of the
> server.
>
well ... yes and no, depending on situations.
OK, decoupling client code and server code is just mandatory for me.
As client is Javascript and server is Java, there is no risk of
accidental or unwanted coupling.
Running client alone without server has very limitted interest since
window1 lead to window 2 only if a call to server come back with data
for window 2.
In other words, client can't work without server.
I'm building application, not site, so there is very little to no
interest of launching only client without the Java backend.
While not very useful, this is simple to do : just double click on
index.html outside any IDE tools in source or build.
So, you could arg that this is exactly the interest of mock object.
Well, I prefer spending time on complete end to end test rather than
mock object.
So, it is deliberate, I won't unit test the GUI part of client side.
Some logic on client side could be unit tested and should not need
server, so no need of mock object too.
And this kind of unit test should also not be the source target for
generate.py.
>> That's excatly the problem : to produce the application, generate.py
>> look for the sdk from QOOXDOO_PATH variable.
>> Then it is wrongly assume that later, at runtime, the SDK will be
>> at a
>> place that correspond to QOOXDOO_PATH.
>> But that's wrong in our config. The path at runtime is different so
>> I'd love to find in the config.json 2 variables :
>> * one for specifying to generate.py where is the SDK to find the
>> generator.py and all the ressources
>> * one to take into account in the generated application for the URI
>> od
>> the SDK at runtime eventually behind a web server.
>
> Ok, try the following. In your config.json, add this job to the
> "jobs" map:
>
> "libraries" : {
> "library" : [
> { "manifest" : "${QOOXDOO_PATH}/Manifest.json",
> "uri" : "<your_desired_SDK_path_for_runtime>"
> }
> ]
> }
>
Cool, so this can be done.
> Now the URIs to the resources from the SDK will be generated using the
> path prefix given in "uri" (only specify the path up to the directory
> including the SDK's Manifest.json).
>
> See these documents for more information:
> http://qooxdoo.org/documentation/0.8/generator_config_ref#library
> http://qooxdoo.org/documentation/0.8/generator_config_articles#library_key_and_manifest_files
>
>> No, it's not 2 SDK : it is only one but can't be the same path from
>> file system (generator.py) and runtime.
>> It is also important to note it is not a simple web server but a Java
>> web container : tomcat.
>
> So, can you tell a bit more about how the path to the SDK differs in
> your
> runtime environment (tomcat)?!
At build-time (when calling the generate.py) the SDK must be reachable
from the filesystem.
When deployed, especially not in Apache but using a Java container
like Tomcat, the paths are not the same.
Basically, even using the classical Apache web server, filesystem path
and URL might be totally different. Think to Alias or virtualhost
concepts.
So, I have only one SDK, that SDK can be reached via one filesystem
path at build-time.
Then, at run-time, once deployed into tomcat, that path is different.
Don't forget that Tomcat is not a web server. It works with
application that had to be self contained (.war concept).
Anyway, see my other email, it works now and even I could test the
library feature as you explained before.
>
>>> That's right, you can invoke generator.py directly if you like.
>> Does it change something ? Could that make QOOXDOO_PATH only useful
>> for runtime ?
>
> No, it doens't make any difference whether you use generate.py or
> generator.py.
>
> HTH, Thomas
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
