You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2017/06/05 03:25:14 UTC
[FlexJS] Removing PasswordInputBead has no effect
Hi,
I just run into an issue with removing the PasswordInputBead when removed the text in the input field was still stared out / hidden.
The way to fix is is the set the strand to null on removing the bead and then having the PasswordInputBead reset the input type to “text" when null is passed into the stand setter.
I've done this and pushed up to develop. This was discussed on the list before (when I added the CORS bead) as the way to fix this but if there's a better way to do fix this please suggest so.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Alex Harui <ah...@adobe.com.INVALID>.
It can't be done in a subclass with an override of the strand setter?
-Alex
On 6/4/17, 8:55 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> I would recommend handling removal in an enhanced bead, maybe call it
>> RemovablePasswordInputBead. Not everybody will need to remove the bead
>>so
>> PAYG would say to offer folks the original and your version.
>
>I’d prefer not to.
>
>There is no extra PAYG cost on the AS side and a null check on the JS
>side.
>
>Copy and pasting 100 lines of code to a new class just to make those
>simple changes doesn't seem like PAYG to me. What do other people think?
>
>Thanks,
>Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Actually, the fix can probably be simplified to replacing the original:
> e.type = 'password’;
> with
> e.type = value ? 'password' : 'text’;
Not quite as in one case e is derived from the the TextInput passed in, the other it’s derived from the existing stand as null is passed in.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Harbs <ha...@gmail.com>.
Actually, the fix can probably be simplified to replacing the original:
e.type = 'password’;
with
e.type = value ? 'password' : 'text’;
I’m personally ok with keeping that change in the original bead.
> On Jun 5, 2017, at 7:15 AM, Harbs <ha...@gmail.com> wrote:
>
> The removal code doubles the practical size of the bead. Definitely not PAYG.
>
> Subclassing the bead and overidding set strand on JS or creating a new one is definitely the way to go.
>
> Harbs
>
>> On Jun 5, 2017, at 6:55 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>>
>> Hi,
>>
>>> I would recommend handling removal in an enhanced bead, maybe call it
>>> RemovablePasswordInputBead. Not everybody will need to remove the bead so
>>> PAYG would say to offer folks the original and your version.
>>
>> I’d prefer not to.
>>
>> There is no extra PAYG cost on the AS side and a null check on the JS side.
>>
>> Copy and pasting 100 lines of code to a new class just to make those simple changes doesn't seem like PAYG to me. What do other people think?
>>
>> Thanks,
>> Justin
>
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by piotrz <pi...@gmail.com>.
Something cutted my email.
If the answer to that question is yes - Let's have it.
That is how I'm thinking about FlexJS.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62119.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by piotrz <pi...@gmail.com>.
Hi,
Ahh I saw your commit and respond to it, but somehow miss this discussion.
It seems to be again different thoughts and view of what is PAYG.
PAYG for me is:
Whenever I can extract something (code - one thing) into separate class
called - Bead - which can be reusable or switch ON/OFF something in my
component.
The question is: Can you extract this part of code into separate class ?
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62116.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by piotrz <pi...@gmail.com>.
I think because this bead after your changes is doing two things and you can
split responsibility to the other class. - Is it enough reasonable ?
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62158.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> What’s not clear once you read that doc?
It’s unclear to me why the code I checked in isn’t PAYG as it fits with the definition of PAYG in that document.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Harbs <ha...@gmail.com>.
The definition is fine. The fact that it’s 4 years old is irrelevant.
What’s not clear once you read that doc?
Please just revert your changes and make a new bead. There’s no reason to have so much discussion on this…
> On Jun 6, 2017, at 11:18 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> Imposing your different opinion in others is not the Apache Way.
>
> How am I’m imposing anything here Alex? It is you that's instating that just in time code that follows the PAYG principal as documented and that has zero practical overhead is not PAYG.
>
> From my understanding several people are unclear of what PAYG actually is and there are several differing options on what it is. Perhaps the definition that you pointed to needs to be updated as you said it is 4 years old.
>
> Wouldn’t it be best to document it so we can all be on the same page?
>
> Thanks,
> Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Imposing your different opinion in others is not the Apache Way.
How am I’m imposing anything here Alex? It is you that's instating that just in time code that follows the PAYG principal as documented and that has zero practical overhead is not PAYG.
From my understanding several people are unclear of what PAYG actually is and there are several differing options on what it is. Perhaps the definition that you pointed to needs to be updated as you said it is 4 years old.
Wouldn’t it be best to document it so we can all be on the same page?
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I didn't say it was my project. Just my vision. And for the past 4
years, others seem to share it. I believe that is consensus. Bertrand
advised us many years ago to make things modular, which FlexJS is, so
folks with different opinions can go implement their opinion in a
different module. That is the Apache Way.
Imposing your different opinion in others is not the Apache Way.
Thanks,
-Alex
On 6/5/17, 3:16 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> If you have a different vision, you can execute that vision in another
>> component set or fork FlexJS entirely. Please do not impose your vision
>> on my vision.
>
>Since when is this your project Alex or that the project has to only
>include your vision? That is not the Apache way.
>
>I would prefer that we all come to a consensus of what PAYG means and
>clearly document it rather that you dictating it.
>
>Thanks,
>Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by piotrz <pi...@gmail.com>.
Another thing - How to resolve this thread ?
1) Setting strand to null - let say that is fine and there is no NO for that
- Am I right ?
2) Some code which maybe can be extracted to separate bead.
For 2 I have an ide:
1 - Revert back
2 - Create Separate bead for cleaning
3 - Create in Express bead which has everything what Justin add.
Would it be satisfactory ?
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62129.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by piotrz <pi...@gmail.com>.
Om,
You mean subclass current bead and have new functionality in the other ? If
yes I'm OK.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62223.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
So you would then understand that it may take a day or two to get things done. The first email was at 9am my time, your email was at 5pm my time, during those hours I have a day job, and I while I may respond to email I generally don't work on Flex during 9-5 while on day job. Have you for instance seen any other checkins from me today? It was first on my list of things to do, so thanks for doing it, but next time would you mind waiting at least 24 hours.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Harbs <ha...@gmail.com>.
Neither do I.
> On Jun 8, 2017, at 9:58 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> I did say I would do it in my last email. Please remember I don't work full time on Apache Flex and I’m in a different time zone.
>
> Thanks,
> Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I did say I would do it in my last email. Please remember I don't work full time on Apache Flex and I’m in a different time zone.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Harbs <ha...@gmail.com>.
This is simply insanity. Discussing a simple change ad nuaseum is a colossal waste of time.
Instead of perpetuating this discussion, I just made the change myself. Use the new PasswordInputRemovableBead if you want to remove password input functionality.
Let’s move on.
Harbs
> On Jun 8, 2017, at 2:00 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> That wont be breaking PAYG. The basic idea is to avoid loading/running
>> unnecessary code during runtime. Altering a class support subclassing
>> should be fine.
>
> Which the modified version does and would comply with that definition of PAYG - unless you think a single null check is anti PAYG.
>
> This is why I been asking for a clear definition of PAYG and it certainly has generated some useful dicussion.
>
>> Looks like there is consensus on the subclassing route. Let's go with that and solve
>> subsequent problems as they arise.
>
> Sure.
>
> Thanks,
> Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> That wont be breaking PAYG. The basic idea is to avoid loading/running
> unnecessary code during runtime. Altering a class support subclassing
> should be fine.
Which the modified version does and would comply with that definition of PAYG - unless you think a single null check is anti PAYG.
This is why I been asking for a clear definition of PAYG and it certainly has generated some useful dicussion.
> Looks like there is consensus on the subclassing route. Let's go with that and solve
> subsequent problems as they arise.
Sure.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Jun 7, 2017 at 3:41 PM, Justin Mclean <ju...@classsoftware.com>
wrote:
> HI,
>
> > "It can't be done in a subclass with
> > an override of the strand setter?
>
> Probably not without altering the original bead which may also be not PAYG.
>
That wont be breaking PAYG. The basic idea is to avoid loading/running
unnecessary code during runtime. Altering a class support subclassing
should be fine.
We are in what some would call an 'analysis paralysis' state. Looks like
there is consensus on the subclassing route. Let's go with that and solve
subsequent problems as they arise.
Thanks,
Om
>
> Thanks,
> Justin
>
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> "It can't be done in a subclass with
> an override of the strand setter?
Probably not without altering the original bead which may also be not PAYG.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Alex Harui <ah...@adobe.com.INVALID>.
This will make the 38th post on this thread. It is a link to the 4th post
on this thread:
https://lists.apache.org/thread.html/8f561b811d2e662769f204200eabe8bc706d97
b19f8859fe74ee9b3b@%3Cdev.flex.apache.org%3E
"It can't be done in a subclass with
an override of the strand setter?
-Alex"
4 people (Piotr, Harbs, Om, me) have asked you to rework the bead. Please
do so.
Thanks,
-Alex
On 6/7/17, 2:06 AM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>It seems subclass is the way to go here. Anyone disagree with that?
>
>Thanks,
>Om
>
>On Jun 7, 2017 1:57 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>> Hi,
>>
>> I'm still awaiting answers from Alex and further discussion on what PAYG
>> is and isn’t and will resolve in accordance to that.
>>
>> Thanks,
>> Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by OmPrakash Muppirala <bi...@gmail.com>.
It seems subclass is the way to go here. Anyone disagree with that?
Thanks,
Om
On Jun 7, 2017 1:57 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
> I'm still awaiting answers from Alex and further discussion on what PAYG
> is and isn’t and will resolve in accordance to that.
>
> Thanks,
> Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by ju...@classsoftware.com.
Hi,
And nothing is broken in develop and a new release (after this one) is a long way away so there’s no huge urgency here. I do intended to correct it once the discussion has died down and PAYG is clearly documented.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I'm still awaiting answers from Alex and further discussion on what PAYG is and isn’t and will resolve in accordance to that.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by piotrz <pi...@gmail.com>.
Agree with Om. I also do not wanna to leave this thread without any action.
In whatever direction it will go.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62213.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The wiki from 4 years ago is very helpful in understanding architectural decisions:
> https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype <https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype> <https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype <https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype>>
The code I checked is as far a I can tell in line with the principal as described there:
"Everything should be "pay as you go" or "just in time" or "on demand". The current Flex framework is slow because it runs a lot of code "just-in-case". For example most mobile apps initialize a PopupManager. And other code sets up a layer for custom cursors. No need to do that unless you are really going to use it.”
There's no extra initialisation and the cost of removing the password feature is on demand.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Harbs <ha...@gmail.com>.
The wiki from 4 years ago is very helpful in understanding architectural decisions:
https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype <https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype>
If you have suggestions to make things clearer then by all means suggest something.
Thanks,
Harbs
> On Jun 6, 2017, at 9:33 AM, Greg Dove <gr...@gmail.com> wrote:
>
> Harbs, a quick comment from the sidelines on: "PAYG is already well
> understood"
>
> I don't really think that is the case, at least it has not been for me. I
> had a more general notion of PAYG that was nothing to do with beads at all,
> and was limited to guesswork/my own interpretation of it at the beginning
> because there was no clear definition.
>
> Unless this is documented somewhere then I believe it is actually a barrier
> (of understanding) for people getting involved. If there's already a
> difficulty with 'thinking this way' and 'acting this way' as you indicated
> when you had started and had understood it, then it seems important that it
> should also be easily understood in the first place in order to make things
> easier for people wanting to participate.
>
> As with a lot of things, once you 'know' it you can tend to take if for
> granted that everyone else does too. But I think you already hinted at that
> with what you said...
>
> I am of the opinion that 'vision', 'mission', 'goals' and even
> 'architecture' etc don't really exist in a form that is useful for shared
> understanding unless they are documented in some way. And no, 'it's obvious
> from the source code' is not what I mean :).
> They are not considered to do so in many other scenarios, in any case, and
> I can't understand why it would be different in an open source project,
> although I definitely have not spent time comparing projects to find out
> what others do here.
>
>
> On Tue, Jun 6, 2017 at 5:21 PM, Harbs <ha...@gmail.com> wrote:
>
>> We’ve all already been implementing things as Alex states. He architected
>> the framework and it’s a good architecture. No need to change things. We
>> need consistent architecture. We can’t have a free-for-all...
>>
>> Percentage of code really has nothing to do with it. Unless something is
>> functionality that you would (virtually) always need, it’s a separate bead.
>> That’s the way the whole SDK is implemented. If there are cases where it’s
>> not, it’s a bug and should be fixed. Removal of password functionality is
>> NOT usually required for password beads.
>>
>> PAYG is already well understood: All functionality should be implemented
>> as beads when practical. Beads should be as modular as possible with the
>> smallest possible functional set.
>>
>> That’s pretty much it. It’s difficult to make the mental switch to working
>> this way. I had similar difficulty when I started implementing things for
>> FlexJS. It takes some getting used to, but it’s a very good design.
>>
>> Harbs
>>
>>> On Jun 6, 2017, at 1:16 AM, Justin Mclean <ju...@classsoftware.com>
>> wrote:
>>>
>>> Hi,
>>>
>>>> If you have a different vision, you can execute that vision in another
>>>> component set or fork FlexJS entirely. Please do not impose your vision
>>>> on my vision.
>>>
>>> Since when is this your project Alex or that the project has to only
>> include your vision? That is not the Apache way.
>>>
>>> I would prefer that we all come to a consensus of what PAYG means and
>> clearly document it rather that you dictating it.
>>>
>>> Thanks,
>>> Justin
>>
>>
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Harbs <ha...@gmail.com>.
That would be great.
Harbs
> On Jun 6, 2017, at 10:24 PM, Greg Dove <gr...@gmail.com> wrote:
>
> If no-one else volunteers to wiki-fy the contents of the new thread at its conclusion, I will give it a shot over the coming weekend.
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by OmPrakash Muppirala <bi...@gmail.com>.
Justin,
Do you now have sufficient info on the PAYG paradigm to resolve this issue?
When you re-read Alex and Harbs' suggestions now, does it make sense?
I suggest we fix this issue and move on, please.
Thanks,
Om
On Jun 6, 2017 5:22 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
Hi,
> Actually I will have definitely looked through this early on, but I'd
have to say it is quite 'light' on what PAYG actually means beyond the
general sense that I had.
I’d go further as say the definition as it is stated there seem to be
perhaps too wide?
> But I can see that the newly created 'DRY' discussion thread is actually
creating the type of content that I think I would have found really helpful
in terms of linking a guiding concept to one of its key implementation
areas.
+1 to that
> If there's that level of clarity and, ultimately, agreement in terms of
definitions and approaches, I expect there will be far less need for
threads like this one.
Al +1 to that. We can also point new people to it rather than trying to
explain the concept(s) again saving everyone time.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Actually I will have definitely looked through this early on, but I'd have to say it is quite 'light' on what PAYG actually means beyond the general sense that I had.
I’d go further as say the definition as it is stated there seem to be perhaps too wide?
> But I can see that the newly created 'DRY' discussion thread is actually creating the type of content that I think I would have found really helpful in terms of linking a guiding concept to one of its key implementation areas.
+1 to that
> If there's that level of clarity and, ultimately, agreement in terms of definitions and approaches, I expect there will be far less need for threads like this one.
Al +1 to that. We can also point new people to it rather than trying to explain the concept(s) again saving everyone time.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Greg Dove <gr...@gmail.com>.
Alex, and Harbs,
Thanks for pointing that out. Actually I will have defifintely looked through this early on, but I'd have to say it is quite 'light' on what PAYG actually means beyond the general sense that I had. It does have some more detail about beads which is great and I could have benefited from revisiting that in recent months which I did not do.
But I can see that the newly created 'DRY' discussion thread is actually creating the type of content that I think I would have found really helpful in terms of linking a guiding concept to one of its key implementation areas.
Creating this type of documentation is *hard*. Not just because creating the content itself is a lot of work, But also because it is not (usually I think) something that a developer wants to do, especially when volunteering their time. "I'd much rather be coding". So thanks Alex for what you already created there.
However, I think the contents of the new thread look really good as something that could be used as a resource to define bead variation in terms of PAYG adherence, as an implementation guide, and I do think we really need this.
If there's that level of clarity and, ultimately, agreement in terms of definitions and approaches, I expect there will be far less need for threads like this one.
If no-one else volunteers to wiki-fy the contents of the new thread at its conclusion, I will give it a shot over the coming weekend.
On 2017-06-06 18:55 (+1200), Alex Harui <ah...@adobe.com.INVALID> wrote:
> This was first published in 2012.
>
> https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
>
> PAYG and avoiding just-in-case code is mentioned in that document. As are
> Beads.
>
> Thanks,
> -Alex
>
> On 6/5/17, 11:33 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> >Harbs, a quick comment from the sidelines on: "PAYG is already well
> >understood"
> >
> >I don't really think that is the case, at least it has not been for me. I
> >had a more general notion of PAYG that was nothing to do with beads at
> >all,
> >and was limited to guesswork/my own interpretation of it at the beginning
> >because there was no clear definition.
> >
> >Unless this is documented somewhere then I believe it is actually a
> >barrier
> >(of understanding) for people getting involved. If there's already a
> >difficulty with 'thinking this way' and 'acting this way' as you indicated
> >when you had started and had understood it, then it seems important that
> >it
> >should also be easily understood in the first place in order to make
> >things
> >easier for people wanting to participate.
> >
> >As with a lot of things, once you 'know' it you can tend to take if for
> >granted that everyone else does too. But I think you already hinted at
> >that
> >with what you said...
> >
> >I am of the opinion that 'vision', 'mission', 'goals' and even
> >'architecture' etc don't really exist in a form that is useful for shared
> >understanding unless they are documented in some way. And no, 'it's
> >obvious
> >from the source code' is not what I mean :).
> >They are not considered to do so in many other scenarios, in any case, and
> >I can't understand why it would be different in an open source project,
> >although I definitely have not spent time comparing projects to find out
> >what others do here.
> >
> >
> >On Tue, Jun 6, 2017 at 5:21 PM, Harbs <ha...@gmail.com> wrote:
> >
> >> Weâve all already been implementing things as Alex states. He
> >>architected
> >> the framework and itâs a good architecture. No need to change things. We
> >> need consistent architecture. We canât have a free-for-all...
> >>
> >> Percentage of code really has nothing to do with it. Unless something is
> >> functionality that you would (virtually) always need, itâs a separate
> >>bead.
> >> Thatâs the way the whole SDK is implemented. If there are cases where
> >>itâs
> >> not, itâs a bug and should be fixed. Removal of password functionality
> >>is
> >> NOT usually required for password beads.
> >>
> >> PAYG is already well understood: All functionality should be implemented
> >> as beads when practical. Beads should be as modular as possible with the
> >> smallest possible functional set.
> >>
> >> Thatâs pretty much it. Itâs difficult to make the mental switch to
> >>working
> >> this way. I had similar difficulty when I started implementing things
> >>for
> >> FlexJS. It takes some getting used to, but itâs a very good design.
> >>
> >> Harbs
> >>
> >> > On Jun 6, 2017, at 1:16 AM, Justin Mclean <ju...@classsoftware.com>
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> >> If you have a different vision, you can execute that vision in
> >>another
> >> >> component set or fork FlexJS entirely. Please do not impose your
> >>vision
> >> >> on my vision.
> >> >
> >> > Since when is this your project Alex or that the project has to only
> >> include your vision? That is not the Apache way.
> >> >
> >> > I would prefer that we all come to a consensus of what PAYG means and
> >> clearly document it rather that you dictating it.
> >> >
> >> > Thanks,
> >> > Justin
> >>
> >>
>
>
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Alex Harui <ah...@adobe.com.INVALID>.
This was first published in 2012.
https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
PAYG and avoiding just-in-case code is mentioned in that document. As are
Beads.
Thanks,
-Alex
On 6/5/17, 11:33 PM, "Greg Dove" <gr...@gmail.com> wrote:
>Harbs, a quick comment from the sidelines on: "PAYG is already well
>understood"
>
>I don't really think that is the case, at least it has not been for me. I
>had a more general notion of PAYG that was nothing to do with beads at
>all,
>and was limited to guesswork/my own interpretation of it at the beginning
>because there was no clear definition.
>
>Unless this is documented somewhere then I believe it is actually a
>barrier
>(of understanding) for people getting involved. If there's already a
>difficulty with 'thinking this way' and 'acting this way' as you indicated
>when you had started and had understood it, then it seems important that
>it
>should also be easily understood in the first place in order to make
>things
>easier for people wanting to participate.
>
>As with a lot of things, once you 'know' it you can tend to take if for
>granted that everyone else does too. But I think you already hinted at
>that
>with what you said...
>
>I am of the opinion that 'vision', 'mission', 'goals' and even
>'architecture' etc don't really exist in a form that is useful for shared
>understanding unless they are documented in some way. And no, 'it's
>obvious
>from the source code' is not what I mean :).
>They are not considered to do so in many other scenarios, in any case, and
>I can't understand why it would be different in an open source project,
>although I definitely have not spent time comparing projects to find out
>what others do here.
>
>
>On Tue, Jun 6, 2017 at 5:21 PM, Harbs <ha...@gmail.com> wrote:
>
>> We’ve all already been implementing things as Alex states. He
>>architected
>> the framework and it’s a good architecture. No need to change things. We
>> need consistent architecture. We can’t have a free-for-all...
>>
>> Percentage of code really has nothing to do with it. Unless something is
>> functionality that you would (virtually) always need, it’s a separate
>>bead.
>> That’s the way the whole SDK is implemented. If there are cases where
>>it’s
>> not, it’s a bug and should be fixed. Removal of password functionality
>>is
>> NOT usually required for password beads.
>>
>> PAYG is already well understood: All functionality should be implemented
>> as beads when practical. Beads should be as modular as possible with the
>> smallest possible functional set.
>>
>> That’s pretty much it. It’s difficult to make the mental switch to
>>working
>> this way. I had similar difficulty when I started implementing things
>>for
>> FlexJS. It takes some getting used to, but it’s a very good design.
>>
>> Harbs
>>
>> > On Jun 6, 2017, at 1:16 AM, Justin Mclean <ju...@classsoftware.com>
>> wrote:
>> >
>> > Hi,
>> >
>> >> If you have a different vision, you can execute that vision in
>>another
>> >> component set or fork FlexJS entirely. Please do not impose your
>>vision
>> >> on my vision.
>> >
>> > Since when is this your project Alex or that the project has to only
>> include your vision? That is not the Apache way.
>> >
>> > I would prefer that we all come to a consensus of what PAYG means and
>> clearly document it rather that you dictating it.
>> >
>> > Thanks,
>> > Justin
>>
>>
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Greg Dove <gr...@gmail.com>.
Harbs, a quick comment from the sidelines on: "PAYG is already well
understood"
I don't really think that is the case, at least it has not been for me. I
had a more general notion of PAYG that was nothing to do with beads at all,
and was limited to guesswork/my own interpretation of it at the beginning
because there was no clear definition.
Unless this is documented somewhere then I believe it is actually a barrier
(of understanding) for people getting involved. If there's already a
difficulty with 'thinking this way' and 'acting this way' as you indicated
when you had started and had understood it, then it seems important that it
should also be easily understood in the first place in order to make things
easier for people wanting to participate.
As with a lot of things, once you 'know' it you can tend to take if for
granted that everyone else does too. But I think you already hinted at that
with what you said...
I am of the opinion that 'vision', 'mission', 'goals' and even
'architecture' etc don't really exist in a form that is useful for shared
understanding unless they are documented in some way. And no, 'it's obvious
from the source code' is not what I mean :).
They are not considered to do so in many other scenarios, in any case, and
I can't understand why it would be different in an open source project,
although I definitely have not spent time comparing projects to find out
what others do here.
On Tue, Jun 6, 2017 at 5:21 PM, Harbs <ha...@gmail.com> wrote:
> We’ve all already been implementing things as Alex states. He architected
> the framework and it’s a good architecture. No need to change things. We
> need consistent architecture. We can’t have a free-for-all...
>
> Percentage of code really has nothing to do with it. Unless something is
> functionality that you would (virtually) always need, it’s a separate bead.
> That’s the way the whole SDK is implemented. If there are cases where it’s
> not, it’s a bug and should be fixed. Removal of password functionality is
> NOT usually required for password beads.
>
> PAYG is already well understood: All functionality should be implemented
> as beads when practical. Beads should be as modular as possible with the
> smallest possible functional set.
>
> That’s pretty much it. It’s difficult to make the mental switch to working
> this way. I had similar difficulty when I started implementing things for
> FlexJS. It takes some getting used to, but it’s a very good design.
>
> Harbs
>
> > On Jun 6, 2017, at 1:16 AM, Justin Mclean <ju...@classsoftware.com>
> wrote:
> >
> > Hi,
> >
> >> If you have a different vision, you can execute that vision in another
> >> component set or fork FlexJS entirely. Please do not impose your vision
> >> on my vision.
> >
> > Since when is this your project Alex or that the project has to only
> include your vision? That is not the Apache way.
> >
> > I would prefer that we all come to a consensus of what PAYG means and
> clearly document it rather that you dictating it.
> >
> > Thanks,
> > Justin
>
>
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by piotrz <pi...@gmail.com>.
Hi Justin,
Agree with you that we may not everywhere applying in PAYG manner, probably
you will find more examples, but there is no point to do this. I think you
can just try to fix that, cause that's what for we are here I think. :)
I'm done with those discussion in case of changes with that Bead - don't
want to fight about those couple of lines. You fix one general bug I think
here apart of changes in that Bead - That's good! Thank you for that!
We really need to have some system of micro voting maybe when discussion
ends up on different thoughts and then die without any action or decision.
As you probably see in my previous post I was trying to summarize everything
and propose something, but again discussion towards to different direction.
We have on the plate more such discussion and I really do not know how to
end up them in order to have - "Ok we agreed how to do this - let's
implement!" - Maybe discuss my concerns in the other thread please.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62146.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Josh Tynjala <jo...@gmail.com>.
The way that beads work means that we will frequently "violate" DRY, as I
understand it. FlexJS is designed to have multiple beads that implement the
same thing in different ways. The simplest bead will be designed to be
never removed and it probably won't include any properties to configure its
behavior. A more complex bead might include some of the same code from the
simplest bead, but it will also be designed to be removed, but still not
configured. An even more complex bead will include all three (the core
feature, removal, and properties to configure). There might even be a
fourth one that can't be removed, but has properties to configure. Going
even further, there might even be variations with different subsets of
properties that can be configured.
Ideally, we'd find a way to reuse some of the code from the simpler beads.
It might be possible to subclass them, for instance. However, unless the
simplest beads are designed for it, reusing their code may not be possible.
In fact, designing them in a way that they can be extended may violate PAYG
instead because it may require adding code that isn't always needed. In
that case, there's no option except to repeat some code.
- Josh
On Tue, Jun 6, 2017 at 12:02 AM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Unless something is functionality that you would (virtually) always
> need, it’s a separate bead.
>
> So for CCS we have border, does everyone need borders? Why do we only a
> sub set of the font attributes included? Some people are not going to use
> all of them or in fact any of them and some other may need other properties
> so why are they not seperate? Not that I think these should be removed
> into seperate parts. The issue is just about every feature you can name is
> going to optional to someone. So I think we near a clearer definition of
> what PAYG is.
>
> Another example why for instance was flexGrow and flexShrink added in to
> the CSS code? Shouldn't they be implemented in line with the PAYG principal
> in another class? And there are numerous other examples of this. I feel
> that PAYG is not being applied consistently and seems selective on who is
> making the contribution.
>
> > PAYG is already well understood
>
> IMO it has not been clearly defined. Alex has described in various ways as
> it size / runtime cost only to move to goal posts. I for one would like a
> clearer definition of it.
>
> > All functionality should be implemented as beads when practical. Beads
> should be as modular as possible with the smallest possible functional set.
>
> What about the cost of violating DRY or the single responsibility
> principal which two beads do similar things? Is it really OK to add
> technical debt / penalise users of a new feature when it would be less cost
> modifying/improving an existing bead at a much smaller cost? How do you
> discourage copy paste coding?
>
> Thanks,
> Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Unless something is functionality that you would (virtually) always need, it’s a separate bead.
So for CCS we have border, does everyone need borders? Why do we only a sub set of the font attributes included? Some people are not going to use all of them or in fact any of them and some other may need other properties so why are they not seperate? Not that I think these should be removed into seperate parts. The issue is just about every feature you can name is going to optional to someone. So I think we near a clearer definition of what PAYG is.
Another example why for instance was flexGrow and flexShrink added in to the CSS code? Shouldn't they be implemented in line with the PAYG principal in another class? And there are numerous other examples of this. I feel that PAYG is not being applied consistently and seems selective on who is making the contribution.
> PAYG is already well understood
IMO it has not been clearly defined. Alex has described in various ways as it size / runtime cost only to move to goal posts. I for one would like a clearer definition of it.
> All functionality should be implemented as beads when practical. Beads should be as modular as possible with the smallest possible functional set.
What about the cost of violating DRY or the single responsibility principal which two beads do similar things? Is it really OK to add technical debt / penalise users of a new feature when it would be less cost modifying/improving an existing bead at a much smaller cost? How do you discourage copy paste coding?
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Harbs <ha...@gmail.com>.
We’ve all already been implementing things as Alex states. He architected the framework and it’s a good architecture. No need to change things. We need consistent architecture. We can’t have a free-for-all...
Percentage of code really has nothing to do with it. Unless something is functionality that you would (virtually) always need, it’s a separate bead. That’s the way the whole SDK is implemented. If there are cases where it’s not, it’s a bug and should be fixed. Removal of password functionality is NOT usually required for password beads.
PAYG is already well understood: All functionality should be implemented as beads when practical. Beads should be as modular as possible with the smallest possible functional set.
That’s pretty much it. It’s difficult to make the mental switch to working this way. I had similar difficulty when I started implementing things for FlexJS. It takes some getting used to, but it’s a very good design.
Harbs
> On Jun 6, 2017, at 1:16 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> If you have a different vision, you can execute that vision in another
>> component set or fork FlexJS entirely. Please do not impose your vision
>> on my vision.
>
> Since when is this your project Alex or that the project has to only include your vision? That is not the Apache way.
>
> I would prefer that we all come to a consensus of what PAYG means and clearly document it rather that you dictating it.
>
> Thanks,
> Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by piotrz <pi...@gmail.com>.
+1 for documenting it and stick with it.
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62128.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> If you have a different vision, you can execute that vision in another
> component set or fork FlexJS entirely. Please do not impose your vision
> on my vision.
Since when is this your project Alex or that the project has to only include your vision? That is not the Apache way.
I would prefer that we all come to a consensus of what PAYG means and clearly document it rather that you dictating it.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 6/4/17, 9:46 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>Sorry autocorrect seems to have got the better of me - correcting:
>
>I think you are forgetting the optimisation that goes on, yes the source
>code has a few more lines of code, but hardly double the size.
>
>Perhaps we can come up with some rules/guildlines to what PAYG actually
>is? Say no more than 5% or 10% final size or runtime cost?
Since November of 2012, my vision has been to make it possible to
eliminate all just-in-case code from a FlexJS customer's application.
Sure, that may not be 100% achievable, but I want everyone to be role
models for how this is attempted. No matter how you measure it, you have
added just-in-case code for those who don't need to remove the
PasswordInputBead. The vision has been to offer customers choices of
beads.
If we instead model that we can ignore this vision and just add 7% or 2%,
we will just be repeating the same mistake we made in regular Flex and
over time, FlexJS will be just as fat and slow as regular Flex. I can't
tell you how many times we said in regular Flex "this is only adds a
little bit of code". But when customers started rejecting Flex because it
couldn't run as fast and small as they needed, we lost our chance to be
part of solutions that people couldn't live without.
If you have a different vision, you can execute that vision in another
component set or fork FlexJS entirely. Please do not impose your vision
on my vision.
Thanks,
-Alex
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Sorry autocorrect seems to have got the better of me - correcting:
I think you are forgetting the optimisation that goes on, yes the source code has a few more lines of code, but hardly double the size.
Perhaps we can come up with some rules/guildlines to what PAYG actually is? Say no more than 5% or 10% final size or runtime cost?
In this case the code has zero cost re final size or practical runtime performance (and extra null check on the JS side) and zero cost on the AS side.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by ju...@classsoftware.com.
Hi,
> Both the original version and my JS compile down to to same size of 92 bytes. The unzipped versions differ by 2% with my version being slighter larger. The AS versions are identical.
Even with simple optimisation (i.e. no code optimised out or renamed) the size increase is 7%.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The removal code doubles the practical size of the bead. Definitely not PAYG.
I think you are forging the optimisation that goes so, yes the source code has a few moraines of code, but hardly double the size. So sorry to say that that an exaggeration and frankly incorrect.
Both the original version and my JS compile down to to same size of 92 bytes. The unzipped versions differ by 2% with my version being slighter larger. The AS versions are identical.
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Harbs <ha...@gmail.com>.
The removal code doubles the practical size of the bead. Definitely not PAYG.
Subclassing the bead and overidding set strand on JS or creating a new one is definitely the way to go.
Harbs
> On Jun 5, 2017, at 6:55 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> I would recommend handling removal in an enhanced bead, maybe call it
>> RemovablePasswordInputBead. Not everybody will need to remove the bead so
>> PAYG would say to offer folks the original and your version.
>
> I’d prefer not to.
>
> There is no extra PAYG cost on the AS side and a null check on the JS side.
>
> Copy and pasting 100 lines of code to a new class just to make those simple changes doesn't seem like PAYG to me. What do other people think?
>
> Thanks,
> Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I would recommend handling removal in an enhanced bead, maybe call it
> RemovablePasswordInputBead. Not everybody will need to remove the bead so
> PAYG would say to offer folks the original and your version.
I’d prefer not to.
There is no extra PAYG cost on the AS side and a null check on the JS side.
Copy and pasting 100 lines of code to a new class just to make those simple changes doesn't seem like PAYG to me. What do other people think?
Thanks,
Justin
Re: [FlexJS] Removing PasswordInputBead has no effect
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I would recommend handling removal in an enhanced bead, maybe call it
RemovablePasswordInputBead. Not everybody will need to remove the bead so
PAYG would say to offer folks the original and your version.
Thanks,
-Alex
On 6/4/17, 8:25 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>I just run into an issue with removing the PasswordInputBead when removed
>the text in the input field was still stared out / hidden.
>
>The way to fix is is the set the strand to null on removing the bead and
>then having the PasswordInputBead reset the input type to “text" when
>null is passed into the stand setter.
>
>I've done this and pushed up to develop. This was discussed on the list
>before (when I added the CORS bead) as the way to fix this but if there's
>a better way to do fix this please suggest so.
>
>Thanks,
>Justin
>