Including non-qooxdoo libraries

[panyasan]

Hello,

again on the subject of using non-qooxdo libraries: At the moment, we
include them by adding a <script> tag in the index.html, which is ok, but
not elegant, and against the generator philosophy of including only what is
needed. I would like to propose to add a compiler hint similar to #require,
which tells the generator to load a script file before including the given
file, such as #load(script/library.js) or
#load(http://domoain.com/path/to/my/library.js). With the
qx.io2.ScriptLoader class, this shouldn't be a problem, and for the build
job, the file could be downloaded and included.

Just an idea.

C.
--
View this message in context: http://n2.nabble.com/Including-non-qooxdoo-libraries-tp3925436p3925436.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Sebastian Werner-5]

I like the idea. Could be useful for integrating stuff like
Progressive, HTML5 storage layers etc. what is not currently on the
radar of qooxdoo.

However I don't see the requirement of a separate statement here. Just
use the existing #require and #use with other than class names would
fulfill all requirements. I would also suggest to support local paths
e.g. external/progressive/progressive.js

The issue here might be that the whole qooxdoo stuff is based around
qooxdoo classes and the class names of these files. All these external
stuff has no valid qooxdoo'ish class name. Maybe one needs to generate
one internally.

Cheers,
Sebastian



2009/10/31 panyasan <info@...>:

>
> Hello,
>
> again on the subject of using non-qooxdo libraries: At the moment, we
> include them by adding a <script> tag in the index.html, which is ok, but
> not elegant, and against the generator philosophy of including only what is
> needed. I would like to propose to add a compiler hint similar to #require,
> which tells the generator to load a script file before including the given
> file, such as #load(script/library.js) or
> #load(http://domoain.com/path/to/my/library.js). With the
> qx.io2.ScriptLoader class, this shouldn't be a problem, and for the build
> job, the file could be downloaded and included.
>
> Just an idea.
>
> C.
> --
> View this message in context: http://n2.nabble.com/Including-non-qooxdoo-libraries-tp3925436p3925436.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7-2]

Yep, we going to need this for other things as well, but I'm thinking
more of a config key, rather than a file-level compiler hint, see this
bug: http://bugzilla.qooxdoo.org/show_bug.cgi?id=3016 . I think this
suits better on the config level.

T.

panyasan wrote:

> Hello,
>
> again on the subject of using non-qooxdo libraries: At the moment, we
> include them by adding a <script> tag in the index.html, which is ok, but
> not elegant, and against the generator philosophy of including only what is
> needed. I would like to propose to add a compiler hint similar to #require,
> which tells the generator to load a script file before including the given
> file, such as #load(script/library.js) or
> #load(http://domoain.com/path/to/my/library.js). With the
> qx.io2.ScriptLoader class, this shouldn't be a problem, and for the build
> job, the file could be downloaded and included.
>
> Just an idea.
>
> C.
>  

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Fritz Zaucker-3]

A related (?) question:

I tried to call qx.io2.ScriptLoader.Load() with two different arguments
directly after each other. I got an error for the second call that there was
still another load request pending.

I can of course make the second call from within the handler of the first,
but this get's a bit cumbersome when loading "many" files. Wouldn't that be
better handled by the Loader itself?

Cheers,
Fritz

On Mon, 2 Nov 2009, thron7 wrote:

> Yep, we going to need this for other things as well, but I'm thinking
> more of a config key, rather than a file-level compiler hint, see this
> bug: http://bugzilla.qooxdoo.org/show_bug.cgi?id=3016 . I think this
> suits better on the config level.
>
> T.
>
> panyasan wrote:
>> Hello,
>>
>> again on the subject of using non-qooxdo libraries: At the moment, we
>> include them by adding a <script> tag in the index.html, which is ok, but
>> not elegant, and against the generator philosophy of including only what is
>> needed. I would like to propose to add a compiler hint similar to #require,
>> which tells the generator to load a script file before including the given
>> file, such as #load(script/library.js) or
>> #load(http://domoain.com/path/to/my/library.js). With the
>> qx.io2.ScriptLoader class, this shouldn't be a problem, and for the build
>> job, the file could be downloaded and included.
>>
>> Just an idea.
>>
>> C.
>>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

