Re: git commit: [flex-asjs] [refs/heads/develop] - MDL Tooltip

[piotrz]

I'm ok with 

referenceNode.parentNode.insertBefore(newNode, referenceNode.nextSibling); 

But still additionally have to have on our host component set up some id and
inside Tooltip fill "for". 

I think we should whenever we can create things in "Flex" or "FlexJS" way -
To give possibility for developer use it in a "Flex" way.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-develop-MDL-Tooltip-tp56939p56962.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Alex Harui]

What does your code look like?  Sounds like DataItemRenderers are still
being created and added.

I think the display: block is from VerticalLayout.  It uses that to tell
the browser to lay things out vertically.  position: relative might also
come from the layout or some container logic as we've seen before.

-Alex

On 12/2/16, 4:41 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>One more thing,
>Where come from the 8px width in List?
>The styles in items are as well suspicious
>
>
>2016-12-03 1:37 GMT+01:00 Carlos Rovira :
>
>> Hi,
>>
>> just integrate the new List component and beads in MDL. As I changed it
>> and introduced a custom item renderer (called
>>itemRenderers/ListItemRenderer.as)
>> in MDLExample (that is what people will do), I found a strange
>>behaviour.
>> The custom IR is running since I put a trace statement and I see one
>>trace
>> for each item renderer. but the createElement is not running, I'm
>>getting:
>>
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> the inner divs was having in other test class="DataItemRenderer"
>>
>> but I have a createElement method in my ItemRenderer:
>>
>> /**
>>  * @flexjsignorecoercion org.apache.flex.core.WrappedHTMLElement
>>  */
>> COMPILE::JS
>> override protected function createElement():WrappedHTMLElement
>> {
>> typeNames = "mdl-list__item";
>>
>> element = document.createElement('li') as
>>WrappedHTMLElement;
>>
>> positioner = element;
>> element.flexjs_wrapper = this;
>>
>> // itemRenderers should provide something for the background
>> to handle
>> // the selection and highlight
>> backgroundView = element;
>>
>> return element;
>> }
>>
>> Do you know what could be happen here? After lots of test I'm lost...
>>
>>
>>
>> 2016-12-02 23:27 GMT+01:00 Carlos Rovira
>>:
>>
>>> Hi Peter,
>>>
>>> so cool! I just created the pom.xml and fill the licenses to build with
>>> maven. Run the example and check the code. I still eating that food to
>>>be
>>> able to comment, but seems what I expect :)
>>>
>>> So many thanks, I'll be playing with it in the following days to apply
>>>to
>>> MDL components
>>>
>>> I think Alex and you has some issue that you want to work on, I'll be
>>> incorporating whatever upgrade you made. I think this is an important
>>> component where the power of flex comes clearly and if we could get as
>>> simpler as possible that will be great.
>>>
>>> Thanks!
>>>
>>> Carlos
>>>
>>>
>>>
>>> 2016-12-02 22:37 GMT+01:00 Alex Harui :
>>>
 This seems mostly right to me.  The top-level component is aggregating
 the
 interfaces onto itself.  More inline...

 On 12/2/16, 12:41 PM, "Peter Ent"  wrote:
 >
 >GenericListView does not extend ListView because that leads to this
 >nesting business we are trying to avoid. Instead, it just extends
 >BeadViewBase and implements IListView (so it can provide the
dataGroup
 for
 >the itemRenderer factory which will be the strand/GenericList
itself).
 >This class makes sure the itemRenderer factory bead is installed and
 >listens for changes to the dataProvider in the model.

 Isn't the real issue that it is ContainerView that ListView extends
that
 makes the assumption that it has to add a viewport to the strand?  I
 think
 that's ok though.  As Harbs said in another thread, or maybe upthread,
 there will be Container views for heavy containers with inner content
 areas and Container views for lightweight containers without inner
 content
 areas.  The current ContainerView is the heavy one.  You have probably
 just written the lightweight one or can factor it out of your
 GenericListView.  Might be time to rename the current ContainerView to
 ContainerWithContentAreaView and make the lighter one the new
 ContainerView.

 >
 >Finally, I had to copy DataItemRendererFactoryForArrayData into a new
 >class because it explicitly references the org.apache.flex.html.List
 class
 >in order to pass along the labelField to each itemRenderer. This, to
me,
 >is a problem that needs to be addressed. I probably wrote this
 originally,
 >but now it must be revisited and corrected.

 In theory, the labelField should be in the model and retrieved from
 there.

 My 2 cents,
 -Alex


>>>
>>>
>>> --
>>>
>>> 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 

Re: [FlexJS] Unexpected TextButton word wrapping

[Alex Harui]

Sounds ok to me.  We are using nowrap on Label already.

On 12/2/16, 4:22 PM, "Josh Tynjala"  wrote:

>I noticed that the default behavior for a TextButton is kind of weird.
>Depending on how long the text is and how large the font size, it starts
>wrapping to the next line for no particular reason. You don't even need to
>set the width or max-width. This doesn't look great, and I found it
>unintuitive.
>
>I found that adding the following CSS for TextButton ensured that the text
>doesn't wrap by default:
>
>white-space: nowrap;
>overflow: hidden;
>text-overflow: ellipsis;
>
>If the width or max-width of the button is set, the text will be truncated
>with ellipsis (...) if it's too long.
>
>This seems like a better default to me. If we wanted to make it easy to
>enable wrapping, maybe we could expose the white-space through
>SimpleCSSStyles. Setting it to "normal" instead of "nowrap" will re-enable
>wrapping, if that's what is desired.
>
>- Josh

Re: Snippets for FlexJS

[Alex Harui]

On 12/2/16, 5:07 PM, "Christian Gotschim"  wrote:

>
>I guess for something where I can read the most common properties
>and styles from. Let’s take the org.apache.flex.html.Button.json: it lists
>only the constructor and the click event. But I still don’t know how
>to (or if I can) set x and y, or if it got left-right-top-bottom, or
>width/height to name
>just a few. And those are exactly the things I wanted to put in the
>snippets (and possibly a documentation website along the way).
>I also couldn’t find any default values included in the JSON files
>(i.e. selected on a CheckBox), no possible values (i.e. true/false for
>CheckBox), no type info (i.e. Boolean for selected).

Wow, you're right there is information missing.  I'll look into adding it.
 You will have to chase down baseClassNames though.  CheckBox doesn't
really have much, most of what it you are looking for it will get from
UIButtonBase.

>
>The html5.Button.json for instance only has this in it:
>
>{ "type": "class",
>  "qname": "org.apache.flex.html5.Button",
>  "baseClassname": "org.apache.flex.html.Button",
>  }
>
>Ok, going to the base class I get only the constructor and click
>event (see top).
>

Same thing. You'll have to keep chasing baseClassnames from Button to
ButtonBase to UIButtonBase.

>
>I wanted to mainly have a list of MXML components so people could
>just insert the snippet, change the already presented values, and then
>go from there knowing that the properties they set are relevant.
>
>The other day I tried modifying the Hello World example a bit by
>changing properties of a js:Label
>
>   lbl2.width  = 300;
>   lbl2.height = 300;
>   lbl2.scaleY = 3;
>   lbl2.alpha  = 0.5;
>   lbl2.rotation   = 45;
>   lbl2.x  = 200;
>   lbl2.scaleX = 0.5;
>
>… and found out that only the alpha and x changed on the label, while
>the other settings didn’t produce an error but also didn’t do anything.
>
>Any ideas?

One of the things I'm working on is exactly this problem.  The SWF classes
might be based on Sprite and so will look like they have scaleX/Y, but the
JS version of those classes won't have those APIs (yet).  The goal is to
get the compiler to report errors about the use of APIs missing on the JS
classes.

-Alex

Re: Snippets for FlexJS

[Christian Gotschim]

I guess for something where I can read the most common properties
and styles from. Let’s take the org.apache.flex.html.Button.json: it lists
only the constructor and the click event. But I still don’t know how
to (or if I can) set x and y, or if it got left-right-top-bottom, or 
width/height to name
just a few. And those are exactly the things I wanted to put in the
snippets (and possibly a documentation website along the way).
I also couldn’t find any default values included in the JSON files
(i.e. selected on a CheckBox), no possible values (i.e. true/false for
CheckBox), no type info (i.e. Boolean for selected).

The html5.Button.json for instance only has this in it:

{ "type": "class",
  "qname": "org.apache.flex.html5.Button",
  "baseClassname": "org.apache.flex.html.Button",
  }

Ok, going to the base class I get only the constructor and click
event (see top).


I wanted to mainly have a list of MXML components so people could
just insert the snippet, change the already presented values, and then
go from there knowing that the properties they set are relevant.

The other day I tried modifying the Hello World example a bit by
changing properties of a js:Label

lbl2.width  = 300;
lbl2.height = 300;
lbl2.scaleY = 3;
lbl2.alpha  = 0.5;
lbl2.rotation   = 45;
lbl2.x  = 200;
lbl2.scaleX = 0.5;

… and found out that only the alpha and x changed on the label, while
the other settings didn’t produce an error but also didn’t do anything.

Any ideas?

- Christian



> On Dec 3, 2016, at 1:12 AM, Alex Harui  wrote:
> 
> 
> 
> On 12/2/16, 2:14 PM, "Christian Gotschim"  wrote:
> 
>> OK, got the zip and looking at it. At first glance not really what I was
>> hoping for, but I’ll see.
> 
> What were you hoping for?
> 
> -Alex
> 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Carlos Rovira]

One more thing,
Where come from the 8px width in List?
The styles in items are as well suspicious


2016-12-03 1:37 GMT+01:00 Carlos Rovira :

