You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Cyrill Zadra <cy...@gmail.com> on 2013/02/28 06:12:17 UTC
Spark Accordion
Hey
I was looking for a Spark Accordion and found the one in tinks and
cframpton whiteboard (branch adobe.next). I moved all the relevant
classes from cframpon's adobe.next branch to my develop branch and
after a couple of hours I had a working accordion and it looks great.
Before I continue to do some work and tests on accordion I just wanted
to ask if there is already a decision which accordion is going to be
in apache flex? If not.. what needs to be done to have a decision.
Cyrill
Re: Spark Accordion
Posted by Cyrill Zadra <cy...@gmail.com>.
I think tink uses a similar approach as you mentioned bogdan,
.. just looking at his source code ;-)
Cyrill
On Fri, Mar 1, 2013 at 8:52 PM, Bogdan DINU <fl...@gmail.com> wrote:
> If I recall correctly, mobile components have destruction policy declared
> by ViewNavigatorBase. However, I don't deny that a NavigatorContent with
> creation/destruction policy is useful, but altering UIComponent (which is
> already huge) is not the best option in my opinion.
>
> All the best,
> Bogdan
>
>
> On Fri, Mar 1, 2013 at 8:11 AM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>>
>> On 2/28/13 9:53 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>>
>> > Hey
>> >
>> >> a while ago, I've looked over the Accordion from "adobe.next" branch,
>> >> having the same intention on my mind. What I found out is that they went
>> >> all the way down, modifying UIComponent to add elementCreationPolicy and
>> >> elementDestructionPolicy to the NavigatorContent, in order to make the
>> >> Accordion support creation and destruction policies.
>> >>
>> >> Since Accordion component seems the only one who needs that, my approach
>> >> (which remained an experiment that I haven't had time to finish), was to
>> >> create a class named NavigatorContentWithPolicies that extends
>> >> SkinnableContainer, so UIComponent doesn't need to be altered.
>> >
>> > @Alex or Carol do you know if there were any reason why
>> > elementDestructionPolicy was added in UIComponent and not in a way as
>> > Bogdan describes?
>> I don't know for sure. It maybe be that we wanted all kinds of containers
>> to allow for destruction policies. I think there are lots of scenarios in
>> mobile where destruction policies are important and NavigatorContent may
>> not
>> always be involved.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>
>
> --
> http://www.badu.ro
Re: Spark Accordion
Posted by Bogdan DINU <fl...@gmail.com>.
If I recall correctly, mobile components have destruction policy declared
by ViewNavigatorBase. However, I don't deny that a NavigatorContent with
creation/destruction policy is useful, but altering UIComponent (which is
already huge) is not the best option in my opinion.
All the best,
Bogdan
On Fri, Mar 1, 2013 at 8:11 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 2/28/13 9:53 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>
> > Hey
> >
> >> a while ago, I've looked over the Accordion from "adobe.next" branch,
> >> having the same intention on my mind. What I found out is that they went
> >> all the way down, modifying UIComponent to add elementCreationPolicy and
> >> elementDestructionPolicy to the NavigatorContent, in order to make the
> >> Accordion support creation and destruction policies.
> >>
> >> Since Accordion component seems the only one who needs that, my approach
> >> (which remained an experiment that I haven't had time to finish), was to
> >> create a class named NavigatorContentWithPolicies that extends
> >> SkinnableContainer, so UIComponent doesn't need to be altered.
> >
> > @Alex or Carol do you know if there were any reason why
> > elementDestructionPolicy was added in UIComponent and not in a way as
> > Bogdan describes?
> I don't know for sure. It maybe be that we wanted all kinds of containers
> to allow for destruction policies. I think there are lots of scenarios in
> mobile where destruction policies are important and NavigatorContent may
> not
> always be involved.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
http://www.badu.ro
Re: Spark Accordion
Posted by Cyrill Zadra <cy...@gmail.com>.
Tinks components are now in experimental project.
Cyrill
On Tue, Mar 19, 2013 at 4:16 PM, Cyrill Zadra <cy...@gmail.com> wrote:
> just fyi.. I have my local experimental project updated with tink's
> components. As soon I've a stable internet connection I'll clone the
> git repository and push my changes.
>
> cyrill
>
> On Tue, Mar 12, 2013 at 9:12 AM, Cyrill Zadra <cy...@gmail.com> wrote:
>> No .. I haven't yet looked at it.
>>
>> On Tue, Mar 12, 2013 at 9:05 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>>> Hi,
>>>
>>>> Tinks and experimental folder contain both a MenuBar component. How do we proceed in this situation?
>>> I just use the existing one unless there's a compelling reason to use Tinks. Any idea how they compare?
>>>
>>> Thanks,
>>> Justin
Re: Spark Accordion
Posted by Cyrill Zadra <cy...@gmail.com>.
just fyi.. I have my local experimental project updated with tink's
components. As soon I've a stable internet connection I'll clone the
git repository and push my changes.
cyrill
On Tue, Mar 12, 2013 at 9:12 AM, Cyrill Zadra <cy...@gmail.com> wrote:
> No .. I haven't yet looked at it.
>
> On Tue, Mar 12, 2013 at 9:05 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>> Hi,
>>
>>> Tinks and experimental folder contain both a MenuBar component. How do we proceed in this situation?
>> I just use the existing one unless there's a compelling reason to use Tinks. Any idea how they compare?
>>
>> Thanks,
>> Justin
Re: Spark Accordion
Posted by Cyrill Zadra <cy...@gmail.com>.
No .. I haven't yet looked at it.
On Tue, Mar 12, 2013 at 9:05 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> Tinks and experimental folder contain both a MenuBar component. How do we proceed in this situation?
> I just use the existing one unless there's a compelling reason to use Tinks. Any idea how they compare?
>
> Thanks,
> Justin
Re: Spark Accordion
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Tinks and experimental folder contain both a MenuBar component. How do we proceed in this situation?
I just use the existing one unless there's a compelling reason to use Tinks. Any idea how they compare?
Thanks,
Justin
Re: Spark Accordion
Posted by Cyrill Zadra <cy...@gmail.com>.
If no one else has any favorite or concerns I would start bring tinks
accordion to the experimantel project. Whats about all the other
components shall I move them aswell? If so.. there would appear a
component conflict ;). Tinks and experimental folder contain both a
MenuBar component. How do we proceed in this situation?
Cyrill
On Mon, Mar 11, 2013 at 1:02 AM, Frédéric THOMAS
<we...@hotmail.com> wrote:
> Hi Cyril,
>
> My thoughts would be the 3rd option as it gives more features but I didn't
> try it yet.
> I guess the tinks components haven't been added to the existing one at the
> time because mustella haven't been donated yet.
>
>
> -Fred
>
> -----Message d'origine----- From: Cyrill Zadra
> Sent: Sunday, March 10, 2013 3:30 PM
>
> To: dev@flex.apache.org
> Subject: Re: Spark Accordion
>
> In the meantime I had a look at tinks Spark Accordion and one thing I
> recognized that his AccordionLayout is supporting animation (Bounce,
> Linear). But his accordion is depending on a few introduced classes
> (Navigator, NavigatorGroup, DefferedGroup ... ) .
>
> For my use case tinks accordion did also work.
> Is anyone already using a spark accordion or has a favorite?
>
> Currently I see following 3 possibilities:
>
> 1) Using Adobe's accordion as it is in adobe.next branch.
>
> Here a list of the files that will be changed or added for spark accordion.
>
> Container.as Modified frameworks/projects/mx/src/mx/core
> FlexVersion.as Modified frameworks/projects/framework/src/mx/core
> Accordion.as Added frameworks/projects/spark/src/spark/components
> AccordionContent.as Added frameworks/projects/spark/src/spark/components
> ContainerDestructionPolicy.as Added frameworks/projects/spark/src/spark/core
> IDeferredContentOwner.as Modified frameworks/projects/framework/src/mx/core
> ModuleLoader.as Modified frameworks/projects/spark/src/spark/modules
> NavigatorContent.as Modified frameworks/projects/spark/src/spark/components
> SkinnableContainer.as Modified
> frameworks/projects/spark/src/spark/components
> defaults.css Modified frameworks/projects/spark
> HorizontalAccordionContentSkin.mxml Added
> frameworks/projects/spark/src/spark/skins/spark
> HorizontalAccordionLayout.as Added
> frameworks/projects/spark/src/spark/components/supportClasses
> HorizontalAccordionSkin.mxml Added
> frameworks/projects/spark/src/spark/skins/spark
> HorizontalAccordionToggleButtonSkin.mxml Added
> frameworks/projects/spark/src/spark/skins/spark
> SparkClasses.as Modified frameworks/projects/spark/src
> VerticalAccordionContentSkin.mxml Added
> frameworks/projects/spark/src/spark/skins/spark
> VerticalAccordionLayout.as Added
> frameworks/projects/spark/src/spark/components/supportClasses
> VerticalAccordionSkin.mxml Added
> frameworks/projects/spark/src/spark/skins/spark
> VerticalAccordionToggleButtonSkin.mxml Added
> frameworks/projects/spark/src/spark/skins/spark
> 2) Using Adobe's accordion (without the creation policy changes). So
> maybe we could remove the creationpolicy feature for first version of
> accordion. I'm not sure if this is really a good way to go.
> 3) Using tinks Accordion and move it and its dependant classes & files
> to experimental project.
>
> regards
> cyrill
Re: Spark Accordion
Posted by Frédéric THOMAS <we...@hotmail.com>.
Hi Cyril,
My thoughts would be the 3rd option as it gives more features but I didn't
try it yet.
I guess the tinks components haven't been added to the existing one at the
time because mustella haven't been donated yet.
-Fred
-----Message d'origine-----
From: Cyrill Zadra
Sent: Sunday, March 10, 2013 3:30 PM
To: dev@flex.apache.org
Subject: Re: Spark Accordion
In the meantime I had a look at tinks Spark Accordion and one thing I
recognized that his AccordionLayout is supporting animation (Bounce,
Linear). But his accordion is depending on a few introduced classes
(Navigator, NavigatorGroup, DefferedGroup ... ) .
For my use case tinks accordion did also work.
Is anyone already using a spark accordion or has a favorite?
Currently I see following 3 possibilities:
1) Using Adobe's accordion as it is in adobe.next branch.
Here a list of the files that will be changed or added for spark accordion.
Container.as Modified frameworks/projects/mx/src/mx/core
FlexVersion.as Modified frameworks/projects/framework/src/mx/core
Accordion.as Added frameworks/projects/spark/src/spark/components
AccordionContent.as Added frameworks/projects/spark/src/spark/components
ContainerDestructionPolicy.as Added frameworks/projects/spark/src/spark/core
IDeferredContentOwner.as Modified frameworks/projects/framework/src/mx/core
ModuleLoader.as Modified frameworks/projects/spark/src/spark/modules
NavigatorContent.as Modified frameworks/projects/spark/src/spark/components
SkinnableContainer.as Modified
frameworks/projects/spark/src/spark/components
defaults.css Modified frameworks/projects/spark
HorizontalAccordionContentSkin.mxml Added
frameworks/projects/spark/src/spark/skins/spark
HorizontalAccordionLayout.as Added
frameworks/projects/spark/src/spark/components/supportClasses
HorizontalAccordionSkin.mxml Added
frameworks/projects/spark/src/spark/skins/spark
HorizontalAccordionToggleButtonSkin.mxml Added
frameworks/projects/spark/src/spark/skins/spark
SparkClasses.as Modified frameworks/projects/spark/src
VerticalAccordionContentSkin.mxml Added
frameworks/projects/spark/src/spark/skins/spark
VerticalAccordionLayout.as Added
frameworks/projects/spark/src/spark/components/supportClasses
VerticalAccordionSkin.mxml Added
frameworks/projects/spark/src/spark/skins/spark
VerticalAccordionToggleButtonSkin.mxml Added
frameworks/projects/spark/src/spark/skins/spark
2) Using Adobe's accordion (without the creation policy changes). So
maybe we could remove the creationpolicy feature for first version of
accordion. I'm not sure if this is really a good way to go.
3) Using tinks Accordion and move it and its dependant classes & files
to experimental project.
regards
cyrill
Re: Spark Accordion
Posted by Cyrill Zadra <cy...@gmail.com>.
In the meantime I had a look at tinks Spark Accordion and one thing I
recognized that his AccordionLayout is supporting animation (Bounce,
Linear). But his accordion is depending on a few introduced classes
(Navigator, NavigatorGroup, DefferedGroup ... ) .
For my use case tinks accordion did also work.
Is anyone already using a spark accordion or has a favorite?
Currently I see following 3 possibilities:
1) Using Adobe's accordion as it is in adobe.next branch.
Here a list of the files that will be changed or added for spark accordion.
Container.as Modified frameworks/projects/mx/src/mx/core
FlexVersion.as Modified frameworks/projects/framework/src/mx/core
Accordion.as Added frameworks/projects/spark/src/spark/components
AccordionContent.as Added frameworks/projects/spark/src/spark/components
ContainerDestructionPolicy.as Added frameworks/projects/spark/src/spark/core
IDeferredContentOwner.as Modified frameworks/projects/framework/src/mx/core
ModuleLoader.as Modified frameworks/projects/spark/src/spark/modules
NavigatorContent.as Modified frameworks/projects/spark/src/spark/components
SkinnableContainer.as Modified frameworks/projects/spark/src/spark/components
defaults.css Modified frameworks/projects/spark
HorizontalAccordionContentSkin.mxml Added
frameworks/projects/spark/src/spark/skins/spark
HorizontalAccordionLayout.as Added
frameworks/projects/spark/src/spark/components/supportClasses
HorizontalAccordionSkin.mxml Added
frameworks/projects/spark/src/spark/skins/spark
HorizontalAccordionToggleButtonSkin.mxml Added
frameworks/projects/spark/src/spark/skins/spark
SparkClasses.as Modified frameworks/projects/spark/src
VerticalAccordionContentSkin.mxml Added
frameworks/projects/spark/src/spark/skins/spark
VerticalAccordionLayout.as Added
frameworks/projects/spark/src/spark/components/supportClasses
VerticalAccordionSkin.mxml Added frameworks/projects/spark/src/spark/skins/spark
VerticalAccordionToggleButtonSkin.mxml Added
frameworks/projects/spark/src/spark/skins/spark
2) Using Adobe's accordion (without the creation policy changes). So
maybe we could remove the creationpolicy feature for first version of
accordion. I'm not sure if this is really a good way to go.
3) Using tinks Accordion and move it and its dependant classes & files
to experimental project.
regards
cyrill
Re: Spark Accordion
Posted by Cyrill Zadra <cy...@gmail.com>.
> I guess it should be 2 first, then 1 if you want to move them to the spark
> lib otherwize I guess, it's preferable to move them to the experimental lib
> as we did with the Bogdan's components, btw, there's also a thread "A
> guideline for adding new components to the Apache Flex SDK?" where we can
> talk about it, what do you think ?
>
Yes sorry.. first 2 then 1 ;-).
Re: Spark Accordion
Posted by Frédéric THOMAS <we...@hotmail.com>.
> If we choose the Accordion in adobe.next branch I would suggest following
> steps:
1) Moving all relevant classes to develop branch direct in spark
project (not experimental project).
2) Writing mustella tests for accordion.
I guess it should be 2 first, then 1 if you want to move them to the spark
lib otherwize I guess, it's preferable to move them to the experimental lib
as we did with the Bogdan's components, btw, there's also a thread "A
guideline for adding new components to the Apache Flex SDK?" where we can
talk about it, what do you think ?
-Fred
-----Message d'origine-----
From: Cyrill Zadra
Sent: Friday, March 01, 2013 6:53 AM
To: dev@flex.apache.org
Subject: Re: Spark Accordion
Hey
> a while ago, I've looked over the Accordion from "adobe.next" branch,
> having the same intention on my mind. What I found out is that they went
> all the way down, modifying UIComponent to add elementCreationPolicy and
> elementDestructionPolicy to the NavigatorContent, in order to make the
> Accordion support creation and destruction policies.
>
> Since Accordion component seems the only one who needs that, my approach
> (which remained an experiment that I haven't had time to finish), was to
> create a class named NavigatorContentWithPolicies that extends
> SkinnableContainer, so UIComponent doesn't need to be altered.
@Alex or Carol do you know if there were any reason why
elementDestructionPolicy was added in UIComponent and not in a way as
Bogdan describes?
> Besides a bug about specifying width / height on AccordionContent that
> produces malfunction (never closes), the Accordion component seems
> compliant to pairing the MX one.
Yes .. until now I have the same impression that it brings everything
that the mx one does.
Just having some issue with the icon attribute I'm trying to figure out.
I haven't look at tink's source code yet just at his examples [1] ..
but I definitely look also at his source code.
If we choose the Accordion in adobe.next branch I would suggest following
steps:
1) Moving all relevant classes to develop branch direct in spark
project (not experimental project).
2) Writing mustella tests for accordion.
Or would you prefer the experimental project?
[1]http://www.tink.ws/examples/apache-flex/
Re: Spark Accordion
Posted by Alex Harui <ah...@adobe.com>.
On 2/28/13 9:53 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
> Hey
>
>> a while ago, I've looked over the Accordion from "adobe.next" branch,
>> having the same intention on my mind. What I found out is that they went
>> all the way down, modifying UIComponent to add elementCreationPolicy and
>> elementDestructionPolicy to the NavigatorContent, in order to make the
>> Accordion support creation and destruction policies.
>>
>> Since Accordion component seems the only one who needs that, my approach
>> (which remained an experiment that I haven't had time to finish), was to
>> create a class named NavigatorContentWithPolicies that extends
>> SkinnableContainer, so UIComponent doesn't need to be altered.
>
> @Alex or Carol do you know if there were any reason why
> elementDestructionPolicy was added in UIComponent and not in a way as
> Bogdan describes?
I don't know for sure. It maybe be that we wanted all kinds of containers
to allow for destruction policies. I think there are lots of scenarios in
mobile where destruction policies are important and NavigatorContent may not
always be involved.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Spark Accordion
Posted by Cyrill Zadra <cy...@gmail.com>.
Hey
> a while ago, I've looked over the Accordion from "adobe.next" branch,
> having the same intention on my mind. What I found out is that they went
> all the way down, modifying UIComponent to add elementCreationPolicy and
> elementDestructionPolicy to the NavigatorContent, in order to make the
> Accordion support creation and destruction policies.
>
> Since Accordion component seems the only one who needs that, my approach
> (which remained an experiment that I haven't had time to finish), was to
> create a class named NavigatorContentWithPolicies that extends
> SkinnableContainer, so UIComponent doesn't need to be altered.
@Alex or Carol do you know if there were any reason why
elementDestructionPolicy was added in UIComponent and not in a way as
Bogdan describes?
> Besides a bug about specifying width / height on AccordionContent that
> produces malfunction (never closes), the Accordion component seems
> compliant to pairing the MX one.
Yes .. until now I have the same impression that it brings everything
that the mx one does.
Just having some issue with the icon attribute I'm trying to figure out.
I haven't look at tink's source code yet just at his examples [1] ..
but I definitely look also at his source code.
If we choose the Accordion in adobe.next branch I would suggest following steps:
1) Moving all relevant classes to develop branch direct in spark
project (not experimental project).
2) Writing mustella tests for accordion.
Or would you prefer the experimental project?
[1]http://www.tink.ws/examples/apache-flex/
Re: Spark Accordion
Posted by Bogdan DINU <fl...@gmail.com>.
Hi all,
a while ago, I've looked over the Accordion from "adobe.next" branch,
having the same intention on my mind. What I found out is that they went
all the way down, modifying UIComponent to add elementCreationPolicy and
elementDestructionPolicy to the NavigatorContent, in order to make the
Accordion support creation and destruction policies.
Since Accordion component seems the only one who needs that, my approach
(which remained an experiment that I haven't had time to finish), was to
create a class named NavigatorContentWithPolicies that extends
SkinnableContainer, so UIComponent doesn't need to be altered.
Besides a bug about specifying width / height on AccordionContent that
produces malfunction (never closes), the Accordion component seems
compliant to pairing the MX one.
By the way, there is also a Spark ViewStack in that branch...
Best regards,
Bogdan
On Thu, Feb 28, 2013 at 7:42 PM, Frédéric THOMAS <we...@hotmail.com>wrote:
> Hi Cyrill,
>
> Thank you for pointing out the ones of Carol, I didn't know, I'll have a
> look ASAP.
> Few weeks ago I had a look at the Tink work, as well here [1] as here [2]
> and they look good, still have to be tested thought.
>
> I guess we could really investigate them and see if we could push some in
> the experimental lib.
>
> Btw, what about you Tink , do you still follow this list ?
>
> -Fred
>
> [1] http://tink.googlecode.com/**svn/trunk/flex4.5/spark/src/**
> ws/tink/spark/<http://tink.googlecode.com/svn/trunk/flex4.5/spark/src/ws/tink/spark/>
> [2] http://www.tink.ws/examples/**apache-flex/<http://www.tink.ws/examples/apache-flex/>
>
> -----Message d'origine----- From: Cyrill Zadra
> Sent: Thursday, February 28, 2013 6:12 AM
> To: dev@flex.apache.org
> Subject: Spark Accordion
>
>
> Hey
>
> I was looking for a Spark Accordion and found the one in tinks and
> cframpton whiteboard (branch adobe.next). I moved all the relevant
> classes from cframpon's adobe.next branch to my develop branch and
> after a couple of hours I had a working accordion and it looks great.
>
> Before I continue to do some work and tests on accordion I just wanted
> to ask if there is already a decision which accordion is going to be
> in apache flex? If not.. what needs to be done to have a decision.
>
> Cyrill
>
--
http://www.badu.ro
Re: Spark Accordion
Posted by Frédéric THOMAS <we...@hotmail.com>.
Hi Cyrill,
Thank you for pointing out the ones of Carol, I didn't know, I'll have a
look ASAP.
Few weeks ago I had a look at the Tink work, as well here [1] as here [2]
and they look good, still have to be tested thought.
I guess we could really investigate them and see if we could push some in
the experimental lib.
Btw, what about you Tink , do you still follow this list ?
-Fred
[1] http://tink.googlecode.com/svn/trunk/flex4.5/spark/src/ws/tink/spark/
[2] http://www.tink.ws/examples/apache-flex/
-----Message d'origine-----
From: Cyrill Zadra
Sent: Thursday, February 28, 2013 6:12 AM
To: dev@flex.apache.org
Subject: Spark Accordion
Hey
I was looking for a Spark Accordion and found the one in tinks and
cframpton whiteboard (branch adobe.next). I moved all the relevant
classes from cframpon's adobe.next branch to my develop branch and
after a couple of hours I had a working accordion and it looks great.
Before I continue to do some work and tests on accordion I just wanted
to ask if there is already a decision which accordion is going to be
in apache flex? If not.. what needs to be done to have a decision.
Cyrill
Re: Spark Accordion
Posted by Alex Harui <ah...@adobe.com>.
On 2/28/13 12:28 AM, "Om" <bi...@gmail.com> wrote:
> On Feb 27, 2013 9:12 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>>
>> Hey
>>
>> I was looking for a Spark Accordion and found the one in tinks and
>> cframpton whiteboard (branch adobe.next). I moved all the relevant
>> classes from cframpon's adobe.next branch to my develop branch and
>> after a couple of hours I had a working accordion and it looks great.
>>
>> Before I continue to do some work and tests on accordion I just wanted
>> to ask if there is already a decision which accordion is going to be
>> in apache flex? If not.. what needs to be done to have a decision.
>>
>> Cyrill
>
> Love this competition! Can you please post both the paths in SVN and
> perhaps we can take a poll after a good technical discussion? What do
> others think?
I'm pretty sure we don't have to have a competition or poll or technical
discussion. If Cyrill picks one and checks it into the develop branch then
the decision has been made unless there is an technical objection by a
commit reviewer. If you are worried that he made a bad decision, then it is
your responsibility to examine the alternatives and raise your objections.
Cyrill is wise to ask on the list first in case someone has used one of
these Accordions and already has a favorite, but if not, then it is his
call. But you are certainly welcome to study both and voice your own
opinion.
For me, I will assume he has made sure the one he chooses does most of what
MX Accordion does. I don't really care which one we choose.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Spark Accordion
Posted by Om <bi...@gmail.com>.
On Feb 27, 2013 9:12 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>
> Hey
>
> I was looking for a Spark Accordion and found the one in tinks and
> cframpton whiteboard (branch adobe.next). I moved all the relevant
> classes from cframpon's adobe.next branch to my develop branch and
> after a couple of hours I had a working accordion and it looks great.
>
> Before I continue to do some work and tests on accordion I just wanted
> to ask if there is already a decision which accordion is going to be
> in apache flex? If not.. what needs to be done to have a decision.
>
> Cyrill
Love this competition! Can you please post both the paths in SVN and
perhaps we can take a poll after a good technical discussion? What do
others think?