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