> Hi,
>
> just integrate the new List component and beads in MDL. As I changed it
> and introduced a custom item renderer (called 
> itemRenderers/ListItemRenderer.as)
> in MDLExample (that is what people will do), I found a strange behaviour.
> The custom IR is running since I put a trace statement and I see one trace
> for each item renderer. but the createElement is not running, I'm getting:
>
> 
> 
> 
> 
> 
> 
>
> the inner divs was having in other test class="DataItemRenderer"
>
> but I have a createElement method in my ItemRenderer:
>
> /**
>  * @flexjsignorecoercion org.apache.flex.core.WrappedHTMLElement
>  */
> COMPILE::JS
> override protected function createElement():WrappedHTMLElement
> {
> typeNames = "mdl-list__item";
>
> element = document.createElement('li') as WrappedHTMLElement;
>
> positioner = element;
> element.flexjs_wrapper = this;
>
> // itemRenderers should provide something for the background
> to handle
> // the selection and highlight
> backgroundView = element;
>
> return element;
> }
>
> Do you know what could be happen here? After lots of test I'm lost...
>
>
>
> 2016-12-02 23:27 GMT+01:00 Carlos Rovira :
>
>> Hi Peter,
>>
>> so cool! I just created the pom.xml and fill the licenses to build with
>> maven. Run the example and check the code. I still eating that food to be
>> able to comment, but seems what I expect :)
>>
>> So many thanks, I'll be playing with it in the following days to apply to
>> MDL components
>>
>> I think Alex and you has some issue that you want to work on, I'll be
>> incorporating whatever upgrade you made. I think this is an important
>> component where the power of flex comes clearly and if we could get as
>> simpler as possible that will be great.
>>
>> Thanks!
>>
>> Carlos
>>
>>
>>
>> 2016-12-02 22:37 GMT+01:00 Alex Harui :
>>
>>> This seems mostly right to me.  The top-level component is aggregating
>>> the
>>> interfaces onto itself.  More inline...
>>>
>>> On 12/2/16, 12:41 PM, "Peter Ent"  wrote:
>>> >
>>> >GenericListView does not extend ListView because that leads to this
>>> >nesting business we are trying to avoid. Instead, it just extends
>>> >BeadViewBase and implements IListView (so it can provide the dataGroup
>>> for
>>> >the itemRenderer factory which will be the strand/GenericList itself).
>>> >This class makes sure the itemRenderer factory bead is installed and
>>> >listens for changes to the dataProvider in the model.
>>>
>>> Isn't the real issue that it is ContainerView that ListView extends that
>>> makes the assumption that it has to add a viewport to the strand?  I
>>> think
>>> that's ok though.  As Harbs said in another thread, or maybe upthread,
>>> there will be Container views for heavy containers with inner content
>>> areas and Container views for lightweight containers without inner
>>> content
>>> areas.  The current ContainerView is the heavy one.  You have probably
>>> just written the lightweight one or can factor it out of your
>>> GenericListView.  Might be time to rename the current ContainerView to
>>> ContainerWithContentAreaView and make the lighter one the new
>>> ContainerView.
>>>
>>> >
>>> >Finally, I had to copy DataItemRendererFactoryForArrayData into a new
>>> >class because it explicitly references the org.apache.flex.html.List
>>> class
>>> >in order to pass along the labelField to each itemRenderer. This, to me,
>>> >is a problem that needs to be addressed. I probably wrote this
>>> originally,
>>> >but now it must be revisited and corrected.
>>>
>>> In theory, the labelField should be in the model and retrieved from
>>> there.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>>
>>
>>
>> --
>>
>> 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.
>>
>>
>
>
> --
>
> Carlos Rovira
> Director General
> M: +34 607 22 60 05 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Carlos Rovira]

Hi,

just integrate the new List component and beads in MDL. As I changed it and
introduced a custom item renderer (called
itemRenderers/ListItemRenderer.as) in MDLExample (that is what people will
do), I found a strange behaviour. The custom IR is running since I put a
trace statement and I see one trace for each item renderer. but the
createElement is not running, I'm getting:








the inner divs was having in other test class="DataItemRenderer"

but I have a createElement method in my ItemRenderer:

/**
 * @flexjsignorecoercion org.apache.flex.core.WrappedHTMLElement
 */
COMPILE::JS
override protected function createElement():WrappedHTMLElement
{
typeNames = "mdl-list__item";

element = document.createElement('li') as WrappedHTMLElement;

positioner = element;
element.flexjs_wrapper = this;

// itemRenderers should provide something for the background to
handle
// the selection and highlight
backgroundView = element;

return element;
}

Do you know what could be happen here? After lots of test I'm lost...



2016-12-02 23:27 GMT+01:00 Carlos Rovira :

> Hi Peter,
>
> so cool! I just created the pom.xml and fill the licenses to build with
> maven. Run the example and check the code. I still eating that food to be
> able to comment, but seems what I expect :)
>
> So many thanks, I'll be playing with it in the following days to apply to
> MDL components
>
> I think Alex and you has some issue that you want to work on, I'll be
> incorporating whatever upgrade you made. I think this is an important
> component where the power of flex comes clearly and if we could get as
> simpler as possible that will be great.
>
> Thanks!
>
> Carlos
>
>
>
> 2016-12-02 22:37 GMT+01:00 Alex Harui :
>
>> This seems mostly right to me.  The top-level component is aggregating the
>> interfaces onto itself.  More inline...
>>
>> On 12/2/16, 12:41 PM, "Peter Ent"  wrote:
>> >
>> >GenericListView does not extend ListView because that leads to this
>> >nesting business we are trying to avoid. Instead, it just extends
>> >BeadViewBase and implements IListView (so it can provide the dataGroup
>> for
>> >the itemRenderer factory which will be the strand/GenericList itself).
>> >This class makes sure the itemRenderer factory bead is installed and
>> >listens for changes to the dataProvider in the model.
>>
>> Isn't the real issue that it is ContainerView that ListView extends that
>> makes the assumption that it has to add a viewport to the strand?  I think
>> that's ok though.  As Harbs said in another thread, or maybe upthread,
>> there will be Container views for heavy containers with inner content
>> areas and Container views for lightweight containers without inner content
>> areas.  The current ContainerView is the heavy one.  You have probably
>> just written the lightweight one or can factor it out of your
>> GenericListView.  Might be time to rename the current ContainerView to
>> ContainerWithContentAreaView and make the lighter one the new
>> ContainerView.
>>
>> >
>> >Finally, I had to copy DataItemRendererFactoryForArrayData into a new
>> >class because it explicitly references the org.apache.flex.html.List
>> class
>> >in order to pass along the labelField to each itemRenderer. This, to me,
>> >is a problem that needs to be addressed. I probably wrote this
>> originally,
>> >but now it must be revisited and corrected.
>>
>> In theory, the labelField should be in the model and retrieved from there.
>>
>> My 2 cents,
>> -Alex
>>
>>
>
>
> --
>
> 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.
>
>


-- 

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 

[FlexJS] Unexpected TextButton word wrapping

[Josh Tynjala]

I noticed that the default behavior for a TextButton is kind of weird.
Depending on how long the text is and how large the font size, it starts
wrapping to the next line for no particular reason. You don't even need to
set the width or max-width. This doesn't look great, and I found it
unintuitive.

I found that adding the following CSS for TextButton ensured that the text
doesn't wrap by default:

white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;

If the width or max-width of the button is set, the text will be truncated
with ellipsis (...) if it's too long.

This seems like a better default to me. If we wanted to make it easy to
enable wrapping, maybe we could expose the white-space through
SimpleCSSStyles. Setting it to "normal" instead of "nowrap" will re-enable
wrapping, if that's what is desired.

- Josh

Re: [1/2] git commit: [flex-asjs] [refs/heads/develop] - SliderTrackView: ignore coercion of WrappedHTMLElement

[Alex Harui]

On 12/2/16, 4:10 PM, "Josh Tynjala"  wrote:

>Someone just mentioned to me that the Basic project no longer gets built,
>and I guess that I need to make changes to a different project. Is it HTML
>now? Maybe we should remove the Basic project code to avoid confusion, and
>if anything needs to be restored later, we can find it in the history.

I have changes locally that will build Basic.  They should be ok to push
in a day or two.  Basic is the old unwrapped Sprite code.  HTML is a copy
of it with wrapped Sprites.  Hopefully we can go back to having only one
copy soon.

I'd rather not remove Basic, but it is ok for folks to focus on HTML.  We
can sync them up later.

Thanks,
-Alex

Re: Snippets for FlexJS

[Alex Harui]

On 12/2/16, 2:14 PM, "Christian Gotschim"  wrote:

>OK, got the zip and looking at it. At first glance not really what I was
>hoping for, but I’ll see.

What were you hoping for?

-Alex

Re: [1/2] git commit: [flex-asjs] [refs/heads/develop] - SliderTrackView: ignore coercion of WrappedHTMLElement

[Josh Tynjala]

Someone just mentioned to me that the Basic project no longer gets built,
and I guess that I need to make changes to a different project. Is it HTML
now? Maybe we should remove the Basic project code to avoid confusion, and
if anything needs to be restored later, we can find it in the history.

- Josh

On Fri, Dec 2, 2016 at 3:06 PM,  wrote:

> Repository: flex-asjs
> Updated Branches:
>   refs/heads/develop aea0364bc -> 7eef1e435
>
>
> SliderTrackView: ignore coercion of WrappedHTMLElement
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/1d39b6eb
> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/1d39b6eb
> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/1d39b6eb
>
> Branch: refs/heads/develop
> Commit: 1d39b6eb9c8e7ccd045cfa0f8faeb79c3a38976a
> Parents: 4e7c736
> Author: Josh Tynjala 
> Authored: Fri Dec 2 15:05:40 2016 -0800
> Committer: Josh Tynjala 
> Committed: Fri Dec 2 15:05:40 2016 -0800
>
> --
>  .../src/main/flex/org/apache/flex/html/beads/SliderTrackView.as | 1 +
>  1 file changed, 1 insertion(+)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> 1d39b6eb/frameworks/projects/Basic/src/main/flex/org/
> apache/flex/html/beads/SliderTrackView.as
> --
> diff --git 
> a/frameworks/projects/Basic/src/main/flex/org/apache/flex/html/beads/SliderTrackView.as
> b/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> html/beads/SliderTrackView.as
> index 4290ac7..eac9d32 100644
> --- a/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> html/beads/SliderTrackView.as
> +++ b/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> html/beads/SliderTrackView.as
> @@ -89,6 +89,7 @@ package org.apache.flex.html.beads
>  *  @playerversion Flash 10.2
>  *  @playerversion AIR 2.6
>  *  @productversion FlexJS 0.0
> + *  @flexjsignorecoercion org.apache.flex.core.WrappedHTMLElement
>  */
> override public function set strand(value:IStrand):void
> {
>
>

Re: [FlexJS] Slider valueChange not working

[Carlos Rovira]

I'd want to bring this again since I think it passed unnoticed.

I think SliderView was never used and if you try to put in place it gives
lots of errors. Hope Alex or Peter could take a look since I'll need it to
continue work on MDL Slider.

Thanks



2016-12-01 18:40 GMT+01:00 Carlos Rovira :

> Hi Alex,
>
> I'm trying to bring the beads I removed while excluding default.css and
> one thing I found is that SliderView is not declared in basic-manifest ergo
> not shipping with HTML.swc and it can't be found when compile MDLExample.
> If I try to add it throws lots of errors.
> I think we should have some basic examples of components to easily detect
> this things like that. maybe this component could be invalid right now
> since nobody saw its view was not working, and several refractors has
> happened in the last months. In this case I'm seeing lots of problems with
> flash.display.Sprite and DisplayObject.
>
> Could you take a look and see if you can update it to working?. After that
> I will continue updating the MDL:Slider
>
> Thanks
>
>
> 2016-12-01 1:30 GMT+01:00 Alex Harui :
>
>> Slider is not a built-in in regular HTML so it has a model, view and
>> controller beads.  IIRC, you are kicking out a lot of default CSS that
>> defines those beads.  Have you explicitly brought them in?  Otherwise the
>> SliderMouseController may not be running.
>>
>> -Alex
>>
>> On 11/30/16, 3:20 PM, "carlos.rov...@gmail.com on behalf of Carlos
>> Rovira"
>>  wrote:
>>
>> >Hi
>> >
>> >can someone confirm that js:Slide is working?
>> >
>> >I created mdl:Slider from js:Slider and I'm trying to use the event
>> >"valueChange", but I think is not implemented.
>> >I'm trying to search in examples but seems is not used yet. I expect to
>> >get
>> >some example of use to apply in my example...
>> >
>> >I seek for
>> >
>> > valueChange="comp.property = slider.value"
>> >
>> >but without luck
>> >
>> >thanks
>> >
>> >
>> >--
>> >Carlos Rovira
>> >http://about.me/carlosrovira
>>
>>
>
>
> --
>
> 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.
>
>


-- 

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: git commit: [flex-asjs] [refs/heads/develop] - MDL Tooltip

[Carlos Rovira]

Hi,

just committed the properties left in Tooltip. I think as well it could be
converted to a bead.
I will go now with the List example Peter did, so feel free to change
Tooltip to a bead if you want

thanks!

2016-12-02 23:10 GMT+01:00 OmPrakash Muppirala :

> That's an interesting suggestion.  In Flex or even html, we specify a
> 'tooltip' attribute or 'title' attribute.  MDL makes it a bit more
> complicated by treating the component and the tooltip as different entities
> and then inventing a new way to connect them.
>
> Specifying it as a bead seems like the natural and correct thing to do in
> the 'FlexJS way'.
>
> Thanks,
> Om
>
> On Fri, Dec 2, 2016 at 2:02 PM, Carlos Rovira <
> carlos.rov...@codeoscopic.com
> > wrote:
>
> > I though on it too, but in MDL they created a separate div that relates
> to
> > the target component by id. For that reason I follow the most natural
> path
> > that is separate. If not I think we could make a bead, but then instead
> of
> > "append" to target it should be write "nextto". I search a bit and I
> think
> > this is done in this way:
> >
> > referenceNode.parentNode.insertBefore(newNode,
> referenceNode.nextSibling);
> >
> > so what do you think?
> >
> >
> > 2016-12-02 21:14 GMT+01:00 Piotr Zarzycki :
> >
> > > Hi Carlos,
> > >
> > > Maybe Tooltip should be a Bead ? Just my first thought when I saw how
> > > example look like.
> > >
> > > Piotr
> > >
> > > 2016-12-02 15:46 GMT+01:00 :
> > >
> > > > Repository: flex-asjs
> > > > Updated Branches:
> > > >   refs/heads/develop 5aebf86cb -> 4e7c7361d
> > > >
> > > >
> > > > MDL Tooltip
> > > >
> > > >
> > > > Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> > > > Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/
> > 4e7c7361
> > > > Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/4e7c7361
> > > > Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/4e7c7361
> > > >
> > > > Branch: refs/heads/develop
> > > > Commit: 4e7c7361d579f24a43645c3a524078389d1862e6
> > > > Parents: 5aebf86
> > > > Author: Carlos Rovira 
> > > > Authored: Fri Dec 2 15:46:22 2016 +0100
> > > > Committer: Carlos Rovira 
> > > > Committed: Fri Dec 2 15:46:22 2016 +0100
> > > >
> > > > 
> --
> > > >  .../MDLExample/src/main/flex/Buttons.mxml   |   3 +-
> > > >  .../main/flex/org/apache/flex/mdl/Tooltip.as| 137
> > > +++
> > > >  .../src/main/resources/mdl-manifest.xml |   1 +
> > > >  3 files changed, 140 insertions(+), 1 deletion(-)
> > > > 
> --
> > > >
> > > >
> > > > http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> > > > 4e7c7361/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > > > 
> --
> > > > diff --git a/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > > > b/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > > > index 7879fad..73edb28 100644
> > > > --- a/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > > > +++ b/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > > > @@ -31,11 +31,12 @@ limitations under the License.
> > > >
> > > >  
> > > >  
> > > > -
> > > > +
> > > >  
> > > >  
> > > >  
> > > >  
> > > > + dataMdlFor="mybtn"/>
> > > >  
> > > >
> > > >  
> > > >
> > > > http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> > > > 4e7c7361/frameworks/projects/MaterialDesignLite/src/main/
> > > > flex/org/apache/flex/mdl/Tooltip.as
> > > > 
> --
> > > > diff --git a/frameworks/projects/MaterialDesignLite/src/main/
> > > > flex/org/apache/flex/mdl/Tooltip.as b/frameworks/projects/
> > > > MaterialDesignLite/src/main/flex/org/apache/flex/mdl/Tooltip.as
> > > > new file mode 100644
> > > > index 000..e3b519d
> > > > --- /dev/null
> > > > +++ b/frameworks/projects/MaterialDesignLite/src/main/
> > > > flex/org/apache/flex/mdl/Tooltip.as
> > > > @@ -0,0 +1,137 @@
> > > > +///
> > > > /
> > > > +//
> > > > +//  Licensed to the Apache Software Foundation (ASF) under one or
> more
> > > > +//  contributor license agreements.  See the NOTICE file distributed
> > > with
> > > > +//  this work for additional information regarding copyright
> > ownership.
> > > > +//  The ASF licenses this file to You under the Apache License,
> > Version
> > > > 2.0
> > > > +//  (the "License"); you may not use this file except in compliance
> > with
> > > > +//  the License.  You may obtain a copy of the License at
> > > > +//
> > 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Carlos Rovira]

Hi Peter,

so cool! I just created the pom.xml and fill the licenses to build with
maven. Run the example and check the code. I still eating that food to be
able to comment, but seems what I expect :)

So many thanks, I'll be playing with it in the following days to apply to
MDL components

I think Alex and you has some issue that you want to work on, I'll be
incorporating whatever upgrade you made. I think this is an important
component where the power of flex comes clearly and if we could get as
simpler as possible that will be great.

Thanks!

Carlos



2016-12-02 22:37 GMT+01:00 Alex Harui :

> This seems mostly right to me.  The top-level component is aggregating the
> interfaces onto itself.  More inline...
>
> On 12/2/16, 12:41 PM, "Peter Ent"  wrote:
> >
> >GenericListView does not extend ListView because that leads to this
> >nesting business we are trying to avoid. Instead, it just extends
> >BeadViewBase and implements IListView (so it can provide the dataGroup for
> >the itemRenderer factory which will be the strand/GenericList itself).
> >This class makes sure the itemRenderer factory bead is installed and
> >listens for changes to the dataProvider in the model.
>
> Isn't the real issue that it is ContainerView that ListView extends that
> makes the assumption that it has to add a viewport to the strand?  I think
> that's ok though.  As Harbs said in another thread, or maybe upthread,
> there will be Container views for heavy containers with inner content
> areas and Container views for lightweight containers without inner content
> areas.  The current ContainerView is the heavy one.  You have probably
> just written the lightweight one or can factor it out of your
> GenericListView.  Might be time to rename the current ContainerView to
> ContainerWithContentAreaView and make the lighter one the new
> ContainerView.
>
> >
> >Finally, I had to copy DataItemRendererFactoryForArrayData into a new
> >class because it explicitly references the org.apache.flex.html.List class
> >in order to pass along the labelField to each itemRenderer. This, to me,
> >is a problem that needs to be addressed. I probably wrote this originally,
> >but now it must be revisited and corrected.
>
> In theory, the labelField should be in the model and retrieved from there.
>
> My 2 cents,
> -Alex
>
>


-- 

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: Snippets for FlexJS

[Christian Gotschim]

OK, got the zip and looking at it. At first glance not really what I was
hoping for, but I’ll see. 

- Christian



> On Dec 2, 2016, at 6:53 PM, Alex Harui  wrote:
> 
> 
> 
> On 12/1/16, 10:41 PM, "Christian Gotschim"  wrote:
> 
>> 
>>> If you know Java, you could write a custom ASDoc emitter.  I've written
>>> one that outputs ASDoc information in JSON format.  Or you could write a
>>> Flex or FlexJS app to read the JSON files and generate the MXML you
>>> want.
>> 
>> I don’t know Java. I’d have to see the JSON file first to see if I can get
>> the necessary info out of that. Can you send it to me?
> 
> The JSON files are posted at [1].  The content/format of these files can
> be modified by changing the Java code in the compiler.
> 
> The list of all classes is in classes.json.  Individual classes have their
> own file.
> 
> [1] http://home.apache.org/~aharui/FlexJS/asdoc-output.zip
> 
> 
> Thanks,
> -Alex
> 

Re: git commit: [flex-asjs] [refs/heads/develop] - MDL Tooltip

[OmPrakash Muppirala]

That's an interesting suggestion.  In Flex or even html, we specify a
'tooltip' attribute or 'title' attribute.  MDL makes it a bit more
complicated by treating the component and the tooltip as different entities
and then inventing a new way to connect them.

Specifying it as a bead seems like the natural and correct thing to do in
the 'FlexJS way'.

Thanks,
Om

On Fri, Dec 2, 2016 at 2:02 PM, Carlos Rovira  wrote:

> I though on it too, but in MDL they created a separate div that relates to
> the target component by id. For that reason I follow the most natural path
> that is separate. If not I think we could make a bead, but then instead of
> "append" to target it should be write "nextto". I search a bit and I think
> this is done in this way:
>
> referenceNode.parentNode.insertBefore(newNode, referenceNode.nextSibling);
>
> so what do you think?
>
>
> 2016-12-02 21:14 GMT+01:00 Piotr Zarzycki :
>
> > Hi Carlos,
> >
> > Maybe Tooltip should be a Bead ? Just my first thought when I saw how
> > example look like.
> >
> > Piotr
> >
> > 2016-12-02 15:46 GMT+01:00 :
> >
> > > Repository: flex-asjs
> > > Updated Branches:
> > >   refs/heads/develop 5aebf86cb -> 4e7c7361d
> > >
> > >
> > > MDL Tooltip
> > >
> > >
> > > Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> > > Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/
> 4e7c7361
> > > Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/4e7c7361
> > > Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/4e7c7361
> > >
> > > Branch: refs/heads/develop
> > > Commit: 4e7c7361d579f24a43645c3a524078389d1862e6
> > > Parents: 5aebf86
> > > Author: Carlos Rovira 
> > > Authored: Fri Dec 2 15:46:22 2016 +0100
> > > Committer: Carlos Rovira 
> > > Committed: Fri Dec 2 15:46:22 2016 +0100
> > >
> > > --
> > >  .../MDLExample/src/main/flex/Buttons.mxml   |   3 +-
> > >  .../main/flex/org/apache/flex/mdl/Tooltip.as| 137
> > +++
> > >  .../src/main/resources/mdl-manifest.xml |   1 +
> > >  3 files changed, 140 insertions(+), 1 deletion(-)
> > > --
> > >
> > >
> > > http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> > > 4e7c7361/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > > --
> > > diff --git a/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > > b/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > > index 7879fad..73edb28 100644
> > > --- a/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > > +++ b/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > > @@ -31,11 +31,12 @@ limitations under the License.
> > >
> > >  
> > >  
> > > -
> > > +
> > >  
> > >  
> > >  
> > >  
> > > +
> > >  
> > >
> > >  
> > >
> > > http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> > > 4e7c7361/frameworks/projects/MaterialDesignLite/src/main/
> > > flex/org/apache/flex/mdl/Tooltip.as
> > > --
> > > diff --git a/frameworks/projects/MaterialDesignLite/src/main/
> > > flex/org/apache/flex/mdl/Tooltip.as b/frameworks/projects/
> > > MaterialDesignLite/src/main/flex/org/apache/flex/mdl/Tooltip.as
> > > new file mode 100644
> > > index 000..e3b519d
> > > --- /dev/null
> > > +++ b/frameworks/projects/MaterialDesignLite/src/main/
> > > flex/org/apache/flex/mdl/Tooltip.as
> > > @@ -0,0 +1,137 @@
> > > +///
> > > /
> > > +//
> > > +//  Licensed to the Apache Software Foundation (ASF) under one or more
> > > +//  contributor license agreements.  See the NOTICE file distributed
> > with
> > > +//  this work for additional information regarding copyright
> ownership.
> > > +//  The ASF licenses this file to You under the Apache License,
> Version
> > > 2.0
> > > +//  (the "License"); you may not use this file except in compliance
> with
> > > +//  the License.  You may obtain a copy of the License at
> > > +//
> > > +//  http://www.apache.org/licenses/LICENSE-2.0
> > > +//
> > > +//  Unless required by applicable law or agreed to in writing,
> software
> > > +//  distributed under the License is distributed on an "AS IS" BASIS,
> > > +//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > > implied.
> > > +//  See the License for the specific language governing permissions
> and
> > > +//  limitations under the License.
> > > +//
> > > +///
> > > /
> > > +package 