--
Oetiker+Partner AG tel: [phone] (direct)
Fritz Zaucker                        [phone] (switch board)
Aarweg 15                            [phone] (mobile)
CH-4600 Olten                   fax: [phone]
Schweiz                         web: www.oetiker.ch

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[panyasan]

thron7-2 wrote:
>
> Yep, we going to need this for other things as well, but I'm thinking
> more of a config key, rather than a file-level compiler hint, see this
> bug: http://bugzilla.qooxdoo.org/show_bug.cgi?id=3016 . I think this
> suits better on the config level.
>

Sounds good to me although admittedly, it seems to me more intuitive and
less hassle to specify it at the file level, especially when using
contributions. How would you deal with the case that a contribution requires
external libraries? Would the script loader pick them up form the
contribution's config.json? I guess I am answering my own question ;-)

C.  

--
View this message in context: http://n2.nabble.com/Including-non-qooxdoo-libraries-tp3925436p3931373.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Sebastian Werner-5]

2009/11/2 thron7 <thomas.herchenroeder@...>:
> Yep, we going to need this for other things as well, but I'm thinking
> more of a config key, rather than a file-level compiler hint, see this
> bug: http://bugzilla.qooxdoo.org/show_bug.cgi?id=3016 . I think this
> suits better on the config level.


I don't get how to define this in the config file. Basically it's just
another type of dependency. We also do not lost depencies of classes
in the configuration. Just the top-level includes. Especially
regarding variants etc. it might be useful to have this in the code
instead of the configuration. It's more flexible IMHO.

Keeping it at class-level might also help when thinking of resources
e.g. assets which could be integrated using the already available
#asset hints.

Maybe this means a pseudo helper class for every external lib, but
still might be better than placing it into the config.

Cheers,
Sebastian

>
> T.
>
> panyasan wrote:
>> Hello,
>>
>> again on the subject of using non-qooxdo libraries: At the moment, we
>> include them by adding a <script> tag in the index.html, which is ok, but
>> not elegant, and against the generator philosophy of including only what is
>> needed. I would like to propose to add a compiler hint similar to #require,
>> which tells the generator to load a script file before including the given
>> file, such as #load(script/library.js) or
>> #load(http://domoain.com/path/to/my/library.js). With the
>> qx.io2.ScriptLoader class, this shouldn't be a problem, and for the build
>> job, the file could be downloaded and included.
>>
>> Just an idea.
>>
>> C.
>>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7-2]

> I don't get how to define this in the config file. Basically it's just
> another type of dependency. We also do not lost depencies of classes
> in the configuration.

Oh, yes we do, just remember the "require" config key.

>  Just the top-level includes.

And I consider these "external" libraries also top-level.

>  Especially
> regarding variants etc. it might be useful to have this in the code
> instead of the configuration. It's more flexible IMHO.
>  

That might be something to think about at some point. But compiler hints
are also variants-ignorant, so they are not very flexible too in this
regard.

> Keeping it at class-level might also help when thinking of resources
> e.g. assets which could be integrated using the already available
> #asset hints.
>
> Maybe this means a pseudo helper class for every external lib, but
> still might be better than placing it into the config.
>  

I think the config is good place to start as this is a major change in
the semantics of the build system. Better than hiding it somewhere in
class code. Mind that alternatively these libraries go into the index.html.

T.

>  

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Sebastian Werner-5]

2009/11/2 thron7 <thomas.herchenroeder@...>:
>
>
>
>> I don't get how to define this in the config file. Basically it's just
>> another type of dependency. We also do not lost depencies of classes
>> in the configuration.
>
> Oh, yes we do, just remember the "require" config key.

