qooxdoo

How to make parts independent

Classic

List

Threaded

21 messages Options

Defero

How to make parts independent

Hi,

for a while now we were using parts in our applications, which work well when we're the one defining these parts.

But soon, alot of external programmers will start using the communication (and some ui) layers that we setup.
So my question is, is there any flexibility in the way the application is built? I wish to avoid the: send me your source and we'll build it in, approach.

The ideal version would be, that they get a compiled version of our build, they include it in their own qx project. And after they are finished, the compile it and send it, which we include in as a "dynamic part" when it is requested by the client.

Regards,
Defero

panyasan

Re: How to make parts independent

This post was updated on .

Hello,

I had a similar problem trying to implement plugins via the parts architecture. I've been told that this was not what the parts system had been designed for, so it is kind of a hack. But it works:

Since the part loader system depends on static code analysis, you need to name the parts explicitly in your config.json, and in the class that contains the part loader. So you need to keep those files updated manually. Third parties then can provide libraries. I use a shell script to create plugin skeletons to make that easier.

Hope that gives you some ideas. I wish it was not a hack, but supported out of the box by qooxdoo!

Best,
Chrsitian

Defero

Re: How to make parts independent

Hi,

in this case your project has to be recompiled everytime for the changes to appear?

Regards,
Defero

panyasan

Re: How to make parts independent

Defero wrote

Hi,

in this case your project has to be recompiled everytime for the changes to appear?

Regards,
Defero

Yes, beacause the generator needs to resolve all the dependencies ... So in the sense of your original question, yes, you will need their source to create the complete app.

Defero

Re: How to make parts independent

Hi,

is there anyway to ensure that 1 part is also 1 built part?

So if i change my config automatically to include only the "newly updated" part. Then i build the project. I would be able to copy only the changes (and the main build) to the production. And in this case leave all the other plugins untouched.

At the moment i can't even tell which part is which.

panyasan

Re: How to make parts independent

Hi Defero,

Defero wrote

is there anyway to ensure that 1 part is also 1 built part?

So if i change my config automatically to include only the "newly updated" part. Then i build the project. I would be able to copy only the changes (and the main build) to the production. And in this case leave all the other plugins untouched.

I think someone from the qooxdoo team should answer this question, but from what I remember (I am currently not working on anything qx-specific), this should work the way you describe. The generator would buld the updated plugin library and no change anything in the other libraries. As long as there are no plugin library API changes, even the main build might stay intact.

Defero

Re: How to make parts independent

Hi,

it might work, but i think it's quite a dangerous hack. It's hard to find any data of how the compiler works, is there any extensive documentations on that?

Does anyone have any ideas in general, how would you guy handle 1000 plugins for example. (These are loaded only per user specific requests).
And if we want to allow full access to qooxdoo functionality with it, i can't see a good way of achieving this.
Either you have 1000 libraries and you include them in the build, or you go with the un-optimized build-all approach.

I hope i'm missing something.

Regards,
Defero

John Spackman-3

Re: How to make parts independent

Hi Defero

To make that work you’d need to be able to analyse the dependencies of each plugin on demand, and then load those classes to the client; I dont think you can do this with the current generator but as it happens I think I’ll have something that will do the job in the next week or so.

I’m getting ready to release a replacement for the generator, written in 100% javascript and running under node.js; it’s API based and exposes dependency information, and you’d be able to use the API to incrementally scan dependencies of new classes (e.g. Add plugins on the fly and analyse them). It also supplies ES6 (via babel) and is way faster that the python version.

The only potential snag is that while all the dependency detection etc is all working, there is not support for parts yet - you’d have to implement your own code to parcel up each part (or plugin) and load it on the fly, but because it’s API based that should not be a problem.

It’s my holiday project to finish it off, and while it’ll be an alpha release it’s there and working apart from some translation work that needs to be done to finalise the ES6 implementation.

So if you can hold off a week or so there might be something to look at :)

Regards
John

On 22/12/2015, 14:08, "Defero" <[hidden email]> wrote:

>Hi,
>
>it might work, but i think it's quite a dangerous hack. It's hard to find
>any data of how the compiler works, is there any extensive documentations on
>that?
>
>Does anyone have any ideas in general, how would you guy handle 1000 plugins
>for example. (These are loaded only per user specific requests).
>And if we want to allow full access to qooxdoo functionality with it, i
>can't see a good way of achieving this.
>Either you have 1000 libraries and you include them in the build, or you go
>with the un-optimized build-all approach.
>
>I hope i'm missing something.
>
>Regards,
>Defero
>
>
>
>--
>View this message in context: http://qooxdoo.678.n2.nabble.com/How-to-make-parts-independent-tp7587856p7587863.html
>Sent from the qooxdoo mailing list archive at Nabble.com.
>
>------------------------------------------------------------------------------
>_______________________________________________
>qooxdoo-devel mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Derrell Lipman