Re: git commit: [flex-asjs] [refs/heads/develop] - MDL Tooltip

[Carlos Rovira]

I though on it too, but in MDL they created a separate div that relates to
the target component by id. For that reason I follow the most natural path
that is separate. If not I think we could make a bead, but then instead of
"append" to target it should be write "nextto". I search a bit and I think
this is done in this way:

referenceNode.parentNode.insertBefore(newNode, referenceNode.nextSibling);

so what do you think?


2016-12-02 21:14 GMT+01:00 Piotr Zarzycki :

> Hi Carlos,
>
> Maybe Tooltip should be a Bead ? Just my first thought when I saw how
> example look like.
>
> Piotr
>
> 2016-12-02 15:46 GMT+01:00 :
>
> > Repository: flex-asjs
> > Updated Branches:
> >   refs/heads/develop 5aebf86cb -> 4e7c7361d
> >
> >
> > MDL Tooltip
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/4e7c7361
> > Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/4e7c7361
> > Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/4e7c7361
> >
> > Branch: refs/heads/develop
> > Commit: 4e7c7361d579f24a43645c3a524078389d1862e6
> > Parents: 5aebf86
> > Author: Carlos Rovira 
> > Authored: Fri Dec 2 15:46:22 2016 +0100
> > Committer: Carlos Rovira 
> > Committed: Fri Dec 2 15:46:22 2016 +0100
> >
> > --
> >  .../MDLExample/src/main/flex/Buttons.mxml   |   3 +-
> >  .../main/flex/org/apache/flex/mdl/Tooltip.as| 137
> +++
> >  .../src/main/resources/mdl-manifest.xml |   1 +
> >  3 files changed, 140 insertions(+), 1 deletion(-)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> > 4e7c7361/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > --
> > diff --git a/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > b/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > index 7879fad..73edb28 100644
> > --- a/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > +++ b/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> > @@ -31,11 +31,12 @@ limitations under the License.
> >
> >  
> >  
> > -
> > +
> >  
> >  
> >  
> >  
> > +
> >  
> >
> >  
> >
> > http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> > 4e7c7361/frameworks/projects/MaterialDesignLite/src/main/
> > flex/org/apache/flex/mdl/Tooltip.as
> > --
> > diff --git a/frameworks/projects/MaterialDesignLite/src/main/
> > flex/org/apache/flex/mdl/Tooltip.as b/frameworks/projects/
> > MaterialDesignLite/src/main/flex/org/apache/flex/mdl/Tooltip.as
> > new file mode 100644
> > index 000..e3b519d
> > --- /dev/null
> > +++ b/frameworks/projects/MaterialDesignLite/src/main/
> > flex/org/apache/flex/mdl/Tooltip.as
> > @@ -0,0 +1,137 @@
> > +///
> > /
> > +//
> > +//  Licensed to the Apache Software Foundation (ASF) under one or more
> > +//  contributor license agreements.  See the NOTICE file distributed
> with
> > +//  this work for additional information regarding copyright ownership.
> > +//  The ASF licenses this file to You under the Apache License, Version
> > 2.0
> > +//  (the "License"); you may not use this file except in compliance with
> > +//  the License.  You may obtain a copy of the License at
> > +//
> > +//  http://www.apache.org/licenses/LICENSE-2.0
> > +//
> > +//  Unless required by applicable law or agreed to in writing, software
> > +//  distributed under the License is distributed on an "AS IS" BASIS,
> > +//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > implied.
> > +//  See the License for the specific language governing permissions and
> > +//  limitations under the License.
> > +//
> > +///
> > /
> > +package org.apache.flex.mdl
> > +{
> > +   import org.apache.flex.core.UIBase;
> > +
> > +COMPILE::JS
> > +{
> > +import org.apache.flex.core.WrappedHTMLElement;
> > +}
> > +
> > +   /**
> > +*  The Tooltip class represents
> > + *
> > +*
> > +*  @langversion 3.0
> > +*  @playerversion Flash 10.2
> > +*  @playerversion AIR 2.6
> > +*  @productversion FlexJS 0.0
> > +*/
> > +   public class Tooltip extends UIBase
> > +   {
> > +   /**
> > +*  constructor.
> > +*
> > +*  @langversion 3.0
> > +*  @playerversion Flash 10.2
> > 

Re: [FlexJS] Team Page

[Carlos Rovira]

@Peter So cool to see that online! great! :)

@Om, MDL Card component (and sub comps are ready to use, so I encourage you
to use it and report your experience :)). If you need something I can help.
Look to Cards.mxml in MDLExample to see how to use Cards in FlexJS.



2016-12-02 20:54 GMT+01:00 OmPrakash Muppirala :

> Looks great!  Eating our own dog food :-)
>
> BTW, this looks like a great use case for an MDL-Card component [1] as a
> container for each team member.  If no one gets to it before me, I will
> take a shot at it!
>
> [1] https://getmdl.io/components/#cards-section
>
> Regards,
> Om
>
> On Fri, Dec 2, 2016 at 10:56 AM, Peter Ent  wrote:
>
> > Hi,
> >
> > If you go to: http://flex.apache.org/team/ you'll see a Flex Team page
> > created using FlexJS. Still needs a bit more styling and polish. This is
> > driven by a JSON file.
> >
> > Take a look and let me know your thoughts. The code is in
> > flex-asjs/examples/flexjs/TeamPage.
> >
> > Peter Ent
> > Adobe Systems/Apache Flex Project
> >
>



-- 

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] Unclear exception when valuesImpl is not set in

[Alex Harui]

On 12/2/16, 1:32 PM, "Josh Tynjala"  wrote:

>I'm trying to write some better beginner docs for FlexJS components this
>afternoon. I don't actually have any time to do this, but it absolutely
>needs to be done for the good of FlexJS so I'll try to get something
>started. Anyway, as a semi-beginner with the framework, I'm paying close
>attention to the weird errors I run into along the way so that they will
>be
>known and can be addressed.

Thanks for working on this.

>
>Will it completely break anything if we skip the call to init() when
>valuesImpl is missing?

Yes.  I would expect the whole world to implode.  ValuesManager generally
dictates how lots of components find their beads.

> In other words, is a valuesImpl essential to a
>FlexJS application? If not, we should skip calling init() instead of
>allowing this vague exception to be thrown. If bad things will happen,
>then
>we need to preemptively throw a different exception with a better
>description of what's wrong.

Could put a try/catch around it and report a nicer error, but even that is
code that won't be needed in production because you'll have long since
figured out you need a valuesImpl.

IMO, it might be time to start on the "heavier" component set.  You could
create a SimpleCSSApplication or POCApplication or just another
Application in a different package like org.apache.flex.full or
org.apache.flex.poc (Proof Of Concept) that has SimpleCSSValuesImpl baked
in.  Then folks will never hit this issue and we don't have to put in code
that isn't needed at runtime.

This is another aspect of pay-as-you-go and composition.  We want to
identify the common aggregations of beads and make higher-level components
that compose them.  Really, the current examples are just testing that
there are no assumed aggregations.  I don't expect lots of folks to use
Basic and aggregate everything from scratch.  I think most folks will use
a heavier set with more things baked in because it will take them less
thinking about what beads are needed.  But if they run into
performance/size issues we will know they can decompose their app into
smaller pieces and throw out what they don't need.  The key is that we,
the framework developers, have to make sure the pieces remain loosely
coupled.

My 2 cents,
-Alex

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Alex Harui]

This seems mostly right to me.  The top-level component is aggregating the
interfaces onto itself.  More inline...

On 12/2/16, 12:41 PM, "Peter Ent"  wrote:
>
>GenericListView does not extend ListView because that leads to this
>nesting business we are trying to avoid. Instead, it just extends
>BeadViewBase and implements IListView (so it can provide the dataGroup for
>the itemRenderer factory which will be the strand/GenericList itself).
>This class makes sure the itemRenderer factory bead is installed and
>listens for changes to the dataProvider in the model.

Isn't the real issue that it is ContainerView that ListView extends that
makes the assumption that it has to add a viewport to the strand?  I think
that's ok though.  As Harbs said in another thread, or maybe upthread,
there will be Container views for heavy containers with inner content
areas and Container views for lightweight containers without inner content
areas.  The current ContainerView is the heavy one.  You have probably
just written the lightweight one or can factor it out of your
GenericListView.  Might be time to rename the current ContainerView to
ContainerWithContentAreaView and make the lighter one the new
ContainerView.

>
>Finally, I had to copy DataItemRendererFactoryForArrayData into a new
>class because it explicitly references the org.apache.flex.html.List class
>in order to pass along the labelField to each itemRenderer. This, to me,
>is a problem that needs to be addressed. I probably wrote this originally,
>but now it must be revisited and corrected.

In theory, the labelField should be in the model and retrieved from there.

My 2 cents,
-Alex

[FlexJS] Unclear exception when valuesImpl is not set in

[Josh Tynjala]

I'm trying to write some better beginner docs for FlexJS components this
afternoon. I don't actually have any time to do this, but it absolutely
needs to be done for the good of FlexJS so I'll try to get something
started. Anyway, as a semi-beginner with the framework, I'm paying close
attention to the weird errors I run into along the way so that they will be
known and can be addressed.

I just created a simple app with . I quickly discovered
that the valuesImpl property must be set or an exception will be thrown.
I've seen enough code on the list to guess that I can probably use
SimpleCSSValuesImpl. A complete beginner won't know that, though.

In org.apache.flex.core.ContainerBase (in both Basic and HTML, but maybe
elsewhere?), I found the following code where the exception is thrown:

if (!_initialized)
{
// each MXML file can also have styles in fx:Style block
ValuesManager.valuesImpl.init(this);
}

I'd like to make this better for beginners who might not know what's wrong.

Will it completely break anything if we skip the call to init() when
valuesImpl is missing? In other words, is a valuesImpl essential to a
FlexJS application? If not, we should skip calling init() instead of
allowing this vague exception to be thrown. If bad things will happen, then
we need to preemptively throw a different exception with a better
description of what's wrong.

- Josh

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Peter Ent]

I've checked in a new example: flex-asjs/examples/flexjs/ListExample. Let
me know if this is close to what you are looking for.

—peter

On 12/2/16, 3:41 PM, "Peter Ent"  wrote:

>I have something working now. It took a bit more doing than I'd like, but
>it is relatively clean. I have to create a new example for this or add it
>to an existing example. But here is the overview:
>
>I created a new component called GenericList (since SimpleList is already
>taken). On the SWF side this is a DisplayObject and on the JS side it is a
>. If you override createElement in the COMPILE::JS section, you could
>make this a .
>
>The idea is that the items generated by the itemRenderer factory become
>children of this component element (eg,  or ). To do that, and
>make use of the existing layout code, GenericList implements
>IItemRendererParent (so the item renderer factory knows which parent
>should be used for the items it creates), ILayoutParent, and ILayoutHost.
>Basically, it is everything since there is no other UI elements except for
>the itemRenderers.
>
>GenericListView does not extend ListView because that leads to this
>nesting business we are trying to avoid. Instead, it just extends
>BeadViewBase and implements IListView (so it can provide the dataGroup for
>the itemRenderer factory which will be the strand/GenericList itself).
>This class makes sure the itemRenderer factory bead is installed and
>listens for changes to the dataProvider in the model.
>
>Finally, I had to copy DataItemRendererFactoryForArrayData into a new
>class because it explicitly references the org.apache.flex.html.List class
>in order to pass along the labelField to each itemRenderer. This, to me,
>is a problem that needs to be addressed. I probably wrote this originally,
>but now it must be revisited and corrected.
>
>When the beads get fired up and the dataProvider has been set, the factory
>discovers the dataGroup from the IListView and begins making
>itemRenderers. I kept with StringItemRenderer, but you could use an
>itemRenderer that created  elements on the JS side.
>
>The result HTML looks like:
>
>
>   Widgets
>   Thingys
>…
>
>
>As I said, I have to package this example up. This really makes me want to
>rethink a bit the complexity of the List classes, but more important,
>there are too many concrete classes being used instead of interfaces.
>
>Let me know if this seems more like what you are looking for.
>
>—peter
>
>On 12/2/16, 12:48 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>
>wrote:
>
>>excelent Peter! I'll be waiting for this :)
>>
>>2016-12-02 15:47 GMT+01:00 Peter Ent :
>>
>>> I will be looking into this, this morning (shortly). Just for
>>>background:
>>>
>>> The ListView creates two things: an outer containment area (div) to
>>>house
>>> the chrome (scroll bars, title bars, footer bars, etc) and the content
>>> area (ContainerContentArea).
>>>
>>> When we first set this up, the JS side wasn't supposed to create two
>>> things since scroll bars are handled by the browser. But when we
>>>decided
>>> there were other "chrome" pieces, the nesting happened.
>>>
>>> If things are set up right, just making something an ILayoutHost the
>>> returns itself as the content area should be enough; its what I did for
>>> the MXMLItemRenderer (it is both ILayoutHost and ILayoutParent). The
>>> ILayoutHost is the object which returns which of its children (or
>>>itself)
>>> is the ILayoutParent. The ILayoutParent is the thing which will be the
>>> parent of all of the ILayoutChild objects.
>>>
>>> I will put an example together today which shows a simpler List without
>>> the nesting.
>>>
>>> ‹peter
>>>
>>> On 12/1/16, 7:40 PM, "Peter Ent"  wrote:
>>>
>>> >I'll look into this tomorrow.
>>> >
>>> >Peter
>>> >
>>> >
>>> >On Dec 1, 2016, at 7:09 PM, Carlos Rovira 
>>> wrote:
>>> >
>>> >>>
>>> >>> Anyway, Peter might be able to better answer your question, but it
>>> >>>appears
>>> >>> that if you create some new subclass of UIBase and have it return
>>> >>>'this'
>>> >>> for layoutHost and contentView, that the ListView might then just
>>>stick
>>> >>> the children in the outer div.  See how MXMLItemRenderer (which I
>>> >>> mentioned upthread) differs from ListBase in that way.  There might
>>>be
>>> >>> some bugs to iron out, but that's my understanding of how it is
>>> >>>supposed
>>> >>> to work.
>>> >>>
>>> >>> -Alex
>>> >>>
>>> >>>
>>> >> Hi,
>>> >>
>>> >> Peter as Alex says you could be of great help here, hope you could
>>>help
>>> >> getting a simple example since I think is crucial for MDL List
>>>component
>>> >> (and other comps that uses the same behaviour).
>>> >>
>>> >> I'll try to investigate about layoutHost and contentView as Alex
>>> >>mention to
>>> >> be able to remove the middle div layer that List View generates. My
>>> >>target
>>> >> is to get a List that 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Peter Ent]

I have something working now. It took a bit more doing than I'd like, but
it is relatively clean. I have to create a new example for this or add it
to an existing example. But here is the overview:

I created a new component called GenericList (since SimpleList is already
taken). On the SWF side this is a DisplayObject and on the JS side it is a
. If you override createElement in the COMPILE::JS section, you could
make this a .

The idea is that the items generated by the itemRenderer factory become
children of this component element (eg,  or ). To do that, and
make use of the existing layout code, GenericList implements
IItemRendererParent (so the item renderer factory knows which parent
should be used for the items it creates), ILayoutParent, and ILayoutHost.
Basically, it is everything since there is no other UI elements except for
the itemRenderers.

GenericListView does not extend ListView because that leads to this
nesting business we are trying to avoid. Instead, it just extends
BeadViewBase and implements IListView (so it can provide the dataGroup for
the itemRenderer factory which will be the strand/GenericList itself).
This class makes sure the itemRenderer factory bead is installed and
listens for changes to the dataProvider in the model.

Finally, I had to copy DataItemRendererFactoryForArrayData into a new
class because it explicitly references the org.apache.flex.html.List class
in order to pass along the labelField to each itemRenderer. This, to me,
is a problem that needs to be addressed. I probably wrote this originally,
but now it must be revisited and corrected.

When the beads get fired up and the dataProvider has been set, the factory
discovers the dataGroup from the IListView and begins making
itemRenderers. I kept with StringItemRenderer, but you could use an
itemRenderer that created  elements on the JS side.

The result HTML looks like:


   Widgets
   Thingys
…


As I said, I have to package this example up. This really makes me want to
rethink a bit the complexity of the List classes, but more important,
there are too many concrete classes being used instead of interfaces.

Let me know if this seems more like what you are looking for.

—peter

On 12/2/16, 12:48 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>excelent Peter! I'll be waiting for this :)
>
>2016-12-02 15:47 GMT+01:00 Peter Ent :
>
>> I will be looking into this, this morning (shortly). Just for
>>background:
>>
>> The ListView creates two things: an outer containment area (div) to
>>house
>> the chrome (scroll bars, title bars, footer bars, etc) and the content
>> area (ContainerContentArea).
>>
>> When we first set this up, the JS side wasn't supposed to create two
>> things since scroll bars are handled by the browser. But when we decided
>> there were other "chrome" pieces, the nesting happened.
>>
>> If things are set up right, just making something an ILayoutHost the
>> returns itself as the content area should be enough; its what I did for
>> the MXMLItemRenderer (it is both ILayoutHost and ILayoutParent). The
>> ILayoutHost is the object which returns which of its children (or
>>itself)
>> is the ILayoutParent. The ILayoutParent is the thing which will be the
>> parent of all of the ILayoutChild objects.
>>
>> I will put an example together today which shows a simpler List without
>> the nesting.
>>
>> ‹peter
>>
>> On 12/1/16, 7:40 PM, "Peter Ent"  wrote:
>>
>> >I'll look into this tomorrow.
>> >
>> >Peter
>> >
>> >
>> >On Dec 1, 2016, at 7:09 PM, Carlos Rovira 
>> wrote:
>> >
>> >>>
>> >>> Anyway, Peter might be able to better answer your question, but it
>> >>>appears
>> >>> that if you create some new subclass of UIBase and have it return
>> >>>'this'
>> >>> for layoutHost and contentView, that the ListView might then just
>>stick
>> >>> the children in the outer div.  See how MXMLItemRenderer (which I
>> >>> mentioned upthread) differs from ListBase in that way.  There might
>>be
>> >>> some bugs to iron out, but that's my understanding of how it is
>> >>>supposed
>> >>> to work.
>> >>>
>> >>> -Alex
>> >>>
>> >>>
>> >> Hi,
>> >>
>> >> Peter as Alex says you could be of great help here, hope you could
>>help
>> >> getting a simple example since I think is crucial for MDL List
>>component
>> >> (and other comps that uses the same behaviour).
>> >>
>> >> I'll try to investigate about layoutHost and contentView as Alex
>> >>mention to
>> >> be able to remove the middle div layer that List View generates. My
>> >>target
>> >> is to get a List that throws:
>> >>
>> >> 
>> >>   
>> >>   
>> >> 
>> >>
>> >> and  elements data will be provided by a dataProvider Array and
>>the
>> >> layout (the li or whatever we want) by an itemRenderer.
>> >>
>> >> As I get this I'll update some MDL comps that will benefit from this
>> >> refactor a part from List (TabBar, 

Re: git commit: [flex-asjs] [refs/heads/develop] - MDL Tooltip

[Piotr Zarzycki]

Hi Carlos,

Maybe Tooltip should be a Bead ? Just my first thought when I saw how
example look like.

Piotr

2016-12-02 15:46 GMT+01:00 :

> Repository: flex-asjs
> Updated Branches:
>   refs/heads/develop 5aebf86cb -> 4e7c7361d
>
>
> MDL Tooltip
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/4e7c7361
> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/4e7c7361
> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/4e7c7361
>
> Branch: refs/heads/develop
> Commit: 4e7c7361d579f24a43645c3a524078389d1862e6
> Parents: 5aebf86
> Author: Carlos Rovira 
> Authored: Fri Dec 2 15:46:22 2016 +0100
> Committer: Carlos Rovira 
> Committed: Fri Dec 2 15:46:22 2016 +0100
>
> --
>  .../MDLExample/src/main/flex/Buttons.mxml   |   3 +-
>  .../main/flex/org/apache/flex/mdl/Tooltip.as| 137 +++
>  .../src/main/resources/mdl-manifest.xml |   1 +
>  3 files changed, 140 insertions(+), 1 deletion(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> 4e7c7361/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> --
> diff --git a/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> b/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> index 7879fad..73edb28 100644
> --- a/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> +++ b/examples/flexjs/MDLExample/src/main/flex/Buttons.mxml
> @@ -31,11 +31,12 @@ limitations under the License.
>
>  
>  
> -
> +
>  
>  
>  
>  
> +
>  
>
>  
>
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> 4e7c7361/frameworks/projects/MaterialDesignLite/src/main/
> flex/org/apache/flex/mdl/Tooltip.as
> --
> diff --git a/frameworks/projects/MaterialDesignLite/src/main/
> flex/org/apache/flex/mdl/Tooltip.as b/frameworks/projects/
> MaterialDesignLite/src/main/flex/org/apache/flex/mdl/Tooltip.as
> new file mode 100644
> index 000..e3b519d
> --- /dev/null
> +++ b/frameworks/projects/MaterialDesignLite/src/main/
> flex/org/apache/flex/mdl/Tooltip.as
> @@ -0,0 +1,137 @@
> +///
> /
> +//
> +//  Licensed to the Apache Software Foundation (ASF) under one or more
> +//  contributor license agreements.  See the NOTICE file distributed with
> +//  this work for additional information regarding copyright ownership.
> +//  The ASF licenses this file to You under the Apache License, Version
> 2.0
> +//  (the "License"); you may not use this file except in compliance with
> +//  the License.  You may obtain a copy of the License at
> +//
> +//  http://www.apache.org/licenses/LICENSE-2.0
> +//
> +//  Unless required by applicable law or agreed to in writing, software
> +//  distributed under the License is distributed on an "AS IS" BASIS,
> +//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> +//  See the License for the specific language governing permissions and
> +//  limitations under the License.
> +//
> +///
> /
> +package org.apache.flex.mdl
> +{
> +   import org.apache.flex.core.UIBase;
> +
> +COMPILE::JS
> +{
> +import org.apache.flex.core.WrappedHTMLElement;
> +}
> +
> +   /**
> +*  The Tooltip class represents
> + *
> +*
> +*  @langversion 3.0
> +*  @playerversion Flash 10.2
> +*  @playerversion AIR 2.6
> +*  @productversion FlexJS 0.0
> +*/
> +   public class Tooltip extends UIBase
> +   {
> +   /**
> +*  constructor.
> +*
> +*  @langversion 3.0
> +*  @playerversion Flash 10.2
> +*  @playerversion AIR 2.6
> +*  @productversion FlexJS 0.0
> +*/
> +   public function Tooltip()
> +   {
> +   super();
> +
> +className = ""; //set to empty string avoid 'undefined'
> output when no class selector is assigned by user;
> +   }
> +
> +private var _text:String = "";
> +
> +/**
> + *  The text of the heading
> + *
> + *  @langversion 3.0
> + *  @playerversion Flash 10.2
> + *  @playerversion AIR 2.6
> + *  @productversion FlexJS 0.0
> + */
> +   public function get text():String
> +   {
> +

Re: [FlexJS] Team Page

[OmPrakash Muppirala]

Looks great!  Eating our own dog food :-)

BTW, this looks like a great use case for an MDL-Card component [1] as a
container for each team member.  If no one gets to it before me, I will
take a shot at it!

[1] https://getmdl.io/components/#cards-section

Regards,
Om

On Fri, Dec 2, 2016 at 10:56 AM, Peter Ent  wrote:

> Hi,
>
> If you go to: http://flex.apache.org/team/ you'll see a Flex Team page
> created using FlexJS. Still needs a bit more styling and polish. This is
> driven by a JSON file.
>
> Take a look and let me know your thoughts. The code is in
> flex-asjs/examples/flexjs/TeamPage.
>
> Peter Ent
> Adobe Systems/Apache Flex Project
>

[FlexJS] Team Page

[Peter Ent]

Hi,

If you go to: http://flex.apache.org/team/ you'll see a Flex Team page created 
using FlexJS. Still needs a bit more styling and polish. This is driven by a 
JSON file.

Take a look and let me know your thoughts. The code is in 
flex-asjs/examples/flexjs/TeamPage.

Peter Ent
Adobe Systems/Apache Flex Project

Re: [FlexJS] dialog-polypfill third party JS

[Alex Harui]

On 12/2/16, 9:59 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>>
>>
>> I'm not sure we have a way to manage random JS files in the tool chain.
>> JS files that use goog.provide can be included in a SWC and will be
>>copied
>> to the output folder by the compiler.  So you may want to consider
>>adding
>> some sort of goog.provide to that file.
>
>
>interesting. Some example already set to see how to do this? something
>already in place to take as example an make my own ?

We've not done this before, AFAIK.

>
>
>> Otherwise, folks will have to
>> manage it like any other asset.  The tool chain does support links to
>> random JS files via the inject_html directive.
>>
>
>so, gol.provide will be for bundle in swc...while inject_html will put the
>line in my index.html right?

Yep.

>
>
>>
>> Also, if this code can be called by other code in JS files being sent to
>> the Google Closure Compiler for minification/optimization, then an
>>externs
>> file for this file will need to be generated.
>>
>
>I think this is not the case. MDL talks about it as a "companion", so they
>provide some class css and  maybe js, but they suppose the dialog-polyfill
>is setup and in place. Right now externs are an obscure concept to me,
>where I could read about it and whats behind?

Google Closure Compiler docs contain information about externs.  Basically
it is a file format that describes which APIs should not be renamed by the
minifier because the files are loaded externally.  If the JS is not called
from any JS code we've written or compiled then you don't need an externs.
 Although it makes me wonder how any of that code gets called.

IMO, linking to it is simpler.  Folks can always download it and integrate
it into their html if they don't want to rely on the CDN.

-Alex

Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW: [FalconJX][FlexJS] COMPJSC and Build order)

[Alex Harui]

I'm about to start working on this.  I haven't actually tried anything
yet, but my thinking is that there are some interesting issues regarding
configuration.  Typically, when compiling an application, you define a
bunch of compiler options, but for a compilation that should produce two
different outputs, you might need two different sets of compiler options.
How should that be managed?

For example, you might want a different library-path for the SWF compile
vs the JS compile.  Or set COMPILE::SWF=true for the SWF build and
COMPILE::SWF=false for the JS compile.

One possibility is that all platform-specific options have to be specified
in -config.xml files and not on the command line.  Then for any
-load-config option, the JS compile will look for a js-prefixed file.  So
instead of using compile-as-config.xml and compile-js-config.xml, we would
use compile-config.xml and js-compile-config.mxml and you would specify
-load-config=compile-config.xml as the compiler option.

Another possibility is that the SWF compile would always set
COMPILE::SWF=true and COMPILE::JS=false and the JS compile would do the
opposite.  The JS compile would see if -js-library-path was specified and
if not, use the -library-path.  The weird thing about this approach is
that the SWF compiler needs to support a -js-library-path option otherwise
the SWF compiler's configuration checker will throw an error.  Adding
options that the SWF compiler must ignore doesn't seem right to me.

Any other ideas?  Thoughts?
-Alex


On 10/7/16, 8:09 AM, "Alex Harui"  wrote:

>I don't know enough about how Flex Tool Groups work to form an opinion.
>Can you provide more details and explain how folks would configure things
>on the command-line?
>
>AIUI, -js-output-type is sort of overloaded right now, because the
>FLEXJS_DUAL dictates the output of a SWF.  In my plan to combine things, I
>would introduce a new configuration parameter like -output-type or
>-targets or something like that.  I supposed it could be a list of
>compiler jars to run.  But -js-output-type doesn't currently go through
>different jars for JSC, NODE, and FLEXJS.  That parameter just sets up a
>few configuration changes within the output classes.
>
>I'm pretty sure Schmalle imagined a true plug-in architecture for the
>emitters as well.  Not sure we want to take all of that on right now, but
>we might want to consider that as well.
>
>-Alex
>
>On 10/7/16, 12:14 AM, "Christofer Dutz"  wrote:
>
>>I would like to propose a different approach:
>>
>>
>>Unless these approaches led to a dead end and there is no solution down
>>that path, I would rather suggest to refactor the compiler to allow
>>dynamic adding of alternate compilers. Currently the supported compilers
>>are limited by the JsOutputType enum. If we however used something like
>>the Java service thing I used for the Flex Tool Groups, we could allow
>>new experiments to start in dedicated Jars and we wouldn't have such a
>>mixture in case someone wants to try something out.
>>
>>
>>Chris
>>
>>
>>Von: Alex Harui 
>>Gesendet: Freitag, 7. Oktober 2016 00:25:30
>>An: dev@flex.apache.org
>>Betreff: Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
>>[FalconJX][FlexJS] COMPJSC and Build order)
>>
>>+1.  Bonus points for making a tag and/or branch before deleting.
>>
>>-Alex
>>
>>On 10/6/16, 3:02 PM, "Josh Tynjala"  wrote:
>>
>>>Makes sense to me. I say we simply delete it. No need to transfer to
>>>another folder. It'll still be in the repository's history.
>>>
>>>- Josh
>>>
>>>On Thu, Oct 6, 2016 at 2:55 PM, Carlos Rovira
>>>>>
 I want to propose the same. I something was an experiment and is no
more
 developed. I think it should go to some folder that make people avoid
 confusion about what code is valid and what is left behind.

 2016-10-06 23:12 GMT+02:00 Christofer Dutz
:

 > I stumble over tons of VF2JS classes and think it would be better to
move
 > stuf like that to some sort of attic. What do you think?
 >
 >
 > Chris
 >
 > 
 > Von: Josh Tynjala 
 > Gesendet: Donnerstag, 6. Oktober 2016 17:13:49
 > An: dev@flex.apache.org
 > Betreff: Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
 > [FalconJX][FlexJS] COMPJSC and Build order)
 >
 > JSC is meant to be purely an ActionScript to JavaScript transpiler
 without
 > any frameworks. By default, it doesn't export an HTML file, but it
