You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by sankar <sa...@gmail.com> on 2017/02/17 11:56:05 UTC

[FlexJS] MDL - Dynamic Child Problem

Hi,

There's a critical and major problem exists with dynamic child creation in
MDL structure.

I've reported this to JIRA at:
https://issues.apache.org/jira/browse/FLEX-35269.

Request to look into this once. 

Thanks!



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
For sure not when page is loaded, cause components has been added to already
loaded page. 

Hmm...I just have an idea that in addedToParent I could check whether
component have "upgraded" tag which is required by MDL if it has I could
based on that upgrade it or not. Than I do not need this Bead
UpgradeElement.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59848.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.
Do you want to know when a component has been added to the DOM or when the
page is considered loaded?

-Alex

On 2/23/17, 10:47 PM, "piotrz" <pi...@gmail.com> wrote:

>Alex,
>
>Do you know about the event which can tell me when component has been
>loaded
>in DOM? 
>
>I may try to use that.
>
>Piotr
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Ch
>ild-Problem-tp59595p59841.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Alex,

Do you know about the event which can tell me when component has been loaded
in DOM? 

I may try to use that.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59841.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.
FWIW, MXML cannot set constructor arguments.  All components instantiated
via MXML must have no constructor arguments or optional constructor
arguments.

I still think the lifecycle should be able to tell you whether an addChild
is happening "dynamically" or not.  Has that been explored and abandoned?

Thanks,
-Alex

On 2/23/17, 8:12 AM, "piotrz" <pi...@gmail.com> wrote:

>I was thinking more about solution for this and I think that interface is
>not
>the right way. 
>
>If my component will implement interface during creation I will  always
>have
>two lines of code:
>
>var textField:TextField = new TextField();
>textField.isDynamic = true:
>
>I think I will just add field to constructor to each component which will
>be
>dynamic.
>
>var textField:TextField = new TextField(true);
>
>Piotr
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Ch
>ild-Problem-tp59595p59836.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
I was thinking more about solution for this and I think that interface is not
the right way. 

If my component will implement interface during creation I will  always have
two lines of code: 

var textField:TextField = new TextField();
textField.isDynamic = true:

I think I will just add field to constructor to each component which will be
dynamic.

var textField:TextField = new TextField(true);

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59836.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Carlos,

I will try to explore it, your focus on AMF is crucial. :)

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59636.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi,

for what you said we have various "update" methods I wasn't aware.
(updateDom, updateAllRegistered and updateElement...and maybe others to
look for)
We should see where's the best way to introduce it in our FlexJS
architecture.
Maybe Alex suggestion could be explored to see the best place to do this
task.

Piotr, I see you take over the ticket. Thanks. I'm right now focused on get
RemoteObject AMF calls. If you have time get on it, if not I'll try to look
as I close things. Right now I have 3 things open.

Thanks



2017-02-17 18:41 GMT+01:00 piotrz <pi...@gmail.com>:

> Hi Sankar,
>
> For me this jira is more like feature than Bug. I will look into that. I
> think all I need to do is add element to the DOM on specified event.
>
> Piotr
>
>
>
> -----
> Apache Flex PMC
> piotrzarzycki21@gmail.com
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
> Problem-tp59595p59620.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Hi Sankar,

For me this jira is more like feature than Bug. I will look into that. I
think all I need to do is add element to the DOM on specified event.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59620.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
I think this should be an answer what they already mentioned in the original
MDL library page:

<http://apache-flex-development.2333347.n4.nabble.com/file/n59618/Untitled.png> 

I also found somewhere at Stackoverflow people discussing on this, someone
suggested this:


> For future readers and users of the Material Design Lite (MDL) framework,
> you can also refresh dynamically added elements individually (instead of
> combing the entire DOM).
> 
> For example, componentHandler.upgradeDom("mdl-menu") will upgrade only
> mdl-menu elements.

So the above sounds can be called /after/ adding the component to HTML
stage.



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59618.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.

On 2/17/17, 7:51 AM, "Josh Tynjala" <jo...@gmail.com> wrote:

>I used in MDL in a JS project recently, and I found that if I created MDL
>components after the initial page load, I needed to run the following code
>once they were added to the DOM:
>
>if("componentHandler" in window)
>{
>    window["componentHandler"].upgradeAllRegistered();
>}
>
>My app was divided into several screens, so I simply called that whenever
>I
>created a new screen, and all MDL components would be upgraded.
>
>However, I don't think this exact function is the best choice for FlexJS
>MDL components. 

Maybe the FlexJS MDL wrappers call upgradeAllRegistered in addedToParent
overrides?  Or is there more to it than that?

-Alex


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Hi Josh,

Thank you for pointing me to these methods. Unfortunately it is not working
for me. I reached the point where I'm able to create dynamically component
in FlexJS, but upgradeElement cannot find it and upgrade properly. 

I decided to create simple pure MDL application [1] where I'm doing same
thing as in FlexJS - adding new Tab to TabBar. If you find some time and
could take a look into that:

1) Why new Tab is not added (this part is working for me in FlexJS)
2) Why upgradeElement is not working (that's my problem)

[1] https://1drv.ms/u/s!ApVpLyjpHDC2zD1d1zd9PuXtmwmG
[2] HTML: https://paste.apache.org/WLPu
[3] Script: https://paste.apache.org/B2Qr

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59649.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Maybe I will commit RadioButton changes and you will see - if I will be able
to even upgrade it.

Let say that our component consists with:

<Checkbox>
<Radio>
 

Checkbox and Span need to be upgraded, so inside my custom component I will
create:

var cbx = new CheckBox(); - If it is upgradable inside I won't have add
anything but if not -> cbx.addBead(new UpgradeElement());
var span = new Span();
span.addBead(new UpgradeElement());

etc.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59724.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
Carlos Rovira wrote
> What about to have a MDLUtils or UpgradeMDLUtils class with static
> methods?
> So people that would create a component will do
> "UpgradeUtils.upgradeElement(buttonToUpgrade);"
> In this way people using a button 90% of times will not be affected by
> that
> overhead.
> (I'm thinking on a general scenario where 80-90% of uses are mxml
> declaration vs 10-20 or less of dynamic creation)

Hi Carlos,

Echoing Piotr's worry with this design, I also has a point I thought you
should consider about. 

The design with 'UpgradeUtils.upgradeElement' maybe find when you adds
single component dynamically. But when you adds a complete external
component consists of many different MDL components, wouldn't be the
procedure will be tricky/complex for 'UpgradeUtils.upgradeElement' method,
to upgrade everything inside?

Thanks!



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59723.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Back to the subject:

I don't see possibility to achieve PAYG without forcing developer to do some
additional hacks  on our components once he add UpgradeElement.

Although I'm able to provide dynamic ability ON DEMAND. Creating IDynamic
interface with property isDynamic. 

I'll start to work - let me know about concerns.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59795.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
In order to refresh dynamically created element in some cases I have to
upgrade also subcomponent. 

In each scenario it can be something else. I've created UpgradeElement which
can upgrade only simple component. 

In case of Button this will be working:

var btn:Button = new Button();
btn.addBead(new UpgradeElement);

But in case of other components like TextField it won't. So I've decided add
isDynamic property which add ability to refresh on demand - instead doing
this every time.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60045.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Carlos,

I'm bringing back to live this thread with question about default upgrade.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60154.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
I have found in MDL library that process of upgrade won't occur if component
is already upgraded. In this case I could get rid off this isDynamic
property and just add upgrade ability as default.

What do you think Carlos ? 

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60046.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.

On 3/3/17, 8:00 AM, "piotrz" <pi...@gmail.com> wrote:

>I didn't think about such scenario, so it look like we should expose
>isDynamic also to MXML.

That might work, although it can't be a constructor parameter.  MXML
doesn't allow constructor parameters.

I would rather explore why whatever isDynamic does can't be built into the
lifecycle so no isDynamic flag is ever needed.  Are we just trying to
detect if addElement is being called after the onLoad event?

Thanks,
-Alex


Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
I didn't think about such scenario, so it look like we should expose
isDynamic also to MXML.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60043.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.
Piotr,

Santanu may be right that there are dynamic MXML scenarios involving
states and includeIn/excludeFrom.  In those cases, the instances are
created by MXMLDataInterpreter just like other MXML tags, but may not be
added to the DOM until much later, or removed and re-added as states
change.

I haven't looked at the code, but are you sure that whatever isDynamic
does can't be run on addedToParent?

Thanks,
-Alex

On 3/2/17, 5:06 AM, "piotrz" <pi...@gmail.com> wrote:

>Sankar,
>
>Code which you are showing me should work without the problem.
>
>var tmpComp:Button = new Button(true); - need to be true in constructor.
>
>This:
>
>	<mdl:Button text="Click to add External components"
>					click="button1_clickHandler(event)" accent="true"/>
>
>You don't need any action cause MDL will handle this one.
>
>Piotr
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Ch
>ild-Problem-tp59595p59983.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.


Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Harbs <ha...@gmail.com>.
Yeah. Debugging these things are not fun.

Chrome also allows you to set breakpoints on DOM elements.

I’ve found this useful in breaking at a specific place in the lifecycle to see what’s going on.

> On Mar 3, 2017, at 7:24 AM, Alex Harui <ah...@adobe.com> wrote:
> 
> 
> 
> On 3/2/17, 8:51 PM, "piotrz" <pi...@gmail.com> wrote:
> 
>> I will try to fight with this. The problem is that in this case I don't
>> have
>> any exception in the console. :)
> 
> Yuk.  I think I would next examine the DOM.  Compare it against the
> js-debug version.  If DOM objects are missing in js-release, then I would
> set breakpoints where they are created.
> 
> HTH,
> -Alex
> 


Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.

