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

Reply via email to