flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: The new Spark RichTextEditor
Date Fri, 26 Sep 2014 14:54:54 GMT
Hi Curtis,

That's great that you're willing to keep working on it.  There is no
hurry.  Almost everyone is contributing in their spare time.

I think VideoPlayer is a good example because it also composes other
sub-components in its skin.  Of course, there isn't any hard requirement
that you follow the Spark patterns and for every "rule" there are always
exceptions.

If you look at VideoPlayer's partAdded method, you'll see that it uses a
videoDisplayProperties "proxy" object.  IIRC, that's because properties
are often set on the component before the skin parts are added and
sometimes skins are changed at runtime so it is important to know which
properties need to be pushed down to the skin.  I believe the proxy object
pattern was adopted in order to save memory.  Since each property needs a
"changed" flag, the BitFlags allow for the "changed" flags to be stored in
a single bit instead of 32-bits.

You'll also see in VideoPlayer's partAdded that there are checks to handle
different skin parts being added in different orders.  I don't think you
can assume that the textArea skin part will be added first.  I noted that
the partAdded you proposed for RichTextEditor is mainly trying to assign a
textArea property to the skin parts.  IMO, you can avoid having to do that
by moving the "controller" or event handling code out of the tool widgets
and into the main component or a separate controller class.  VideoPlayer's
partAdded is mainly attaching event listeners to its tool widgets.  Now
there could definitely be some good reason to have it the way you proposed
it, but the "theory" is that if the event handling code is elsewhere the
skin could be more easily re-used for some other editor-like component.
Back in the Adobe days, the goal was to keep as much code out of the skins
as possible so Flash Catalyst and other Skin editors could enable
designers to customize the skin and not worry about breaking the logic.
Not sure how important that is now.

Anyway, looking forward to more patches.

Thanks,
-Alex

On 9/26/14 4:19 AM, "Curtis Aube" <curtis.aube@piematrix.com> wrote:

>Alex,
>
>I'm fine discussing it here. I can keep working on it, I just don't have
>a lot of time, so the turnaround may be slow.
>I'll have to take a look at the VideoPlayer code. In your notes, I may
>need more details on what you mean by proxy.
>
>Thanks,
>
>Curtis
>
>On Sep 25, 2014, at 4:28 PM, Alex Harui <aharui@adobe.com> wrote:
>
>> Hi Curtis,
>> 
>> I took a look at the patch.  Thanks for working on this.  I'm wondering
>>if
>> you still have time and energy to make further changes and whether you
>>are
>> still ok working in front of the large audience on this list or if you'd
>> prefer to just use JIRA which has fewer listeners.  Again, this thread
>>can
>> serve as an example for others interested in the patch process and how
>>it
>> can lead to getting committer rights.
>> 
>> I'll go into more detail if you're interested, but I put some notes down
>> below so I don't forget.  Most importantly, we are all volunteers so
>>there
>> is no requirement to keep putting in more time and effort, and I don't
>> want to make the process so strict that nobody wants to do it.
>> 
>> Let me know and thanks again,
>> -Alex
>> 
>> Notes:
>> -Should RichTextEditor follow more patterns and practices from
>>VideoPlayer?
>>   -Sub-components are also skinnable
>>   -Controller logic is not in the tool widgets
>> -PartAdded needs null checks in case skin parts arrive in different
>>orders.
>> -Proxy objects may be needed for exposed properties
>> 
>> On 9/24/14 7:10 AM, "Curtis Aube" <curtis.aube@piematrix.com> wrote:
>> 
>>> Alex,
>>> 
>>> Alright, I added a patch to the same ticket (FLEX-34476). The RTE now
>>> extends SkinnableComponent and includes a skin.
>>> I could put it on a new ticket if that is preferable, but I figured I
>>>put
>>> it there since that ticket is still open.
>>> Justin Mclean is assigned to the ticket.
>>> 
>>> Curtis
>>> 
>>> On Sep 8, 2014, at 12:29 PM, Alex Harui <aharui@adobe.com> wrote:
>>> 
>>>> Hi Curtis,
>>>> 
>>>> Sounds great.  Looking forward to another patch.
>>>> 
>>>> -Alex
>>>> 
>>>> On 9/8/14 8:13 AM, "Curtis Aube" <curtis.aube@piematrix.com> wrote:
>>>> 
>>>>> Alex,
>>>>> 
>>>>> It's seems that it should probably subclass SkinnableComponent as you
>>>>> suggest. It keeps more with the spirit of Spark.
>>>>> 
>>>>> I was actually planning on doing it but never got around to it. I was
>>>>> sitting on the code for a while and figured I would submit it as is
>>>>>and
>>>>> see if there was any demand for it before I spent the time to do it.
>>>>> 
>>>>> I'd be happy to work on making it skinnable.
>>>>> 
>>>>> Curtis
>>>>> 
>>>>> On Aug 29, 2014, at 11:19 AM, Alex Harui <aharui@adobe.com> wrote:
>>>>> 
>>>>>> Hey Curtis,
>>>>>> 
>>>>>> First off, thanks for contributing a Spark RichTextEditor component.
>>>>>> I'm
>>>>>> sure others will find it useful as well, and the process you went
>>>>>> through
>>>>>> (filing a JIRA [1], submitting patches, tweaking the code) will
>>>>>>serve
>>>>>> as a
>>>>>> good example for others who are wondering how to contribute to
>>>>>>Apache
>>>>>> Flex.
>>>>>> 
>>>>>> I looked over the code the other day, and I have a question for you.
>>>>>> I'm
>>>>>> asking on the mailing list instead of directly in the JIRA so folks
>>>>>> who
>>>>>> don't normally watch JIRA can participate in the discussion as well.
>>>>>> 
>>>>>> The question is: What factored into the decision to write Spark
>>>>>> RichTextEditor in ActionScript and subclass Group?  I saw that part
>>>>>>of
>>>>>> the
>>>>>> reason is that you were having trouble adding an MXML component to
>>>>>>the
>>>>>> Spark namespace.  But IMO, even if we work that out, there are at
>>>>>> least
>>>>>> two choices: 1) write it in MXML like the MX RichTextEditor, and
2)
>>>>>> Write
>>>>>> it in AS and subclass SkinnableComponent.
>>>>>> 
>>>>>> IMO, the MX RichTextEditor was written in MXML to make it easy to
>>>>>> reconfigure the UI.  And in Spark, reconfiguration of the UI is
>>>>>> generally
>>>>>> done in the Skin which would then be a reason to subclass
>>>>>> SkinnableComponent.  Opinion from others is welcome here: if you
>>>>>>were
>>>>>> to
>>>>>> use Spark RichTextEditor would you rather just copy and tweak an
>>>>>>MXML
>>>>>> file, or use the skinning workflow?
>>>>>> 
>>>>>> Also, let us know if you have the cycles to keep making improvements
>>>>>> to
>>>>>> this component.  As this is open-source, others can always pitch
in
>>>>>>to
>>>>>> help, not only on this component, but any code in the project.  And
>>>>>> contributing code is a common way one becomes a committer on the
>>>>>> project
>>>>>> (which is generally a valuable thing to your employers and/or
>>>>>> clients),
>>>>>> although there is no guarantee.
>>>>>> 
>>>>>> Thanks,
>>>>>> -Alex
>>>>>> 
>>>>>> [1] https://issues.apache.org/jira/browse/FLEX-34476
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>


Mime
View raw message