[FlexJS] Removing PasswordInputBead has no effect

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
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

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Alex Harui-2
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" <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Alex Harui-2
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" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Harbs
In reply to this post by Justin Mclean
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Harbs
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 <[hidden email]> 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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
In reply to this post by Harbs
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
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
In reply to this post by Justin Mclean
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
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Alex Harui-2
In reply to this post by Justin Mclean


On 6/4/17, 9:46 PM, "Justin Mclean" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

piotrz
In reply to this post by Justin Mclean
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
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

piotrz
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
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Justin Mclean
Administrator
In reply to this post by Alex Harui-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

piotrz
+1 for documenting it and stick with it.
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

piotrz
In reply to this post by Justin Mclean
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
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Harbs
In reply to this post by Justin Mclean
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Greg Dove
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 <[hidden email]> 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 <[hidden email]>
> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Harbs
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Removing PasswordInputBead has no effect

Alex Harui-2
In reply to this post by Greg Dove
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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
>>
>>

123