+1 for two libs On Thu, 7 Oct 2021, 2:42 am Piotr Zarzycki, <[email protected]> wrote:
> +1 for that. > > Could you share for application which is being build by Maven how would > look like dependencies if someone would like to use both libraries. > > It’s just for the documentation purposes here. > > Thanks, > Piotr > > On Wed, 6 Oct 2021 at 22:59, Greg Dove <[email protected]> wrote: > > > I have had at least two requests for it, and others still express support > > for it, and it has been said in past discussions that if someone is > willing > > to 'put in the work' that it's welcome... so I wanted to signal my > > intention to split MXRoyale up into two libraries - the first being most > of > > the non-UI classes "MXRoyaleBase", and the second being the same as the > > current "MXRoyale" lib is now. > > > > I already have this working locally, so this is really just a check-in to > > make sure everyone is comfortable with it before I push any changes > related > > to this. > > If, after reading this post, you have any concerns, can you please share > > them in reply to this thread. > > > > The change will make it easier for people who want to use (for example) > the > > mx services/remoting support with a non-emulation component set (e.g. > > Jewel). It may also make it easier for any Royale developer who wants to > > take a shot at an alternate version of the mx emulation set (if anyone is > > so inclined) because the non-UI parts and likely some of the UI > interfaces > > only will be in the MXRoyaleBase library. As an example, someone might > want > > to create a new emulation set that more closely mirrors (assuming it is > > possible to do so) the original measurement and layout aspects of the > Flex > > lifecycle, or which takes advantage of more modern browser APIs because > > they don't care about support for older browsers, or simply for whatever > > other reasons they might have. > > > > What impact will it have on me? > > *Royale User:* > > No change for emulation users: If you are using MXRoyale currently, it > will > > continue to work as it has before. > > Non-emulation users: If you want to use mx service classes (for example) > in > > some non-emulation component set (e.g. Jewel or Basic), it will make > things > > easier for you because you can switch to MXRoyaleBase.swc and won't have > to > > exclude the css from the MXRoyale.swc. At the same time, the current > > approach for excluding css will continue to work as before. > > > > *Royale Developer:* > > The source code from the current MXRoyale codebase will be split into two > > libraries- MXRoyaleBase for mostly non-UI code and MXRoyale which will be > > mostly the UI implementation code. MXRoyale swc build will include the > > MXRoyaleBase source code and its mxml component definitions so that the > > code from the other swc gets included, resulting in the same swc build as > > before for MXRoyale (this avoids breaking any builds for folks using > > MXRoyale). The biggest impact from an emulation developer's perspective > is > > that potentially you might need to look in two library codebases (e.g. if > > you are making changes to IUIComponent which is in MXRoyaleBase and > > UIComponent which is in MXRoyale). If you are working on non-UI code, it > > should mainly be in MXRoyaleBase. If you are mainly working mainly on the > > UI code, which I think is very often the case, it will continue to be in > > MXRoyale. > > > > > > Thanks, > > Greg > > > -- > > Piotr Zarzycki >
