Release Step 005 Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_005 and run the following commands: git push You will need your Apache/Github username and 2FA token.
Royale_Release_Step_005 - Build # 29 - Failure!
Royale_Release_Step_005 - Build # 29 - Failure: Check console output at http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_005/29/ to view the results.
Royale_Release_Step_006 - Build # 30 - Failure!
Royale_Release_Step_006 - Build # 30 - Failure: Check console output at http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_006/30/ to view the results.
Release Step 005a Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_005a_If_Utils and run the following commands: git push You will need your Apache/Github username and 2FA token.
Release Step 005 Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_005 and run the following commands: git push You will need your Apache/Github username and 2FA token.
Re: library-path changes
Just to add to the discussion on the 'provided' vs. 'runtime' scopes... I'm not really sure what scope name should be used for what, but here's what I have assumed: 'runtime' is for 'native' libs where the runtime provides the api surface that is represented by the swc. (playerglobal/ js-typedefs examples) 'provided' is for dependencies that are pre-compiled swc dependencies, where the dependency is expected to provided when the application is built (in this case I have assumed it is explicitly listed as a dependency for the application build). I think these are different to what used to be the case with FlexMojos (see 'Scope options in Flexmojos' [1]) Also it seems that we don't do any of this in the framework project level poms, so I assume that true at frameworks/projects/pom.xml is a 'brute-force' override, simulating provided for each of the child framework projects' swc dependencies, and avoiding them being merged in for each of the framework swcs. I assume this might be another difference from [1] also, but I'm not really sure as my only exposure to maven has been since FlexJS/Royale. 1. https://www.adobe.com/devnet/flex/articles/flex-maven-flexmojos-pt3.html On Tue, Jul 23, 2019 at 5:37 AM Josh Tynjala wrote: > Thanks for posting that, Carlos. It reminded me of another rule that's > important: All "typedefs" SWCs should always be added to the > external-library-path. Even if you are building an app and not a library, > typedefs must be external (because they are provided natively by the > browser or using a
Re: Discuss of release steps preparation
Hi Piotr, What differences did you see? I downloaded the two SWCs and the only difference I saw was the timestamps in the catalog.xml in the SWCs. The timestamps are set by the SWCDATE parameter in Step 005. The log indicates that you did not specify a timezone so maybe that's why the timestamps are not matching up. Please update the instructions so that future RMs do not forget to include a timezone. The example pattern that Jenkins should show should include a timezone. You will have to remove the tag and revert any commits from steps 5, 6, and 7 before re-running step 5. HTH, -Alex On 7/23/19, 6:57 AM, "Piotr Zarzycki" wrote: Hi Alex, Thanks! I have moved forward and in step 7 - related to typedefs during build on my local machine I got mismatch error [1]. What could actually happen? I did compare some files inside those two swc and they are indeed different - I have used Total Command to compare them. When I'm starting steps related to typedefs - first step actually checkout fresh sources ? I'm wondering whether Jenkins checkout them earlier when I started one of the step before typedefs steps? This those 2 files [2] [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fbren2data=02%7C01%7Caharui%40adobe.com%7C16b7c35e1eb544ec8f5408d70f75bc69%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636994870702395435sdata=P%2FWxNbjF2DrHY7uDr7cPY9lF6qO4NSOKDlywOkaZfZ0%3Dreserved=0 [2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2Fu%2Fs!ApVpLyjpHDC2icJBcCsTMZrzfnTTuQ%3Fe%3DNwidMgdata=02%7C01%7Caharui%40adobe.com%7C16b7c35e1eb544ec8f5408d70f75bc69%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636994870702395435sdata=sk8SNjjBlbQF8xflFMBJmQEFp0ewY6mgCOxDxAR2Wm0%3Dreserved=0 Thanks, Piotr wt., 23 lip 2019 o 07:31 Alex Harui napisał(a): > Hi Piotr, > > The email with the subject "Release Step 003 Succeeded" says: > > 1. If you are releasing the utils jars (compiler-jburg-types and > compiler-build-tools), Run: > ant -f releasesteps.xml Release_Step_003 -Dutils=true > -Drelease.version=0.9.6 > > It looks like you are not using the -Dutils=true. Please improve the > email so future RMs will not miss that parameter. > > Thanks, > -Alex > > On 7/22/19, 9:06 AM, "Piotr Zarzycki" wrote: > > Hi Alex, > > I have made adjustment to documentation. I'm on step 3 where I need > build > on my end sources. I have run on my PC this: > > ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6 > > It downloads sources and maven artifacts, but it also tried build them > automatically as I understa. I got error [1] - it understandable cause > there is no 1.0.0 compiler-jburg-types. Should I on my own build > first compiler-jburg-types with 1.0.0 to have stuff in local cache or > should I made something else ? > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fa10nqdata=02%7C01%7Caharui%40adobe.com%7C16b7c35e1eb544ec8f5408d70f75bc69%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636994870702395435sdata=QeV1rkVP9nV7ibPpSESKjwRveLhhTeM%2FLOKhLVM8ChU%3Dreserved=0 > > Thanks, > Piotr > > sob., 20 lip 2019 o 06:25 Alex Harui > napisał(a): > > > Please update the wiki in a way that the next person will know which > 2FA > > token to use. > > > > Thanks, > > -Alex > > > > On 7/19/19, 9:08 AM, "Piotr Zarzycki" > wrote: > > > > So far so good. I'm on a step 3, where I need build artifacts on > my > > sight > > and compare them with what Jenkins produce. > > > > I will get back to that probably on Monday. > > > > On Fri, Jul 19, 2019, 1:40 PM Piotr Zarzycki < > > piotrzarzyck...@gmail.com> > > wrote: > > > > > Hi Alex, > > > > > > Thanks it's working. I'm moving forward with that stuff let's > see > > how far > > > I go with it. > > > > > > Piotr > > > > > > pt., 19 lip 2019 o 05:49 Alex Harui > > napisał(a): > > > > > >> I am using the token generated this way: > > >> > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Fen%2Farticles%2Fcreating-a-personal-access-token-for-the-command-linedata=02%7C01%7Caharui%40adobe.com%7C16b7c35e1eb544ec8f5408d70f75bc69%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636994870702395435sdata=aMoa8GRVyxoLF7gomeOYFraB0%2BzDdORRYu3N8f9DGoM%3Dreserved=0 > > >> > > >> There is no
Re: ComboBox list-item renderer
Hi Andrew, El mar., 23 jul. 2019 a las 16:40, Frost, Andrew () escribió: > 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..) > you should avoid use of "id", use instead "localId". https://stackoverflow.com/questions/55923924/whats-the-difference-between-id-and-localid-in-apache-royale (as well think in use more SOF, so we get more exposure to other users that wants to learn Royale but are not users of apache mailing lists) -- Carlos Rovira http://about.me/carlosrovira
RE: ComboBox list-item renderer
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
Sent: 23 July 2019 07:43
To: dev@royale.apache.org
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" 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
Sent: 22 July 2019 18:17
To: dev@royale.apache.org
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
Sent: Monday, July 22, 2019 8:13:31 PM
To: dev@royale.apache.org
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
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
Sent: Monday, July 22, 2019 7:53 PM
To: dev@royale.apache.org
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
Sent: 22 July 2019 17:43
To: dev@royale.apache.org
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]
Re: AMF and class aliases
Thanks all - some useful information there. Yes I think sending as a typed
class would be better but we're not touching the server-side... so we have to
have these workarounds. I can see the benefit of the minification for sure, but
yes when there's an object being created with the property name coming from an
AMF data stream, it then doesn't match the minified version!
Working now anyway, thanks!
Andrew
-Original Message-
From: Greg Dove
Sent: 23 July 2019 05:58
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases
Andrew, you mentioned this was being 'deserialized', so I assume this is coming
from the server as an untyped (plain) Object?
In that case, it will be deserialized with the correct original field name from
the server ('RESULT_CODE' in this case), but there is no typed reference to
that in your local code, so as Alex says the release build is renaming it, and
as suggested there needs to be more 'clues' to prevent the renaming. I believe
Alex knows more about the rules for that than I do.
It seems that you have a way to make it work now, which is probably all you
want.
But for completeness: another option is to send it as a typed class using
public vars (not using any manual-coded getter/setter pair or Bindable).
class ResultCode { public var RESULT_CODE:String; } You could then cast the
result in the same way you mentioned in your first post.
The difference here is that this will also likely rename the field access in
the release build in the same way that you saw with the original problem, but
amf deserialization will support that and it should therefore match up with the
renamed field name used in your release-build local code.
So it's probably an 'in-between' option to consider, for the future.
On Tue, Jul 23, 2019 at 4:11 PM Alex Harui wrote:
> FWIW, AIUI, the property names of plain Objects and public vars will
> be renamed unless a quoted string of that property name is used
> "somewhere" in the JS code.
>
> It might have worked just to use JSON-style:
> {"RESULT_CODE": "OK"}
>
> Creating a class definition causes the compiler to generate an
> Object.defineProperties structure with the property name as a key in
> the object structure, thus preventing the rename.
>
> If you scan the js-debug output for RESULT_CODE, you should see where
> that string showed up and how having a variable "nc" would save bytes,
> but the name to use for a renamable property is independent of that,
> and I think properties are renamed before figuring out whether a local
> variable would further save bytes.
>
> So, that's roughly the answer to #1. For #2, you "should" use classes
> with getter/setters instead of [Bindable] unless you need property
> change detection at runtime in order to get code-completion and compile-time
> checking that you didn't mis-type "RESULTCODE". There is probably a
> trade-off of how many times you'll make mistakes like that vs the time
> to create the classes and the additional time to load the class definitions.
> It should be smaller to use [brackets] than load the classes.
>
> The new IDEs should consider a wizard to help generate those classes.
>
> HTH,
> -Alex
>
>
> On 7/22/19, 2:18 AM, "Frost, Andrew" wrote:
>
> Hi again
>
> One extra question here: we have the AMF connection working fine
> now in Debug mode, but in Release mode the minifier is changing the
> property names of our JavaScript (compiled from ActionScript), but
> these are not being reflected in the objects that are deserialised.
>
> So for example, we are receiving an ArrayCollection, and accessing
> one element's property directly e.g.:
> var results : ArrayCollection = resultEvt.result as ArrayCollection;
> for (var i : uint = 0; i < results.length; i++)
> {
> var resultCode : String =
> results[i].outputArray.source[0].RESULT_CODE;
> ...
>
> There are a couple of things going on:
> (a) each element in the main ArrayCollection has an "outputArray"
> property which is itself an ArrayCollection. We could cast it into an
> ArrayCollection variable I guess, but instead have just added "source"
> so that the JavaScript doesn't try adding the [] operator to the
> ArrayCollection object directly...
> (b) the contents of this ArrayCollection, in this particular case,
> is a simple object {RESULT_CODE: "OK"} - which I can see in the
> console when we add some trace. The js-debug file has the same
> structure as the ActionScript; but the js-release file has a mapping
> at the start "nc='RESULT_CODE'" and then accesses the data with "
> a.L(c).outputData.source[0].tP" (and that's even weirder as why is it 'tP'
> rather than 'nc'?!)
>
>
> I guess the questions I have are:
>
> 1) Is there a way to prevent the Google closure compiler from
> minifying a particular property name/string?
> or
> 2) Are we going to have to just declare classes for all of these
> and do a typecast
Re: Discuss of release steps preparation
Hi Alex, Thanks! I have moved forward and in step 7 - related to typedefs during build on my local machine I got mismatch error [1]. What could actually happen? I did compare some files inside those two swc and they are indeed different - I have used Total Command to compare them. When I'm starting steps related to typedefs - first step actually checkout fresh sources ? I'm wondering whether Jenkins checkout them earlier when I started one of the step before typedefs steps? This those 2 files [2] [1] https://paste.apache.org/bren2 [2] https://1drv.ms/u/s!ApVpLyjpHDC2icJBcCsTMZrzfnTTuQ?e=NwidMg Thanks, Piotr wt., 23 lip 2019 o 07:31 Alex Harui napisał(a): > Hi Piotr, > > The email with the subject "Release Step 003 Succeeded" says: > > 1. If you are releasing the utils jars (compiler-jburg-types and > compiler-build-tools), Run: > ant -f releasesteps.xml Release_Step_003 -Dutils=true > -Drelease.version=0.9.6 > > It looks like you are not using the -Dutils=true. Please improve the > email so future RMs will not miss that parameter. > > Thanks, > -Alex > > On 7/22/19, 9:06 AM, "Piotr Zarzycki" wrote: > > Hi Alex, > > I have made adjustment to documentation. I'm on step 3 where I need > build > on my end sources. I have run on my PC this: > > ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6 > > It downloads sources and maven artifacts, but it also tried build them > automatically as I understa. I got error [1] - it understandable cause > there is no 1.0.0 compiler-jburg-types. Should I on my own build > first compiler-jburg-types with 1.0.0 to have stuff in local cache or > should I made something else ? > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fa10nqdata=02%7C01%7Caharui%40adobe.com%7C9f9cf5dbc62941839a3008d70ebe8172%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636994083767826897sdata=R7ZZeu6nz4wKPxtbSqrVyy40Y2fV8qqMEEl4c5F8RC0%3Dreserved=0 > > Thanks, > Piotr > > sob., 20 lip 2019 o 06:25 Alex Harui > napisał(a): > > > Please update the wiki in a way that the next person will know which > 2FA > > token to use. > > > > Thanks, > > -Alex > > > > On 7/19/19, 9:08 AM, "Piotr Zarzycki" > wrote: > > > > So far so good. I'm on a step 3, where I need build artifacts on > my > > sight > > and compare them with what Jenkins produce. > > > > I will get back to that probably on Monday. > > > > On Fri, Jul 19, 2019, 1:40 PM Piotr Zarzycki < > > piotrzarzyck...@gmail.com> > > wrote: > > > > > Hi Alex, > > > > > > Thanks it's working. I'm moving forward with that stuff let's > see > > how far > > > I go with it. > > > > > > Piotr > > > > > > pt., 19 lip 2019 o 05:49 Alex Harui > > napisał(a): > > > > > >> I am using the token generated this way: > > >> > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Fen%2Farticles%2Fcreating-a-personal-access-token-for-the-command-linedata=02%7C01%7Caharui%40adobe.com%7C9f9cf5dbc62941839a3008d70ebe8172%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636994083767826897sdata=%2FOwoa7TPLlsGNeGNOcVTSdaR%2F4iAqWMbyikJdqaZjnY%3Dreserved=0 > > >> > > >> There is no short code from Google Authenticator. > > >> > > >> -Alex > > >> > > >> On 7/18/19, 8:46 AM, "Piotr Zarzycki" < > piotrzarzyck...@gmail.com> > > wrote: > > >> > > >> I'm using 2FA authentication, second step for me is typing > > short code > > >> from > > >> Google Authenticator application. Do you use something > > different? > > >> > > >> czw., 18 lip 2019 o 17:42 Alex Harui > > > >> napisał(a): > > >> > > >> > I don't think git version matters. Are you using your > 2fa > > token as > > >> the > > >> > password? It should be a really long sequence of > characters. > > >> > > > >> > Get Outlook for Android< > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36data=02%7C01%7Caharui%40adobe.com%7C9f9cf5dbc62941839a3008d70ebe8172%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636994083767836892sdata=iV0exQGmG4ohbGHczIBWWm%2FA%2Bb%2BXZl%2BGRvi%2Bb%2FR1%2Fg0%3Dreserved=0 > > >> > > > >> > > > >> > > > >> > From: Piotr Zarzycki > > >> > Sent: Thursday, July 18, 2019 7:43:44 AM > > >> > To: dev@royale.apache.org > > >> > Subject: Re: Discuss of release steps preparation > > >> > > > >> > Maybe Git just should be updated on Machine ? I see > 2.15 and > > there > > >> is 2.22 >
Release Step 007 Succeeded
>From the royale-typedefs repo: 1. Run ant -f releasesteps.xml Release_Step_007 -Drelease.version=0.9.6 This will download the artifacts then unzip and compile the source artifact. 2. Validate that the compiled artifacts match the downloaded artifacts. 3. If they do, then run ant -f releasesteps.xml Release_Step_007_Sign -Drelease.version=0.9.6 This will PGP sign the source ZIP and compiled JARs 4. Then run ant -f releasesteps.xml Release_Step_007_Upload -Drelease.version=0.9.6 This will upload the signed artifacts to Maven Release Staging. Do not "Close" the staging repository until the other repos have been added.
Release Step 006 Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_006 and run the following commands: git push git push origin org.apache.royale.typedefs-0.9.6-rc1 You will need your Apache/Github username and 2FA token.
Release Step 005a Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_005a and run the following commands: git push You will need your Apache/Github username and 2FA token.
Release Step 005 Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_005 and run the following commands: git push You will need your Apache/Github username and 2FA token.
Release Step 004 Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_004 and run the following commands: git push git checkout release/0.9.6 git push -u origin release/0.9.6 You will need your Apache/Github username and 2FA token.
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" 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
Sent: 22 July 2019 18:17
To: dev@royale.apache.org
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
Sent: Monday, July 22, 2019 8:13:31 PM
To: dev@royale.apache.org
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
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
Sent: Monday, July 22, 2019 7:53 PM
To: dev@royale.apache.org
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
Sent: 22 July 2019 17:43
To: dev@royale.apache.org
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Ff637c857122d56f838bab21314a11900ed0add8e%2Fexamples%2Froyale%2FTodoListSampleApp%2Fsrc%2Fmain%2Froyale%2Fsample%2Ftodo%2Fviews%2FTodoListView.mxml%23L169data=02%7C01%7Caharui%40adobe.com%7Cd3872c0a305540bd0c8d08d70ed0241a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636994159504560528sdata=zMXZrtGppirdF8kCbxK3nO4VjQaAULy2bK2SdcXn%2FvI%3Dreserved=0
From: Carlos Rovira
Sent: Monday, July 22, 2019 6:32:27 PM
To: dev@royale.apache.org
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
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 ()
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