will
 > optionally support custom HTML templates in 0.8.0. It is exposed
through
 > the js/bin/asjsc executable, where it loads the
frameworks/js-config.xml
 > configuration. js-config.xml references js.swc to give ActionScript
 access
 > to browser APIs.
 

Re: [FlexJS] dialog-polypfill third party JS

[Carlos Rovira]

>
>
> I'm not sure we have a way to manage random JS files in the tool chain.
> JS files that use goog.provide can be included in a SWC and will be copied
> to the output folder by the compiler.  So you may want to consider adding
> some sort of goog.provide to that file.


interesting. Some example already set to see how to do this? something
already in place to take as example an make my own ?


> Otherwise, folks will have to
> manage it like any other asset.  The tool chain does support links to
> random JS files via the inject_html directive.
>

so, gol.provide will be for bundle in swc...while inject_html will put the
line in my index.html right?


>
> Also, if this code can be called by other code in JS files being sent to
> the Google Closure Compiler for minification/optimization, then an externs
> file for this file will need to be generated.
>

I think this is not the case. MDL talks about it as a "companion", so they
provide some class css and  maybe js, but they suppose the dialog-polyfill
is setup and in place. Right now externs are an obscure concept to me,
where I could read about it and whats behind?



-- 

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: Snippets for FlexJS

