@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
