Yes that's fair enough :-)

We have one outstanding question with this, about how the Royale compiler 
generates the "bindings" array. In order to get this to work with a renderer 
defined as inline MXML (rather than as a separate MXML document), we are 
creating a class that implements the IMXMLDocument interface, which is great as 
then we have the MXML array that defines this structure and we can create 
multiple renderers based on this array: this part is all working fine now, so 
we have our custom renderer...

There's one interesting issue where there's an 'id' field defined within the 
inline MXML, but I'm not sure whether it needs to be. The browser seems to cope 
okay with two elements having the same ID! but perhaps we should just have a 
usage rule where you can't include IDs within the MXML structure (or we change 
the ID to include an index, etc..)

The outstanding problem is that the child elements aren't being filled in from 
the data..  the data object has been set on the new renderer object, but this 
isn't resulting in the child elements updating their content. The bindings 
within our inline MXML structure are actually being included within the 
main/enclosing document's binding array, which is a pain because the 'data' 
object is a member of the renderer rather than of the enclosing document.

So would anyone know if there is a way we can get the compiler to generate a " 
_bindings" array that's part of a child element's MXML definition rather than 
within the main class's properties? or is that not possible, and either we have 
to try to hack a little, or we just go with the MXML renderer being always 
defined in a separate class document?

thanks

   Andrew


-----Original Message-----
From: Alex Harui <[email protected]> 
Sent: 23 July 2019 07:43
To: [email protected]
Subject: [EXTERNAL] Re: ComboBox list-item renderer

A reminder that Royale emphasizes PAYG and has to live with DAYG (do as you 
go).  For PAYG reasons, the simplest ComboBox probably shouldn't have to 
support custom itemRenderers.  Some subclass is more than welcome to.  And I 
don't think anyone has done it yet so volunteers are welcome.

HTH,
-Alex

On 7/22/19, 11:12 AM, "Frost, Andrew" <[email protected]> wrote:

    Thanks - yes we can try that, the issue being that we don't want all combo 
box lists to appear the same way hence trying to have something embedded into 
each bit of mxml...  
    
    
    
    We'll take a proper look and see what we can get :-)
    
    cheers
    
    
    -----Original Message-----
    From: Yishay Weiss <[email protected]> 
    Sent: 22 July 2019 18:17
    To: [email protected]
    Subject: [EXTERNAL] RE: ComboBox list-item renderer
    
    Note that the overridden css is of ComboBoxList, which is by default the 
list created in runtime, not ComboBox, which is the button that creates the 
list.
    
    
    
    ________________________________
    From: Yishay Weiss <[email protected]>
    Sent: Monday, July 22, 2019 8:13:31 PM
    To: [email protected] <[email protected]>
    Subject: RE: ComboBox list-item renderer
    
    Actually, have you tried something like this in your css?
    
    ComboBoxList
    {
       IItemRenderer: ClassReference("com.ccc.myRenderer");
    }
    From: Yishay Weiss<mailto:[email protected]>
    Sent: Monday, July 22, 2019 8:08 PM
    Subject: RE: ComboBox list-item renderer
    
    Oh, it looks like you're one step ahead of me. Didn't read your mail 
carefully enough. I think you can safely open a bug, or try to write the bead 
yourself.
    
    From: Frost, Andrew<mailto:[email protected]>
    Sent: Monday, July 22, 2019 7:53 PM
    To: [email protected]<mailto:[email protected]>
    Subject: RE: ComboBox list-item renderer
    
    Thanks - yes, happy to adjust our code to that sort of format, but we 
continue to hit the issue that this is a renderer for a list, being set on the 
list, and we want to have a renderer for the list that's being created at 
runtime from the combo box.
    
    It might be that we can set the itemRenderer property of the list object as 
it's created by the combo box's view object, but this feels a little hacky and 
it would be nicer if we could accomplish this just via MXML or CSS..
    
    cheers
    
    
    -----Original Message-----
    From: Yishay Weiss <[email protected]>
    Sent: 22 July 2019 17:43
    To: [email protected]
    Subject: [EXTERNAL] RE: ComboBox list-item renderer
    
    Another option is to specify the renderer class as an mxml att [1]. 
ItemRenderers are not beads, so adding them to the beads list has no effect (it 
should actually cause an RTE).
    
    
    
    [1] 