Re: How to make parts independent

John, that sounds incredibly cool!

Derrell

On Tue, Dec 22, 2015, 8:06 PM John Spackman <[hidden email]> wrote:

Hi Defero

To make that work you’d need to be able to analyse the dependencies of each plugin on demand, and then load those classes to the client; I dont think you can do this with the current generator but as it happens I think I’ll have something that will do the job in the next week or so.

I’m getting ready to release a replacement for the generator, written in 100% javascript and running under node.js; it’s API based and exposes dependency information, and you’d be able to use the API to incrementally scan dependencies of new classes (e.g. Add plugins on the fly and analyse them). It also supplies ES6 (via babel) and is way faster that the python version.

The only potential snag is that while all the dependency detection etc is all working, there is not support for parts yet - you’d have to implement your own code to parcel up each part (or plugin) and load it on the fly, but because it’s API based that should not be a problem.

It’s my holiday project to finish it off, and while it’ll be an alpha release it’s there and working apart from some translation work that needs to be done to finalise the ES6 implementation.

So if you can hold off a week or so there might be something to look at :)

Regards
John

On 22/12/2015, 14:08, "Defero" <[hidden email]> wrote:

>Hi,
>
>it might work, but i think it's quite a dangerous hack. It's hard to find
>any data of how the compiler works, is there any extensive documentations on
>that?
>
>Does anyone have any ideas in general, how would you guy handle 1000 plugins
>for example. (These are loaded only per user specific requests).
>And if we want to allow full access to qooxdoo functionality with it, i
>can't see a good way of achieving this.
>Either you have 1000 libraries and you include them in the build, or you go
>with the un-optimized build-all approach.
>
>I hope i'm missing something.
>
>Regards,
>Defero
>
>
>
>--
>View this message in context: http://qooxdoo.678.n2.nabble.com/How-to-make-parts-independent-tp7587856p7587863.html
>Sent from the qooxdoo mailing list archive at Nabble.com.
>
>------------------------------------------------------------------------------
>_______________________________________________
>qooxdoo-devel mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

John Spackman-3

Re: How to make parts independent

Thanks Derrell :)

I’ve been working on it on and off for ages, and adding babel put it back a bit but was such cool idea I couldn’t resist :)

John

From: Derrell Lipman <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 23 December 2015 at 02:58
To: qooxdoo Development <[hidden email]>
Subject: Re: [qooxdoo-devel] How to make parts independent

John, that sounds incredibly cool!

Derrell

On Tue, Dec 22, 2015, 8:06 PM John Spackman <[hidden email]> wrote:

Hi Defero

To make that work you’d need to be able to analyse the dependencies of each plugin on demand, and then load those classes to the client; I dont think you can do this with the current generator but as it happens I think I’ll have something that will do the job in the next week or so.

I’m getting ready to release a replacement for the generator, written in 100% javascript and running under node.js; it’s API based and exposes dependency information, and you’d be able to use the API to incrementally scan dependencies of new classes (e.g. Add plugins on the fly and analyse them). It also supplies ES6 (via babel) and is way faster that the python version.

The only potential snag is that while all the dependency detection etc is all working, there is not support for parts yet - you’d have to implement your own code to parcel up each part (or plugin) and load it on the fly, but because it’s API based that should not be a problem.

It’s my holiday project to finish it off, and while it’ll be an alpha release it’s there and working apart from some translation work that needs to be done to finalise the ES6 implementation.

So if you can hold off a week or so there might be something to look at :)

Regards
John

On 22/12/2015, 14:08, "Defero" <[hidden email]> wrote:

>Hi,
>
>it might work, but i think it's quite a dangerous hack. It's hard to find
>any data of how the compiler works, is there any extensive documentations on
>that?
>
>Does anyone have any ideas in general, how would you guy handle 1000 plugins
>for example. (These are loaded only per user specific requests).
>And if we want to allow full access to qooxdoo functionality with it, i
>can't see a good way of achieving this.
>Either you have 1000 libraries and you include them in the build, or you go
>with the un-optimized build-all approach.
>
>I hope i'm missing something.
>
>Regards,
>Defero
>
>
>
>--
>View this message in context: http://qooxdoo.678.n2.nabble.com/How-to-make-parts-independent-tp7587856p7587863.html
>Sent from the qooxdoo mailing list archive at Nabble.com.
>
>------------------------------------------------------------------------------
>_______________________________________________
>qooxdoo-devel mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Defero

