Hi Alex,
Forgot this for now, I must to rethink a bit. I'll be back when I have more
clear something. Thanks in advance.
Anyway, I think item renderers docs will be very helpful for me and others
Thanks!
El mar., 10 mar. 2020 a las 5:51, Alex Harui ()
escribió:
> FWIW, I built TDJ locally on
FWIW, I built TDJ locally on Feb 19 when I pushed the has branch. If I go to
the ComboBox there is a demo with sliders and the sliders work for me. Is that
ComboBox virtual or no?
-Alex
On 3/9/20, 4:54 PM, "Carlos Rovira" wrote:
Hi Alex,
in Jewel ComboBox something is not
Hi Alex,
in Jewel ComboBox something is not working as expected for ItemRenderers,
while in VirtualComboBox is working right. I mean rowCount/rowHeight.
If you check ComboBoxPlayGround in TDJ for an example where those
properties are set (the one with HSliders), you'll see those properties are
On 3/1/20, 11:54 PM, "Harbs" wrote:
Sure. I think separating Selection from the Renderer was the right thing to
do, but we also need to figure out how to make it do the “right thing” be
default.
I’m wondering if there should be a “selectionBead” property in every item
renderer
Sure. I think separating Selection from the Renderer was the right thing to do,
but we also need to figure out how to make it do the “right thing” be default.
I’m wondering if there should be a “selectionBead” property in every item
renderer which could be null.
Maybe DataContainerBase should
More loosely-coupled pieces often results in head-scratching. But it also
results in PAYG and flexibility.
Our job is to find the common patterns, and pre-compose as needed, such as the
Express component set. This "has" pattern is a new pattern so we'll have to
figure out new best practices.
Yes. If I replace the default SelectableItemRendererClassFactory
My work-around was to use:
js|List{
IItemRendererClassFactory:
ClassReference("org.apache.royale.core.OverridableSelectableItemRendererClassFactory");
}
The average user will be scratching their heads on how to solve this
On 3/1/20, 12:33 AM, "Harbs" wrote:
I’ve also discovered that setting the selection bead is more difficult than
I would hope it to be.
For example there should be an easy way to specify the selection bead in a
situation like this:
I may not be understanding the problem. The
I’ve also discovered that setting the selection bead is more difficult than I
would hope it to be.
For example there should be an easy way to specify the selection bead in a
situation like this:
>
I've tried two different patterns:
1) ItemRendererOwnerVIew via "has": See
Core/src/main/royale/org/apache/royale/core/ItemRendererOwnerViewBead.as. Then
the ItemRendererClassFactory or the initializer can set it
2) Baking it in where needed and implementing IItemRendererOwnerView and
What’s the recommended pattern for getting the “data host” from an itemRenderer
now that itemRendererParent/itemRendererOwnerView is no longer a “thing”?
I have the following code in an itemRenderer which inherits from
DataItemRenderer:
(itemRendererParent.host.parent as
It seemed like a separate concern. Right now there are two highly used
ItemRendererClassFactory, but several Initializers.
-Alex
On 2/24/20, 3:06 AM, "Harbs" wrote:
Why is IItemRendererInitializer separate from IItemRendererClassFactory?
> On Feb 21, 2020, at 12:03 AM, Alex
Why is IItemRendererInitializer separate from IItemRendererClassFactory?
> On Feb 21, 2020, at 12:03 AM, Alex Harui wrote:
>
> I pushed changes that I think has everything working in Jewel by using the
> same "has" pattern that is used in other component sets.
>
> The Lists in the ToDo
Hi,
I tried to remove (commit d8ae342bb12e1006caed480dba7e3d91bab589da) and
seems all ok since is managed in the beads.
If is wrong feel free to revert
thanks
El vie., 21 feb. 2020 a las 12:11, Carlos Rovira ()
escribió:
> Hi Alex,
> thanks for the changes all have more sense that way now.
> One
Hi Alex,
thanks for the changes all have more sense that way now.
One question about Jewel ListItemRenderer.as
in line 56
addClass("selectable");
that should remain?
I guess it must be removed (like in "NavigationLinkItemRenderer" and "
TabBarButtonItemRenderer"
right?
El jue., 20 feb. 2020 a las
I pushed changes that I think has everything working in Jewel by using the same
"has" pattern that is used in other component sets.
The Lists in the ToDo examples use a regular ItemRendererClassFactory instead
of SelectableItemRendererClassFactory that is now used in most other places
yes, Jewel has the "structure" and is organized in SASS files, then
JewelTheme has the "styling" part and is as well SASS.
so Jewel should not need to change, and people should only need to change
JewelTheme or create a new theme one using it as a template.
I'll add examples to ant tomorrow
On 2/20/20, 11:04 AM, "Carlos Rovira" wrote:
forgot to say. Can you add missing examples to ANT? don't know where to do
that
and checking Jewel don't see the use of SelectableItemRendererClassFactory.
all times ItemRendererClassFactory is used
I could fix the Ant side,
forgot to say. Can you add missing examples to ANT? don't know where to do
that
and checking Jewel don't see the use of SelectableItemRendererClassFactory.
all times ItemRendererClassFactory is used
El jue., 20 feb. 2020 a las 20:00, Carlos Rovira ()
escribió:
> Hi Alex,
>
> remember that Jewel
I replied on this topic on your commit email.
So I don't have to copy that into this thread, read what I said in that email
and reply on that thread and let's figure out the right thing to do. I am
having some weird problem with my Maven build where every time I try to change
Jewel's
Hi Alex,
I found that TodoMVC examples was not working, so I fixed it removing the
non existing properties (hoverable and selectable).
But I found Jewel ListItemRenderer has all baked, so I created a
SimpleListItemRenderer (in Jewel Simple in the normal prefix for a "base",
"basic" or "simple"
I'm not sure I understand what you mean by "control".
Before the "has" changes, every ItemRenderer contained or inherited code that
had hovered/selected APIs that drew visuals, and the ItemRenderer also "had" a
bead like ItemRendererMouseController that set the hovered property on that
item
Hi Alex,
Could you provide an example how would I control hovering/selecting in item
renderer when I don't have build in hover property etc. ? How should I
compose such item renderer ?
Thanks,
Piotr
czw., 20 lut 2020 o 03:20 Alex Harui napisał(a):
> I pushed the "has" changes. TourDeJewel
I pushed the "has" changes. TourDeJewel seems to be working correctly for me.
The principle of "has" is similar to inheritance vs composition. Just like
top-level components like List are composed of many beads, the item renderers
are now composed of more beads as well. That reduces the
Hi Alex,
if will be of help if you point us to different links where we can learn
about this modifications, since I at least can just imagine what is all
about, but will need to get deeper in the concepts to understand the
changes and to apply this patterns.
In Jewel each "list component has its
I've pushed the "has" branch that contains a refactoring of the item renderers.
Tour De Jewel and MDL Example seem to be working as is Basic List Example and
MX AdvancedDataGrid.
"has" is really just calls to getBeadByType. If we start to see performance
issues, then we'll look into
Hi Alex,
I'm happy with Item renderers, maybe we can do some refactors, but if it
was my time, I'll try to prioritize the actual few problems we have that
can be cumbersome for users and that use to make us code things that should
not be that way. I think as long as we have some problems that
Hi,
I had a window of time to try to do the "has" vs "is" refactor for
ItemRenderers.
However, I didn't get very far because as I started looking through the
ItemRenderer code, I realized that there are other things that could use a
refactor as well. IMO, there is too much just-in-case code
4110fd011b617949c1faae5f158/frameworks/projects/MXRoyale/src/main/royale/mx/charts/renderers/CircleItemRenderer.as#L141
>
> From: Carlos Rovira<mailto:carlosrov...@apache.org>
> Sent: Thursday, January 16, 2020 11:50 AM
> To: dev@royale.apache.org<mailto:dev@royale.apache.or
/main/royale/mx/charts/renderers/CircleItemRenderer.as#L141
From: Carlos Rovira<mailto:carlosrov...@apache.org>
Sent: Thursday, January 16, 2020 11:50 AM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: "has" vs "is": sharing code, swapping
Currently "has" is getBeadByType(ISomeInterface). I personally don't want to
spend the energy adding a new keyword to the language. Also, this kind of
"has" is not the same as "hasOwnProperty". This is more about composition, not
what properties exist.
My first proposal for optimization is
I like the idea of a “has”. What would the syntax be and how would it work?
I’d love to be able to write if(foo has Baz) (and that would be compiled to
something like if(Language.has(foo,Baz))
I’d also guess that it would loop through the list of beads and test “is” on
all of them. For
Hi,
recently I want to do a "has" instead of "is", but I couldn't.
I'm not talking about at "bead" level, just something like we use to do in
Flash (hasOwnProperty)
Taking the code in [1]. I'd like to change this
if(!(_strand is IDataGridColumnList))
for something like this
You are welcome to try and see how many cache hits it gets. I think in
renderers, we ask once per renderer. I'm not sure there is a faster way to do
the first lookup of "is", but for "has" we could change the lookup and save
time.
On 1/15/20, 10:38 PM, "Greg Dove" wrote:
For the
For the 'something is ISomeInterface'
I had wondered in the past if these types of lookups could be incrementally
cached on the 'is' target (after first lookup), that might make sense for
interfaces, which are the deepest checks I think?
caching result (could optionally create the Map)
Hi,
Several different threads have brought up issues with sharing code between
component sets. Other threads have offered different and clever ways to do
various things like how MXML is applied to a component. Meanwhile, over in MX
emulation, I was starting to copy some code from Basic to
36 matches
Mail list logo