On 3/2/17, 8:51 PM, "piotrz" <pi...@gmail.com> wrote:

>I will try to fight with this. The problem is that in this case I don't
>have
>any exception in the console. :)

Yuk.  I think I would next examine the DOM.  Compare it against the
js-debug version.  If DOM objects are missing in js-release, then I would
set breakpoints where they are created.

HTH,
-Alex


Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
I will try to fight with this. The problem is that in this case I don't have
any exception in the console. :)

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60024.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.

On 3/2/17, 5:59 PM, "piotrz" <pi...@gmail.com> wrote:

>Alex,
>
>What could help you to fix that. Should I try to find in minified JS my
>potential class and show it here?

I don't know how much time you have, but it would be great if you simply
tried to debug into it on your own.  Maybe you will find a set of tools
and techniques that is better than mine.

I think every time, I get an exception in the console, then it is a matter
of figuring out what renamed variables map back to the original variable
names.

For me, I find it difficult to set breakpoints because so many original
lines of code have been packed onto a single line.  I often delete the
source map and hand edit the minified code to break the line of minified
code that is throwing the exception into many lines so I can reliably set
a breakpoint.

Good luck,
-Alex


Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Alex,

What could help you to fix that. Should I try to find in minified JS my
potential class and show it here? 

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60021.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.

On 3/2/17, 9:19 AM, "piotrz" <pi...@gmail.com> wrote:

>Alex,
>
>Do you think because it is something with variable renaming in release
>version? 
>I remember that this problem come back to us.

Almost every time js-debug works and js-release doesn't, it has to do with
renaming.  It is a pain to figure out (at least, I haven't found an easy
way), but it is important to find and fix these.

-Alex


Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Alex,

Do you think because it is something with variable renaming in release
version? 
I remember that this problem come back to us.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59991.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.
Hi Piotr,

Congratulations on finding the problem.  You might want to make a set of
externs or typedefs for MDL.  That would prevent renaming of these
functions and type check those functions as well.   See the way I put
together the BarcodeScanner.swc in the flex-tourjs repo.

-Alex

On 3/4/17, 4:12 AM, "piotrz" <pi...@gmail.com> wrote:

>Santanau,
>
>I just pushed fix for problem with release version of your application.
>
>Alex,
>
>In that case it was problem with function which I've called from
>javascript
>[1]
>
>[1] https://paste.apache.org/FyB8
>
>Piotr
>
>
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Ch
>ild-Problem-tp59595p60068.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.


Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
I think it depends whether you will show me some scenario where it need it. I
think some components you may never use as dynamic - you will always use it
in mxml. 

I know that we have states where components even in mxml can be dynamically
created, but I need to see such scenario to make them dynamic.

Just let me know and I will start to work when I found the time. :)

Piotr




-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60611.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
piotrz wrote
> I just introduce another bead which may be helpful for custom component,
> but in most cases will be used inside MDL components UpgradeChildren. 
> 
> I've just make as default possible to create dynamically following
> components:
> Button,
> RadioButton,
> CheckBox,
> TextArea,
> TextField,
> IconToggle,
> Spinner,
> Switch,
> Tooltip

Hi Piotr,

Thanks for this update! I shall give a try by downloading latest source from
repo soon possible. 

I was wondering, is that the final list where you should add the new bad, or
this going to get updated across other available components to MDL, i.e.
Table item renderer, toast etc. (?)

Thanks!




--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60606.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Hi Carlos,

No problem :) Thanks!

Santanau,

I just introduce another bead which may be helpful for custom component, but
in most cases will be used inside MDL components UpgradeChildren. 

I've just make as default possible to create dynamically following
components:
Button,
RadioButton,
CheckBox,
TextArea,
TextField,
IconToggle,
Spinner,
Switch,
Tooltip

I think newest nightly build will have all the changes. Let me know about
any cases where you have some more problems with component dynamic creation.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60564.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Piotr,

sorry, just see this, but as you said I'm very busy this days and even
can't take the time to look to all the threads going on.
I can't analyze right now the changes you want to do, but I trust you and
I'm sure what you plan will be the right way to go.
Hope I can return in some days as I get all the overload controlled.

Thanks and sorry to get late!

Carlos



2017-03-16 12:24 GMT+01:00 sankar <sa...@gmail.com>:

> piotrz wrote
> > I'm thinking on adding as "default" to components ability for dynamic
> > creation without any "isDynamic" property etc. I wanted to discuss it
> with
> > Carlos in the other thread, but he is busy currently, so I'm still
> waiting
> > for his input.
>
> Hi Piotr,
>
> That sounds nice. Although I don't know if there'll be any stress to
> processing, which Carlos and others can suggest. But I'm fine with this
> solution and I haven't seen any noticeable delay/stress to my browser even
> when I give quite heavy application codes.
>
> I'm using following codes in my modified UIBase class at this moment, and
> this working expecedly.
>
>
> > public function addElement(c:IChild, dispatchEvent:Boolean = true):void
> > {
> >      ...
> >      COMPILE::JS
> >      {
> >           if ("componentHandler" in document.defaultView)
> >           {
> >               var componentHandler:Object = window["componentHandler"];
> >               componentHandler["upgradeElement"](c.positioner);
> >           }
> >           element.appendChild(c.positioner);
> >           (c as IUIBase).addedToParent();
> >      }
> > }
>
> Thanks!
>
>
>
>
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
> Problem-tp59595p60506.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
piotrz wrote
> I'm thinking on adding as "default" to components ability for dynamic
> creation without any "isDynamic" property etc. I wanted to discuss it with
> Carlos in the other thread, but he is busy currently, so I'm still waiting
> for his input.

Hi Piotr,

That sounds nice. Although I don't know if there'll be any stress to
processing, which Carlos and others can suggest. But I'm fine with this
solution and I haven't seen any noticeable delay/stress to my browser even
when I give quite heavy application codes. 

I'm using following codes in my modified UIBase class at this moment, and
this working expecedly.


> public function addElement(c:IChild, dispatchEvent:Boolean = true):void
> {
>      ...
>      COMPILE::JS
>      {
>           if ("componentHandler" in document.defaultView)
>           {
> 		var componentHandler:Object = window["componentHandler"];
> 		componentHandler["upgradeElement"](c.positioner);
>           }
>           element.appendChild(c.positioner);
>           (c as IUIBase).addedToParent();
>      }
> }

Thanks!




--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60506.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Hi Santanau,

I'm thinking on adding as "default" to components ability for dynamic
creation without any "isDynamic" property etc. I wanted to discuss it with
Carlos in the other thread, but he is busy currently, so I'm still waiting
for his input. If I got it positiv I will start work and you shouldn't have
problem for dynamic creation of component even in mxml. - I hope ;)

Thanks,
Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60494.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
piotrz wrote
> In that case it was problem with function which I've called from
> javascript [1]
> 
> [1] https://paste.apache.org/FyB8

Hi Piotr,

I was busy for quite some time from the updates here. Thank you! for the
link you shared. That actually fix the problem for dynamically adding
component in "bin-release" version! 

I didn't able to test your latest updates yet, I shall do that hopefully
soon. 

Thanks!




--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60493.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Santanau,

I just pushed fix for problem with release version of your application.

Alex,

In that case it was problem with function which I've called from javascript
[1]

[1] https://paste.apache.org/FyB8

Piotr





-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p60068.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
piotrz wrote
> var tmpComp:Button = new Button(true); - need to be true in constructor.

I've seen such usage of addition do not works in compiled "bin-release"
version. Things not works like 'ripple' etc. in "bin-release" version.

Thanks!




--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59989.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Sankar,

Code which you are showing me should work without the problem.

var tmpComp:Button = new Button(true); - need to be true in constructor.

This:

	<mdl:Button text="Click to add External components"
					click="button1_clickHandler(event)" accent="true"/>

You don't need any action cause MDL will handle this one.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59983.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
piotrz wrote
> Ok but you didn't add this Grid to MXML, you will add this component by
> addElement yes ? 
> 
> Maybe I do not understand your use cases - provide me an example if you
> can.

Hi Piotr,

My test was pretty basic with FlexJS MDL default components only. Here's the
basic test case where I added a MDL button to one GridCell after a button
click:

https://kobra.io/#/e/-KeE-9-OM5UGpVORDPwt

Thanks!




--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59982.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Sankar,

Ok but you didn't add this Grid to MXML, you will add this component by
addElement yes ? 