Re: How to make parts independent

In reply to this post by John Spackman-3

Hi,

that does sound cool ye :)

I would definitely like to volunteer to be one of the testers

Regards,
Defero

John Spackman-3

Re: How to make parts independent

Well I’ve talked about it now so I’d better put it up! :)

My plan is to get it finished off and release on github as an alpha before getting-paid work starts again on the 4th, I’ll post up here when it’s ready

John

On 23/12/2015, 09:31, "Defero" <[hidden email]> wrote:

>Hi,
>
>that does sound cool ye :)
>
>I would definitely like to volunteer to be one of the testers
>
>
>Regards,
>Defero
>
>
>
>--
>View this message in context: http://qooxdoo.678.n2.nabble.com/How-to-make-parts-independent-tp7587856p7587871.html
>Sent from the qooxdoo mailing list archive at Nabble.com.
>
>------------------------------------------------------------------------------
>_______________________________________________
>qooxdoo-devel mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Dietrich Streifert

Re: How to make parts independent

Hi John,

is this completely independent from the latest grunt toolchain works in qx?

http://manual.qooxdoo.org/devel/pages/tool/grunt.html

Am 23.12.2015 um 10:40 schrieb John Spackman:
> Well I’ve talked about it now so I’d better put it up! :)
>
> My plan is to get it finished off and release on github as an alpha before getting-paid work starts again on the 4th, I’ll post up here when it’s ready
>
> John
>
>
>
>

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

John Spackman-3

Re: How to make parts independent

Hi Dietrich

Yes, completely independent - it’s just a node app that is self contained; the code is written using Qx classes and the command line interface is a thin wrapper around them. I’m not intending to use grunt at all, I prefer that it’s focused on analysing code, generating dependency trees, and writing out the application in source/build/hybrid. So it’s a tool that your grunt script might execute to create the app, rather than being integrated into grunt.

I presume that it’s trivial to roll your own grunt task to execute something, and if you wanted to pass dependency information for grunt you could write a bit of code to pull it out easy enough. The database of dependencies etc is just in JSON.

A command line interface is just a few lines of code - the API makes it easy to create all kinds of specialised tooling, e.g. Petr’s talked about creating custom builds of apps with all Qooxdoo classes, etc

John

On 23/12/2015, 10:21, "Dietrich Streifert" <[hidden email]> wrote:

>Hi John,
>
>is this completely independent from the latest grunt toolchain works in qx?
>
>http://manual.qooxdoo.org/devel/pages/tool/grunt.html
>
>
>Am 23.12.2015 um 10:40 schrieb John Spackman:
>> Well I’ve talked about it now so I’d better put it up! :)
>>
>> My plan is to get it finished off and release on github as an alpha before getting-paid work starts again on the 4th, I’ll post up here when it’s ready
>>
>> John
>>
>>
>>
>>
>
>
>------------------------------------------------------------------------------
>_______________________________________________
>qooxdoo-devel mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Defero

Re: How to make parts independent

Hi,

any news on this maybe? Also, if you need any help, i would be happy to help.

Defero

John Spackman-3

Re: How to make parts independent

Hi Defero

Yes, there is and I think it’s good news :) My original implementation was based on Esprima and I’ve had to rejig it to make it work with Babel for ES6 - I think it’s ready for alpha release baring one issue with environment settings and some documentation. Sorry it’s a bit later than I planned, but I should be able to put it up this week.

Thanks for the offer of help - yes please :) I’ll publish on github and I’m very open to pull requests etc.

Regards
John

On 06/01/2016, 07:28, "Defero" <[hidden email]> wrote:

>Hi,
>
>any news on this maybe? Also, if you need any help, i would be happy to
>help.
>
>Defero
>
>
>
>--
>View this message in context: http://qooxdoo.678.n2.nabble.com/How-to-make-parts-independent-tp7587856p7587915.html
>Sent from the qooxdoo mailing list archive at Nabble.com.
>
>------------------------------------------------------------------------------
>_______________________________________________
>qooxdoo-devel mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Defero

Re: How to make parts independent

Hi,

really good news then :)

Yes, count me in. Will right away probably try implement something like parts to it.

Regards,
Defero

Defero

Re: How to make parts independent

Hi,

me again :)

normally i wouldn't bug people this much, but i need to find a viable and fully operational solution here at work this year.
I really love how this one works and i'm just getting eager too try it out :)

Regards,
Defero

John Spackman-3

Re: How to make parts independent

Hi Defero

