I have no idea why this has been sent to me personally. I assume some form of addressing error.
Mark On 29/04/2019 16:41, Alex Harui wrote: > @Mark, I'm assuming you want something in the output that identifies the > actual versions used. In Royale, you may also need to identify the version > of the transpiler as well, and maybe the version of Google Closure. If you > want to propose (or better yet, implement) a PAYG way to do that in Royale, > please do so. If other folks think this will be useful, please speak up so > we get a sense of how important it is. A simple hack may be to embed the > pom.xml file in your output as a string if you are using Maven. If you use > Ant, you could grab the SDK version from build.properties or embed the > flex-sdk-description.xml file. > > @Carlos, I couldn't understand your scenario. Feel free to start a separate > thread on it. The key aspect, as a guess, is trying to avoid code that > assumes that an instance is a subclass of a particular base class instead of > an implementation of an interface. > > HTH, > -Alex > > On 4/29/19, 7:29 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote: > > @Mark, if you use Maven, then artifacts in the poms are all what you need, > so maven takes care of pulling all right dependencies you need. > > @Alex, about extending IUIBase, my own experience is that beads are a very > good way to extend/compose more code you need, but extending core > interfaces like the one you said is not the case. Let me put you an > example: For Jewel I use "StyledUIBase" that extends "UIBase" to add > IClassSelectorListSupport, the css CRUD API (addClass, removeClass, > etc..): > > public class StyledUIBase extends UIBase implements > IClassSelectorListSupport > > This makes that some components are easy to extend but others need to be > recreate. There are lots of cases in Jewel where I need to > > If you search in Jewel for implements IClassSelectorListSupport > you'll find Jewel Group, Jewel DataContainerBase and Jewel Table, are > implementing that class while, so they are not StyledUIBase in it's core > are standard UIBase and at its level we implement the interface and add > again all methods repeating the code. So we are duplicating that code all > that times. > > I think this is one of the few things I don't like in Jewel, If you know > some way to do this in a better way, I can change it > > thanks > > > > > > El lun., 29 abr. 2019 a las 12:36, Kessler CTR Mark J > (<mark.kessler....@usmc.mil.invalid>) escribió: > > > Yeah just concerned with an official build number, or date, or > > something with numbers we can use to identify a production app back to > what > > SDK was used to compile it. Imagine having an app released on > production > > and a user reports a problem. We would need to reproduce the problem in > a > > test environment. This would include using the same SDK to compile the > > app. Currently in Flex, we can just access its version directly which > > makes things faster. > > > > If the SDK doesn't have anything like this at the moment and we did > > add that functionality in there, I would say let's just use a date field > > since it could be automated. Something like YYYYMMDD type format. > > > > > > -Mark K > > > > > > -----Original Message----- > > From: Alex Harui [mailto:aha...@adobe.com.INVALID] > > Sent: Friday, April 26, 2019 12:02 PM > > To: dev@royale.apache.org > > Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale > > version to 1.0) > > > > > > > > On 4/26/19, 4:29 AM, "Kessler CTR Mark J" > <mark.kessler....@usmc.mil.INVALID> > > wrote: > > > > > So far, we have not had the release scripts properly generate the > > right version number for the NPM artifacts. > > > > > > This spurred a question for me. Is there a way to find out what > > version number the SDK binaries are in code for Royale? Sort of like > the > > Flex SDK mx.core.FlexVersion or at least a build date? > > > > Not at this time. IMO, runtime versioning wasn't worth the cost of all > of > > those strings and code in the production app. Also, Royale was designed > > from the beginning to try to be "version-agnostic". By using > > loose-coupling via Beads/PAYG/ValuesManager and lots of interfaces > instead > > of direct class references, there shouldn't be a need to deal with > version > > incompatibilities at runtime like Flex did with the Marshall Plan and > > FlexVersion and more. > > > > Flex had to care about version incompatibilities because the fundamental > > base classes were not loosely-coupled. Flex HelloWorld was 128K not > just > > because UIComponent was huge, but because UIComponent pulled in other > > classes as init-time strongly-coupled dependencies. A good thing to > think > > about as you write Royale framework code is, "can every dependency be > > easily replaced"? > > > > After we hit 1.0 (and hopefully find some volunteers to write regression > > tests), then new APIs to existing classes will need to be considered > > carefully and implemented in extensions. So there will be some > extension > > of IUIBase that has some new API instead of adding new APIs to IUIBase. > I > > have a personal preference to use long names instead of numbers, so the > > extension will hopefully be called IUIBaseWithWhatever instead of > IUIBase2. > > > > If you are asking about build-time versioning, we haven't done anything > > there either. As long as there is no impact on production apps I think > it > > is fine for folks to contribute something if there is a need. > > > > My 2 cents, > > -Alex > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C94fddf253e6b4a8b6ec208d6ccaf1219%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921449642861921&sdata=I4BGFaXHFOuk5lClNTySl6g0k%2Fo%2FM8weJkivqJQkgs8%3D&reserved=0 > >