https://clicktime.symantec.com/312V9KgaR3PyjyMCjLC5wZt7Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fapache%252Froyale-asjs%252Fblob%252Ff637c857122d56f838bab21314a11900ed0add8e%252Fexamples%252Froyale%252FTodoListSampleApp%252Fsrc%252Fmain%252Froyale%252Fsample%252Ftodo%252Fviews%252FTodoListView.mxml%2523L169%26data%3D02%257C01%257Caharui%2540adobe.com%257Cd3872c0a305540bd0c8d08d70ed0241a%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636994159504560528%26sdata%3DzMXZrtGppirdF8kCbxK3nO4VjQaAULy2bK2SdcXn%252FvI%253D%26reserved%3D0
    
    
    
    ________________________________
    From: Carlos Rovira <[email protected]>
    Sent: Monday, July 22, 2019 6:32:27 PM
    To: [email protected] <[email protected]>
    Subject: Re: ComboBox list-item renderer
    
    Hi Andrew,
    
    for this one in Royale it use to be done in CSS. For example in tour de 
jewel for List we do:
    
    Source code in GitHub
    
<https://clicktime.symantec.com/3V1EzyYJGWFnH4yatcrNfXf7Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fapache%252Froyale-asjs%252Fblob%252Fdevelop%252Fexamples%252Froyale%252FTourDeJewel%252Fsrc%252Fmain%252Froyale%252FListPlayGround.mxml%26data%3D02%257C01%257Caharui%2540adobe.com%257Cd3872c0a305540bd0c8d08d70ed0241a%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636994159504560528%26sdata%3DtrSVUXGoZpSb2duv9nvXZSk9kW69g%252BaEv%252Bq6spx9d6E%253D%26reserved%3D0>
    
    <j:List id="iconList" width="200" height="300" className="
    iconListItemRenderer" labelField="label">
    
    and in iconListItemRenderer you can find
    
    .iconListItemRenderer
    {
    IItemRenderer: ClassReference("itemRenderers.IconListItemRenderer");
    }
    
    but as well we should can do as inline in MXML, so if that does not work 
it's a bug to solve I think...
    
    HTH
    
    Carlos
    
    
    El lun., 22 jul. 2019 a las 17:14, Frost, Andrew (<[email protected]>)
    escribió:
    
    > Hi again
    >
    > Just in case someone's already done this and knows already how to set 
    > it
    > up: we want to have an itemRenderer for the ListView part of a 
    > ComboBox control, i.e. when you click on the ComboBox button and it 
    > creates the ListView, we need a custom renderer. Currently it's 
    > defaulting to StringItemRenderer (from the call [1] within the default 
    > ItemRendererClassFactory), but we want it instead to use the inline 
    > MXML [2].
    >
    > I'm hoping that we can set this up by adding a bead of some sort to 
    > the ComboBox element that will tell it what item renderer to use; all 
    > the item renderer examples I can find are just using a list view 
    > directly rather than being something that's set up via a ComboBox. So 
    > far we've created a custom View for the ComboBox and we are 
    > controlling the creation of the ListView, but this creation doesn't 
    > then set up any of the MXMLDescriptor values which are needed for this to 
work...
    >
    > Hope that makes sense. Don't worry if not, we'll get to the bottom of 
    > it, but I wondered if someone already had done this and knew how to do 
    > it :-)
    >
    > thanks
    >
    >    Andrew
    >
    >
    >
    > [1] Current way ItemRenderClassFactory selects the item renderer:
    > if (_strand is IItemRendererProvider && (_strand as
    > IItemRendererProvider).itemRenderer) { ... } else {
    >     var itemRendererClass:Class =
    > ValuesManager.valuesImpl.getValue(_strand, "iItemRenderer") as Class; 
    > <<<<< we're getting StringItemRenderer here
    >     if (itemRendererClass) { ... }
    >     else if (!MXMLDescriptor) { ... }
    >     <<< we want it to hit this point i.e. not get set up because it 
    > falls through and then uses the MXMLDescriptor value
    >
    > [2] Our code:
    >   <mx:ComboBox width="100" dataProvider="{val}" labelField="subval1">
    >     <mx:itemRenderer>
    >       <js:ItemRendererClassFactory>  <<<< was "fx:Component"
    >         <mx:HBox width="100%" horizontalScrollPolicy="off"> ... layout 
    > in here ...  </mx:HBox>
    >       </js:ItemRendererClassFactory>
    >     </mx:itemRenderer>
    >   </mx:ComboBox>
    >
    >
    >
    >
    >
    
    --
    Carlos Rovira
    
https://clicktime.symantec.com/37uaR5VN2pNCL4WWL9cvXPQ7Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fabout.me%252Fcarlosrovira%26data%3D02%257C01%257Caharui%2540adobe.com%257Cd3872c0a305540bd0c8d08d70ed0241a%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636994159504560528%26sdata%3DXM0FOjMnt9V1F12WJgOnO3z1sP8E5%252FR7%252BtOnB1UkGmE%253D%26reserved%3D0
    
    

Reply via email to