Ok, makes sense. So if you happen to use PopUp control, the draggable titlebar bead will be tied to it as a part of component code itself.
Module support will be interesting & probably a relatively more complex problem to solve & though I am quite new to closure, there seems to be quite a good amount of material on it, bringing in code for component just used in modules on need basis makes sense. I haven't delved too deep into the bead declaration in the CSS & just wonder how it works on JS, I guess that is one part of the framework I need to look at little bit deeper into. I guess I am good to complete drag feature on PopUp class. P.S.: A small problem I faced though mxmlc seems to assume that there will be a .js file for each closure class but that doesn't seems to be the case for goog.events.BrowserEvent.MouseButton, this causes a compilation error, had to make a very minor tweak on the dragger requires to make it work, this is a non sustainable change though that should be fixed on compiler, I will create a JIRA for this. Thanks, Pratyoosh -----Original Message----- From: Alex Harui [mailto:aha...@adobe.com] Sent: Tuesday, October 15, 2013 1:16 PM To: dev@flex.apache.org Subject: Re: [FlexJS] how much of Google closure goodies do we plan to use? Interesting. I was thinking that the opt-in for drag/drop code is in the definition of the component itself. Either you would take some base container and somehow add the dragging bead to it, or choose a base class that had it baked in, maybe a subclass of Panel called DraggablePanel. I didn't envision people wanting to choose at the point of creating the popup instance itself, but I could be wrong. Side note: a lot of these dragEnabled-like flags probably go away and are replaced by the adding of a bead somehow. Flags generally require that the dependencies for both code paths are baked in except in rare cases where you can defer the work. Either way, these code dependencies are in a class definition of either the popup or a bead the popup needs, and you are back to the classic and more generic problem of deferring loading of classes. We'll have some thing that works like Flex Modules where you can defer the loading of some code, and we will hopefully find a way to externally link beads that are not explicitly declared so they can come in via a module "just-in-time". In the prototype, most beads are "declared" in CSS so they aren't seen by the compiler as a dependency, and that gives us the option of linking them differently. BTW, I agree about conditional compilation. I don't want to make that a requirement in FlexJS. Thoughts? -Alex On 10/15/13 9:03 AM, "Sharma, Pratyoosh" <pratyoosh.sha...@jpmorgan.com> wrote: >Makes sense, however there are practical considerations. > >There are 2 ways in which people enable dragging on components: > >Style 1: >PopUp.createPopUp(PopUpComponent: PopupContent,parentComponent: >this,Title: "Component Popup Test", dragEnabled: true, >Modal:true);//default for dragEnabled can be true, this is the >traditional UI framework design & does offers convenience. > >However this would mean that PopUp component needs to have a >goog.require line for goog.fx.dragger & since the dependency tree has >to be calculated at the time of compilation, this class will be >included in this case if not instantiated. > >Style 2: > >var popup:PopUpComponent = PopUp.createPopUp(PopUpComponent: >PopupContent,parentComponent: this,Title: "Component Popup Test", >Modal:true) as PopUpComponent; >popup.addBead(new PopUpDragBead()); > >In Scenario 2, the inclusion of PopUpDragBead can be tracked by the >compiler for inclusions & compile time optimizations can be performed >for only including the drag & drop support only if "PopUpDragBead" is >referred. >This will grow tedious over time IMHO, runtime loading is not a good >idea for features like drag & drop. >Conditional compilation is another idea, but that would mean too many >switches on the compilation arguments, I particularly dislike it. > >With all of this being said I am not authority on either Closure >optimizations or code usability but are there other ways to optimize? > >Thanks, >Pratyoosh > >-----Original Message----- >From: Alex Harui [mailto:aha...@adobe.com] >Sent: Monday, October 14, 2013 5:58 PM >To: dev@flex.apache.org >Subject: Re: [FlexJS] how much of Google closure goodies do we plan to >use? > >Good question. In general, unless we suspect that there is a way to do >it with better performance or smaller footprint, we'd probably use a >Google Closure library implementation. > >The most important thing though, is to make sure that the inclusion in >FlexJS is pay-as-you-go so you only pick up the extra download if you >are actually using drag-drop. We may also investigate ways to bring in >the drag-drop code after startup. No need to initialize interaction >handling until there is something to handle. This is why I hope to see >code packaged in small plug-ins called "beads", so we can optimize >when/if that code gets loaded and run. > >-Alex > >On 10/14/13 1:09 PM, "Sharma, Pratyoosh" ><pratyoosh.sha...@jpmorgan.com> >wrote: > >>I was thinking on dragging implementation for popups & seems that >>libraries like closure abstracts a lot of it. >>Understanding that using these functions will start bringing in a lot >>of closure classes into the download of FlexJS framework, it seems >>like a lot of reinventing the wheel work to implement natively on >>FlexJS Thoughts.... >> >>Thanks, >>Pratyoosh >> >>This email is confidential and subject to important disclaimers and >>conditions including on offers for the purchase or sale of securities, >>accuracy and completeness of information, viruses, confidentiality, >>legal privilege, and legal entity disclaimers, available at >>http://www.jpmorgan.com/pages/disclosures/email. > > >This email is confidential and subject to important disclaimers and >conditions including on offers for the purchase or sale of securities, >accuracy and completeness of information, viruses, confidentiality, >legal privilege, and legal entity disclaimers, available at >http://www.jpmorgan.com/pages/disclosures/email. This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