Oops, yes I overlooked this. But I wonder: is really anybody using it?
Just because it's there, does not mean that it's good to be there. ;)

Most stuff is more easily resolvable in the client side code. As with
the automatic detection of dependencies to other classes, with support
for variants and assets, it is much more powerful.

>
>>  Just the top-level includes.
>
> And I consider these "external" libraries also top-level.

The problem might be here in more complex apps. We use, for example,
one tree of classes for different platforms and products. This
external lib dependencies would be easily handleable in our client
side code in the same way we do it with other classes and resources.
Moving this to the config makes it impossible to use it for us, as our
config is pretty generic and just differs in a set of variants.
Nothing else.

I just want to came up with a practical example as I can already see
that this will not help us, and may also not help others. It may be
enough for your internal requirements - that for sure. And it may be
easier to first implement it in your suggested way. Nothing to say
against this. But it does not completely solve the issue of the bug.

>
>>  Especially
>> regarding variants etc. it might be useful to have this in the code
>> instead of the configuration. It's more flexible IMHO.
>>
>
> That might be something to think about at some point. But compiler hints
> are also variants-ignorant, so they are not very flexible too in this
> regard.

What do you mean by compiler-hints?

>
>> Keeping it at class-level might also help when thinking of resources
>> e.g. assets which could be integrated using the already available
>> #asset hints.
>>
>> Maybe this means a pseudo helper class for every external lib, but
>> still might be better than placing it into the config.
>>
>
> I think the config is good place to start as this is a major change in
> the semantics of the build system. Better than hiding it somewhere in
> class code. Mind that alternatively these libraries go into the index.html.

We currently do it with wrapping the original class into a qooxdoo
class file and using this file for dependency injection. Until this is
support is based on code inside the classes I think we keep using this
approach.

Sebastian

>
> T.
>
>>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[panyasan]

Yes, it would probably be good to start with concrete use cases and develop
the theory from there, wouldn't it?

For example, let's say I use the persist-js library
(http://pablotron.org/?cid=1557) in a contribution. The code plays nicely
with qooxdoo since it is put into the namespace "Persist". For it to work, I
have a minified script persisit-all-min.js and a small flash file called
persist.swf that I both put into source/script folder of the contribution.
It shouldn't go into source/class since it is not qooxdoo-compliant. Maybe
an extra folder "lib" or "vendor" or "external" should be added? Or should
it go into "resource"?

Now, we either add an key to config.json or - as Sebastian and I would
prefer - indicate the dependecy of my contribution class on persist.js with
a compiler hint. There might be the unlikely but not impossible situation
that a different contribution also uses persist.js and thus the code would
be loaded twice. Not fatal, but this should be checked by the generator.

When I do a build, the external library needs to be loaded as a dependency
of the class in the script file. Also, it must be copied over to the build
folder for generate.py build. If I include the contribution into another
project, I should have to deal with this dependency in my own code or
config.json, this should be automatically be included into the build jobs.

Hope this use case is helpful for your thoughts on the design of this
feature.

C.




Sebastian Werner-2 wrote:

>
> 2009/11/2 thron7 <thomas.herchenroeder@...>:
>>
>>
>>
>>> I don't get how to define this in the config file. Basically it's just
>>> another type of dependency. We also do not lost depencies of classes
>>> in the configuration.
>>
>> Oh, yes we do, just remember the "require" config key.
>
> Oops, yes I overlooked this. But I wonder: is really anybody using it?
> Just because it's there, does not mean that it's good to be there. ;)
>
> Most stuff is more easily resolvable in the client side code. As with
> the automatic detection of dependencies to other classes, with support
> for variants and assets, it is much more powerful.
>
>>
>>>  Just the top-level includes.
>>
>> And I consider these "external" libraries also top-level.
>
> The problem might be here in more complex apps. We use, for example,
> one tree of classes for different platforms and products. This
> external lib dependencies would be easily handleable in our client
> side code in the same way we do it with other classes and resources.
> Moving this to the config makes it impossible to use it for us, as our
> config is pretty generic and just differs in a set of variants.
> Nothing else.
>
> I just want to came up with a practical example as I can already see
> that this will not help us, and may also not help others. It may be
> enough for your internal requirements - that for sure. And it may be
> easier to first implement it in your suggested way. Nothing to say
> against this. But it does not completely solve the issue of the bug.
>
>>
>>>  Especially
>>> regarding variants etc. it might be useful to have this in the code
>>> instead of the configuration. It's more flexible IMHO.
>>>
>>
>> That might be something to think about at some point. But compiler hints
>> are also variants-ignorant, so they are not very flexible too in this
>> regard.
>
> What do you mean by compiler-hints?
>
>>
>>> Keeping it at class-level might also help when thinking of resources
>>> e.g. assets which could be integrated using the already available
>>> #asset hints.
>>>
>>> Maybe this means a pseudo helper class for every external lib, but
>>> still might be better than placing it into the config.
>>>
>>
>> I think the config is good place to start as this is a major change in
>> the semantics of the build system. Better than hiding it somewhere in
>> class code. Mind that alternatively these libraries go into the
>> index.html.
>
> We currently do it with wrapping the original class into a qooxdoo
> class file and using this file for dependency injection. Until this is
> support is based on code inside the classes I think we keep using this
> approach.
>
> Sebastian
>
>
>>
>> T.
>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) 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/devconference
>> _______________________________________________
>> qooxdoo-devel mailing list
>> qooxdoo-devel@...
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