[Alex Harui]

On 12/1/16, 10:41 PM, "Christian Gotschim"  wrote:

>
>> If you know Java, you could write a custom ASDoc emitter.  I've written
>> one that outputs ASDoc information in JSON format.  Or you could write a
>> Flex or FlexJS app to read the JSON files and generate the MXML you
>>want.
>
>I don’t know Java. I’d have to see the JSON file first to see if I can get
>the necessary info out of that. Can you send it to me?

The JSON files are posted at [1].  The content/format of these files can
be modified by changing the Java code in the compiler.

The list of all classes is in classes.json.  Individual classes have their
own file.

[1] http://home.apache.org/~aharui/FlexJS/asdoc-output.zip


Thanks,
-Alex

Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)

[Carlos Rovira]

Hi Josh,

right. As I get some few components more, I think I could refactor removing
the dependencies from some HTML comps so we could manage better MDL set. So
for example, I will took things from Core, like UIBase or ContainerBase
while removing html things like TextButton, Container and so on...(in the
end removing HTML.swc dependency at all). In this way I think MDL will be
more independent.

2016-12-02 16:55 GMT+01:00 Josh Tynjala :

> Alex's first point about using the same beads, but not subclassing sounds
> cleaner to me, Carlos. Kind of the same idea from the other day where all
> components should be possible to recreate from UIBase with the right set of
> beads. You should consider trying that out for MDL.
>
> - Josh
>
> On Dec 1, 2016 11:09 PM, "Alex Harui"  wrote:
>
> > Re-ordering your post so I can address higher-level points first:
> >
> >
> > On 12/1/16, 4:55 PM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira"
> >  wrote:
> > >
> > >But Basic set is at the core of
> > >all. Is at the core of MDL set
> > >
> > >
> >
> > This statement doesn't have to be true, and makes me think that the old
> > Flex SDK mentality is persisting.  IMO, the MDL set has no obligation to
> > subclass the Basic set.  The top-level components in the Basic set are
> > supposed to be compositions of beads.  MDL can just compose the same or
> > different beads without having to subclass Basic components.
> >
> > One of the problems of having a core and inheritance is that you have to
> > get it right, but often there isn't one right answer.
> >
> > >I think
> > >Basic set (as is) will not be used at all since the final visuals are
> not
> > >production ready, so you know people will need this level of
> customization
> > >or they will never join FleJS for sure. and here you have the first
> > >example of many
> > >of the styles in flexjs needs to be removed in order to get the MDL
> branch
> > >working ok, and so will happen with others like Bootstrap, and so on...
> > >Only if we create our own FlexJS style design could take into account
> the
> > >actual styles, but I think that if MDL or Bootstrap does not need all of
> > >that, we should not need creating our own CSS set in the end (I can't
> say
> > >much more here since I'm not a CSS expert to affirm that, but based on
> > >what
> > >I see...is clear that it's the reality).
> > >
> >
> > In my mind, there are going to be two kinds of themes: pre-existing ones
> > like MDL and custom ones like the themes that regular Flex SDK customers
> > used to brand their applications.  In the second kind, I don't think it
> > matters as much as to what default styles are. Folks will simply override
> > the defaults in their themes.
> >
> > I was a bit surprised that MDL didn't override everything we set as
> > defaults for HTML.swc.  That means to me that if someone has certain
> > styles set elsewhere, even in their browser settings, that could cause
> > really strange and unexpected results.  But OK, that's the way it is, and
> > so we should think of other ways to have a default look for HTML.swc,
> > although again, as I said above, the MDL library has no obligation to
> > inherit from HTML.swc.
> >
> > If we really need to support more inheritance, then maybe all visual
> > styles should be moved from HTML into some default theme.  It would be
> > nice to have a better set of defaults that are a bit more production
> ready
> > for Basic so we can see how and why there are collisions between themes.
> >
> > >You could as well use documentation to expose requirements and make
> people
> > >know that 2 or 3 styles are required and if they remove from CSS things
> > >could break. We could prepare as well a MVCSS (minimum viable CSS) so
> > >people would not need to use the remove default compiler flag, and have
> > >another with relative positions, borders and other no-so required
> things,
> > >but needed in basic comp set.
> > >
> > >
> >
> > Way back in early Flex, we found our customers didn't like this.  There
> > was a version of Flex where only the type-selectors with the same name as
> > the component was applied.  So CheckBox extended Button and lots of
> styles
> > important to Button needed to be copied to the CheckBox type selector.
> > This was way faster at runtime because we didn't have to chase down the
> > super classes and their styles. But customers really complained because
> if
> > you subclassed Button and made a MyButton, you had to know which styles
> to
> > copy to a MyButton type selector or the component wouldn't work.  I'm
> sure
> > our documentation was not sufficient, but even then, folks thought it was
> > a pain.
> >
> > If you want to ensure no styles are specified in code for the MDL library
> > feel free to do so.  I'm just not sure how important tat is for the Basic
> > set.
> >
> > >
> > >> Similarly, Label isn't supposed to 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Carlos Rovira]

excelent Peter! I'll be waiting for this :)

2016-12-02 15:47 GMT+01:00 Peter Ent :

> I will be looking into this, this morning (shortly). Just for background:
>
> The ListView creates two things: an outer containment area (div) to house
> the chrome (scroll bars, title bars, footer bars, etc) and the content
> area (ContainerContentArea).
>
> When we first set this up, the JS side wasn't supposed to create two
> things since scroll bars are handled by the browser. But when we decided
> there were other "chrome" pieces, the nesting happened.
>
> If things are set up right, just making something an ILayoutHost the
> returns itself as the content area should be enough; its what I did for
> the MXMLItemRenderer (it is both ILayoutHost and ILayoutParent). The
> ILayoutHost is the object which returns which of its children (or itself)
> is the ILayoutParent. The ILayoutParent is the thing which will be the
> parent of all of the ILayoutChild objects.
>
> I will put an example together today which shows a simpler List without
> the nesting.
>
> ‹peter
>
> On 12/1/16, 7:40 PM, "Peter Ent"  wrote:
>
> >I'll look into this tomorrow.
> >
> >Peter
> >
> >
> >On Dec 1, 2016, at 7:09 PM, Carlos Rovira 
> wrote:
> >
> >>>
> >>> Anyway, Peter might be able to better answer your question, but it
> >>>appears
> >>> that if you create some new subclass of UIBase and have it return
> >>>'this'
> >>> for layoutHost and contentView, that the ListView might then just stick
> >>> the children in the outer div.  See how MXMLItemRenderer (which I
> >>> mentioned upthread) differs from ListBase in that way.  There might be
> >>> some bugs to iron out, but that's my understanding of how it is
> >>>supposed
> >>> to work.
> >>>
> >>> -Alex
> >>>
> >>>
> >> Hi,
> >>
> >> Peter as Alex says you could be of great help here, hope you could help
> >> getting a simple example since I think is crucial for MDL List component
> >> (and other comps that uses the same behaviour).
> >>
> >> I'll try to investigate about layoutHost and contentView as Alex
> >>mention to
> >> be able to remove the middle div layer that List View generates. My
> >>target
> >> is to get a List that throws:
> >>
> >> 
> >>   
> >>   
> >> 
> >>
> >> and  elements data will be provided by a dataProvider Array and the
> >> layout (the li or whatever we want) by an itemRenderer.
> >>
> >> As I get this I'll update some MDL comps that will benefit from this
> >> refactor a part from List (TabBar, NavigationBar,...)
> >>
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
>
>


-- 

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: Using source class instead of compiled swc

[Alex Harui]

On 12/2/16, 8:49 AM, "sankar"  wrote:

>Can I use supplied source class in FlexJS SDK instead from the compiled
>"swc"? For an example,
>
>If I want to access *SimpleBinding* API resides at
>/\frameworks\projects\Binding\src\main\flex\org\apache\flex\binding\S
>impleBinding.as/
>instead from /\frameworks\libs\Binding.swc/, is that possible
>someway?

Any classes found in the source-path will be used instead of classes in a
SWC.  That is the basis of "monkey-patching".  Doing so can be a bit
trickier in FlexJS as many AS files contain conditional compilation which
you will have to set up in your compile flags and use a different set of
conditional compilation flags when doing the cross-compile.

HTH,
-Alex

Re: [FlexJS] dialog-polypfill third party JS

[Alex Harui]

On 12/2/16, 4:02 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Ok, so as we can add to our project, I will upload. I think is more safe.

I'm not sure we have a way to manage random JS files in the tool chain.
JS files that use goog.provide can be included in a SWC and will be copied
to the output folder by the compiler.  So you may want to consider adding
some sort of goog.provide to that file.  Otherwise, folks will have to
manage it like any other asset.  The tool chain does support links to
random JS files via the inject_html directive.

Also, if this code can be called by other code in JS files being sent to
the Google Closure Compiler for minification/optimization, then an externs
file for this file will need to be generated.

-Alex

Using source class instead of compiled swc

[sankar]

Can I use supplied source class in FlexJS SDK instead from the compiled
"swc"? For an example,

If I want to access *SimpleBinding* API resides at
/\frameworks\projects\Binding\src\main\flex\org\apache\flex\binding\SimpleBinding.as/
instead from /\frameworks\libs\Binding.swc/, is that possible someway?

I want to check the class' property at runtime in debug mode mainly, this
would help to understand how beads using different properties and help us to
contribute to FlexJS SDK as well (in long run). 

Thanks.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Using-source-class-instead-of-compiled-swc-tp56928.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Snippets for FlexJS

[Josh Tynjala]

This just goes to show again that we need a dedicated page for each of the
Basic components with simple examples of the component's most common tasks.
Set the text on a button, and listen for some kind of click/tap event.
Populate a list's data provider, listen for a selection change event, and
change the selected index programatically. People can't figure out how to
use these core features of the components far too often, and then FlexJS
feels broken or unfinished.

- Josh

On Thu, Dec 1, 2016 at 10:41 PM, Christian Gotschim 
wrote:

> Hi Alex,
>
> > Thanks for offering to help.  We could use all the help we can get.
> >
> > I don't know what your areas of expertise are and how much time you have,
> > and I don't quite know how you want to organize the list, but you might
> be
> > able to write code to build out the list of components.
>
> My expertise is in AS3 and Flex 4.6 with PHP and MySQL on the backend.
> I just recently tried FlexJS with the NextGenAS VSCode extension and
> it was tough to say the least! That’s how I came up with the idea of
> using snippets to get people start using FlexJS without giving up
> shortly after.
>
> Organizing the list: I would have to see what’s even in FlexJS, but
> basically
> having a prefix (like ‘ng’ (for NextGen)) and then the components
> classname. That way one could instantly see a list of all ng???
> components to use. So typing ngLabel will list the snippet and insert all
> the relevant properties/styles to tab through — better more than less
> and then just delete the ones not needed. I think that’s easier than
> looking around for a property/style that one doesn’t know about or
> if they’re relevant.
>
> Time: well, not enough like all of us ;)  But enough to get this done
> as proposed (list of components to snippets). I cannot write any
> documentation on FlexJS since I don’t know much about it at all yet.
>
>
> > If you know Java, you could write a custom ASDoc emitter.  I've written
> > one that outputs ASDoc information in JSON format.  Or you could write a
> > Flex or FlexJS app to read the JSON files and generate the MXML you want.
>
> I don’t know Java. I’d have to see the JSON file first to see if I can get
> the necessary info out of that. Can you send it to me?
>
>
> > One thing to keep in mind is that styles work a bit differently in FlexJS
> > than in Flex.  FlexJS currently doesn't document style properties because
> > on the JS-side the components are pretty much going to respond to every
> > CSS style that the browser knows about.  I suppose we could document
> which
> > of those styles are currently implemented for SWF, but I haven't heard
> too
> > many folks ask for that.
>
> I’ve been following this list for months and I get the feeling that people
> are
> really interested in FlexJS, but only a few know how to even get started
> with
> a basic app. Hence the idea that snippets (with input from the FlexJS
> developers themselves) in VSCode (while not replacing
> documantation) would at least allow people to get started faster. I’ve
> struggled with just finding a way to color the text of a label or if I’m
> even
> using the right label component (I think I had 3 listed in
> auto-completion).
> That’s very frustrating for someone who’s just writing a large
> Flex 4.6 app alone.
>
> Now if a snippet puts the code right there infront of me then I can see
> what properties/styles are relevant right away and even tab through them.
> I know there’s been talk of a wiki page and that would be great, but
> snippets would be more of a hands-on approach. And I think with
> Josh’s VSCode extension there’s a really good combination to get
> FlexJS out of the cellar (no pun intended) and into the hands of
> developers and companies.
> I recently had an interview for a contract and I told them about FlexJS.
> They
> were very excited about it and have never heard of it. I was told that once
> FlexJS is ready to go they’d book me for the next 2 years
> just to convert old Flex apps to FlexJS!
>
> I mean it would already be helpful if people already using FlexJS to
> copy/paste components out of their existing code and adding them to this
> list.
>
> -Christian
>
>
>
> > On 12/1/16, 8:49 PM, "Christian Gotschim"  wrote:
> >
> >> I've been thinking about the complaints I’ve read on this list about the
> >> missing documentation for FlexJS and I’d like to do something to help
> >> out. I’ve used AS3/Flex for many years, and I’m now trying to get a hang
> >> of FlexJS.
> >>
> >> So I thought it might be a good starting point for FlexJS newbies (like
> >> me) to have snippets for most or all components that FlexJS has to
> offer,
> >> and make them useable in Josh’s NextGenAS VSCode extension.
> >>
> >> I’d be happy to create the snippets, but I would need someone
> experienced
> >> to write a list of FlexJS components as a starting point.
> >>
> >> The list would have to be in MXML format and the components could 

Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)

