Quantcast

Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

totty
Hello!

I know I've already asked a question about server-side js, but now as I use the OO part of qooxdoo (what it's supposed to be used on the server) I find 2 problems:

 - How should I organize my code in order to use them on both on server and on the client? I would like to don't have to copy-paste files or code from a folder containing only server to the client or viceversa. I don't even need all the code from the server on the client and viceversa.


 - I'm using "require" to get classes available to the program, but are relative from where I need them so I have to take care that it's the right way to require them every time. I have to repeat things: once in the require and the other when I use the code; I'm asking if it's possible to make some absolute require? require('/myapp/abc') instead of require('./abc') if I'm in requiring it from the myapp folder or require('./myapp/abc') if I'm requiring it from the root folder. I can provide an alternative idea:
instead of using "things" like this:
   var a = new qx.core.Aspect();
use:
   // in the beginning of the program
qx.Class.define("myapp.class", [
   // uses
   'qx.core.Aspect'
   ], function(u){
   //here we put extend, construct, properties and members
   this.members = {
      myMethod: function(){
          var a = new u.Aspect();
          // or
          var b = new u.qx.core.Aspect();
          // or
          var c = new u['qx.core.Aspect']();
          // or you could define an alias for that in the "uses" section
          // instead of ['qx.core.Aspect'] write [['qx.core.Aspect', 'myAlias']]
          var d = new u.myAlias();
      }
   }
}

the qooxdoo class should abstract the "require" part from the end user by using a closure that it's run only when files are loaded. I can provide a more "real" example of what I mean if interested.

but it's just a suggestion, and both ways can coexists.


Thanks for your time and for reading this,
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

Daniel Wagner
Administrator
Hi,

On 04/10/2012 03:44 PM, totty wrote:
>
>   - How should I organize my code in order to use them on both on server and
> on the client? I would like to don't have to copy-paste files or code from a
> folder containing only server to the client or viceversa. I don't even need
> all the code from the server on the client and viceversa.
>

I suggest organizing the server-side code in a basic skeleton
(create-application.py -t basic). It gives you the usual benefits of the
toolchain like dependency analysis and optimization (which aren't that
useful on the server), but more importantly it provides a Manifest.json
file. That way, your client application can use classes from the
server-side code like with any other qooxdoo library.


Regards,
Daniel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

Thomas Herchenroeder
In reply to this post by totty


On 04/10/2012 03:44 PM, totty wrote:
>   - I'm using "require" to get classes available to the program, but are

Is this the Node.js' built-in 'require'?!

> relative from where I need them so I have to take care that it's the right
> way to require them every time. I have to repeat things: once in the require
> and the other when I use the code;

What do you mean? Can you give an example of these two uses?

>   I'm asking if it's possible to make some
> absolute require? require('/myapp/abc') instead of require('./abc') if I'm

In Node.js' 'require' you can always be passed an absolute path.


> in requiring it from the myapp folder or require('./myapp/abc') if I'm
> requiring it from the root folder.

Another alternative would be to use a 'node_modules' folder. If it is
e.g. a subfolder of your root folder, it would always be
require('myapp/abc'), no matter which of the enclosed files are
require'ing it. You can also achieve a similar effect using the
NODE_PATH os environment variable.

>   I can provide an alternative idea:
> instead of using "things" like this:
>     var a = new qx.core.Aspect();
> use:
>     // in the beginning of the program
> qx.Class.define("myapp.class", [
>     // uses
>     'qx.core.Aspect'
>     ], function(u){
>     //here we put extend, construct, properties and members
>     this.members = {
>        myMethod: function(){
>            var a = new u.Aspect();
>            // or
>            var b = new u.qx.core.Aspect();
>            // or
>            var c = new u['qx.core.Aspect']();
>            // or you could define an alias for that in the "uses" section
>            // instead of ['qx.core.Aspect'] write [['qx.core.Aspect',
> 'myAlias']]
>            var d = new u.myAlias();
>        }
>     }
> }
>
> the qooxdoo class should abstract the "require" part from the end user by
> using a closure that it's run only when files are loaded. I can provide a
> more "real" example of what I mean if interested.

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.

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.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

totty
>>   - I'm using "require" to get classes available to the program, but are

>Is this the Node.js' built-in 'require'?!

yes. require('./this/that');



>> relative from where I need them so I have to take care that it's the right
>> way to require them every time. I have to repeat things: once in the require
>> and the other when I use the code;

>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.
"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();

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();



----------------------------
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...




----------------------------
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?




----------------------------
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?
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?

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?

thanks a lot for your answer (:
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

Thomas Herchenroeder


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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

totty
First of all thank you for the detailed response.

I've been reflecting on how to do it and it seems a great idea to create a single project for all the stuff but generate 2 separate loaders, as you said, one for the client and one for the server.

This seems the best option available right now, and it's good enough.

thanks again ;)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