--
View this message in context: http://n2.nabble.com/Including-non-qooxdoo-libraries-tp3925436p3934602.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7-2]

> I
> have a minified script persisit-all-min.js and a small flash file called
> persist.swf that I both put into source/script folder of the contribution.
> It shouldn't go into source/class since it is not qooxdoo-compliant. Maybe
> an extra folder "lib" or "vendor" or "external" should be added? Or should
> it go into "resource"?

Yes, like Sebastian suggested, "resource" would be a good place as these
files are in fact static resources for the app, right?!

> Now, we either add an key to config.json or - as Sebastian and I would
> prefer - indicate the dependecy of my contribution class on persist.js
> with
> a compiler hint.

See my reply to Sebastian's posting. I currently feel that putting it in
the config is "cleaner", and putting them in the class code is somehow
"burrying" the information. Think of a big project with a couple of
hundred classes, maintained by several developers and several classes
using the third-party code. I'm not saying you couldn't look at it the
other way, it's just my current angle. While I think the "resource" tree
is a good store for those files, there is a big difference (in my eyes) to
other resources like images: the foreign code is to be automatically
loaded into the index.html. I think this deserves to be more prominent
than just another form of #asset(...).

> There might be the unlikely but not impossible situation
> that a different contribution also uses persist.js and thus the code would
> be loaded twice. Not fatal, but this should be checked by the generator.

Interesting point.

> When I do a build, the external library needs to be loaded as a dependency
> of the class in the script file.

Yes, the external library should be loaded. With the approach I see, the
library is somewhat like a "global" dependency of the current app. It's
not going down to the level of class dependencies. If the class is
required by the application, and the library is required by the class,
then the library is required by the app, right?! For me it's more
interesting to think about how this would apply to parts.

> Also, it must be copied over to the build
> folder for generate.py build.

This would be covered by storing it under "resources" and adding #asset()
hints for them in the using class.

> If I include the contribution into another
> project, I should have to deal with this dependency in my own code or
> config.json, this should be automatically be included into the build jobs.

You are right, and here the current handling falls short. Class code and
resources for contribs are treated. But there are other things that have
to be taken care of, and which are specified in the config.json of the
contrib (foreing libraries for one, but e.g. also compile options). We'll
have to think about this.

> Hope this use case is helpful for your thoughts on the design of this
> feature.

Indeed it is. Maybe we should copy it over to the bug.

Thomas



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel