Pivotgrid like this
one<http://dev.sencha.com/deploy/ext-3.4.0/examples/pivotgrid/people.html>.
Before I start on trying to make it, I'll ask if anybody has made anything
like that before and would be willing to share something about it.
Best Regards,
Alex Knol
Movil: +34 693 206 868
Company: Pumiwex S.L.U.
PostBox: Apartado Correos 842, Camarles
Delivery: Plaza Don Diego de Leon 3, Camarles
Postal Code: 43894
Country: Espana
On Thu, Jan 12, 2012 at 7:43 PM, <
[email protected]> wrote:
> Send qooxdoo-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of qooxdoo-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Odd Mixins Behavior (aditya siram)
> 2. Re: Odd Mixins Behavior (thron7)
> 3. Re: Introducing LIBERATED -- qooxdoo-based server with
> built-in server simulator for easy debugging (Gene Amtower)
> 4. Re: Odd Mixins Behavior (Derrell Lipman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 12 Jan 2012 12:04:40 -0600
> From: aditya siram <[email protected]>
> Subject: Re: [qooxdoo-devel] Odd Mixins Behavior
> To: qooxdoo Development <[email protected]>
> Message-ID:
> <cajrreyi3wta+f2oc_t8btgme-04y5pzxkhae-8edwda7s5b...@mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> And the two lines that I wanted to swap were in the middle of the "invoke"
> function before it makes a call to the server on completion. So subclassing
> and calling the superclass would not have worked because the side effect
> would have occured by the time it reached my code.
> -deech
>
> On Thu, Jan 12, 2012 at 12:01 PM, aditya siram <[email protected]
> >wrote:
>
> > The problem with this subclassing approach is that, doing this the right
> > way, I would have to cut-and-paste the "__createRequest" and a number of
> > other private functions wholesale into the subclass. All I really wanted
> to
> > do was swap the order of two lines in the "invoke" method.
> >
> > I agree that mixins shouldn't have access to private members when
> > "include"ed but when "patch"ing, which is a hacky last-resort anyway, I
> > should have complete access.
> >
> > -deech
> >
> > On Thu, Jan 12, 2012 at 11:33 AM, Derrell Lipman <
> > [email protected]> wrote:
> >
> >>
> >>
> >> On Thu, Jan 12, 2012 at 12:28, aditya siram <[email protected]
> >wrote:
> >>
> >>> Hi all,
> >>> I had a mixin issue that I'd been battling for the past couple of days
> >>> and fixed it but wanted to post the solution.
> >>>
> >>> The problem was that I needed to patch the "qx.io.rest.Resource" class
> >>> and with a new "invoke(...)" method. In my "source" application
> everything
> >>> worked fine and the mixin's method was used with no problem. In the
> "build"
> >>> version I kept getting an error saying that my mixin was undefined.
> >>>
> >>> The original "invoke" method looks something like:
> >>> invoke : function ( ... ) {
> >>> ...
> >>> this.__createRequest();
> >>> ...
> >>> }
> >>>
> >>> And my mixin method looked like:
> >>> invoke : function ( ... ) {
> >>> ...
> >>> this.__createRequest();
> >>> doSomeMoreStuff();
> >>> ...
> >>> }
> >>>
> >>>
> >>> The reason this is happening is that the "__createRequest" method in
> >>> "qx.io.rest.Resource" gets mangled before the mixin patches the class
> and
> >>> so the "this.__createRequest()" call in the mixin is "undefined".
> >>>
> >>> The stop-gap solution is to turn off private method name-mangling in my
> >>> config.json like so :
> >>> "let" :{
> >>> ...
> >>> /* disable "privates" optimization in build version due to current
> >>> issues */
> >>> "OPTIMIZE" : ["variables", "basecalls", "strings"],
> >>> ...
> >>> }
> >>>
> >>> I think this is a bug in the "build" job because I would expect the
> >>> mixin to patch the class before name-mangling.
> >>>
> >>
> >> No, you just can't do that. Mixins have no more right to access private
> >> members than does anything else.
> >>
> >> In this case, though, could you not simply subclass qx.io.rest.Resource,
> >> override the invoke() method such that it calls the superclass method
> >> followed by doing your own stuff? You could then use your subclass
> instead
> >> of qx.io.rest.Resource.
> >>
> >> Derrell
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> RSA(R) Conference 2012
> >> Mar 27 - Feb 2
> >> Save $400 by Jan. 27
> >> Register now!
> >> http://p.sf.net/sfu/rsa-sfdev2dev2
> >> _______________________________________________
> >> qooxdoo-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> >>
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 2
> Date: Thu, 12 Jan 2012 19:23:56 +0100
> From: thron7 <[email protected]>
> Subject: Re: [qooxdoo-devel] Odd Mixins Behavior
> To: qooxdoo Development <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
>
> On 01/12/2012 07:01 PM, aditya siram wrote:
> > The problem with this subclassing approach is that, doing this the
> > right way, I would have to cut-and-paste the "__createRequest" and a
> > number of other private functions wholesale into the subclass. All I
> > really wanted to do was swap the order of two lines in the "invoke"
> > method.
> >
> > I agree that mixins shouldn't have access to private members when
> > "include"ed but when "patch"ing, which is a hacky last-resort anyway,
> > I should have complete access.
>
> The problem is that any form of mixin handling is done at runtime, while
> private optimization happens at compile time.
>
> You might want to open an enhancement request to turn these private
> methods in protected methods, so it would be easier to subclass and
> overwrite (You might still have to provide the entire _createRequest
> method, but would then be able to just use the other internal functions
> called from there).
>
> For the time being I think subclassing and "wholesale copying" would be
> the cleaner way, rather than patching privates through a mixin.
>
> T.
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 12 Jan 2012 09:33:51 -0500
> From: Gene Amtower <[email protected]>
> Subject: Re: [qooxdoo-devel] Introducing LIBERATED -- qooxdoo-based
> server with built-in server simulator for easy debugging
> To: qooxdoo Development <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Derrell,
>
> I downloaded and read your entire thesis yesterday - Great job!
>
> In addition to the awesome contribution that LIBERATED makes to the
> qooxdoo project, your thesis can be a very helpful learning guide on the
> way the qooxdoo RPC methods operate. I don't know if there's any issue
> with a link to it from within the qooxdoo wiki, but I believe it would
> be very beneficial. Also, some of the written info within the thesis
> regarding the basic RPC functionality could serve as additional
> documentation in the appropriate wiki pages.
>
> What issues or concerns might that raise, for either you or the
> university?
>
> This may be one of the most useful tools to come along for extending
> interest in qooxdoo for the reasons outlined in your thesis. At some
> point, I hope the mix-ins that you've created to support virtual
> databases in the browser will be rolled into the main qooxdoo libraries
> - I don't see a downside but would like insight into your view of
> that.
>
> In some application scenarios, a developer might want to pull data from
> a remote database and manage it within a browser-level database during
> the user session, then update the remote database from it later in the
> user session - think of it as a local working copy of a portion of the
> remote database. Have you considered this aspect of your enhancements?
>
> Now I'm anxious to find some time in my work schedule to experiment with
> LIBERATED. For existing qooxdoo developers who have an older qooxdoo
> version, what version is required for LIBERATED? Will we need to update
> our qooxdoo at the same time we download LIBERATED to insure they work
> together?
>
> Thanks much,
>
> Gene
>
> On Wed, 2012-01-11 at 09:27 -0500, Derrell Lipman wrote:
> > On Wed, Jan 11, 2012 at 09:11, panyasan <[email protected]> wrote:
> >
> > Hi Derrell,
> >
> > the project sounds fascinating. But I think people will need
> > more
> > documentation (How to install & use it) before this will take
> > off. I have
> > only superficially looked at the github repository, and didn't
> > find any. Did
> > I overlook anything?
> >
> >
> >
> > LIBERATED is simply a "library", in qooxdoo parlance. It is installed
> > like any contrib or other library by referencing its Manifest.js file
> > in the application's config.js "libraries" section.
> >
> >
> > As to using it, LIBERATED is described in excruciating detail in my
> > thesis, which you can find
> > at http://www.cs.uml.edu/~dlipman/thesis-liberated.pdf. Although that
> > document uses the current name of the library (LIBERATED), it predates
> > the renaming of the namespace, so anyplace you see 'rpcjs' in the
> > document is now called 'liberated'.
> >
> >
> > The API documentation should be quite complete, so running
> > "./generate.py api" from the top level will provide the normal API
> > viewer with a fair amount of useful information. In particular, for
> > database manipulation, see liberated.dbif.Entity.
> >
> >
> > The App Inventor Community Gallery code
> > at https://github.com/app-inventor-gallery/aig should also provide a
> > good basis for learning by example.
> >
> >
> > Some additional and better user-level documentation would definitely
> > be useful.
> >
> >
> > Derrell
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> > infrastructure or vast IT resources to deliver seamless, secure access to
> > virtual desktops. With this all-in-one solution, easily deploy virtual
> > desktops for less than the cost of PCs and save 60% on VDI infrastructure
> > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> > _______________________________________________ qooxdoo-devel mailing
> list [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: Thu, 12 Jan 2012 13:43:24 -0500
> From: Derrell Lipman <[email protected]>
> Subject: Re: [qooxdoo-devel] Odd Mixins Behavior
> To: qooxdoo Development <[email protected]>
> Message-ID:
> <canzyupn64t0gno4env1nwe5ngrktxy356qw8vkbqgo2bwq7...@mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Jan 12, 2012 at 13:23, thron7 <[email protected]>
> wrote:
>
> > The problem is that any form of mixin handling is done at runtime, while
> > private optimization happens at compile time.
> >
> > You might want to open an enhancement request to turn these private
> > methods in protected methods, so it would be easier to subclass and
> > overwrite (You might still have to provide the entire _createRequest
> > method, but would then be able to just use the other internal functions
> > called from there).
>
>
> I've had similar problems with mixins in the past. There are appropriate
> times to patch a function that uses privates, and the only way to
> accomplish that at present is to copy in large portions of the class being
> patched.
>
> One possible feature enhancement would be command line options to the
> generator, or a new type of entry in an application's config.json file,
> that specify specific privates in particular classes which should not be
> optimized. That doesn't sound like a trivial piece of work, but may be a
> good alternative.
>
> Derrell
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
>
> ------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
> End of qooxdoo-devel Digest, Vol 68, Issue 37
> *********************************************
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