If you are adding Grid in MXML - It will be initialized on his own - MDL
will upgrade it automatically. 

Maybe I do not understand your use cases - provide me an example if you can.

If you have created your custom component it is your responsibility to make
upgrade, I can only add upgrade to the component which we currently created
with Carlos.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59981.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
Hi Piotr,

I may oppose this your opinion:

piotrz wrote
> I don't see any advantage to have this property in MXML. Dynamic component
> is supposed to be created from code new Button(true).

Say I have an external Grid component which has many buttons and TextFields
declared in MXML tag - and I wants to add that external Grid component to
somewhere at runtime. So in the way your opinion, I see the dynamic addition
and component upgrade will going to fail, unless I write every component
addition code in that external Grid component in <fx:Script/> area. 

Secondly, have you tried your fix in "bin-release" version? 

I did a small test by adding a button the way constructor demands it; it
does well in "bin-debug" version though but "bin-release". 

Thanks!



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59980.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Hi Sankar,

I don't see any advantage to have this property in MXML. Dynamic component
is supposed to be created from code new Button(true).

If you need more dynamic components which is already in our MDL library let
me know. I've changed only few of them to be dynamic.

If component do not have in the constructor isDynamic you may try to add
UpgradeElement bead during creation, but it won't guarantee that your
component will be refreshed. Sometimes refreshing required refreshing also
sub components.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59979.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
Hi,

I recently updated my local framework source from Git repository. I am not
sure where we're standing now with this but I wanted to give Piotr's Button
and TextField implementation a try with new UpgradeElement bead.

So far I able to get the dynamic element upgraded by this way:

var newButton:Button = new Button(true);

Piotr, I have a question:

- I didn't seen any "isDynamic" property in MXML declaration as I know the
property was only limited to constructor. Are you planning to do something
on this?

Also, if I have a component filled with many elements, i.e. buttons,
textfields etc. and want to add that component at runtime, I shall basically
needs to set "isDynamic=true" to every components in it, is that right?

Thanks!



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59978.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Harbs <ha...@gmail.com>.
> and in some
> situations, it might need to be the parent document's body if you are in
> an IFrame.

That’s not going to work unless there’s some way to create elements in the outer document which we currently don’t have.

I think the simplest way to go about it, is to leave it as-is for now. It’s actually about as simple as it can be.

I assume in another half-year or so we’re going to move over to mdc-web when it has it’s release.[1][2]

They are in the process of working on dialog in a way which does not use <dialog>, so I’m assuming it can be used somewhere other than <body>.[3][4]

[1]https://github.com/material-components/material-components-web <https://github.com/material-components/material-components-web>
[2]https://www.pivotaltracker.com/n/projects/1664011 <https://www.pivotaltracker.com/n/projects/1664011>
[3]https://github.com/material-components/material-components-web/issues/32 <https://github.com/material-components/material-components-web/issues/32>
[4]http://codepen.io/amsheehan/pen/QdBPXL?editors=0100 <http://codepen.io/amsheehan/pen/QdBPXL?editors=0100>

> On Feb 25, 2017, at 7:37 AM, Alex Harui <ah...@adobe.com> wrote:
> 
> 
> 
> On 2/24/17, 3:00 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
> 
>> Having two discussions in one thread is confusing… ;-)
>> 
>> I guess we could make a custom object, but I’m not sure what the point
>> is. AIUI, the purpose of IPopUpHost is to support many levels of popups.
>> Assuming we are right that dialog must be attached to <body>, the
>> simplest way to handle that is to attach it directly.
>> 
>> However, I just looked around a bit, and it seems like that’s not true.
>> It looks like dialog can be attached to pretty much any element. The only
>> caveat seems to be in the polyfill that it’s supposed to not be in an
>> element which has a stacking context.[1]
>> 
>> What I’m not sure about dialog is whether the position can be relative to
>> an element, or it’s always relative to the whole page. Depending on the
>> answer to that, it might make sense to allow different IPopUpHosts, or
>> not.
> 
> IMO, that's the point of IPopUpHost.  It allows various configurations to
> dictate where to hang the popups.  It doesn't have to be body, and in some
> situations, it might need to be the parent document's body if you are in
> an IFrame.
> 
> Regular Flex has a PopUpManager, but really, it was designed for multiple
> overlapping windows like in MS Windows and was overkill for most
> applications.  In fact, the FlexJS examples don't have a PopUpManager and
> can still hang one modal dialog at a time somewhere.  So, IMO, popup
> support should also be PAYG and have an abstraction that doesn't assume it
> is the <body> tag.
> 
> My 2 cents,
> -Alex


Re: [MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.

On 2/24/17, 3:00 AM, "Harbs" <ha...@gmail.com> wrote:

>Having two discussions in one thread is confusing… ;-)
>
>I guess we could make a custom object, but I’m not sure what the point
>is. AIUI, the purpose of IPopUpHost is to support many levels of popups.
>Assuming we are right that dialog must be attached to <body>, the
>simplest way to handle that is to attach it directly.
>
>However, I just looked around a bit, and it seems like that’s not true.
>It looks like dialog can be attached to pretty much any element. The only
>caveat seems to be in the polyfill that it’s supposed to not be in an
>element which has a stacking context.[1]
>
>What I’m not sure about dialog is whether the position can be relative to
>an element, or it’s always relative to the whole page. Depending on the
>answer to that, it might make sense to allow different IPopUpHosts, or
>not.

IMO, that's the point of IPopUpHost.  It allows various configurations to
dictate where to hang the popups.  It doesn't have to be body, and in some
situations, it might need to be the parent document's body if you are in
an IFrame.

Regular Flex has a PopUpManager, but really, it was designed for multiple
overlapping windows like in MS Windows and was overkill for most
applications.  In fact, the FlexJS examples don't have a PopUpManager and
can still hang one modal dialog at a time somewhere.  So, IMO, popup
support should also be PAYG and have an abstraction that doesn't assume it
is the <body> tag.

My 2 cents,
-Alex


[MDL Dialogs] was: Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Harbs <ha...@gmail.com>.
Having two discussions in one thread is confusing… ;-)

I guess we could make a custom object, but I’m not sure what the point is. AIUI, the purpose of IPopUpHost is to support many levels of popups. Assuming we are right that dialog must be attached to <body>, the simplest way to handle that is to attach it directly.

However, I just looked around a bit, and it seems like that’s not true. It looks like dialog can be attached to pretty much any element. The only caveat seems to be in the polyfill that it’s supposed to not be in an element which has a stacking context.[1]

What I’m not sure about dialog is whether the position can be relative to an element, or it’s always relative to the whole page. Depending on the answer to that, it might make sense to allow different IPopUpHosts, or not.

[1]https://github.com/GoogleChrome/dialog-polyfill <https://github.com/GoogleChrome/dialog-polyfill>

> On Feb 24, 2017, at 6:04 AM, Alex Harui <ah...@adobe.com> wrote:
> 
> 
> 
> On 2/23/17, 12:12 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> It could return the body, but the body is not an IPopUpHost and it does
>> not have addElement().
>> 
>> The element of an embedded app will not be the body, so addElement() to
>> that will blow up if it needs to be added to the body.
> 
> This is JavaScript right?  We can do just about anything we want.  I would
> think you can have IPopUpHost return an object that has addElement that
> proxies the calls to body just like any of our other wrapped HTMLElements.
> 
> The advantage of having an abstraction like IPopUpHost is that different
> configurations have a better chance of having dialog work properly by
> offering their own custom place to hang dialogs.
> 
> Of course, I could be wrong...
> -Alex
> 


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.

On 2/23/17, 12:12 AM, "Harbs" <ha...@gmail.com> wrote:

>It could return the body, but the body is not an IPopUpHost and it does
>not have addElement().
>
>The element of an embedded app will not be the body, so addElement() to
>that will blow up if it needs to be added to the body.

This is JavaScript right?  We can do just about anything we want.  I would
think you can have IPopUpHost return an object that has addElement that
proxies the calls to body just like any of our other wrapped HTMLElements.

The advantage of having an abstraction like IPopUpHost is that different
configurations have a better chance of having dialog work properly by
offering their own custom place to hang dialogs.

Of course, I could be wrong...
-Alex


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Harbs <ha...@gmail.com>.
It could return the body, but the body is not an IPopUpHost and it does not have addElement().

The element of an embedded app will not be the body, so addElement() to that will blow up if it needs to be added to the body.

> On Feb 23, 2017, at 9:57 AM, Alex Harui <ah...@adobe.com> wrote:
> 
> 
> 
> On 2/22/17, 11:18 PM, "Harbs" <ha...@gmail.com> wrote:
> 
>> That’s not going to work for an embedded app because the body element can
>> be outside the app completely.
> 
> What would it take to make it work?  If we ask each parent if it is an
> IPopUpHost and if it answers yes and it gives us an Iparent to call
> addElement on, why couldn't EmbeddedApplication return the body if it
> wanted to?
> 
> -Alex
> 


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.

