Discussion:
Component library
(too old to reply)
d***@cost-savers.net
2016-02-25 18:02:00 UTC
Permalink
After thinking back and forth we have tried to find out about how to make the UI components independent of the core of the framework.

It would be fantastic if it would be possible to uncouple dependencies other than the core ones.

Imagine to have a UI component library, which is not decided by the qooxdoo team and not a compulsory unit coupled unconditionally to the core...

If that would be possible to do, then the core team can focus on core development, while anyone can contribute with UI components. The current so called core UI components would be available separately and loadable on demand but uncoupled from the core.

What do you say about that? Any ideas? Pros and cons?

Stefan
Derrell Lipman
2016-02-25 18:08:09 UTC
Permalink
qooxdoo apps already include only those GUI components that are actively
used by the user's app. Yes, they're included in the qooxdoo source code,
but are otherwise unused.

I would be opposed to removing them. That's going in the opposite direction
of making qooxdoo easier for new people to use. A related option that I
wouldn't oppose (but don't see a very good reason for implementing) is to
create a GUI "library" (in qooxdoo parlance) that is by default included in
config.json (or whatever build system is used). An advanced user could
choose to remove that library entry from config.json to entirely decouple
the core GUI code. Again, though, I don't think this is necessary, as users
are free to create whatever GUI they like, and as long as they have their
own namespace, have no concern of including qooxdoo core GUI functionality
in their app.

Derrell
Post by d***@cost-savers.net
After thinking back and forth we have tried to find out about how to make
the UI components independent of the core of the framework.
It would be fantastic if it would be possible to uncouple dependencies
other than the core ones.
Imagine to have a UI component library, which is not decided by the
qooxdoo team and not a compulsory unit coupled unconditionally to the
core...
If that would be possible to do, then the core team can focus on core
development, while anyone can contribute with UI components. The current so
called core UI components would be available separately and loadable on
demand but uncoupled from the core.
What do you say about that? Any ideas? Pros and cons?
Stefan
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
d***@cost-savers.net
2016-02-26 09:21:33 UTC
Permalink
Derrell,
Post by Derrell Lipman
qooxdoo apps already include only those GUI components that are actively
used by the user's app. Yes, they're included in the qooxdoo source code,
but are otherwise unused.
Putting them in a separate library fully accessible at genertion might increase interest of community to add their UI components and the API would be clearer than today...
Post by Derrell Lipman
I would be opposed to removing them. That's going in the opposite direction
of making qooxdoo easier for new people to use. A related option that I
wouldn't oppose (but don't see a very good reason for implementing) is to
create a GUI "library" (in qooxdoo parlance) that is by default included in
config.json (or whatever build system is used). An advanced user could
choose to remove that library entry from config.json to entirely decouple
the core GUI code. Again, though, I don't think this is necessary, as users
are free to create whatever GUI they like, and as long as they have their
own namespace, have no concern of including qooxdoo core GUI functionality
in their app.
Not removing them but moving them into a separate library list where they can be accessed and used at compilation. Versions of them can then be handled easier.
The doc and everything would be the same. In practice no difference except that other users might be interested to use one of the components and can then easily add it without getting all qooxdoo. A structure more like jquery using git to hold the components and for a list of accepted, tested and approved components, but with qooxdoo's complexity. Many developers use jquery, which still is very successful, of this reason...easy to access and use without studying a whole framework...

It might also force the core to be even leaner and modularized without extra overhead.

I think your last sentence is a concern for new users...overhead and complexity....steep learning curve

Stefan
Post by Derrell Lipman
Derrell
Post by d***@cost-savers.net
After thinking back and forth we have tried to find out about how to make
the UI components independent of the core of the framework.
It would be fantastic if it would be possible to uncouple dependencies
other than the core ones.
Imagine to have a UI component library, which is not decided by the
qooxdoo team and not a compulsory unit coupled unconditionally to the
core...
If that would be possible to do, then the core team can focus on core
development, while anyone can contribute with UI components. The current so
called core UI components would be available separately and loadable on
demand but uncoupled from the core.
What do you say about that? Any ideas? Pros and cons?
Stefan
------------------------------------------------------------------------------
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
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
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
John Spackman
2016-02-27 23:13:49 UTC
Permalink
Hi Stefan

I hadn't seen this when I replied earlier, but reading it now I think that
this touches on the discussions ages ago about how to integrate
contributions into builds.

If bringing in outside contributions could be simplified, then the
location and control of components, whether UI components or something
else, becomes less of an issue.

Ideally I'd like to see something where creating a contrib was no harder
than pushing to github, and using one was no harder than referencing a
github url. If there was also a unified namespace, then just referencing a
class could cause the compiler to include the contrib; for example, my
qx-serverobjects uses the namespace .zenesis.qx.remote and obviously I own
zenesis.com so I should be able to define a mapping to my github release
somehow.

How cool would it be if it automatically downloaded my contrib just
because your code referenced it? For new users, it would mean that any
example snippets work, out of the box. What do you think?

Regards
John



