On 2/20/20, 11:04 AM, "Carlos Rovira" <[email protected]> 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, but I don't have time. It think all you need to do
is add it to the examples/build.xml
I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't sure
if the selection was supposed to be changeable at runtime. I think you've
confirmed that it isn't so we can change to use
SelectableItemRendererClassFactory
I knew the themes were generated by SASS, but I didn't realize the Jewel one
was as well.
-Alex
El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<[email protected]>)
escribió:
> Hi Alex,
>
> remember that Jewel uses SASS to create the CSS. I already pushed a commit
> with ["warning"]. It's not the first time I warn about it ;)
> You must to change SASS file. The css is just generated (like other
> generations in compiler), and is committed since no body added SASS to
ANT.
> Maven has a sass plugin to compile SASS.
>
> I saw you response and commented there
>
> Thanks
>
> Carlos
>
>
> El jue., 20 feb. 2020 a las 19:55, Alex Harui (<[email protected]>)
> escribió:
>
>> 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 defaults.css something overwrites it. I'm trying to
>> figure out what is going on there.
>>
>> -Alex
>>
>> On 2/20/20, 10:47 AM, "Carlos Rovira" <[email protected]> wrote:
>>
>> 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" option) that hast the minimum required.
>>
>> So at least in Jewel if people wants hoverable and selectable
>> renderers use
>> the normal ListItemRenderer.
>> If don't want that indicators, use SimpleListItemRenderer. If you
>> want just
>> show hover, but not selected state, then extend Simple version and
>> add "
>> ClassSelectorListRuntimeSelectableItemRendererBead" and configure to
>> have
>> just "hoverable" to true ¿ok?
>>
>> Hope I understand ok how it works. Let me know if something is not as
>> expected.
>>
>> Thanks
>>
>> Carlos
>>
>>
>>
>> El jue., 20 feb. 2020 a las 18:06, Alex Harui
>> (<[email protected]>)
>> escribió:
>>
>> > 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 renderer, and the List's controller would set the
>> selected
>> > property.
>> >
>> > Now, every ItemRenderer "has" a bead that has the hovered/selected
>> > properties, and the ItemRendererMouseController and the Lists's
>> controllers
>> > get that bead instead of talking to the ItemRenderer directly. I
>> guess
>> > that's the new way of thinking for has/composition vs
>> is/inheritance: a
>> > component doesn't have to have all of its APIs glued to its API
>> surface.
>> > We mainly do that for convenience in MXML, but for more internal
>> stuff like
>> > this, loose-coupling via has/composition shared more code and
>> increases
>> > configurability, but does add some runtime overhead in its raw
form.
>> > Hopefully we can optimize that away.
>> >
>> > HTH,
>> > -Alex
>> >
>> > On 2/20/20, 5:01 AM, "Piotr Zarzycki" <[email protected]>
>> wrote:
>> >
>> > 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 <[email protected]>
>> > napisał(a):
>> >
>> > > 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
>> > > requirement to add code to a class in order to "be/is"
>> something.
>> > >
>> > > There used to be copies of code that drew hover and selected
>> states
>> > on
>> > > the item renderers in each new kind of item renderer that
>> couldn't
>> > inherit
>> > > from an item renderer that could draw selected and hovered
>> states.
>> > Now,
>> > > the itemrenderers compose their selection visuals. A single
>> item
>> > renderer
>> > > like StringItemRenderer can be composed with no selection
>> drawing at
>> > all,
>> > > or with solid color selection drawing or with alternate color
>> > selection
>> > > drawing or something new. And that means that some new
>> kind of
>> > item
>> > > renderer, like a TextInput can become an item renderer more
>> easily,
>> > by
>> > > composing a selection visuals bead instead of having to add
>> all of
>> > that
>> > > code.
>> > >
>> > > Another place I started using "has" but didn't fully replace
>> the old
>> > code
>> > > was in handling itemRendererParent, which is now called
>> > > itemRendererOwnerView (to try to make it more clear that
isn't
>> > always the
>> > > parent of the item renderer and is sometimes an internal
>> > > datagroup/container). Turns out a lot of our renderers
>> didn't need
>> > to know
>> > > the itemRendererParent, so in many cases we no longer figure
>> it out
>> > and
>> > > assign it. But in cases where it is needed, the property is
>> > currently left
>> > > baked into the renderer, but in some new cases, it is
>> composed. An
>> > > ItemRendererOwnerViewBead is added to the strand instead of
>> added to
>> > a
>> > > class and contains the reference to the ownerView. Maybe
>> someday
>> > we'll
>> > > fully remove the old pattern, not sure.
>> > >
>> > > Ideally we would do more "has" than "is". It could allow us
>> to
>> > eliminate
>> > > much of the required code to be a top tag in an MXML
document.
>> > >
>> > > Other changes in this branch were to add "Initializers" so
the
>> > > RendererFactories didn't bake in code for specific item
>> renderers,
>> > and to
>> > > create a few base classes with overrides so there is less
>> code to
>> > maintain.
>> > >
>> > > There should be little if any impact to application code. It
>> should
>> > > mainly affect the internals of how item renderer-based things
>> are
>> > created.
>> > >
>> > > Thanks,
>> > > -Alex
>> > >
>> > > On 2/17/20, 4:33 PM, "Carlos Rovira" <[email protected]
>> >
>> > wrote:
>> > >
>> > > 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 own type of
>> renderer, so
>> > for
>> > > example
>> > > List uses ListItemRenderer and DataGrid has
>> > DataGridItemRenderer, since
>> > > usually at that component level the user needs similar
>> > infrastructure
>> > > like
>> > > hoverable, selectable...and some (not much) more, don't
>> know
>> > right now
>> > > how
>> > > all this will fit with the "has" new pattern....I'll try
>> it.
>> > >
>> > > Just one important thing. There's actual users and
>> clients using
>> > Jewel
>> > > and
>> > > other UI sets and are with very short times for their
>> > migrations, so
>> > > just
>> > > want to ask you to test as much as possible, since TDJ
>> has many
>> > > examples
>> > > now. Other thing you can test is new TodoMVC to see how
it
>> > behaves,
>> > > since
>> > > it uses a List with IRs. So we can ensure (as much as we
>> can)
>> > the merge
>> > > left things working (as much as we can)
>> > >
>> > > Thanks for working on this, will try all of this tomorrow
>> > >
>> > > Carlos
>> > >
>> > >
>> > >
>> > >
>> > > El lun., 17 feb. 2020 a las 22:35, Alex Harui
>> > > (<[email protected]>)
>> > > escribió:
>> > >
>> > > > 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 optimizing.
>> The
>> > motivation
>> > > to
>> > > > switch to "has" came from several bugs about using MX
>> > Label/CheckBox
>> > > as
>> > > > item renderers. In Royale, the ItemRenderers were in
>> control
>> > of the
>> > > > visuals of their rollover and selected state. That is
>> a more
>> > proper
>> > > > encapsulation than the way it was in Flex where the
>> lists drew
>> > the
>> > > rollover
>> > > > and selected states and it was hard to override the
>> visuals
>> > for a
>> > > custom
>> > > > item renderer. But in the develop branch Royale code,
>> it would
>> > > require
>> > > > that custom itemrenderers implement a lot of APIs
>> related to
>> > > rollover and
>> > > > selected visuals. Instead we can now reuse/share code
>> for
>> > visuals
>> > > between
>> > > > different renderers because a renderer now can "has" a
>> > > rollover/selection
>> > > > implementation instead of being one.
>> > > >
>> > > > There are more pieces involved, but there is more
>> sharing of
>> > code.
>> > > Along
>> > > > the way I found that there were some not-so-PAYG
>> patterns
>> > being used
>> > > in MDL
>> > > > and Jewel renderers that might deserve further
>> modification.
>> > There
>> > > are
>> > > > "hoverable" and "selectable" APIs that appear to be
>> used to
>> > > permanently
>> > > > turn off selection and hover visuals. In general, I
>> think
>> > there is
>> > > better
>> > > > use of PAYG and composition when functionality is
>> "built up"
>> > and not
>> > > > "turned off", so with the "has" pattern the renderers
>> can be
>> > added
>> > > to a
>> > > > list without any selection visuals at all (for a
>> non-selectable
>> > > list) or
>> > > > re-composed with custom visuals that only support
>> hoverable,
>> > for
>> > > example.
>> > > > I left it "hoverable/selectable" in the API surface for
>> now,
>> > but
>> > > something
>> > > > to think about going forward.
>> > > >
>> > > > I’m going to run a few more tests before merging and
>> pushing to
>> > > develop.
>> > > >
>> > > > -Alex
>> > > >
>> > > > On 1/15/20, 10:44 PM, "Alex Harui"
>> <[email protected]>
>> > wrote:
>> > > >
>> > > > 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" <
>> [email protected]>
>> > wrote:
>> > > >
>> > > > 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)
>> > > >
>> ISomeInterface['implMap'].set(something.constructor,
>> > > isResult )
>> > > >
>> > > > then earlier in the interface checks, it could
>> do
>> > something
>> > > like:
>> > > > if (ISomeInterface['implMap'] &&
>> > > >
>> ISomeInterface['implMap'].has(something.constructor) )
>> > return
>> > > >
>> ISomeInterface['implMap'].get(something.constructor)
>> > > >
>> > > > I realize its extra code, but it should be
>> quite a bit
>> > > faster over
>> > > > time I
>> > > > think.
>> > > >
>> > > > On Thu, Jan 16, 2020 at 7:20 PM Alex Harui
>> > > > <[email protected]> wrote:
>> > > >
>> > > > > 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
>> > > > MXRoyale to
>> > > > > get the various MX components to be valid
item
>> > renderers.
>> > > > MXRoyale is
>> > > > > using Basic's item renderer architecture
>> which is
>> > better
>> > > > encapsulated: the
>> > > > > renderer draws its hovered and selected
>> state. In
>> > Flex,
>> > > the
>> > > > List draws
>> > > > > over the renderer, which makes it hard to
>> customize
>> > the
>> > > way the
>> > > > renderer
>> > > > > will look when hovered and selected.
>> > > > >
>> > > > > It finally occurred to me that one of the
>> reasons we
>> > end up
>> > > > copying code
>> > > > > is because we are still using too many "is"
>> checks
>> > instead
>> > > of
>> > > > "has"
>> > > > > checks. I'm not even sure we have any "has"
>> checks
>> > in the
>> > > Royale
>> > > > > framework. I was afraid of the overhead of a
>> "has"
>> > check,
>> > > but
>> > > > I'm starting
>> > > > > to change my mind because:
>> > > > >
>> > > > > 1) The "is" check actually runs a fair amount
>> of
>> > code,
>> > > > especially for
>> > > > > (comp is ISomeInterface)
>> > > > > 2) The length of bead arrays don't seem too
>> long.
>> > > > >
>> > > > > A "has" check calls
>> getBeadByType(ISomeInterface),
>> > so it
>> > > > actually will run
>> > > > > the (bead is ISomeInterface) on potentially
>> the
>> > entire
>> > > strand
>> > > > array/vector,
>> > > > > although we could speed that up by annotating
>> beads
>> > or
>> > > keeping
>> > > > track of
>> > > > > what is on the strand. But the code
>> sharing/reuse
>> > > potential of
>> > > > this
>> > > > > pattern seems significant to me.
>> > > > >
>> > > > > For example, it could change how hard it is
>> to make a
>> > > component
>> > > > usable as
>> > > > > a top tag in MXML. Instead of the component
>> having
>> > to
>> > > implement
>> > > > certain
>> > > > > methods, the component could have a bead
>> installed
>> > and the
>> > > > > MXMLDataInterpreter could talk to that bead
>> instead
>> > of the
>> > > > component.
>> > > > >
>> > > > > In the case of the item renderers, instead of
>> > testing if
>> > > the
>> > > > renderer "is"
>> > > > > ISelectableLIstItemRenderer, it could ask if
>> the
>> > created
>> > > widget
>> > > > "has" an
>> > > > > ISelectableLIstItemRenderer bead and the
>> logic in
>> > that
>> > > bead can
>> > > > be reused
>> > > > > in both Basic and MXRoyale without being
>> copied.
>> > > > >
>> > > > > Some code, like Container overrides of
>> addElement
>> > probably
>> > > can't
>> > > > be
>> > > > > refactored into a "has". But I wonder how
>> many other
>> > > things
>> > > > could. I'm
>> > > > > not sure I would move everything that could
>> be moved
>> > into a
>> > > > shared bead.
>> > > > > We'd have to think about the overhead on
small
>> > components
>> > > and
>> > > > apps. But
>> > > > > for MXML support and Item Renderer support,
>> it seems
>> > to
>> > > make
>> > > > sense.
>> > > > >
>> > > > > Anyway, I will look into refactoring the item
>> > renderer
>> > > code in
>> > > > a few days
>> > > > > unless feedback indicates otherwise. Bugs
>> like #676
>> > and
>> > > #681
>> > > > inspired this
>> > > > > post.
>> > > > >
>> > > > > Of course, I could be wrong...
>> > > > > -Alex
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > > --
>> > > Carlos Rovira
>> > >
>> > >
>> >
>>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0
>> > >
>> > >
>> > >
>> >
>> > --
>> >
>> > Piotr Zarzycki
>> >
>> > Patreon: *
>> >
>>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=GiQ6hMBA27oNI4zjcqNpgMTTIKCuiitizY8QwIQ48JI%3D&reserved=0
>> > <
>> >
>>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=GiQ6hMBA27oNI4zjcqNpgMTTIKCuiitizY8QwIQ48JI%3D&reserved=0
>> > >*
>> >
>> >
>> >
>>
>> --
>> Carlos Rovira
>>
>>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0