On 2/22/17, 11:18 PM, "Harbs" <ha...@gmail.com> wrote:

>That’s not going to work for an embedded app because the body element can
>be outside the app completely.

What would it take to make it work?  If we ask each parent if it is an
IPopUpHost and if it answers yes and it gives us an Iparent to call
addElement on, why couldn't EmbeddedApplication return the body if it
wanted to?

-Alex


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Harbs <ha...@gmail.com>.
That’s not going to work for an embedded app because the body element can be outside the app completely.

> On Feb 23, 2017, at 9:01 AM, Alex Harui <ah...@adobe.com> wrote:
> 
> 
> 
> On 2/22/17, 9:49 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> It looks like my change works.
>> 
>> I just committed a change where instead of Dialog being added to
>> Application, the Dialog HTML element is added to <body>. I needed to
>> manually call addedToParent() to make sure the children render, and it
>> all seems to work. :-)
> 
> FWIW, there is an IPopUpHost we are trying to use in Basic/HTML and
> UIUtils.findPopUpHost.  It would be nice if MDL could use it or some
> extension of it.
> 
> HTH,
> -Alex
> 


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.

On 2/22/17, 9:49 AM, "Harbs" <ha...@gmail.com> wrote:

>It looks like my change works.
>
>I just committed a change where instead of Dialog being added to
>Application, the Dialog HTML element is added to <body>. I needed to
>manually call addedToParent() to make sure the children render, and it
>all seems to work. :-)

FWIW, there is an IPopUpHost we are trying to use in Basic/HTML and
UIUtils.findPopUpHost.  It would be nice if MDL could use it or some
extension of it.

HTH,
-Alex


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Harbs <ha...@gmail.com>.
It looks like my change works.

I just committed a change where instead of Dialog being added to Application, the Dialog HTML element is added to <body>. I needed to manually call addedToParent() to make sure the children render, and it all seems to work. :-)

Harbs

> On Feb 22, 2017, at 5:24 PM, Harbs <ha...@gmail.com> wrote:
> 
> I’m going to commit a change which will hopefully work… ;-)


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Harbs <ha...@gmail.com>.
> On Feb 22, 2017, at 6:08 PM, Alex Harui <ah...@adobe.com> wrote:
> 
> 
> 
> On 2/22/17, 7:24 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> So, this is going to be a problem.
>> 
>> Right now Application is always attached to <body>, but that is probably
>> going to change. A very common use case of RIAs is embedded in web pages.
>> In that case, the base element will not be <body> unless it’s in an
>> iframe. iframes are not always a good solution. For example, iOS has a
>> bug where you can not use the soft keyboard in an iframe.
>> 
>> I’m going to commit a change which will hopefully work… ;-)
> 
> Or create another Application class, maybe called "NonBodyApplication" (I
> thought of EmbeddedApplication as well).

Right. I’m planning on that. The problem is I want to use mdl dialogs in an EmbeddedApplication. That’s not gonna work with the way dialogs are currently done.

> 
>>>>> 2017-02-22 9:53 GMT+01:00 Harbs <ha...@gmail.com>:
>>>>> 
>>>>>> “Must” is too strong.
>>>>>> 
>>>>>> Our app needs MDL for controls, but the main functionality doesn’t
>>>>>> and
>>>>>> CAN’T rely on MDL. If mdl:Application can do everything a
>>>> basic:Application
>>>>>> can do, then that’s fine (as long as it can be sub-classed, because
>>>>>> our
>>>> app
>>>>>> cannot be based off <body>), but if mdl:Application cannot take other
>>>>>> components, it’s a not starter.
>>>>>> 
>>>>>> I do think it’s fine to say that it’s “batteries not included” (with
>>>>>> documentation on what needs to be done) if you don’t use
>>>> mdl:Application /
>>>>>> mdl:Container, but it’s absolutely necessary for components to be
>>>>>> mixed
>>>> and
>>>>>> matched. I don’t think our app is so unique that others will not have
>>>> the
>>>>>> same issue.
> 
> 
> No component set should be required to accept mix-and-match.  If it can be
> supported via beads, then great.
> I thought MDL was for UI.  What other app functionality are you referring
> to?

Lots. First of all, mdl is not a full component set. Also, we have interactive elements which is mostly svg, but there’s also HTML wrapped stuff. We are likely going to have a canvas component before we’re done as well.

> -Alex
> 


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.

On 2/22/17, 7:24 AM, "Harbs" <ha...@gmail.com> wrote:

>So, this is going to be a problem.
>
>Right now Application is always attached to <body>, but that is probably
>going to change. A very common use case of RIAs is embedded in web pages.
>In that case, the base element will not be <body> unless it’s in an
>iframe. iframes are not always a good solution. For example, iOS has a
>bug where you can not use the soft keyboard in an iframe.
>
>I’m going to commit a change which will hopefully work… ;-)

Or create another Application class, maybe called "NonBodyApplication" (I
thought of EmbeddedApplication as well).

>>>>2017-02-22 9:53 GMT+01:00 Harbs <ha...@gmail.com>:
>>>> 
>>>>> “Must” is too strong.
>>>>> 
>>>>> Our app needs MDL for controls, but the main functionality doesn’t
>>>>>and
>>>>> CAN’T rely on MDL. If mdl:Application can do everything a
>>> basic:Application
>>>>> can do, then that’s fine (as long as it can be sub-classed, because
>>>>>our
>>> app
>>>>> cannot be based off <body>), but if mdl:Application cannot take other
>>>>> components, it’s a not starter.
>>>>> 
>>>>> I do think it’s fine to say that it’s “batteries not included” (with
>>>>> documentation on what needs to be done) if you don’t use
>>> mdl:Application /
>>>>> mdl:Container, but it’s absolutely necessary for components to be
>>>>>mixed
>>> and
>>>>> matched. I don’t think our app is so unique that others will not have
>>> the
>>>>> same issue.


No component set should be required to accept mix-and-match.  If it can be
supported via beads, then great.
I thought MDL was for UI.  What other app functionality are you referring
to?

-Alex


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Harbs <ha...@gmail.com>.
So, this is going to be a problem.

Right now Application is always attached to <body>, but that is probably going to change. A very common use case of RIAs is embedded in web pages. In that case, the base element will not be <body> unless it’s in an iframe. iframes are not always a good solution. For example, iOS has a bug where you can not use the soft keyboard in an iframe.

I’m going to commit a change which will hopefully work… ;-)

Harbs

> On Feb 22, 2017, at 5:06 PM, Carlos Rovira <ca...@codeoscopic.com> wrote:
> 
> Hi Harbs
> 
> I asked here for the best way to reference <body> tag from Dialog. I did
> the actual implementation as a workaround since at that moment you
> discussed it but no definite solution was opted. So considere it as a
> temporal code.
> If you see Dialog:
> 
> https://getmdl.io/components/index.html#dialog-section
> 
> you only need a robust way to refer <body> since Dialogs are always
> attached to body (and could not be other tag)
> 
> So feel free to change it if you have a better implementation
> 
> thanks!
> 
> 
> 2017-02-22 14:41 GMT+01:00 Harbs <ha...@gmail.com>:
> 
>> I just looked at that code for the first time.
>> 
>> I’m confused. Why are you attaching it to Application? Why not just add
>> dialog to <body>? I don’t see why you need a reference to Application at
>> all.
>> 
>> Unless, of course the dialog should be centered in the application (which
>> might not be <body>).
>> 
>> Additionally, does it make sense to have a property which allows
>> specifying an HTML element to attach the dialog to (be it <body> or
>> something else)?
>> 
>>> On Feb 22, 2017, at 11:53 AM, Carlos Rovira <
>> carlos.rovira@codeoscopic.com> wrote:
>>> 
>>> Regarding mdl:Application in concrete, is just a js:Application with a
>>> static var to handle body since is needed for Dialog, and that's what MDL
>>> Dialog impose.
>>> so just a static var is the difference...
>>> 
>>> 2017-02-22 9:53 GMT+01:00 Harbs <ha...@gmail.com>:
>>> 
>>>> “Must” is too strong.
>>>> 
>>>> Our app needs MDL for controls, but the main functionality doesn’t and
>>>> CAN’T rely on MDL. If mdl:Application can do everything a
>> basic:Application
>>>> can do, then that’s fine (as long as it can be sub-classed, because our
>> app
>>>> cannot be based off <body>), but if mdl:Application cannot take other
>>>> components, it’s a not starter.
>>>> 
>>>> I do think it’s fine to say that it’s “batteries not included” (with
>>>> documentation on what needs to be done) if you don’t use
>> mdl:Application /
>>>> mdl:Container, but it’s absolutely necessary for components to be mixed
>> and
>>>> matched. I don’t think our app is so unique that others will not have
>> the
>>>> same issue.
>>>> 
>>>> Harbs
>>>> 
>>>>> On Feb 22, 2017, at 9:03 AM, Alex Harui <ah...@adobe.com> wrote:
>>>>> 
>>>>> IMO, it is fine to say that folks must use mdl:Application
>>>>> instead of basic:Application and mdl:Container instead of
>> basic:Container
>>>>> if that gives you control over the lifecycle that you need in order to
>>>>> help your customer.
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> 
>>> Carlos Rovira
>>> Director General
>>> M: +34 607 22 60 05
>>> http://www.codeoscopic.com
>>> http://www.avant2.es
>>> 
>>> Este mensaje se dirige exclusivamente a su destinatario y puede contener
>>> información privilegiada o confidencial. Si ha recibido este mensaje por
>>> error, le rogamos que nos lo comunique inmediatamente por esta misma vía
>> y
>>> proceda a su destrucción.
>>> 
>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>> comunicamos
>>> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>>> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>>> servicio o información solicitados, teniendo usted derecho de acceso,
>>> rectificación, cancelación y oposición de sus datos dirigiéndose a
>> nuestras
>>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>>> necesaria.
>> 
>> 
> 
> 
> -- 
> 
> Carlos Rovira
> Director General
> M: +34 607 22 60 05
> http://www.codeoscopic.com
> http://www.avant2.es
> 
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> información privilegiada o confidencial. Si ha recibido este mensaje por
> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> proceda a su destrucción.
> 
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> servicio o información solicitados, teniendo usted derecho de acceso,
> rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> necesaria.


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Harbs

