You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by "Sharma, Pratyoosh" <pr...@jpmorgan.com> on 2013/09/04 00:50:08 UTC
[FlexJS] General questions
I got my workspace setup for ASJS with all the tweaks required for SDK overlay & compilation
Figured out that the best way to start would be to work on a sample application that showcases the components, in the process I will be able to modify components & test them as well (in future it can be enhanced & used as a Flex ASJS demo app as well)
I stepped into few bugs with the components & got them fixed (pretty minor stuff so far this missing on Alert.js), so what is the most straightforward way to contribute the code back? Send it back to the maintainer?
I am reading the tutorial & generated code so hopefully I will be able to unlock my doubts on styling on components :), but the plan generally seems not to expose style as properties like Flex , correct?
Thanks,
Pratyoosh
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
Re: [FlexJS] General questions
Posted by Cosma Colanicchia <co...@gmail.com>.
>
> IMO, a pain point in Flex was that styles had to be specified on the
> component when the style implementation was actually in the skin/theme.
> The skinning model is different in FlexJS anyway so I think that gives us
> license to change the styling model as well. If you ever set a style on a
> Flex component that wasn't in your custom theme, or tried to add a new
> style to a skin/theme that wasn't declared on the component, then you know
> what pain I'm talking about.
>
>
Absolutely.
Some time ago I was writing about this on the list: "... this make me think
about a limitation see with current Spark skinning implementation: the
relation between skins and styles. Sometime it would be useful to
"configure" some skin visual properties directly from MXML using a style,
but style must be declared by the host component (even if inherited by the
skin, think about "borderColor" and "borderAlpha"). This force you to
subclass and/or create a strong dependency between component and skin
(leading to "theme warnings", such as "the style XXX could only be used
with theme YYY"). My current workaround is to use CSS rules to assign
styles directly
to skin classes, but its far from perfect.."
I didn't have the chance to see if the FalconJS skinning model overcome
this issue, is there some wiki page or thread explaining the approach?
Thanks,
Cosma
RE: [FlexJS] General questions
Posted by "Sharma, Pratyoosh" <pr...@jpmorgan.com>.
Well there has to be an order of override:
If there is a conflict the inline declared style property wins over something buried inside a style attribute, but I am not a code usability expert :)
Also I am hopeful that tooling would mature eventually but I would avoid counting on it if I can.
You have to remember that components in new flex framework would be composite as well & they would have underlying components that would need to have their styles exposed as well
Talk is cheap so I will pull some code sample & I guess we can more effectively arbitrate on that.
Thanks,
Pratyoosh
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Wednesday, September 04, 2013 12:17 PM
To: dev@flex.apache.org
Subject: Re: [FlexJS] General questions
On 9/4/13 9:04 AM, "Cosma Colanicchia" <co...@gmail.com> wrote:
>2013/9/4 Alex Harui <ah...@adobe.com>
>
>> Maybe we'll have an 'customStyles' object for styles that aren't in
>> CSS
>
>
>+1 (I would prefer simply "styles" as for the name)
Maybe, but then folks might stuff all of their styles in there. Which would work, but maybe we shouldn't invite them to do that? What wins if you do:
<foo style="color:red" color="red" />
-Alex
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
Re: [FlexJS] General questions
Posted by Cosma Colanicchia <co...@gmail.com>.
Maybe we could follow W3C rules, if any, in this case. Its the "custom"
prefix that feels just too broad to me, and could lead to confusion..
2013/9/4 Alex Harui <ah...@adobe.com>
>
>
> On 9/4/13 9:04 AM, "Cosma Colanicchia" <co...@gmail.com> wrote:
>
> >2013/9/4 Alex Harui <ah...@adobe.com>
> >
> >> Maybe we'll have an 'customStyles' object for styles that aren't in CSS
> >
> >
> >+1 (I would prefer simply "styles" as for the name)
> Maybe, but then folks might stuff all of their styles in there. Which
> would work, but maybe we shouldn't invite them to do that? What wins if
> you do:
> <foo style="color:red" color="red" />
>
> -Alex
>
>
Re: [FlexJS] General questions
Posted by Alex Harui <ah...@adobe.com>.
On 9/4/13 9:04 AM, "Cosma Colanicchia" <co...@gmail.com> wrote:
>2013/9/4 Alex Harui <ah...@adobe.com>
>
>> Maybe we'll have an 'customStyles' object for styles that aren't in CSS
>
>
>+1 (I would prefer simply "styles" as for the name)
Maybe, but then folks might stuff all of their styles in there. Which
would work, but maybe we shouldn't invite them to do that? What wins if
you do:
<foo style="color:red" color="red" />
-Alex
Re: [FlexJS] General questions
Posted by Cosma Colanicchia <co...@gmail.com>.
2013/9/4 Alex Harui <ah...@adobe.com>
> Maybe we'll have an 'customStyles' object for styles that aren't in CSS
+1 (I would prefer simply "styles" as for the name)
RE: [FlexJS] General questions
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Just a random comment for the IE8 issue.
We have IE8 here on our enterprise network. IE9 is approved already, but who knows when they will actually setup a package for it and push it (they are really slow about it, sometimes years). I would rather keeping using standard flex web-apps than use an JS IE8 version that has made lots of special considerations. After all IE9 is the first version that (to me at least) starts working better and supporting standards.
-Mark
Re: [FlexJS] General questions
Posted by Alex Harui <ah...@adobe.com>.
Code-completion is a strong argument, but it can be done in the styles
object as well, although FB doesn't know how to do that today.
Maybe we'll have an 'customStyles' object for styles that aren't in CSS
spec.
-Alex
On 9/4/13 7:14 AM, "Sharma, Pratyoosh" <pr...@jpmorgan.com>
wrote:
>Thanks for your prompt reply Alex, I will add JIRA items for defects
>
>I did a little bit for deep digging into the CSS file generated & can see
>that it would barely work.
>I have a certain itch to make the sample application look beautiful so I
>will try to make it work with the consensus from group here.
>
>I read both Om's & Alex's option, as a classic Flex application
>developer, I absolutely love to be able to able to specify basic style
>overrides on the component declaration itself without sub classing on the
>CSS; it's a huge productivity boost
>
>I guess here are the design considerations
>
>1) Inline styling would though add quite a bit of code to the component,
>how do we define the basic style properties that would be available for
>inline declaration (I can see that this can be frustration for few users).
>2) I agree with that just in-line styles should not be the way to go & as
>new style properties come around & start getting supported by modern
>browsers, SDK modification should not be necessary for consumers to use
>it.
>3) Internet explorer 8 is not going anywhere near term in the enterprises
>for sure & people would be tempted to use CSS goodies provided by the
>modern browsers, does SCSS makes more sense?
>
>Thanks,
>Pratyoosh
>-----Original Message-----
>From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of OmPrakash
>Muppirala
>Sent: Tuesday, September 03, 2013 8:13 PM
>To: dev@flex.apache.org
>Subject: Re: [FlexJS] General questions
>
>On Tue, Sep 3, 2013 at 5:03 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 9/3/13 4:55 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>>
>> >On Tue, Sep 3, 2013 at 4:38 PM, Alex Harui <ah...@adobe.com> wrote:
>> >
>> >> Good question. I added a FalconJX and FlexJS component to JIRA.
>> >> Please submit patches there. There is already a Falcon component.
>> >>
>> >> In theory, if you have problems compiling a SWF that FB/MXMLC
>> >>compiled, then file the bug against Falcon. If Falcon compiled the
>> >>SWF but you get an error creating the JS version, file the bug
>> >>against FalconJX, and if there is a bug in the AS or JS code, file
>> >>the bug against FlexJS.
>> >>
>> >> The styling implementation on JS is not yet complete, so you can't
>> >>use non-standard CSS styles in JS right now. But the goal is to
>> >>support the appropriate CSS styles in the SWF since those styles
>>should "just work"
>> >>in
>> >> the browser.
>> >>
>> >> In-line styles (like <basic:Foo color="red" />) isn't supported yet
>> >> either. I'm on the fence about whether to keep adding
>> >> styles/properties or just use HTML's styles object (like <basic:Foo
>>style="color:red" />).
>> >> Some properties like "width" also support being set in CSS.
>> >> Opinions welcome.
>> >>
>> >
>> >It would be nice if we retained the current Flex way of inlining
>> >styles/properties, please.
>> I assume your main reason is compatibility? That's definitely a
>> strong argument, but here's the counter-argument:
>>
>> IMO, a pain point in Flex was that styles had to be specified on the
>> component when the style implementation was actually in the skin/theme.
>>
>
>For the component developer, yes it was a pain. As an SDK user, this was
>not a pain point at all :-) My biggest problem with the styles property
>is that it does not play well with autocomplete. I have the same
>problems with the setStyle method. I vote for the convenience of being
>able to set these on the components itself. I think it just makes sense.
>
>
>> The skinning model is different in FlexJS anyway so I think that gives
>> us license to change the styling model as well. If you ever set a
>> style on a Flex component that wasn't in your custom theme, or tried
>> to add a new style to a skin/theme that wasn't declared on the
>> component, then you know what pain I'm talking about. With FlexJS,
>> some new browser might come up with a new custom CSS property and you
>> won't be able to set it in MXML without us rev-ing the entire SDK.
>> Yes, you should be able to set it in the .CSS file, but just not
>>in-line.
>>
>
>Great points - never thought of that. I agree with the 'just not in-line'
>part. But support for in-lining should also be available like it is
>today. For most cases, this convenience is very useful.
>
>Thanks,
>Om
>
>
>
>
>>
>> Thoughts?
>> -Alex
>>
>>
>>
>
>This email is confidential and subject to important disclaimers and
>conditions including on offers for the purchase or sale of securities,
>accuracy and completeness of information, viruses, confidentiality, legal
>privilege, and legal entity disclaimers, available at
>http://www.jpmorgan.com/pages/disclosures/email.
RE: [FlexJS] General questions
Posted by "Sharma, Pratyoosh" <pr...@jpmorgan.com>.
Thanks for your prompt reply Alex, I will add JIRA items for defects
I did a little bit for deep digging into the CSS file generated & can see that it would barely work.
I have a certain itch to make the sample application look beautiful so I will try to make it work with the consensus from group here.
I read both Om's & Alex's option, as a classic Flex application developer, I absolutely love to be able to able to specify basic style overrides on the component declaration itself without sub classing on the CSS; it's a huge productivity boost
I guess here are the design considerations
1) Inline styling would though add quite a bit of code to the component, how do we define the basic style properties that would be available for inline declaration (I can see that this can be frustration for few users).
2) I agree with that just in-line styles should not be the way to go & as new style properties come around & start getting supported by modern browsers, SDK modification should not be necessary for consumers to use it.
3) Internet explorer 8 is not going anywhere near term in the enterprises for sure & people would be tempted to use CSS goodies provided by the modern browsers, does SCSS makes more sense?
Thanks,
Pratyoosh
-----Original Message-----
From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of OmPrakash Muppirala
Sent: Tuesday, September 03, 2013 8:13 PM
To: dev@flex.apache.org
Subject: Re: [FlexJS] General questions
On Tue, Sep 3, 2013 at 5:03 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 9/3/13 4:55 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >On Tue, Sep 3, 2013 at 4:38 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> Good question. I added a FalconJX and FlexJS component to JIRA.
> >> Please submit patches there. There is already a Falcon component.
> >>
> >> In theory, if you have problems compiling a SWF that FB/MXMLC
> >>compiled, then file the bug against Falcon. If Falcon compiled the
> >>SWF but you get an error creating the JS version, file the bug
> >>against FalconJX, and if there is a bug in the AS or JS code, file
> >>the bug against FlexJS.
> >>
> >> The styling implementation on JS is not yet complete, so you can't
> >>use non-standard CSS styles in JS right now. But the goal is to
> >>support the appropriate CSS styles in the SWF since those styles should "just work"
> >>in
> >> the browser.
> >>
> >> In-line styles (like <basic:Foo color="red" />) isn't supported yet
> >> either. I'm on the fence about whether to keep adding
> >> styles/properties or just use HTML's styles object (like <basic:Foo style="color:red" />).
> >> Some properties like "width" also support being set in CSS.
> >> Opinions welcome.
> >>
> >
> >It would be nice if we retained the current Flex way of inlining
> >styles/properties, please.
> I assume your main reason is compatibility? That's definitely a
> strong argument, but here's the counter-argument:
>
> IMO, a pain point in Flex was that styles had to be specified on the
> component when the style implementation was actually in the skin/theme.
>
For the component developer, yes it was a pain. As an SDK user, this was
not a pain point at all :-) My biggest problem with the styles property
is that it does not play well with autocomplete. I have the same problems with the setStyle method. I vote for the convenience of being able to set these on the components itself. I think it just makes sense.
> The skinning model is different in FlexJS anyway so I think that gives
> us license to change the styling model as well. If you ever set a
> style on a Flex component that wasn't in your custom theme, or tried
> to add a new style to a skin/theme that wasn't declared on the
> component, then you know what pain I'm talking about. With FlexJS,
> some new browser might come up with a new custom CSS property and you
> won't be able to set it in MXML without us rev-ing the entire SDK.
> Yes, you should be able to set it in the .CSS file, but just not in-line.
>
Great points - never thought of that. I agree with the 'just not in-line'
part. But support for in-lining should also be available like it is today. For most cases, this convenience is very useful.
Thanks,
Om
>
> Thoughts?
> -Alex
>
>
>
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
Re: [FlexJS] General questions
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Tue, Sep 3, 2013 at 5:03 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 9/3/13 4:55 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >On Tue, Sep 3, 2013 at 4:38 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> Good question. I added a FalconJX and FlexJS component to JIRA. Please
> >> submit patches there. There is already a Falcon component.
> >>
> >> In theory, if you have problems compiling a SWF that FB/MXMLC compiled,
> >> then file the bug against Falcon. If Falcon compiled the SWF but you
> >>get
> >> an error creating the JS version, file the bug against FalconJX, and if
> >> there is a bug in the AS or JS code, file the bug against FlexJS.
> >>
> >> The styling implementation on JS is not yet complete, so you can't use
> >> non-standard CSS styles in JS right now. But the goal is to support the
> >> appropriate CSS styles in the SWF since those styles should "just work"
> >>in
> >> the browser.
> >>
> >> In-line styles (like <basic:Foo color="red" />) isn't supported yet
> >> either. I'm on the fence about whether to keep adding styles/properties
> >> or just use HTML's styles object (like <basic:Foo style="color:red" />).
> >> Some properties like "width" also support being set in CSS. Opinions
> >> welcome.
> >>
> >
> >It would be nice if we retained the current Flex way of inlining
> >styles/properties, please.
> I assume your main reason is compatibility? That's definitely a strong
> argument, but here's the counter-argument:
>
> IMO, a pain point in Flex was that styles had to be specified on the
> component when the style implementation was actually in the skin/theme.
>
For the component developer, yes it was a pain. As an SDK user, this was
not a pain point at all :-) My biggest problem with the styles property
is that it does not play well with autocomplete. I have the same problems
with the setStyle method. I vote for the convenience of being able to set
these on the components itself. I think it just makes sense.
> The skinning model is different in FlexJS anyway so I think that gives us
> license to change the styling model as well. If you ever set a style on a
> Flex component that wasn't in your custom theme, or tried to add a new
> style to a skin/theme that wasn't declared on the component, then you know
> what pain I'm talking about. With FlexJS, some new browser might come up
> with a new custom CSS property and you won't be able to set it in MXML
> without us rev-ing the entire SDK. Yes, you should be able to set it in
> the .CSS file, but just not in-line.
>
Great points - never thought of that. I agree with the 'just not in-line'
part. But support for in-lining should also be available like it is
today. For most cases, this convenience is very useful.
Thanks,
Om
>
> Thoughts?
> -Alex
>
>
>
Re: [FlexJS] General questions
Posted by Alex Harui <ah...@adobe.com>.
On 9/8/13 10:01 PM, "flexcapacitor@gmail.com" <fl...@gmail.com>
wrote:
>Yes, I agree. What might alleviate that pain would be:
>
>€ move all the styles metadata into the skin instead of the component.
>have
>the component declare skin styles like we declare skin parts, so
>[SkinStyle(name="color", required=true)]
>€ or allow styles to be declared in the skin and make the compiler add
>those styles to the list of styles available to that component type for
>code completion and compilation
>€ or add a compiler flag to ignore attributes it is not aware of
>(highlight
>in a different color?) and treat those unknown attributes as styles.
>€ or add a styles proxy object on the component for styles not known to
>the
>component
>
><button>
> <styles color="red" cornerRadius="8" />
></button>
>
>I would prefer the above to inline, "color:red;cornerRadius:8".
>
>The more I think about it MXML should be a generic XML description of an
>application. Since we want MXML to output to other languages things like
>binding expressions and inline name value pairs like,
>style="fontFamily:Arial;fontWeight:bold" are getting away from the one of
>the reasons that XML was created; that being readability.
>
>I think another feature of an XML spec is that it defines guidelines for
>parsers. E4X is an advanced notation to get right to the information you
>need in an XML document. With, style="color:yellow;fontFamily:Times New
>Roman" you would need to use E4X to get the attribute and then another
>expression engine, RegExp, to get the names and values you need.
>
>I'm not saying no to inline styles but to keep in mind MXML's roots. In
>time, as MXML is adopted, the tooling and the developer base will grow as
>well and I would think we'd want a distributable document to be as
>portable
>and parsable as possible (say that 3 times fast).
All good thoughts and suggestions. I'm still not sure what we're going
to do, but I've ruled out only using html-like inline styles for now.
>
>Are you using the style property as a proxy to the CSS class now?
>
>MXML,
><style source="styles.css"/>
><button style="MyStyles" />
>
>HTML,
><stylesheet src="styles.css"></stylesheet>
><input class="MyStyles"></input>
>
Yes, and some properties like width and height get set in HTML on the
styles object. Although today, it only works for known CSS properties.
I'm exploring what to do for custom CSS properties, especially in IE8.
The goal is to find best practices in HTML/JS then wrap and present them
in AS3.
-Alex
Re: [FlexJS] General questions
Posted by jude <fl...@gmail.com>.
Yes, I agree. What might alleviate that pain would be:
• move all the styles metadata into the skin instead of the component. have
the component declare skin styles like we declare skin parts, so
[SkinStyle(name="color", required=true)]
• or allow styles to be declared in the skin and make the compiler add
those styles to the list of styles available to that component type for
code completion and compilation
• or add a compiler flag to ignore attributes it is not aware of (highlight
in a different color?) and treat those unknown attributes as styles.
• or add a styles proxy object on the component for styles not known to the
component
<button>
<styles color="red" cornerRadius="8" />
</button>
I would prefer the above to inline, "color:red;cornerRadius:8".
The more I think about it MXML should be a generic XML description of an
application. Since we want MXML to output to other languages things like
binding expressions and inline name value pairs like,
style="fontFamily:Arial;fontWeight:bold" are getting away from the one of
the reasons that XML was created; that being readability.
I think another feature of an XML spec is that it defines guidelines for
parsers. E4X is an advanced notation to get right to the information you
need in an XML document. With, style="color:yellow;fontFamily:Times New
Roman" you would need to use E4X to get the attribute and then another
expression engine, RegExp, to get the names and values you need.
I'm not saying no to inline styles but to keep in mind MXML's roots. In
time, as MXML is adopted, the tooling and the developer base will grow as
well and I would think we'd want a distributable document to be as portable
and parsable as possible (say that 3 times fast).
Are you using the style property as a proxy to the CSS class now?
MXML,
<style source="styles.css"/>
<button style="MyStyles" />
HTML,
<stylesheet src="styles.css"></stylesheet>
<input class="MyStyles"></input>
On Tue, Sep 3, 2013 at 7:03 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 9/3/13 4:55 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >On Tue, Sep 3, 2013 at 4:38 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> Good question. I added a FalconJX and FlexJS component to JIRA. Please
> >> submit patches there. There is already a Falcon component.
> >>
> >> In theory, if you have problems compiling a SWF that FB/MXMLC compiled,
> >> then file the bug against Falcon. If Falcon compiled the SWF but you
> >>get
> >> an error creating the JS version, file the bug against FalconJX, and if
> >> there is a bug in the AS or JS code, file the bug against FlexJS.
> >>
> >> The styling implementation on JS is not yet complete, so you can't use
> >> non-standard CSS styles in JS right now. But the goal is to support the
> >> appropriate CSS styles in the SWF since those styles should "just work"
> >>in
> >> the browser.
> >>
> >> In-line styles (like <basic:Foo color="red" />) isn't supported yet
> >> either. I'm on the fence about whether to keep adding styles/properties
> >> or just use HTML's styles object (like <basic:Foo style="color:red" />).
> >> Some properties like "width" also support being set in CSS. Opinions
> >> welcome.
> >>
> >
> >It would be nice if we retained the current Flex way of inlining
> >styles/properties, please.
> I assume your main reason is compatibility? That's definitely a strong
> argument, but here's the counter-argument:
>
> IMO, a pain point in Flex was that styles had to be specified on the
> component when the style implementation was actually in the skin/theme.
> The skinning model is different in FlexJS anyway so I think that gives us
> license to change the styling model as well. If you ever set a style on a
> Flex component that wasn't in your custom theme, or tried to add a new
> style to a skin/theme that wasn't declared on the component, then you know
> what pain I'm talking about. With FlexJS, some new browser might come up
> with a new custom CSS property and you won't be able to set it in MXML
> without us rev-ing the entire SDK. Yes, you should be able to set it in
> the .CSS file, but just not in-line.
>
> Thoughts?
> -Alex
>
>
>
Re: [FlexJS] General questions
Posted by Alex Harui <ah...@adobe.com>.
On 9/3/13 4:55 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>On Tue, Sep 3, 2013 at 4:38 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> Good question. I added a FalconJX and FlexJS component to JIRA. Please
>> submit patches there. There is already a Falcon component.
>>
>> In theory, if you have problems compiling a SWF that FB/MXMLC compiled,
>> then file the bug against Falcon. If Falcon compiled the SWF but you
>>get
>> an error creating the JS version, file the bug against FalconJX, and if
>> there is a bug in the AS or JS code, file the bug against FlexJS.
>>
>> The styling implementation on JS is not yet complete, so you can't use
>> non-standard CSS styles in JS right now. But the goal is to support the
>> appropriate CSS styles in the SWF since those styles should "just work"
>>in
>> the browser.
>>
>> In-line styles (like <basic:Foo color="red" />) isn't supported yet
>> either. I'm on the fence about whether to keep adding styles/properties
>> or just use HTML's styles object (like <basic:Foo style="color:red" />).
>> Some properties like "width" also support being set in CSS. Opinions
>> welcome.
>>
>
>It would be nice if we retained the current Flex way of inlining
>styles/properties, please.
I assume your main reason is compatibility? That's definitely a strong
argument, but here's the counter-argument:
IMO, a pain point in Flex was that styles had to be specified on the
component when the style implementation was actually in the skin/theme.
The skinning model is different in FlexJS anyway so I think that gives us
license to change the styling model as well. If you ever set a style on a
Flex component that wasn't in your custom theme, or tried to add a new
style to a skin/theme that wasn't declared on the component, then you know
what pain I'm talking about. With FlexJS, some new browser might come up
with a new custom CSS property and you won't be able to set it in MXML
without us rev-ing the entire SDK. Yes, you should be able to set it in
the .CSS file, but just not in-line.
Thoughts?
-Alex
Re: [FlexJS] General questions
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Tue, Sep 3, 2013 at 4:38 PM, Alex Harui <ah...@adobe.com> wrote:
> Good question. I added a FalconJX and FlexJS component to JIRA. Please
> submit patches there. There is already a Falcon component.
>
> In theory, if you have problems compiling a SWF that FB/MXMLC compiled,
> then file the bug against Falcon. If Falcon compiled the SWF but you get
> an error creating the JS version, file the bug against FalconJX, and if
> there is a bug in the AS or JS code, file the bug against FlexJS.
>
> The styling implementation on JS is not yet complete, so you can't use
> non-standard CSS styles in JS right now. But the goal is to support the
> appropriate CSS styles in the SWF since those styles should "just work" in
> the browser.
>
> In-line styles (like <basic:Foo color="red" />) isn't supported yet
> either. I'm on the fence about whether to keep adding styles/properties
> or just use HTML's styles object (like <basic:Foo style="color:red" />).
> Some properties like "width" also support being set in CSS. Opinions
> welcome.
>
It would be nice if we retained the current Flex way of inlining
styles/properties, please.
Om
>
> And thanks for trying it out,
> -Alex
>
>
> On 9/3/13 3:50 PM, "Sharma, Pratyoosh" <pr...@jpmorgan.com>
> wrote:
>
> >I got my workspace setup for ASJS with all the tweaks required for SDK
> >overlay & compilation
> >
> >Figured out that the best way to start would be to work on a sample
> >application that showcases the components, in the process I will be able
> >to modify components & test them as well (in future it can be enhanced &
> >used as a Flex ASJS demo app as well)
> >
> >I stepped into few bugs with the components & got them fixed (pretty
> >minor stuff so far this missing on Alert.js), so what is the most
> >straightforward way to contribute the code back? Send it back to the
> >maintainer?
> >
> >I am reading the tutorial & generated code so hopefully I will be able to
> >unlock my doubts on styling on components :), but the plan generally
> >seems not to expose style as properties like Flex , correct?
> >
> >Thanks,
> >Pratyoosh
> >
> >
> >This email is confidential and subject to important disclaimers and
> >conditions including on offers for the purchase or sale of securities,
> >accuracy and completeness of information, viruses, confidentiality, legal
> >privilege, and legal entity disclaimers, available at
> >http://www.jpmorgan.com/pages/disclosures/email.
>
>
Re: [FlexJS] General questions
Posted by Alex Harui <ah...@adobe.com>.
Good question. I added a FalconJX and FlexJS component to JIRA. Please
submit patches there. There is already a Falcon component.
In theory, if you have problems compiling a SWF that FB/MXMLC compiled,
then file the bug against Falcon. If Falcon compiled the SWF but you get
an error creating the JS version, file the bug against FalconJX, and if
there is a bug in the AS or JS code, file the bug against FlexJS.
The styling implementation on JS is not yet complete, so you can't use
non-standard CSS styles in JS right now. But the goal is to support the
appropriate CSS styles in the SWF since those styles should "just work" in
the browser.
In-line styles (like <basic:Foo color="red" />) isn't supported yet
either. I'm on the fence about whether to keep adding styles/properties
or just use HTML's styles object (like <basic:Foo style="color:red" />).
Some properties like "width" also support being set in CSS. Opinions
welcome.
And thanks for trying it out,
-Alex
On 9/3/13 3:50 PM, "Sharma, Pratyoosh" <pr...@jpmorgan.com>
wrote:
>I got my workspace setup for ASJS with all the tweaks required for SDK
>overlay & compilation
>
>Figured out that the best way to start would be to work on a sample
>application that showcases the components, in the process I will be able
>to modify components & test them as well (in future it can be enhanced &
>used as a Flex ASJS demo app as well)
>
>I stepped into few bugs with the components & got them fixed (pretty
>minor stuff so far this missing on Alert.js), so what is the most
>straightforward way to contribute the code back? Send it back to the
>maintainer?
>
>I am reading the tutorial & generated code so hopefully I will be able to
>unlock my doubts on styling on components :), but the plan generally
>seems not to expose style as properties like Flex , correct?
>
>Thanks,
>Pratyoosh
>
>
>This email is confidential and subject to important disclaimers and
>conditions including on offers for the purchase or sale of securities,
>accuracy and completeness of information, viruses, confidentiality, legal
>privilege, and legal entity disclaimers, available at
>http://www.jpmorgan.com/pages/disclosures/email.