Thomas Herchenroeder
The more general approach that I expected would be to have at least 3
qooxdoo libraries:
- one containing generic code, potentially used on various platforms
- one containing platform-specific code used for the client
- on containing platform-specific code used for the server

The latter two could both include the first, and in the client library
you would generate a client-specific loader from all involved classes,
and in the server library you would create a server-specific loader for
all involved classes.

T.

On 04/24/2012 03:31 PM, totty wrote:

> First of all thank you for the detailed response.
>
> I've been reflecting on how to do it and it seems a great idea to create a
> single project for all the stuff but generate 2 separate loaders, as you
> said, one for the client and one for the server.
>
> This seems the best option available right now, and it's good enough.
>
> thanks again ;)
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/Reusing-server-side-code-in-the-client-side-how-to-get-rid-of-the-require-in-nodejs-suggestion-tp7452919p7495892.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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

totty
wow, I got an exact thought earlier but I didn't liked it so much because that would mean to make 3 namespaces, and managing code from 3 places would be quite overkill example:

If we can't merge namespace then would be:

shared.routerPaths  // shared/routerPaths.js
client.Router  // client/Router.js
server.Router  // server/Router.js

each in their respective folder (shared, client and server)



If we can merge namespaces then it could be:

router.sharedRouter  // shared/router/sharedRouter  .js
router.ClientRouter  // client/router/ClientRouter  .js
router.ServerRouter  // server/router/ServerRouter  .js

but they would lie in 3 different folder and would make my development a pain. I would have to jump from one folder to another and sometimes I would have to check 3 folders to find what I need (in more complex cases)..

I like more the main project containing everything and leverage the loader to separate the files. This also seems more practical and logical.

router.sharedRouter // router/sharedRouter.js
router.ClientRouter // router/ClientRouter .js
router.ServerRouter // router/ServerRouter .js


What do you think?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

Thomas Herchenroeder
For me it would be much more logical and practical, if I had two
different apps to have two different libs for them, and a third to take
shared code (and yes, common namespace prefixes in different libraries
does work).

The advantage shows when you build your apps. In a dedicated library
(say, "client"), you can run "generate.py source/build/test/api/..." and
everything works as expected, all targets are generated nicely, yourself
testing everything in a browser. Same in the "server" app, where you
test everything, say, with node.js. No collisons, no conflicts.

If you collapse everything in a single library, what is "generate.py
source" supposed to build, the client or the server app? Same with all
other generator targets. So you start building custom jobs for each,
like "source-client", "source-server", "build-client", "build-server"
... horrible. You have to take care of several other things, e.g. the
output paths, or else e.g. "build-client" and "build-server" jobs would
mutually overwrite each other in the build/script directory and you'd
never had both at the same time. And so on.

So it appears to me much cleaner and easier to used dedicated libs. But
of course it has to suit *you* ... :-).

T.

On 04/24/2012 04:33 PM, totty wrote:

> wow, I got an exact thought earlier but I didn't liked it so much because
> that would mean to make 3 namespaces, and managing code from 3 places would
> be quite overkill example:
>
> If we can't merge namespace then would be:
>
> shared.routerPaths  // shared/routerPaths.js
> client.Router  // client/Router.js
> server.Router  // server/Router.js
>
> each in their respective folder (shared, client and server)
>
>
>
> If we can merge namespaces then it could be:
>
> router.sharedRouter  // shared/router/sharedRouter  .js
> router.ClientRouter  // client/router/ClientRouter  .js
> router.ServerRouter  // server/router/ServerRouter  .js
>
> but they would lie in 3 different folder and would make my development a
> pain. I would have to jump from one folder to another and sometimes I would
> have to check 3 folders to find what I need (in more complex cases)..
>
> I like more the main project containing everything and leverage the loader
> to separate the files. This also seems more practical and logical.
>
> router.sharedRouter // router/sharedRouter.js
> router.ClientRouter // router/ClientRouter .js
> router.ServerRouter // router/ServerRouter .js
>
>
> What do you think?
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/Reusing-server-side-code-in-the-client-side-how-to-get-rid-of-the-require-in-nodejs-suggestion-tp7452919p7496099.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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

totty
Can you put some directory structure and paths? I understand better that way..

thanks
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reusing server-side code in the client-side && how to get rid of the require in nodejs? +suggestion

Thomas Herchenroeder
Maybe better, just run these commands in a directory of you choice, and
inspect the ensuing directory structure:

create-application -n shared -s router.basic
create-application -n client    -s router.client
create-application -n server  -s router.server

Each of these namespaces could then have a file Router.js (so you'd have
router.basic.Router, router.client.Router and router.server.Router).
This could be one way to do it, I think you will find this instructive.

T.

On 04/24/2012 06:27 PM, totty wrote:

> Can you put some directory structure and paths? I understand better that
> way..
>
> thanks
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/Reusing-server-side-code-in-the-client-side-how-to-get-rid-of-the-require-in-nodejs-suggestion-tp7452919p7496553.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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Loading...