I asked here for the best way to reference <body> tag from Dialog. I did
the actual implementation as a workaround since at that moment you
discussed it but no definite solution was opted. So considere it as a
temporal code.
If you see Dialog:

https://getmdl.io/components/index.html#dialog-section

you only need a robust way to refer <body> since Dialogs are always
attached to body (and could not be other tag)

So feel free to change it if you have a better implementation

thanks!


2017-02-22 14:41 GMT+01:00 Harbs <ha...@gmail.com>:

> I just looked at that code for the first time.
>
> I’m confused. Why are you attaching it to Application? Why not just add
> dialog to <body>? I don’t see why you need a reference to Application at
> all.
>
> Unless, of course the dialog should be centered in the application (which
> might not be <body>).
>
> Additionally, does it make sense to have a property which allows
> specifying an HTML element to attach the dialog to (be it <body> or
> something else)?
>
> > On Feb 22, 2017, at 11:53 AM, Carlos Rovira <
> carlos.rovira@codeoscopic.com> wrote:
> >
> > Regarding mdl:Application in concrete, is just a js:Application with a
> > static var to handle body since is needed for Dialog, and that's what MDL
> > Dialog impose.
> > so just a static var is the difference...
> >
> > 2017-02-22 9:53 GMT+01:00 Harbs <ha...@gmail.com>:
> >
> >> “Must” is too strong.
> >>
> >> Our app needs MDL for controls, but the main functionality doesn’t and
> >> CAN’T rely on MDL. If mdl:Application can do everything a
> basic:Application
> >> can do, then that’s fine (as long as it can be sub-classed, because our
> app
> >> cannot be based off <body>), but if mdl:Application cannot take other
> >> components, it’s a not starter.
> >>
> >> I do think it’s fine to say that it’s “batteries not included” (with
> >> documentation on what needs to be done) if you don’t use
> mdl:Application /
> >> mdl:Container, but it’s absolutely necessary for components to be mixed
> and
> >> matched. I don’t think our app is so unique that others will not have
> the
> >> same issue.
> >>
> >> Harbs
> >>
> >>> On Feb 22, 2017, at 9:03 AM, Alex Harui <ah...@adobe.com> wrote:
> >>>
> >>> IMO, it is fine to say that folks must use mdl:Application
> >>> instead of basic:Application and mdl:Container instead of
> basic:Container
> >>> if that gives you control over the lifecycle that you need in order to
> >>> help your customer.
> >>
> >>
> >
> >
> > --
> >
> > Carlos Rovira
> > Director General
> > M: +34 607 22 60 05
> > http://www.codeoscopic.com
> > http://www.avant2.es
> >
> > Este mensaje se dirige exclusivamente a su destinatario y puede contener
> > información privilegiada o confidencial. Si ha recibido este mensaje por
> > error, le rogamos que nos lo comunique inmediatamente por esta misma vía
> y
> > proceda a su destrucción.
> >
> > De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> comunicamos
> > que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> > S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> > servicio o información solicitados, teniendo usted derecho de acceso,
> > rectificación, cancelación y oposición de sus datos dirigiéndose a
> nuestras
> > oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> > necesaria.
>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Harbs <ha...@gmail.com>.
I just looked at that code for the first time.

I’m confused. Why are you attaching it to Application? Why not just add dialog to <body>? I don’t see why you need a reference to Application at all.

Unless, of course the dialog should be centered in the application (which might not be <body>).

Additionally, does it make sense to have a property which allows specifying an HTML element to attach the dialog to (be it <body> or something else)?

> On Feb 22, 2017, at 11:53 AM, Carlos Rovira <ca...@codeoscopic.com> wrote:
> 
> Regarding mdl:Application in concrete, is just a js:Application with a
> static var to handle body since is needed for Dialog, and that's what MDL
> Dialog impose.
> so just a static var is the difference...
> 
> 2017-02-22 9:53 GMT+01:00 Harbs <ha...@gmail.com>:
> 
>> “Must” is too strong.
>> 
>> Our app needs MDL for controls, but the main functionality doesn’t and
>> CAN’T rely on MDL. If mdl:Application can do everything a basic:Application
>> can do, then that’s fine (as long as it can be sub-classed, because our app
>> cannot be based off <body>), but if mdl:Application cannot take other
>> components, it’s a not starter.
>> 
>> I do think it’s fine to say that it’s “batteries not included” (with
>> documentation on what needs to be done) if you don’t use mdl:Application /
>> mdl:Container, but it’s absolutely necessary for components to be mixed and
>> matched. I don’t think our app is so unique that others will not have the
>> same issue.
>> 
>> Harbs
>> 
>>> On Feb 22, 2017, at 9:03 AM, Alex Harui <ah...@adobe.com> wrote:
>>> 
>>> IMO, it is fine to say that folks must use mdl:Application
>>> instead of basic:Application and mdl:Container instead of basic:Container
>>> if that gives you control over the lifecycle that you need in order to
>>> help your customer.
>> 
>> 
> 
> 
> -- 
> 
> Carlos Rovira
> Director General
> M: +34 607 22 60 05
> http://www.codeoscopic.com
> http://www.avant2.es
> 
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> información privilegiada o confidencial. Si ha recibido este mensaje por
> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> proceda a su destrucción.
> 
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> servicio o información solicitados, teniendo usted derecho de acceso,
> rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> necesaria.


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Carlos Rovira <ca...@codeoscopic.com>.
Regarding mdl:Application in concrete, is just a js:Application with a
static var to handle body since is needed for Dialog, and that's what MDL
Dialog impose.
so just a static var is the difference...

2017-02-22 9:53 GMT+01:00 Harbs <ha...@gmail.com>:

> “Must” is too strong.
>
> Our app needs MDL for controls, but the main functionality doesn’t and
> CAN’T rely on MDL. If mdl:Application can do everything a basic:Application
> can do, then that’s fine (as long as it can be sub-classed, because our app
> cannot be based off <body>), but if mdl:Application cannot take other
> components, it’s a not starter.
>
> I do think it’s fine to say that it’s “batteries not included” (with
> documentation on what needs to be done) if you don’t use mdl:Application /
> mdl:Container, but it’s absolutely necessary for components to be mixed and
> matched. I don’t think our app is so unique that others will not have the
> same issue.
>
> Harbs
>
> > On Feb 22, 2017, at 9:03 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> > IMO, it is fine to say that folks must use mdl:Application
> > instead of basic:Application and mdl:Container instead of basic:Container
> > if that gives you control over the lifecycle that you need in order to
> > help your customer.
>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Harbs <ha...@gmail.com>.
“Must” is too strong.

Our app needs MDL for controls, but the main functionality doesn’t and CAN’T rely on MDL. If mdl:Application can do everything a basic:Application can do, then that’s fine (as long as it can be sub-classed, because our app cannot be based off <body>), but if mdl:Application cannot take other components, it’s a not starter.

I do think it’s fine to say that it’s “batteries not included” (with documentation on what needs to be done) if you don’t use mdl:Application / mdl:Container, but it’s absolutely necessary for components to be mixed and matched. I don’t think our app is so unique that others will not have the same issue.

Harbs

> On Feb 22, 2017, at 9:03 AM, Alex Harui <ah...@adobe.com> wrote:
> 
> IMO, it is fine to say that folks must use mdl:Application
> instead of basic:Application and mdl:Container instead of basic:Container
> if that gives you control over the lifecycle that you need in order to
> help your customer.


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.

On 2/21/17, 11:51 AM, "piotrz" <pi...@gmail.com> wrote:

>One thing which I wanted to add to make you more understand.
>
>1) If component is instantiated in mxml and this component has added
>UpgradeElement as default - upgradeElement method from MDL will not be
>fired
>- Cause "componentHandler" do not exists yet.
>2) Once web is loaded and some component is created - logic will fire.
>
>I will wait for others voice also...

