Hi,
as we talked I take the time to make a list of package name changes.
Finally 20 classes were changed from package.
Here's the list from 16c0dcd643974fe708fd67a3774ea6e35e879811 (in red the
changes to better following)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/MXMLBeadView.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/MXMLBeadView.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/views/ContainerView.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/ContainerView.as.
(1)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/views/DataContainerView.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/DataContainerView.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/GroupView.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/GroupView.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/IBackgroundBead.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/
html/beads/IBackgroundBead.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/IBorderBead.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/IBorderBead.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/IDropDownListView.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/IDropDownListView.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/IListView.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/IListView.as.
(2)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/ITextFieldView.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/
html/beads/ITextFieldView.as (2)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/TextFieldViewBase.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/TextFieldViewBase.as
(2)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/layouts/LayoutChangeNotifier.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/layouts/LayoutChangeNotifier.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/models/ArraySelectionModel.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/models/ArraySelectionModel.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/models/ViewportModel.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/models/ViewportModel.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/supportClasses/Border.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/
html/supportClasses/Border.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/supportClasses/ContainerContentArea.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html/supportClasses/ContainerContentArea.as.
(2)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/supportClasses/DataGroup.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html/supportClasses/DataGroup.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/DataItemRenderer.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html/
supportClasses/DataItemRenderer.as (3)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/MXMLItemRenderer.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html/
supportClasses/MXMLItemRenderer.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/UIItemRendererBase.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html/
supportClasses/UIItemRendererBase.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/supportClasses/Viewport.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/supportClasses/Viewport.as
Some comments:
(1) "views" should follow the same package structure we have with other
beads 8"models", "controllers"...) to be consistent.
(2) should go to "core/beads/views" as well
(3) item renderers that should normaly be used by final users could go some
kind of "itemRenderers" package, while base item redeemer classes could go
again to supportClasses.
As Harbs said, if we agree in the change of packages, we should do this
well and perform some other changes that make all more consistent though
libraries.
Thanks
Carlos
2018-05-17 11:16 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> Definitely a plan.
>
> My guess is that if we agree on changing package paths, there will likely
> be other classes that should be considered.
>
> My preference would be to have this discussion after we finish the project
> refactor discussion because I think it’s going to be related to the outcome
> of that.
>
> Either way, I don’t think discussion should hold up the 0.9.3 release.
> We’re already past due for a release. We want to “release early and release
> often”… ;-)
>
> Thanks,
> Harbs
>
> > On May 17, 2018, at 12:07 PM, Carlos Rovira <carlosrov...@apache.org>
> wrote:
> >
> > Ok,
> >
> > what if:
> >
> > * I take the time to generate a list of classes with package name changes
> > * Make a thread with the list to expose it
> > * Let's see from there if people can live with it (We'll call people to
> > express about this changes and could see if are or not dramatic to them)
> >
> > Sounds this like a plan?
> >
> > Thanks
> >
> >
> >
> > 2018-05-17 10:58 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> >
> >> Sure. Same here.
> >>
> >> But things are much more stable now. As we move closer to “1.0”, I think
> >> we should be more careful about breaking changes and documenting them
> when
> >> we decide they are necessary.
> >>
> >> As far as these specific changes go: We haven’t even come to a
> conclusion
> >> on what (if any) package names should change yet, and including those
> >> changes in a release is premature. If we do change package names, I’m of
> >> the opinion that they should be decided on and all happen at once to
> >> minimize impact on end-users.
> >>
> >> Does that help clarify things?
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On May 17, 2018, at 11:49 AM, Justin Mclean <jus...@classsoftware.com>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>>> We are at the point where people are using Royale in production. While
> >> we can make breaking changes if they are warranted, they should be kept
> to
> >> an absolute minimum and be carefully considered and well documented if
> we
> >> do.
> >>>
> >>> There has been many previous breaking changes that broke the
> application
> >> I was working on and some more major than this and cost me a lot of
> time to
> >> fix. Until you make it version 1.0 I think people will expect that some
> >> things may break with a new version. So why should this be an exception
> to
> >> what has happened before? Saying that however, what would be good to
> see is
> >> to provide guidance to what users need to change so their app works with
> >> any changes / backward compatibility issues.
> >>>
> >>> Thanks,
> >>> Justin
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