----------------------------------------
From: ***@cost-savers.net
Sent: Friday, February 26, 2016 9:34 AM
To: "qooxdoo Development" <qooxdoo-***@lists.sourceforge.net>
Subject: Re: [qooxdoo-devel] Component library
Derrell,
Post by Derrell Lipman
qooxdoo apps already include only those GUI components that are actively
used by the user's app. Yes, they're included in the qooxdoo source code,
but are otherwise unused.
Putting them in a separate library fully accessible at genertion might
increase interest of community to add their UI components and the API would
be clearer than today...
Post by Derrell Lipman
I would be opposed to removing them. That's going in the opposite direction
of making qooxdoo easier for new people to use. A related option that I
wouldn't oppose (but don't see a very good reason for implementing) is to
create a GUI "library" (in qooxdoo parlance) that is by default included in
config.json (or whatever build system is used). An advanced user could
choose to remove that library entry from config.json to entirely decouple
the core GUI code. Again, though, I don't think this is necessary, as users
are free to create whatever GUI they like, and as long as they have their
own namespace, have no concern of including qooxdoo core GUI
functionality
Post by Derrell Lipman
in their app.
Not removing them but moving them into a separate library list where they
can be accessed and used at compilation. Versions of them can then be
handled easier.
The doc and everything would be the same. In practice no difference except
that other users might be interested to use one of the components and can
then easily add it without getting all qooxdoo. A structure more like
jquery using git to hold the components and for a list of accepted, tested
and approved components, but with qooxdoo's complexity. Many developers use
jquery, which still is very successful, of this reason...easy to access and
use without studying a whole framework...

It might also force the core to be even leaner and modularized without
extra overhead.

I think your last sentence is a concern for new users...overhead and
complexity....steep learning curve

Stefan
Post by Derrell Lipman
Derrell
Post by d***@cost-savers.net
After thinking back and forth we have tried to find out about how to make
the UI components independent of the core of the framework.
It would be fantastic if it would be possible to uncouple dependencies
other than the core ones.
Imagine to have a UI component library, which is not decided by the
qooxdoo team and not a compulsory unit coupled unconditionally to the
core...
If that would be possible to do, then the core team can focus on core
development, while anyone can contribute with UI components. The current so
called core UI components would be available separately and loadable on
demand but uncoupled from the core.
What do you say about that? Any ideas? Pros and cons?
Stefan
----------------------------------------------------------------------------
--
Post by Derrell Lipman
Post by d***@cost-savers.net
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
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
----------------------------------------------------------------------------
--
Post by Derrell Lipman
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
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
Fritz Zaucker
2016-02-28 20:07:58 UTC
Permalink
Post by John Spackman
How cool would it be if it automatically downloaded my contrib just
because your code referenced it? For new users, it would mean that any
example snippets work, out of the box. What do you think?
I am not sure if automatic download is really the best solution. This could
also lead to breaking existing applications if the owner of the contrib
makes a mistake or an incompatible change.

A well defined API for contrib that would just require a simple git clone to
my local file system that then can be easily be pulled in by the compiler
would be consistent with most existing work flows.

Cheers,
Fritz
--
Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker +41 62 775 9900 (switch board)
Aarweg 15 +41 79 675 0630 (mobile)
CH-4600 Olten fax: +41 62 775 9905
Schweiz web: www.oetiker.ch
Tobias Oetiker
2016-02-28 21:18:16 UTC
Permalink
Hi Fritz,
Post by Fritz Zaucker
Post by John Spackman
How cool would it be if it automatically downloaded my contrib just
because your code referenced it? For new users, it would mean that any
example snippets work, out of the box. What do you think?
I am not sure if automatic download is really the best solution. This could
also lead to breaking existing applications if the owner of the contrib
makes a mistake or an incompatible change.
this can be easily addressed by using mandatory semantic versioning
and a config file where you declear what version you want to use
and the option of allowing bugfix updates, I think ...
Post by Fritz Zaucker
A well defined API for contrib that would just require a simple git clone to
my local file system that then can be easily be pulled in by the compiler
would be consistent with most existing work flows.
yes ... we need to get and contrib issue fixed and we need tooling
support for it, and since the build system is part of the qooxdoo
offering, management of the 3rd party extensions should be part of
it.

cheers
tobi
--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch ***@oetiker.ch +41 62 775 9902
John Spackman
2016-02-27 21:37:14 UTC
Permalink
Hi Stefan

Im not sure if I've misunderstood but while I think it would be quite
straightforward to separate them off, Im not sure what the benefit would
be? There's no runtime overhead because the compiler/generator would only
bring in what's necessary, so it would be useful for admin purposes but
would make it more complicated for new users to get started. At the moment
the "core" development effort is spread across all parts of Qooxdoo so I'd
be concerned that it would admin overhead at a time when there is so much
to do.

Regards
John




----------------------------------------
From: ***@cost-savers.net
Sent: Thursday, February 25, 2016 6:14 PM
To: qooxdoo-***@lists.sourceforge.net
Subject: [qooxdoo-devel] Component library
After thinking back and forth we have tried to find out about how to make
the UI components independent of the core of the framework.

It would be fantastic if it would be possible to uncouple dependencies
other than the core ones.

Imagine to have a UI component library, which is not decided by the qooxdoo
team and not a compulsory unit coupled unconditionally to the core...

If that would be possible to do, then the core team can focus on core
development, while anyone can contribute with UI components. The current so
called core UI components would be available separately and loadable on
demand but uncoupled from the core.

What do you say about that? Any ideas? Pros and cons?

Stefan

----------------------------------------------------------------------------
--
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
d***@cost-savers.net
2016-02-28 10:40:23 UTC
Permalink
Hi John,
Post by John Spackman
Hi Stefan
I hadn't seen this when I replied earlier, but reading it now I think that
this touches on the discussions ages ago about how to integrate
contributions into builds.
If bringing in outside contributions could be simplified, then the
location and control of components, whether UI components or something
else, becomes less of an issue.
Ideally I'd like to see something where creating a contrib was no harder
than pushing to github, and using one was no harder than referencing a
github url. If there was also a unified namespace, then just referencing a
class could cause the compiler to include the contrib; for example, my
qx-serverobjects uses the namespace .zenesis.qx.remote and obviously I own
zenesis.com so I should be able to define a mapping to my github release
somehow.
How cool would it be if it automatically downloaded my contrib just
because your code referenced it? For new users, it would mean that any
example snippets work, out of the box. What do you think?
Exactly this is our idea about it. It should be seemlessly integrated. The cloud should be used. An automatic behaviour when referenced bothers new users less and they can focus on less details...i.e. they need less reading of manuals etc...that is something for framework developers.

With a contribution system where also the existing GUI components are contributed but maybe called "core", it is possible to easily contribute and then the community will test it and approve the component after certain rules set up. KISS Keep It Stupid Simple but increase flexibility...

A contributor sends a pull request to one collecting repository of GUI components. It will then be tested and approved or not etc. When generating the application all references are checked against this repository and prints a warning message of an unapproved component is referenced etc.

It makes it easier to expand the set of GUI components, versionize them and focus on keeping the core of the framework lean and effective with a clear focus.

Is it a good idea?

Stefan
Post by John Spackman
Regards
John
----------------------------------------
Sent: Friday, February 26, 2016 9:34 AM
Subject: Re: [qooxdoo-devel] Component library
Derrell,
Post by Derrell Lipman
qooxdoo apps already include only those GUI components that are actively
used by the user's app. Yes, they're included in the qooxdoo source
code,
Post by Derrell Lipman
but are otherwise unused.
Putting them in a separate library fully accessible at genertion might
increase interest of community to add their UI components and the API would
be clearer than today...
Post by Derrell Lipman
I would be opposed to removing them. That's going in the opposite
direction
Post by Derrell Lipman
of making qooxdoo easier for new people to use. A related option that I
wouldn't oppose (but don't see a very good reason for implementing) is
to
Post by Derrell Lipman
create a GUI "library" (in qooxdoo parlance) that is by default included
in
Post by Derrell Lipman
config.json (or whatever build system is used). An advanced user could
choose to remove that library entry from config.json to entirely
decouple
Post by Derrell Lipman
the core GUI code. Again, though, I don't think this is necessary, as
users
Post by Derrell Lipman
are free to create whatever GUI they like, and as long as they have
their
Post by Derrell Lipman
own namespace, have no concern of including qooxdoo core GUI
functionality
Post by Derrell Lipman
in their app.
Not removing them but moving them into a separate library list where they
can be accessed and used at compilation. Versions of them can then be
handled easier.
The doc and everything would be the same. In practice no difference except
that other users might be interested to use one of the components and can
then easily add it without getting all qooxdoo. A structure more like
jquery using git to hold the components and for a list of accepted, tested
and approved components, but with qooxdoo's complexity. Many developers use
jquery, which still is very successful, of this reason...easy to access and
use without studying a whole framework...
It might also force the core to be even leaner and modularized without
extra overhead.
I think your last sentence is a concern for new users...overhead and
complexity....steep learning curve
Stefan
Post by Derrell Lipman
Derrell
Post by d***@cost-savers.net
After thinking back and forth we have tried to find out about how to
make
Post by Derrell Lipman
Post by d***@cost-savers.net
the UI components independent of the core of the framework.
It would be fantastic if it would be possible to uncouple dependencies
other than the core ones.
Imagine to have a UI component library, which is not decided by the
qooxdoo team and not a compulsory unit coupled unconditionally to the
core...
If that would be possible to do, then the core team can focus on core
development, while anyone can contribute with UI components. The current
so
Post by Derrell Lipman
Post by d***@cost-savers.net
called core UI components would be available separately and loadable on
demand but uncoupled from the core.
What do you say about that? Any ideas? Pros and cons?
Stefan
----------------------------------------------------------------------------
--
Post by Derrell Lipman
Post by d***@cost-savers.net
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
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
----------------------------------------------------------------------------
--
Post by Derrell Lipman
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
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
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
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Loading...