I don't think I fully understand the issue.  A summary of what code needs
to be run when might help.

FlexJS should always be PAYG in it implementations, but a library like MDL
can and should also look to improve developer productivity in general.
So, if there is some method that needs to be called in order to
dynamically add a child after page load we should see if that code can get
run on-demand, instead of just-in-case.  If StackOverflow shows that folks
are frequently forgetting to run this code, if we can run it for them, it
will be an advantage for FlexJS.

We should be able to control when/if such code runs by controlling the
lifecycle.  IMO, it is fine to say that folks must use mdl:Application
instead of basic:Application and mdl:Container instead of basic:Container
if that gives you control over the lifecycle that you need in order to
help your customer.  Mixing and matching from different component sets
doesn't need to be a guarantee.  Bonus if it works, but, IMO, no big deal
if it doesn't.

IMO, if you can wrap calls to addChild, you can figure out whether page
load has happened and run code for the user.  You also have the option to
postpone the initial DOM setup until after page loads.  IIRC, Cordova
Applications wait until Cordova gets setup before creates the DOM.  The
CSSFontFaceBead delays the DOM setup until after a font loads.  However,
if there is performance improvements to setting up the initial DOM without
calling this dynamic code, that's fine too.  Set a flag once the page load
is complete.

HTH,
-Alex


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
One thing which I wanted to add to make you more understand.

1) If component is instantiated in mxml and this component has added
UpgradeElement as default - upgradeElement method from MDL will not be fired
- Cause "componentHandler" do not exists yet.
2) Once web is loaded and some component is created - logic will fire.

I will wait for others voice also...
Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59733.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi,

I always try to extrapolate from what I see people are doing in MDL. I
didn't have the time to search too much, but seems people as the perform
something dinamic they use the method, so something "external" is done, and
that's the same approach I proposed with the static utility class. That
class could as well have some param to loop in child elements to make it
more usable.

the interface proposed could be another option, is not introducing the bead
by default, so is better option, since we don't have the code instantiated
at runtime for each component, but adds the code to the class what seems to
me not as PAYG as Util.

Hope others like Alex could give us thoughs about this since seems each one
is very happy with his solution ;)

thanks



2017-02-21 19:56 GMT+01:00 piotrz <pi...@gmail.com>:

> I went through the comments and I see that voices rather saying that we
> shouldn't make automatic upgrades for the components, but since it is not
> easy add this ability as an util, maybe we should introduce an interface -
> IDynamic with property IsDynamic - setted by constructor or traditionally.
> (of course I'm open for naming)
>
> If user set it we will add Bead appropriately.
>
> Is it more PAYG ?
>
> Piotr
>
>
>
> -----
> Apache Flex PMC
> piotrzarzycki21@gmail.com
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
> Problem-tp59595p59726.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
I went through the comments and I see that voices rather saying that we
shouldn't make automatic upgrades for the components, but since it is not
easy add this ability as an util, maybe we should introduce an interface -
IDynamic with property IsDynamic - setted by constructor or traditionally.
(of course I'm open for naming)

If user set it we will add Bead appropriately. 

Is it more PAYG ?

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59726.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
But from the developer point of view I see TextField - if text field has
inside one or three elements to upgrade ? 

As a developer I don't know nothing about component inside - I would like to
use it, dynamically. If I won't upgrade some internal components than
something won't be working. 

For example for RadioButton - ripple options wasn't work when I upgrade only
one part of RadioButton.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59722.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by "Guild, Jason A (DFG)" <ja...@alaska.gov>.
Alex:

Replies below...

On 2/21/2017 22:20, Alex Harui wrote:
> That said, we don't want the compiler generating code.  Everything else
> is converted to data structures so the framework can interpret the data
> structures.  The reason is mostly practical. It is scary for most folks to
> change the compiler.

I agree. When you put it this way maybe it is not the compiler 
generating additional code to setup strands with this or that beads, but 
is instead generating more data to be interpreted by the framework. Data 
that says "caller referenced 'disabled' attribute" on this component or 
container and that the reference "involved a binding expression". Then 
Express could pay attention to such data while maybe Basic does not.

> Express components could instantiate beads in the setter.  That sounds
> like a pattern worth more investigation. And you plug in the DisableBead without adding to the
> model.  The Express Button aggregates all of those things and probably
> more.

Yes. But I hope we can just say disabled="{ model.disabled }" on a 
component and have it auto-setup. And that the "disabled" attribute is 
just documented as part of the API of some component or container. When 
you use it you get it, when you don't then it's not there. That's PAYG 
in the truest sense.

I'm not for a moment debating how it is done, just that it is important 
for people new to FlexJS to be able to get productivity like the old 
Flex API gave us. Where you could look at the published docs, paste some 
code from it or Peter DeHaan's flex samples site and see that some 
feature "just works". Fairly generally, without a bunch of exceptions. 
Then you build out your app having seen how some specific feature is 
simply realized.

> In the end, all of this PAYG and beads and composition comes back to DRY.

I totally believe in DRY to the extent that it is practical. Composition 
is absolutely the right approach. But it remains to be seen whether the 
beads being developed can be made sufficiently generalized that they are 
composable without requiring leaky abstractions. For example, like a 
DisabledBead that just works for "everything". All components and 
containers no exceptions. Because it is a very basic thing to want to 
put a component or a complete hierarchy of components into a disabled 
state conveniently. Or that you just want to be able to add a child to a 
container at runtime. That's where I think the rub is compared to the 
old inheritance-based Flex API.

> One final thought:  I think of large hardware stores.  You go to the tool
> area and the number of screwdrivers or drills is overwhelming.  They are
> all slightly different, optimized for some particular scenario.  The same
> will be true for FlexJS and beads. Most of
> us manage to choose a screwdriver or drill that makes us happy.

Okay, well said.

Jason



Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.
Well, I agree that most FlexJS users will not be more productive having to
assemble everything from tons of little beads, and that's why I've been
saying for quite a while that I expect heavier component sets like Express
to be more popular.

That said, we don't want the compiler generating code.  With FlexJS, we
are trying hard not to generate any code out of the compiler.  I think I
have it down to just the getter/setters for [Bindable].  Everything else
is converted to data structures so the framework can interpret the data
structures.  The reason is mostly practical. It is scary for most folks to
change the compiler.  Better to put the bug fixing in the framework code
where most folks are more familiar.  But also, it means that different
frameworks can do different things with the data, and that allows testing
harnesses to muck with what actually happens which is useful if you want
to slip in mocks or test-only versions of things.

Express components could instantiate beads in the setter.  That sounds
like a pattern worth more investigation.  Basic components won't because
that would involve extending the model beyond the basic model.  A Basic
button doesn't even have a model, it doesn't have text or image
properties, or a disabled property.  A Basic TextButton adds on a
text/html property.  And you plug in the DisableBead without adding to the
model.  The Express Button aggregates all of those things and probably
more.

In the end, all of this PAYG and beads and composition comes back to DRY.
We encapsulate small chunks of useful code in beads so nobody else has to
write and debug it.  We compose it into heavier aggregations in various
ways: as a strand full of beads so individual beads can be replaced, and
as "inlined" heavy components so you don't have to waste time with all of
these little objects if you know you are going to use all of them most of
the time.

One final thought:  I think of large hardware stores.  You go to the tool
area and the number of screwdrivers or drills is overwhelming.  They are
all slightly different, optimized for some particular scenario.  The same
will be true for FlexJS and beads. But the cool thing about software is
that it will have the best "return policy".  Grab a bead, try it, toss it
if it doesn't work, check the reviews for what one to try next.  Most of
us manage to choose a screwdriver or drill that makes us happy.  We will
be able to choose beads as well, but we will need a good online
catalog/store for beads.  I hope to see us build one with FlexJS of course.

My 2 cents,
-Alex

On 2/21/17, 5:03 PM, "Guild, Jason A (DFG)" <ja...@alaska.gov> wrote:

>THIS.
>
>As an outsider looking in who also doesn't have much experience with
>FlexJS, I see the approach outlined below to be the best compromise
>between the "FlexJS the API" and PAYG for efficiency.
>
>I know it's just a step on the way, and I am positive that Express will
>be a big help, but I've been alarmed at the number of special-purpose
>beads and tags which have been proposed and implemented to get stuff
>done in a way that was what made Flex so productive in the first place.
>The developer is supposed to browse all of them and know which ones to
>compose together to get the basics?
>
>The approach given below effectively treats PAYG as a course-grained
>optimization pass.
>If the compiler detects that some feature is used and then hooks up the
>appropriate bead automatically then the developer just has to use the
>API and gets PAYG out-of-the-box. If the developer doesn't use a feature
>then the compiler doesn't generate code to set it up.
>
>Powerful concept.
>Jason
>
>
>On 2/21/2017 6:11, Dev LFM wrote:
>> I did not tried yet FlesJS, but I'm listening every post. I think those
>> beads should be added automatically and internally only if needed, ex:
>>
>> if some component have a binding tag like visible="{model.show}", this
>> would automatically add 2 beads, the binding bead and the
>>visibilitybead.
>> What I mean is that every component could be PAYG in the way that are
>>the
>> very basic in the beginning, but as the dev requires functionalities, it
>> should add them automatically. In the cases that the dev wants custom
>> beads, then it must overrides the method that set those beads.
>>
>> Maybe I'm missing some point..
>>
>> 2017-02-21 14:59 GMT+00:00 yishayw <yi...@hotmail.com>:
>>
>>> I agree. If you think this bead will be used very often you can create
>>>a
>>> subclass that bakes it in. ImageButton in Express is probably a good
>>> example, though I would use StrandUtils to save some code lines.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://apache-flex-
>>> development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
>>> Problem-tp59595p59712.html
>>> Sent from the Apache Flex Development mailing list archive at
>>>Nabble.com.
>>>
>


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by "Guild, Jason A (DFG)" <ja...@alaska.gov>.
THIS.

As an outsider looking in who also doesn't have much experience with 
FlexJS, I see the approach outlined below to be the best compromise 
between the "FlexJS the API" and PAYG for efficiency.

I know it's just a step on the way, and I am positive that Express will 
be a big help, but I've been alarmed at the number of special-purpose 
beads and tags which have been proposed and implemented to get stuff 
done in a way that was what made Flex so productive in the first place. 
The developer is supposed to browse all of them and know which ones to 
compose together to get the basics?

The approach given below effectively treats PAYG as a course-grained 
optimization pass.
If the compiler detects that some feature is used and then hooks up the 
appropriate bead automatically then the developer just has to use the 
API and gets PAYG out-of-the-box. If the developer doesn't use a feature 
then the compiler doesn't generate code to set it up.

Powerful concept.
Jason


On 2/21/2017 6:11, Dev LFM wrote:
> I did not tried yet FlesJS, but I'm listening every post. I think those
> beads should be added automatically and internally only if needed, ex:
>
> if some component have a binding tag like visible="{model.show}", this
> would automatically add 2 beads, the binding bead and the visibilitybead.
> What I mean is that every component could be PAYG in the way that are the
> very basic in the beginning, but as the dev requires functionalities, it
> should add them automatically. In the cases that the dev wants custom
> beads, then it must overrides the method that set those beads.
>
> Maybe I'm missing some point..
>
> 2017-02-21 14:59 GMT+00:00 yishayw <yi...@hotmail.com>:
>
>> I agree. If you think this bead will be used very often you can create a
>> subclass that bakes it in. ImageButton in Express is probably a good
>> example, though I would use StrandUtils to save some code lines.
>>
>>
>>
>> --
>> View this message in context: http://apache-flex-
>> development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
>> Problem-tp59595p59712.html
>> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>>


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Dev LFM <de...@gmail.com>.
I did not tried yet FlesJS, but I'm listening every post. I think those
beads should be added automatically and internally only if needed, ex:

if some component have a binding tag like visible="{model.show}", this
would automatically add 2 beads, the binding bead and the visibilitybead.
What I mean is that every component could be PAYG in the way that are the
very basic in the beginning, but as the dev requires functionalities, it
should add them automatically. In the cases that the dev wants custom
beads, then it must overrides the method that set those beads.

Maybe I'm missing some point..

2017-02-21 14:59 GMT+00:00 yishayw <yi...@hotmail.com>:

> I agree. If you think this bead will be used very often you can create a
> subclass that bakes it in. ImageButton in Express is probably a good
> example, though I would use StrandUtils to save some code lines.
>
>
>
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
> Problem-tp59595p59712.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Josh Tynjala <jo...@gmail.com>.
I think, since the core MDL library doesn't upgrade components by default,
it's okay if the FlexJS wrapper doesn't either. I think we should make sure
it's well documented, though. Maybe with a special section in the MDL
example app.

- Josh

On Feb 21, 2017 7:18 AM, "Carlos Rovira" <ca...@codeoscopic.com>
wrote:

What about to have a MDLUtils or UpgradeMDLUtils class with static methods?
So people that would create a component will do
"UpgradeUtils.upgradeElement(buttonToUpgrade);"
In this way people using a button 90% of times will not be affected by that
overhead.
(I'm thinking on a general scenario where 80-90% of uses are mxml
declaration vs 10-20 or less of dynamic creation)



2017-02-21 15:59 GMT+01:00 yishayw <yi...@hotmail.com>:

> I agree. If you think this bead will be used very often you can create a
> subclass that bakes it in. ImageButton in Express is probably a good
> example, though I would use StrandUtils to save some code lines.
>
>
>
> --
> View this message in context: http://apache-flex-development
> .2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59712.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



--

Carlos Rovira
Director General
M: +34 607 22 60 05 <607%2022%2060%2005>
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Carlos Rovira <ca...@codeoscopic.com>.
What about to have a MDLUtils or UpgradeMDLUtils class with static methods?
So people that would create a component will do
"UpgradeUtils.upgradeElement(buttonToUpgrade);"
In this way people using a button 90% of times will not be affected by that
overhead.
(I'm thinking on a general scenario where 80-90% of uses are mxml
declaration vs 10-20 or less of dynamic creation)



2017-02-21 15:59 GMT+01:00 yishayw <yi...@hotmail.com>:

> I agree. If you think this bead will be used very often you can create a
> subclass that bakes it in. ImageButton in Express is probably a good
> example, though I would use StrandUtils to save some code lines.
>
>
>
> --
> View this message in context: http://apache-flex-development
> .2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59712.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05 <607%2022%2060%2005>
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by yishayw <yi...@hotmail.com>.
I agree. If you think this bead will be used very often you can create a
subclass that bakes it in. ImageButton in Express is probably a good
example, though I would use StrandUtils to save some code lines.



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59712.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Hi Carlos,

Well at some point I agree, but there are components which you won't be able
to simple use this bead:

For example TextField. You cannot do such things:

var textField = new TextField();
textField.addBead(new UpgradeElement()) - cause this bead is registering
host.element and element is not always something what need to be upgraded.
Sometimes upgrades needs some internal components - Take a look how I use
UpgradeElement in TextField.

The other things RadioButton - It's also same or even worse, cause Radio
contains two components inside which need to be upgraded.

If we wanna add possibility to create such basic components dynamically I
don't see any other options. 

This bead is also for someone who will create custom component in FlexJS,
register it and will need to upgrade it during dynamic creation. - That's
the place where PAYG will work fully.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59711.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Piotr,

thanks for introducing the UpgradeElement bead. I saw that Button and
TextField add this element by default.
But that breaks IMHO the concept of PAYG. many people can use a button
without the need to have always that bead added. For me is the same example
that with TextField and Prompt or DisplayAsPassword. Is not needed 100% of
times

do you agree?

Thanks



2017-02-21 13:24 GMT+01:00 sankar <sa...@gmail.com>:

> Hi Piotr,
>
> On a separate thought, this following throws me error in "bin-release"
> version, but "bin-debug" doing good.
>
>
> >       if ("componentHandler" in document.defaultView)
> >         {
> >
> > document.defaultView["componentHandler"].upgradeElement(c.positioner);
> >         }
>
> I don't know what path you choose to update the window DOM, but you may
> want
> to keep an eye on "bin-release" version. The above code throws me exception
> as this:
>
> TypeError: document.defaultView.componentHandler.Cf is not a function
>
>
> Thanks!
>
>
>
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
> Problem-tp59595p59708.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
Hi Piotr,

On a separate thought, this following throws me error in "bin-release"
version, but "bin-debug" doing good.


> 	if ("componentHandler" in document.defaultView)
>         {
>               
> document.defaultView["componentHandler"].upgradeElement(c.positioner);
>         }

I don't know what path you choose to update the window DOM, but you may want
to keep an eye on "bin-release" version. The above code throws me exception
as this:

TypeError: document.defaultView.componentHandler.Cf is not a function


Thanks!



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59708.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
I think it's available - you can pull the source and try TextField and Button

I'm working next on adding UpgradeElement bead to RadioButton an Checkbox -
it's more tricky than adding it to TextField or Button.

Once I do this I will get back to work on Tabs.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59694.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
Hi Piotr,

Sound nice. Although I can't think about any one component but the feature
probably good to be default to all the components available in FlexJS MDL. 

Let me know when I should update latest source when you done with these.

I'm also hoping you get an answer to update Tabs as well.


Thanks!



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59692.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Sankar,

I just pushed UpgradeElement bead as part of fix for this jira. I've added
this bead as default to Button and TextField. You can from now on create
those components dynamically. 

Let me know to which component you want to add more this bead and I will
make the changes. 

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59688.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
Sounds good, Piotr.



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59685.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Sankar,

In case of standard component it is working and I'm going add Bead which
will be doing such upgrade - This bead will be default add to some
components. 

In case of TabBar I need to do some other things - probably this approach
which find me Om.

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59683.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
Hi,

I'm not sure if this is the right approach, but I took some ideas from Josh,
Alex and MDL library website, and modified UIBase.as class inside HTML
package. I modified it to this,


> public function addElement(c:IChild, dispatchEvent:Boolean = true):void
> {
>             COMPILE::JS
>             {
>             		var window:Object = document.defaultView;
>             		if("componentHandler" in window)
>             		{
>             		    window["componentHandler"].upgradeElement(c.positioner);
>             		}
> 
>                 element.appendChild(c.positioner);
>                 (c as IUIBase).addedToParent();
>             }
> }

I tested this works nice, although my tests was limited to adding TextField
and Button components at this moment. And TextField also didn't tooltip but
other features seems good to my initial tests!

Thanks!



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59680.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
Hi Piotr,

Thanks for the update. Previously I was updating dataProvider by using
<js:SimpleBinding/> but it anyway required me to change something in TabBar
source. Your fixed example showing more cleaner procedure now. I shall use
that.

I shall update my local source soon, hopefully dynamic child problem will
resolve soon.

Thanks!



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59672.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Sankar,

In case of adding Tab in TabBar I've already commit fix which prepare this
component for adding Tabs. Unfortunately I need also fix this jira with
dynamic child problem, cause once you add tab dynamically it stopped
working.

If you wanna try my fix you need to add to your css [1] and use as an source
binding Array list. TabBar component need to also use bead [2]
DataProviderChangeNotifier.

[1] https://paste.apache.org/m8G9
[2] https://paste.apache.org/4Kbk

Piotr




-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59669.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
piotrz wrote
> Deeper investigation points me to componentHandler.register method - It
> looks like created component need to be registered and maybe than
> upgradeElement method will work.
> 
> Method register take:
> 
> /**
>  * Describes the type of a registered component type managed by
>  * componentHandler. Provided for benefit of the Closure compiler.
>  *
>  * @typedef {{
>  *   constructor: Function,
>  *   classAsString: string,
>  *   cssClass: string,
>  *   widget: (string|boolean|undefined)
>  * }}
>  */
> componentHandler.ComponentConfigPublic;
> 
> How actually register my created Tab ? :)
> 
> Piotr

I'm not sure about if it (FlexJS components) needs to be registered, I took
out a simple test. I took the example that I supplied to the dynamic
add/remove tab requirement JIRA for this test. 

What I did is I added a basic 'setInterval' script in wrapper HTML which
calls a method and runs the 'componentHandler' methods. I made the
'setInterval' in few seconds' delay so I can add the dynamic child before
them.




After above command fired, I saw there still probably a few things not
working. Here's a list of things which I found worked and not-worked after
the command (I had TextField and Button only):

Worked:
1. Button ripple effect
2. TextField floating label
3. TextField expanding search field

Not worked:
1. TextField tooltip 
2. There could be some more.. 

So my point is, Piotr, it seems when FlexJS adds component to the HTML, they
anyway get registered or maybe they don't need to be explicitly registered
to get called for 'componentHandler' codes.

Thanks.



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59668.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Hi Om,

Thank you. I will give a try tomorrow and let you know!

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59662.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by OmPrakash Muppirala <bi...@gmail.com>.
Piotr,

I ran into this codepen from one of the issues in MDLs github

http://codepen.io/anon/pen/BNOVvw

Is that what we need to here?

Thanks,
Om

On Feb 19, 2017 7:47 AM, "piotrz" <pi...@gmail.com> wrote:

> Alex,
>
> Actually this code which I'm showing in the links is something which I
> wanted to achieve and should work. Maybe someone have more knowledge about
> MDL, but I'm looking into MDL code it's pointing me nowhere. I will wait a
> bit if no one help me here I will try to on stackoverflow.
>
> Piotr
>
>
>
> -----
> Apache Flex PMC
> piotrzarzycki21@gmail.com
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
> Problem-tp59595p59658.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Alex,

Actually this code which I'm showing in the links is something which I
wanted to achieve and should work. Maybe someone have more knowledge about
MDL, but I'm looking into MDL code it's pointing me nowhere. I will wait a
bit if no one help me here I will try to on stackoverflow. 

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59658.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Alex Harui <ah...@adobe.com>.
FWIW, one approach Peter and I often take is to start with the HTML that
you want to change, then write some JS to make it work.  That way, no Flex
code is getting in your way.  As Adobe employees we get to use Dreamweaver
for free so we use that, but I'm sure any other HTML/JS editor will work,
even JSFiddle which I've also used occasionally.  Then you can often more
easily see the patterns of code that need to be encapsulated and plugged
in somewhere.

HTH,
-Alex

On 2/19/17, 6:13 AM, "piotrz" <pi...@gmail.com> wrote:

>Deeper investigation points me to componentHandler.register method - It
>looks
>like created component need to be registered and maybe than upgradeElement
>method will work.
>
>Method register take:
>
>/**
> * Describes the type of a registered component type managed by
> * componentHandler. Provided for benefit of the Closure compiler.
> *
> * @typedef {{
> *   constructor: Function,
> *   classAsString: string,
> *   cssClass: string,
> *   widget: (string|boolean|undefined)
> * }}
> */
>componentHandler.ComponentConfigPublic;
>
>How actually register my created Tab ? :)
>
>Piotr
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Ch
>ild-Problem-tp59595p59652.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.


Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
Deeper investigation points me to componentHandler.register method - It looks
like created component need to be registered and maybe than upgradeElement
method will work.