[Josh Tynjala]

Alex's first point about using the same beads, but not subclassing sounds
cleaner to me, Carlos. Kind of the same idea from the other day where all
components should be possible to recreate from UIBase with the right set of
beads. You should consider trying that out for MDL.

- Josh

On Dec 1, 2016 11:09 PM, "Alex Harui"  wrote:

> Re-ordering your post so I can address higher-level points first:
>
>
> On 12/1/16, 4:55 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
> >
> >But Basic set is at the core of
> >all. Is at the core of MDL set
> >
> >
>
> This statement doesn't have to be true, and makes me think that the old
> Flex SDK mentality is persisting.  IMO, the MDL set has no obligation to
> subclass the Basic set.  The top-level components in the Basic set are
> supposed to be compositions of beads.  MDL can just compose the same or
> different beads without having to subclass Basic components.
>
> One of the problems of having a core and inheritance is that you have to
> get it right, but often there isn't one right answer.
>
> >I think
> >Basic set (as is) will not be used at all since the final visuals are not
> >production ready, so you know people will need this level of customization
> >or they will never join FleJS for sure. and here you have the first
> >example of many
> >of the styles in flexjs needs to be removed in order to get the MDL branch
> >working ok, and so will happen with others like Bootstrap, and so on...
> >Only if we create our own FlexJS style design could take into account the
> >actual styles, but I think that if MDL or Bootstrap does not need all of
> >that, we should not need creating our own CSS set in the end (I can't say
> >much more here since I'm not a CSS expert to affirm that, but based on
> >what
> >I see...is clear that it's the reality).
> >
>
> In my mind, there are going to be two kinds of themes: pre-existing ones
> like MDL and custom ones like the themes that regular Flex SDK customers
> used to brand their applications.  In the second kind, I don't think it
> matters as much as to what default styles are. Folks will simply override
> the defaults in their themes.
>
> I was a bit surprised that MDL didn't override everything we set as
> defaults for HTML.swc.  That means to me that if someone has certain
> styles set elsewhere, even in their browser settings, that could cause
> really strange and unexpected results.  But OK, that's the way it is, and
> so we should think of other ways to have a default look for HTML.swc,
> although again, as I said above, the MDL library has no obligation to
> inherit from HTML.swc.
>
> If we really need to support more inheritance, then maybe all visual
> styles should be moved from HTML into some default theme.  It would be
> nice to have a better set of defaults that are a bit more production ready
> for Basic so we can see how and why there are collisions between themes.
>
> >You could as well use documentation to expose requirements and make people
> >know that 2 or 3 styles are required and if they remove from CSS things
> >could break. We could prepare as well a MVCSS (minimum viable CSS) so
> >people would not need to use the remove default compiler flag, and have
> >another with relative positions, borders and other no-so required things,
> >but needed in basic comp set.
> >
> >
>
> Way back in early Flex, we found our customers didn't like this.  There
> was a version of Flex where only the type-selectors with the same name as
> the component was applied.  So CheckBox extended Button and lots of styles
> important to Button needed to be copied to the CheckBox type selector.
> This was way faster at runtime because we didn't have to chase down the
> super classes and their styles. But customers really complained because if
> you subclassed Button and made a MyButton, you had to know which styles to
> copy to a MyButton type selector or the component wouldn't work.  I'm sure
> our documentation was not sufficient, but even then, folks thought it was
> a pain.
>
> If you want to ensure no styles are specified in code for the MDL library
> feel free to do so.  I'm just not sure how important tat is for the Basic
> set.
>
> >
> >> Similarly, Label isn't supposed to be interactive, so we turn off mouse
> >> events.  It is the equivalent of mouseEnabled in SWF.  The way we found
> >>to
> >> do it is to set a style.  Again, I'm not sure that should be settable
> >>in a
> >> CSS theme.
> >>
> >>
> >I think so. If we could set the style in CSS and we are not doing this
> >because we are afraid of our user...that's a very bad policy. There's
> >other
> >methods to avoid that. For example, if in MDL mouseEnabled is not
> >contemplated...I would left in my CSS.
> >
> >
> >
> >> The way we handle visible=false also sets a style: display:none.
> >
> >
> >that's one of the styles I historically use when doing some html, and
> 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Peter Ent]

