Re: [Royale] DynamicItemsRendererFactoryForArrayListData

Cool! Look forward to your commit! :) Thanks, Piotr 2017-12-07 22:19 GMT+01:00 Peter Ent : > It looks like, after discussing this with Alex, we will use > DynamicItemsRendererFactoryForArrayListData to refresh and insert items > and if you want to remove items, add in

Re: [Royale] DynamicItemsRendererFactoryForArrayListData

It looks like, after discussing this with Alex, we will use DynamicItemsRendererFactoryForArrayListData to refresh and insert items and if you want to remove items, add in the RemoveItemRendererBead. I'll probably think of a better name for that one. ‹peter On 12/7/17, 4:03 PM, "Piotr Zarzycki"

Re: [Royale] DynamicItemsRendererFactoryForArrayListData

My thoughts about DynamicItemsRendererFactoryForArrayListData was initially that this bead allows for Adding and Removing items from List. I just didn't have chance to finish it. As I said you can even remove it and use your own. In whatever direction you will go I just need solution which allows

Re: MXML attributes, minification, and initialization

Hi Yishay, I think you may need to specify the type of myComp. I'm not sure the closure compiler is going to inference it. /** @type components.MyComp */ var myComp = new components.MyComp(); HTH, -Alex On 12/7/17, 1:55 AM, "Yishay Weiss" wrote: >It looks like

Re: [Royale] DynamicItemsRendererFactoryForArrayListData

Hi Peter, If your new Beads, will be doing also adding, you can even replace my DynamicItemsRendererFactoryForArrayListData. I'm ok in whatever direction you will go. There is an example which is using that bead [1] [1]

[Royale] DynamicItemsRendererFactoryForArrayListData

I'm trying to see if my new RemoveItemRendererBead works with DynamicItemsRendererFactoryForArrayListData and discovered that this class is listening to the model for the ITEM_ADDED event. The model doesn't dispatch the event - the dataProvider (ArrayList) dispatches the event. The model

Re: Thoughts on ToggleButton

We can certainly create a really sophisticated bead system and ensure the topology of every component is consistent, but I think that will defeat the goal of having really small and fast components. IMO, it is more important that the resulting apps are small and fast than sophisticated,

Re: Names and Packages (was Re: MXMLDataInterpreter)

I first want to acknowledge Piotr's concern about shuffling things around, but on the other hand, if we think we have a lot of beads now, I hope after several years we have 10x or 100x as many, so having good organization will help people find things. I think we also need to consider that some

Re: Names and Packages (was Re: MXMLDataInterpreter)

Behavior would be something like: Password bead, SingleSelecttion, Disabled, etc. Appearance would be things like: DataGridLines, DisabledAlpha, Border, Background, etc. > On Dec 7, 2017, at 7:16 PM, Alex Harui wrote: > > What's a "behavior" and "appearance"? > >

Re: Names and Packages (was Re: MXMLDataInterpreter)

What's a "behavior" and "appearance"? -Alex On 12/7/17, 1:39 AM, "Harbs" wrote: >Related thoughts about names and packages: >1. I think the bead classes should be organized better. There’s currently >controllers, layouts and models packages. There should be views,

Re: Names and Packages (was Re: MXMLDataInterpreter)

Hi Harbs, Peter, I agree with point 1, 2 and 3, but I would leave as is all components which we have currently in basic in place. Another change of API and restructuring ? Let's make current components better and give users feeling of stability with another moving from one place to another we

Re: Names and Packages (was Re: MXMLDataInterpreter)

I also wonder if List, DataGrid, Tree shouldn't be moved out of "basic" and into "advanced" - they along with their supporting beads. From the work I've been doing with handling "itemAdded" event vs "dataProviderChanged", it might be easier for customers who want the expense of a DataGrid to just

Re: Thoughts on ToggleButton

Basically, every bead would have a list of “interests”. Rather than add event listeners, beads would list their interests. It should be much lighter-weight and enable looser coupling. I might pick up where I left off on that, although it’s going to be difficult to pull my changes after the

Re: Thoughts on ToggleButton

I’ve felt that way on occasion too. What we did was create view beads for SWF and not JS in some cases because the createElement function was enough. Not sure what to do in these cases. Peter > On Dec 7, 2017, at 5:52 AM, Piotr Zarzycki wrote: > > Hi Harbs, > >

Re: Thoughts on ToggleButton

Harbs, Can you please recall how would it help to resolve the situation when we need for example those two models TextModel and ImageModel - assuming that they were splitted ? Thanks, Piotr 2017-12-07 12:26 GMT+01:00 Harbs : > Related: > > Currently the architecture

Re: Thoughts on ToggleButton

Related: Currently the architecture assumes that there’s a single view, model, or controller. Many of these could (and maybe should) be broken into smaller logic pieces. For example, there’s TextAndImageButton which has a TextAndImageModel, when all it really needs is a TextModel and an

Re: Thoughts on ToggleButton

Hi Harbs, I would also place the logic which changes the image into the View bead. If I correct understand your thoughts. I think if it is possible it would be great reuse ImageButton in somehow, cause actually it is doing for one state what you want. It is the matter of handling states in the

Thoughts on ToggleButton

I need a toggle button which displays images (i.e. ImageToggleButton). Right now, the way ImageButton works is that the main component modifies the element to show an image. This works only if you want a single image no matter what the state of the button is. If you want different images on

RE: MXML attributes, minification, and initialization

It looks like exported properties are not renamed when they’re not initialized, but are renamed when they are. I think I’ve demonstrated [1] that this results in bugs in the closure compiler. I suggest to see if the closure guys want to fix this or can suggest a workaround. [1]

Names and Packages (was Re: MXMLDataInterpreter)

Related thoughts about names and packages: 1. I think the bead classes should be organized better. There’s currently controllers, layouts and models packages. There should be views, behaviors, appearances, etc. 2. I’m not sure that the “html” package in Basic is the right name. “basic” seems

Re: MXMLDataInterpreter

I was thinking a bit about naming. A few points to ponder: 1. If anything it should mention Group rather than Container, because anything subclassing GroupBase should work. 2. Maybe mentioning the “holder” type is just confusing. Maybe SingleSelectionBead? 3. This got me thinking about bead