Yes. I would love to help update the documentation to reflect this advance. First step would be a clear example app or two. Then I would try to update our getting-started material. THEN I would have to tackle the tutorials that Carlos wrote.
a On Wed, Oct 6, 2021 at 7:17 PM Alina Kazi <[email protected]> wrote: > +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 > > > -- Andrew Wetmore http://cottage14.blogspot.com/