Method register take:

/**
 * Describes the type of a registered component type managed by
 * componentHandler. Provided for benefit of the Closure compiler.
 *
 * @typedef {{
 *   constructor: Function,
 *   classAsString: string,
 *   cssClass: string,
 *   widget: (string|boolean|undefined)
 * }}
 */
componentHandler.ComponentConfigPublic;

How actually register my created Tab ? :)

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59652.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by piotrz <pi...@gmail.com>.
I was able to achieve adding element dynamically but upgradeElement is still
not working. Updated app [1]

[1] https://1drv.ms/u/s!ApVpLyjpHDC2zD1d1zd9PuXtmwmG

Piotr



-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59651.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Josh Tynjala <jo...@gmail.com>.
I used in MDL in a JS project recently, and I found that if I created MDL
components after the initial page load, I needed to run the following code
once they were added to the DOM:

if("componentHandler" in window)
{
    window["componentHandler"].upgradeAllRegistered();
}

My app was divided into several screens, so I simply called that whenever I
created a new screen, and all MDL components would be upgraded.

However, I don't think this exact function is the best choice for FlexJS
MDL components. I see that there's also an upgradeElement() method, and I
think that's probably what you want to use. A component can upgrade its own
DOM and it won't affect anything else.

https://github.com/google/material-design-lite/blob/mdl-1.x/src/mdlComponentHandler.js#L47

- Josh

On Fri, Feb 17, 2017 at 5:50 AM, Carlos Rovira <
carlos.rovira@codeoscopic.com> wrote:

> Hi Sankar,
>
> when using MDL standard (non flexjs version) how things are done to
> dinamicaly create some component?
> Since FlexJS MDL is a "wrap" over MDL js/css libraries, what we should
> envision is the way to "flex"-ify the things
> coming from MDL world. So I propose that investigate the problem and see
> how it's done in JS to provide some clues
> for a solution.
>
>
> 2017-02-17 12:56 GMT+01:00 sankar <sa...@gmail.com>:
>
> > Hi,
> >
> > There's a critical and major problem exists with dynamic child creation
> in
> > MDL structure.
> >
> > I've reported this to JIRA at:
> > https://issues.apache.org/jira/browse/FLEX-35269.
> >
> > Request to look into this once.
> >
> > Thanks!
> >
> >
> >
> > --
> > View this message in context: http://apache-flex-
> > development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
> > Problem-tp59595.html
> > Sent from the Apache Flex Development mailing list archive at Nabble.com.
> >
>
>
>
> --
>
> Carlos Rovira
> Director General
> M: +34 607 22 60 05
> http://www.codeoscopic.com
> http://www.avant2.es
>
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> información privilegiada o confidencial. Si ha recibido este mensaje por
> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> proceda a su destrucción.
>
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> servicio o información solicitados, teniendo usted derecho de acceso,
> rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> necesaria.
>

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by sankar <sa...@gmail.com>.
Hi Carlos,

Is this makes some sense? -
http://stackoverflow.com/questions/32363511/how-can-i-update-refresh-google-mdl-elements-that-i-add-to-my-page-dynamically
(the answer part). I'm not very familiar with DOM development, though.

Thanks!



--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59611.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Sankar,

when using MDL standard (non flexjs version) how things are done to
dinamicaly create some component?
Since FlexJS MDL is a "wrap" over MDL js/css libraries, what we should
envision is the way to "flex"-ify the things
coming from MDL world. So I propose that investigate the problem and see
how it's done in JS to provide some clues
for a solution.


2017-02-17 12:56 GMT+01:00 sankar <sa...@gmail.com>:

> Hi,
>
> There's a critical and major problem exists with dynamic child creation in
> MDL structure.
>
> I've reported this to JIRA at:
> https://issues.apache.org/jira/browse/FLEX-35269.
>
> Request to look into this once.
>
> Thanks!
>
>
>
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
> Problem-tp59595.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.