On 04/11/2012 03:04 PM, totty wrote:
>
>> What do you mean? Can you give an example of these two uses?
> "relative from where I need them so I have to take care that it's the right
> way to require them every time."
> here I mean: if I have a app structure like this:
> root
> |-file3.js<-- I'm here (1)
> |-folder1
> |-folder2
> |-file1.js<-- I want this
> |-file2.js<-- I'm here (2)
>
> If I want file1 from file3 the require would be:
> require('./folder2/file1');
>
> If I want file1 from file2 the require would be:
> require('./file1');
>
> And this is quite painful because then I would have to repeat this whenever
> I would need them too.
Ok, yes, so if you are using relative requires, the path to the same
file varies depending on the path of the requiring file. node_modules/
and NODE_PATH are means for that.
> "I have to repeat things: once in the require and the other when I use the
> code"
> My code would look:
>
> require('./file1');
> // ...
> var a = new folder2.file1();
I don't think so. The require() needs to address the file in some way.
But after the file is read, everything should be the same, no matter
with which relative path it was loaded. It only depends on the symbols
file1 creates. So if it creates a symbol "folder2.file1" it will do so
in every requiring file. There should be no difference.
> Here is quite bad design I think and could lead to more errors and of course
> repetition of code.
>
> Here I begin to think that it's better to use the "node_modules" way so I
> could make my code like this, which is quite better:
>
> require('folder2/file1');
> // ...
> var a = new folder2.file1();
As I said. The way you require() a module should have no effect on the
symbols it exports.
> ----------------------------
> Which problem are you trying to solve here? You're not aiming at getting
> rid of code like
>
> var a = new qx.core.Aspect()
>
> , do you? As this would be breaking a lot of qooxdoo code.
>
> You probably want to get rid of the corrsponding 'require' call
> (something like 'require("qx/core/Aspect.js")')?! That's very sensible,
> but you wouldn't need an entirely new qx.Class.define, would you?! And
> you wouldn't want to declare all your dependencies, too. That's what the
> generator is for. So a good solution for me would be that the generator
> extracts all dependencies, generates the corresponding 'require' calls,
> and wraps this code in front of your class definition.
> ----------------------------
> Well this can be solved in 2 ways:
> 1) use a generator for the server side: this would solve all problems, but I
> don't know the level time and effort of doing this and if it's worth.
> or
> 2) declare dependencies and change some code in the qx.Class.define, that's
> why it's more painful, but that would solve some problems too: we can run
> server side code without generating and using require in node js. This could
> also be used in the client side too...
I think you are mixing things here. For one thing there is no "server
side". There is just JavaScript code, and in the form of classes if you
use qooxdoo.
Secondly then, there is the question which platform some of this code
should run on. Ideally, this is nothing which is wired into the code
itself. Rather, it is determined by the way the generator is run. So you
could have a qooxdoo library, with "business logic" (ie. free of
references to DOM or 'platform' or whatever platform-specific object),
which you can include in a web client as well as a server-side program.
The generator would use the same classes in both cases, but generate
different loaders (to put it short).
So surely you can use the generator for your server-side programs.
Alternatively, of course you can make your code platform-specific, but
then you loose the general usability of your code, and you have to live
in more than one world. On the one side, managing all dependencies by
hand with explicit require()'s, on the other side automatic loader
generation.
> ----------------------------
> This would be on a per-file basis. The generator is already doing
> something similar, but on a file-set basis, in the current loader. So if
> you e.g. use the 'basic' skeleton, the generator will create a loader
> that handles all 'require's for you.
> ----------------------------
> Are you talking for the server side? how could I do it?
Just have a look at a 'basic' skeleton (run 'create-application.py -t
basic').
> ----------------------------
> So from what I understood this is how it could be done to share code to the
> client, please correct me if I'm wrong:
>
> First use the node_modules to keep javascript code.
> I have my modules here "C:\Users\Totty\node_modules";
> Should I create here a new folder and name it as the project name?
> Here I will put all my classes of qooxdoo, right?
Well, then you would be back in the land of manually managed requires().
But following this train of thought, yes, this is how I would do it:
Create a tree structure under a top-level 'node_modules', so you could
always write 'require("folder2/file1") for all requiring files under
this top-level dir.
> then this folder will be included in the build (config.json, manifest) in
> order to be able to use them on the client side?
> I keep those files as a library?
Well, that would be a bit awkward I guess. But it would be doable, by
pointing the 'class' key of the library's Manifest.json to the
node_modules folder. I would rather have a normally set-up library, and
then copy the files over to a node_modules folder if I so wished (or add
the library's source/class folder to NODE_PATH).
> So I create a folder named "my_project" as the main project;
> Then in the "C:\projects\my_project" (where I keep my projects) I use:
>
> Here I use the library made before...
> a) require from nodejs
> b) or the generator can handle it? How should I config?
Yes, as I said before, I think you can have the source/class tree in a
normal qooxdoo library be used as node module lookup folder.
T.
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