I will be looking into this, this morning (shortly). Just for background:

The ListView creates two things: an outer containment area (div) to house
the chrome (scroll bars, title bars, footer bars, etc) and the content
area (ContainerContentArea).

When we first set this up, the JS side wasn't supposed to create two
things since scroll bars are handled by the browser. But when we decided
there were other "chrome" pieces, the nesting happened.

If things are set up right, just making something an ILayoutHost the
returns itself as the content area should be enough; its what I did for
the MXMLItemRenderer (it is both ILayoutHost and ILayoutParent). The
ILayoutHost is the object which returns which of its children (or itself)
is the ILayoutParent. The ILayoutParent is the thing which will be the
parent of all of the ILayoutChild objects.

I will put an example together today which shows a simpler List without
the nesting.

‹peter

On 12/1/16, 7:40 PM, "Peter Ent"  wrote:

>I'll look into this tomorrow.
>
>Peter 
>
>
>On Dec 1, 2016, at 7:09 PM, Carlos Rovira  wrote:
>
>>> 
>>> Anyway, Peter might be able to better answer your question, but it
>>>appears
>>> that if you create some new subclass of UIBase and have it return
>>>'this'
>>> for layoutHost and contentView, that the ListView might then just stick
>>> the children in the outer div.  See how MXMLItemRenderer (which I
>>> mentioned upthread) differs from ListBase in that way.  There might be
>>> some bugs to iron out, but that's my understanding of how it is
>>>supposed
>>> to work.
>>> 
>>> -Alex
>>> 
>>> 
>> Hi,
>> 
>> Peter as Alex says you could be of great help here, hope you could help
>> getting a simple example since I think is crucial for MDL List component
>> (and other comps that uses the same behaviour).
>> 
>> I'll try to investigate about layoutHost and contentView as Alex
>>mention to
>> be able to remove the middle div layer that List View generates. My
>>target
>> is to get a List that throws:
>> 
>> 
>>   
>>   
>> 
>> 
>> and  elements data will be provided by a dataProvider Array and the
>> layout (the li or whatever we want) by an itemRenderer.
>> 
>> As I get this I'll update some MDL comps that will benefit from this
>> refactor a part from List (TabBar, NavigationBar,...)
>> 
>> 
>> 
>> -- 
>> Carlos Rovira
>> http://about.me/carlosrovira

Re: [FlexJS] last git code doesn't work as of 2016 NOV 29,

[Pan Li]

Hi Alex
I think the javascript runtime issues happened to us again, I don't have
more time to test it fully now, but it seems to happen when I didn't
removed old files before rebuilding. I didn't see this in 0.7.
I will test more later and send you my result if I find something.


My Apache Flex community contribution is working on the open source
Moonshine-IDE.com for FlexJS.

Re: [FlexJS] dialog-polypfill third party JS

[Carlos Rovira]

Ok, so as we can add to our project, I will upload. I think is more safe.

Thanks Justin! :)

2016-12-02 12:08 GMT+01:00 Justin Mclean :

> Hi,
>
> > so this mean I can bundle (upload to our project *git*)
>
> You only need to do that if i'st bundled in the release.
>
> > or better link to CDN JS (don't know reliability of this)
>
> If you do this then it's not bundled so there no need to do anything to
> LICENSE. The downside as you say the CDN may not be 100% up all the time or
> it may change location over time.
>
> Thanks,
> jJustin




-- 

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] dialog-polypfill third party JS

[Justin Mclean]

Hi,

> so this mean I can bundle (upload to our project *git*)

You only need to do that if i'st bundled in the release.

> or better link to CDN JS (don't know reliability of this)

If you do this then it's not bundled so there no need to do anything to 
LICENSE. The downside as you say the CDN may not be 100% up all the time or it 
may change location over time.

Thanks,
jJustin

Re: [FlexJS] dialog-polypfill third party JS

[Carlos Rovira]

Thanks Justin,
so this mean I can bundle (upload to our project *git*) or better link to
CDN JS (don't know reliability of this)



2016-12-02 11:28 GMT+01:00 Justin Mclean :

> Hi,
>
> > I'm finding that MDL Dialog is based on dialog-polyfill:
> >
> > https://github.com/GoogleChrome/dialog-polyfill
> > https://github.com/GoogleChrome/dialog-polyfill/blob/master/LICENSE
> >
> > how should we manage this (taking account of the license)?
>
> It’s 3 clause BSD which is compatible, recommended way is to a short
> pointer to the full text of the license in our LICENSE file. [1]
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/licensing-howto.html#permissive-deps




-- 

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] dialog-polypfill third party JS

[Justin Mclean]

Hi,

> I'm finding that MDL Dialog is based on dialog-polyfill:
> 
> https://github.com/GoogleChrome/dialog-polyfill
> https://github.com/GoogleChrome/dialog-polyfill/blob/master/LICENSE
> 
> how should we manage this (taking account of the license)?

It’s 3 clause BSD which is compatible, recommended way is to a short pointer to 
the full text of the license in our LICENSE file. [1]

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#permissive-deps

[FlexJS] dialog-polypfill third party JS

[Carlos Rovira]

Hi,

I'm finding that MDL Dialog is based on dialog-polyfill:

https://github.com/GoogleChrome/dialog-polyfill
https://github.com/GoogleChrome/dialog-polyfill/blob/master/LICENSE

how should we manage this (taking account of the license)?

I could link as I'm doing with MDL to a hosted CDN here:
https://cdnjs.com/libraries/dialog-polyfill




-- 
Carlos Rovira
http://about.me/carlosrovira

Re: git commit: [flex-asjs] [refs/heads/develop] - - Add first Material Icons beads "cancel" and "add" - Use "add' material icon bead in Buttons example - Add missing classList - Throw error Deletable

[Carlos Rovira]

As I saw is common for all, for that reason I think we could have a Base
Class with that common properties that rest off icons will inherit. If not
you will end replicating in all material icon classes ;)

2016-12-02 7:04 GMT+01:00 piotrz :

> One question - does "md-48" is something what can you put to every
> "material-icons" or it's something specific to some choosen elements?
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/Re-git-commit-flex-asjs-
> refs-heads-develop-Add-first-Material-Icons-beads-cancel-
> and-add-Use-add-mats-tp56899p56912.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.