Sorry, I really haven’t forgotten - I’ve just been so flat out with work this year. I do think that I’ll be able to do the docs etc this week, but I’ll put what I have up regardless and then we’ll chat over the ML

Regards
John

On 10/02/2016, 14:28, "Defero" <[hidden email]> wrote:

>Hi,
>
>me again :)
>
>normally i wouldn't bug people this much, but i need to find a viable and
>fully operational solution here at work this year.
>I really love how this one works and i'm just getting eager too try it out
>:)
>
>
>Regards,
>Defero
>
>
>
>--
>View this message in context: http://qooxdoo.678.n2.nabble.com/How-to-make-parts-independent-tp7587856p7587987.html
>Sent from the qooxdoo mailing list archive at Nabble.com.
>
>------------------------------------------------------------------------------
>Site24x7 APM Insight: Get Deep Visibility into Application Performance
>APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>Monitor end-to-end web transactions and take corrective actions now
>Troubleshoot faster and improve end-user experience. Signup Now!
>http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>_______________________________________________
>qooxdoo-devel mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

mitya

Re: How to make parts independent

In reply to this post by John Spackman-3

John,

Thank you for you efforts, and please be sure you've got another beta-
tester and probably contributor(s).

Some background first. We are developing a massive qooxdoo Desktop
application. When we were about to roll integration tests, it turned
out that our app doesn't run in PhantomJS - because of Promises that we
heavily use in our app. Up to this moment, supporting legacy browsers
was not our primary objective, but certainly that PhantomJS issue was
something to be dealt with.

Lack of Promises is a well-known problem in PhantomJS [1]. The guys
have already begun transitioning to CEF [2], and it's unlikely that
PhantomJS gets Promises until then. God knows how long will it take,
considering another ~1500 open issues.

From the discussion [1] I've learned about Babel. Employing Babel would
not only solve the PhantomJS+Promise issue, but would also allow us to
use full ES6, at the same time making our app compatible with legacy
browsers.

I've started to investigate how to integrate Babel into qooxdoo
toolchain, but suddenly stumbled upon this thread. Needless to say how
excited I was :) I wish you luck, and kindly ask you please to keep us
informed.

P.S. Thanks for the excellent UploadMgr, we've been using it in our
project since the very beginning. It has been a real time saver for our
developers.

[1] https://github.com/ariya/phantomjs/issues/12401
[2] https://github.com/ariya/phantomjs/issues/10209

> Hi Defero
>
> To make that work you’d need to be able to analyse the dependencies
> of each plugin on demand, and then load those classes to the client;
> I dont think you can do this with the current generator but as it
> happens I think I’ll have something that will do the job in the next
> week or so.
>
> I’m getting ready to release a replacement for the generator, written
> in 100% javascript and running under node.js; it’s API based and
> exposes dependency information, and you’d be able to use the API to
> incrementally scan dependencies of new classes (e.g. Add plugins on
> the fly and analyse them). It also supplies ES6 (via babel) and is
> way faster that the python version.
>
> The only potential snag is that while all the dependency detection
> etc is all working, there is not support for parts yet - you’d have
> to implement your own code to parcel up each part (or plugin) and
> load it on the fly, but because it’s API based that should not be a
> problem.
>
> It’s my holiday project to finish it off, and while it’ll be an alpha
> release it’s there and working apart from some translation work that
> needs to be done to finalise the ES6 implementation.
>
> So if you can hold off a week or so there might be something to look
> at :)
>
> Regards
> John
>
>
>
> On 22/12/2015, 14:08, "Defero" <[hidden email]> wrote:
>
> > Hi,
> >
> > it might work, but i think it's quite a dangerous hack. It's hard
> > to find
> > any data of how the compiler works, is there any extensive
> > documentations on
> > that?
> >
> > Does anyone have any ideas in general, how would you guy handle
> > 1000 plugins
> > for example. (These are loaded only per user specific requests).
> > And if we want to allow full access to qooxdoo functionality with
> > it, i
> > can't see a good way of achieving this.
> > Either you have 1000 libraries and you include them in the build,
> > or you go
> > with the un-optimized build-all approach.
> >
> > I hope i'm missing something.
> >
> > Regards,
> > Defero
> >
> >
> >
> > --
> > View this message in context: http://qooxdoo.678.n2.nabble.com/How-
> > to-make-parts-independent-tp7587856p7587863.html
> > Sent from the qooxdoo mailing list archive at Nabble.com.
> >
> > -----------------------------------------------------------------
> > -------------
> > _______________________________________________
> > qooxdoo-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>
> -------------------------------------------------------------------
> -----------
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel