Discussion about Qooxdoo "Website" new feature

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Discussion about Qooxdoo "Website" new feature

benco
This post was updated on .
Hi guys,

I would take the opportunity to discuss a bit about the new "website" functionalities.

On one hand, I like the concept and the idea very much. First of all, it's very simple for newbie and the way it was conceived is rather good: it can help popularize a lot the entire framework because of the "jquery approach" (maybe jquery users would be interested in giving a try to qooxdoo and furthermore it opens the door to jquery's modules conversion).

On the other hand, I must say I fell a bit lost with this whole new "facet" :

* the qx.bom package seems to be doomed to "internal usage only" in the future or to simply disappear when/if "q shortcuts" won't be shortcuts anymore.
* I have the impression developing qooxdoo Native applications makes not "direct" sense anymore. I like the "native application" approach but I wonder now if it wouldn't be better to have "q module wrappers" to custom qx classes developed in a qx-OO way most of the time.

Actually I doesn't mean that I don't like the approach but now I really wonder how the whole framework will evolve in the future at bom level...

Regards,

Benoît.
Reply | Threaded
Open this post in threaded view
|

Re: Discussion about Qooxdoo "Website" new feature

Tristan Koch
Hi Benoît,

first of all many thanks for checking out the qx.Website component. qx.Website is still in an early phase of development and feedback is very much appreciated.

I'm glad you find qx.Website more accessible, as this was one of the main design goals of both the framework and the new website. The questions you raise point to the heart of the issues we still see with the component. While we have a vague vision, its still work in progress. Therefore I cannot answer your questions,  but perhaps you want to share your view? Do you consider qx.bom.* as something that should be kept alongside the (q) API? Do you see (q) as a "replacement" of jQuery in terms of the features provided? What do you think of the API when compared directly to jQuery (e.g. explicity setters/getters). Do you think jQuery has serious short-comings feature-wise that (q) could improve upon?

Also, note that the documentation of qx.Website is incredibly outdated (sadly). Right now, I recommend looking at the source code and the API docs for qx.module [1]. We're working on it and I'm sure that with the 2.0 release we'll have reached the quality of other component's docs.

Concerning qooxdoo Native applications, one use case I see are qx.Website views. Take a look at the website application and view of the feedreader sample application [2]. You'll notice the (q) API is not used, but that's because the application was written before (q) was introduced and has not been updated yet. At least, I would assume so.

To see more (q) code in action, feel free to take a look at the new website's JavaScript code. You'll notice the scripts are organized in (q) plug-ins – with q.attach – and classes are defined using the recently introduced q.define method which is basically a qx.Bootstrap.define in disguise.

Regards
Tristan

[1] http://demo.qooxdoo.org/devel/apiviewer/#qx.module
[2] http://bit.ly/HXgByu

Am 19.04.2012 um 23:26 schrieb benco:

> Hi guys,
>
> I would take the opportunity to discuss a bit about the new "website"
> functionalities.
>
> On one hand, I like the concept and the idea very much. First of all, it's
> very simple for newbie and the way it was conceived is rather good: it can
> help popularize a lot the entire framework because of the "jquery approach"
> (maybe jquery users would be interested in giving a try to qooxdoo and
> furthermore it opens the door to jquery's modules conversion).
>
> On the other hand, I must say I fell a bit lost with this whole new "facet"
> :
>
> * the qx.bom package seems to be doomed to "internal usage only" in the
> future or to simply disappear when "q shortcuts" won't be shortcuts anymore.
> I mean that the whole design architecture/hierarchy has changed. It's not
> anymore qx.bom+qx.oo > qx.html > qx.ui.{mobile}. It's rather qx.bom ~ q AND
> qx.bom+qx.oo > qx.html > qx.ui.{mobile}.
> * I have the impression developing qooxdoo Native applications makes not
> "direct" sense anymore. I like the OO approach but I wonder now if it
> wouldn't be better to have "q module wrappers" to custom qx classes
> developed in a OO way.
>
> Actually I doesn't mean that I don't like the approach but now I really
> wonder how the whole framework will evolve in the future at bom level...
>
> Regards,
>
> Benoît.
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/Discussion-about-Qooxdoo-Website-new-feature-tp7482249p7482249.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Discussion about Qooxdoo "Website" new feature

benco
This post was updated on .
Hi Tristan,

Thanks for your reply. So here are my answers and views (please don't consider it as critics... Also perhaps nobody else see the same problems with it!):

* The current wip implementation has a drawback: I have a feeling it's not "all in one piece" according to the programmer point of view. There isn't clear abstraction levels' hierarchy anymore: you have to choose either (q ~ qx.Collection + qx.module.*) or (the other parts of the framework). Currently all the (q) functions are shortcuts to qx.bom. My idea is (q) should completely become the new qx.bom - so no, I don't think it's good to keep qx.bom.* alongside of q. But there is another problem: (q) is also a bootstrap shortcut to qx.Collection that inits as the result of qx.bom.Selectory.query() and we don't always need the Sizzle functionalities. So, my idea is (q) shouldn't init as that function result. Then we possibily and manually "attachRoot" (some sort of) qx.module.Collection to have the Jquery-style behavior. I know it's perhaps a strange way to do but I fell we then keep much more consistency. By extension, we could keep a whole self-containing structure if all is module-oriented (for instance: q.attach(qx.module.Class);). The py-compiler would then automatically guess what to init and modules to load if we directly program in OO-style. Voilà, I think I don't forget to mention anything. Of course, please, note that my ideas come into view after very little thought. Perhaps I forget essential points!

* Also the event layer isn't clear anymore. Does the "application-style" event layer will extend the new minimal event class/module in the future ?

* I don't see directly (q) as a replacement for Jquery but it could be if we init as it! In fact all your other questions can find their answer in my previous point.

Regards

Benoît.
Reply | Threaded
Open this post in threaded view
|

Re: Discussion about Qooxdoo "Website" new feature

Thomas Herchenroeder
> * The current wip implementation has a drawback: I have a feeling it's not
> "all in one piece" according to the programmer point of view. There isn't
> clear abstraction levels' hierarchy anymore: you have to choose either (q
> ~
> qx.Collection + qx.module.*) or (the other parts of the framework).

Let me chime in a bit. One way to look at (q) is as a set of
functionality. But another way is to abstract away from the concrete
functionality and to look at it as an infrastructure to expose
functionality in a procedural way. You have a global object which exposes
a number of methods, you have a way of adding methods, you can chain
expressions, etc. So there are a number of little protocols involved. This
could be the defining character of (q).

Related to the framework you could say it is just another interface to the
(/some) functionality the framework provides. And in that view, the class
hierarchy is *also* just another view, another interface to it. For the
developer it shouldn't matter how things are implemented under the hood.
He or she just chooses the interface he/she likes to work with.

And I think that's what (q) is mainly about: Provide another choice to
work with the framework. I think most developers want to choose. And both
interfaces don't have to fit into a single hierarchical view of functional
blocks where (q) is here and goes so far, and the OO classes are there and
go so far. They can coexist independently.

> Currently all the (q) functions are shortcuts to qx.bom. My idea is (q)
> should completely become the new qx.bom - so no, I don't think it's good
> to
> keep qx.bom.* alongside of q.

I could see developers using the OO interface, and be wanting the ability
to use a qx.bom layer. So why should the be forced to break out of the OO
paradigm and use (q) on that level?!

> But there is another problem: (q) is also a
> bootstrap shortcut to qx.Collection that inits as the result of
> qx.bom.Selectory.query() and we don't always need the Sizzle
> functionalities.

This refers to the question of the functional set (q) should comprise. We
could argue whether or not a selection API should be part of the basic
deliverable "(q)". But I think over mid-term this will be a question of
customization on the part of the user. There might be a base (q) package,
and everything else in modules which you can combine. There might be a few
popular selections of modules be pre-packaged for download. There might be
a web service that simply lets you pick and choose the modules you want
included and the corresponding package will be created on the fly. And so
on.

> So, my idea is (q) shouldn't init as that function
> result.
> Then we possibily and manually "attachRoot" (some sort of)
> qx.module.Collection to have the Jquery-style behavior. I know it's
> perhaps
> a strange way to do but I fell we then keep much more consistency. By
> extension, we could keep a whole self-containing structure if all is
> module-oriented (for instance: q.attach(qx.module.Class);).

Indeed, there might be few limits as to how far "up" the (q) interface can
include functionality from the framework.

> The
> py-compiler
> would then automatically guess what to init and modules to load if we
> directly program in OO-style.

As I said I wouldn't force to mix the two interfaces (although it should
be technically possible). You either work with pre-shrunk, procedural
libraries, or with a class-based interface with dependency detection.

> * I don't see directly (q) as a replacement for Jquery but it could be if
> we
> init as it!

Exactly. (q)-the-platform could be used to create a package which can act
as a replacement for jquery.

T.


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Discussion about Qooxdoo "Website" new feature

benco
Hi Thomas,

Thanks for your comment.

thron7-2 wrote
I could see developers using the OO interface, and be wanting the ability
to use a qx.bom layer. So why should the be forced to break out of the OO
paradigm and use (q) on that level?!
Said like that, I agree a lot with you... But actually, most of qx.bom Classes are "static ones", there are only a few ones that can be instanciated to objects.

Regards,

Benoît.