Hi Andrew, Thanks, hopefully this is not really too complicated. I think there are already some crux examples in the SDK that would already be candidates for changing, for example. I can look at modifying those when I add it, assuming there are no concerns voiced about moving forward with this. I might leave it another 36 hours or so and move forward at that point if there are no objections.
On Thu, Oct 7, 2021 at 11:24 AM Andrew Wetmore <[email protected]> wrote: > 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/ >
