Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread James Ong
Using ZK and Java is great. I'm still sticking to Flex for developing
desktop applications and gaming.
Of course, many will still using it for animations, there is no such thing
as abandon, some developers
are just over use Flash and end up hurting user experience than necessary.

When it comes to web application, I stick to PHP but will definitely use
Flex for mobile, desktop and
components within the web browser.


On Thu, Jan 12, 2012 at 10:16 AM, michael_reg...@dell.com wrote:

 **


 Staying with Flex.  Not looking elsewhere.

 ** **

 *Michael*

 ** **

 *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] *On
 Behalf Of *Ron G
 *Sent:* Wednesday, January 11, 2012 8:15 PM
 *To:* flexcoders@yahoogroups.com
 *Subject:* [flexcoders] Re: Flex alternatives

 ** **

   

 Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a
 Java shop, on the server side, it seemed logical to use a Java based
 framework on the client-side.

 The thing I really like about ZK or ZKoss is that it has equivalent
 components to Flex. In fact, it actually has more components than Flex.

 It implements an approach that I really like of separating the UI into
 appearance and behavior - much like the Spark components of Flex. Well, not
 exactly, but sort of. :) Here's what I mean. For each UI object, it has a
 client side (widget) and server side (component). I won't go into further
 detail, but it gives you a nice separation of concerns that you can avail
 yourself of. This feature also greatly insulates the rendered pages from
 x-browser compatibility issues.

 Check it out for yourself at their site (zkoss.org).

 Ron

 --- In flexcoders@yahoogroups.com, Sal sal.celli@... wrote:
 
  hi,
  as i can sadly see from the message history bottom grid, many
 programmers are leaving flex.
  So this thread is to ask you all, if you have already found a valid
 alternative to flex for RIA development.
 

 

  



RE: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Merrill, Jason
Unless I'm not understanding it right, ZKoss looks like it requires some web 
server configuration in order to run.  Flex doesn't, which is nice for people 
like me who work in server environments they can't control.  But it looks like 
awesome tech! Am I right about it needing server side configuration?

Jason Merrill
Instructional Technology Architect II
Bank of America  Global Learning





___

From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf 
Of Ron G
Sent: Wednesday, January 11, 2012 9:15 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Flex alternatives



Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a Java 
shop, on the server side, it seemed logical to use a Java based framework on 
the client-side.

The thing I really like about ZK or ZKoss is that it has equivalent components 
to Flex. In fact, it actually has more components than Flex.

It implements an approach that I really like of separating the UI into 
appearance and behavior - much like the Spark components of Flex. Well, not 
exactly, but sort of. :) Here's what I mean. For each UI object, it has a 
client side (widget) and server side (component). I won't go into further 
detail, but it gives you a nice separation of concerns that you can avail 
yourself of. This feature also greatly insulates the rendered pages from 
x-browser compatibility issues.

Check it out for yourself at their site (zkoss.org).

Ron

--- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, Sal 
sal.celli@... wrote:

 hi,
 as i can sadly see from the message history bottom grid, many programmers are 
 leaving flex.
 So this thread is to ask you all, if you have already found a valid 
 alternative to flex for RIA development.



--
This message w/attachments (message) is intended solely for the use of the 
intended recipient(s) and may contain information that is privileged, 
confidential or proprietary. If you are not an intended recipient, please 
notify the sender, and then please delete and destroy all copies and 
attachments, and be advised that any review or dissemination of, or the taking 
of any action in reliance on, the information contained in or attached to this 
message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a 
solicitation of any investment products or other financial product or service, 
an official confirmation of any transaction, or an official statement of 
Sender. Subject to applicable law, Sender may intercept, monitor, review and 
retain e-communications (EC) traveling through its networks/systems and may 
produce any such EC to regulators, law enforcement, in litigation and as 
required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, 
and EC may be archived, supervised and produced in countries other than the 
country in which you are located. This message cannot be guaranteed to be 
secure or free of errors or viruses. 

References to Sender are references to any subsidiary of Bank of America 
Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are 
Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a 
Condition to Any Banking Service or Activity * Are Not Insured by Any Federal 
Government Agency. Attachments that are part of this EC may have additional 
important disclosures and disclaimers, which you should read. This message is 
subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you 
consent to the foregoing.


[flexcoders] Re: How to access IP camera with Adobe air?

2012-01-12 Thread markflex2007
Hi James,

Thanks for help.

how to to access offline mjpeg video?  please give me a help.

Thanks

Mark
--- In flexcoders@yahoogroups.com, James Ong yanlilei64@... wrote:

 Video stream back through mjpeg and output to AIR will be tricky unless you
 have a streaming server and serve over UDP protocol.
 Definitely need a server to push data into the AIR application.
 
 If you prefer to access offline mjpeg video, it should be easy as using
 netconnection.
 
 On Thu, Jan 12, 2012 at 3:00 AM, markflex2007 markflex2007@...wrote:
 
  **
 
 
 
  IP camera is not attached to current computer. and just provide a access
  ip that is a mjpeg format file.
 
  Any idea to do this.Thanks
 
  Mark
 
 
  --- In flexcoders@yahoogroups.com, markflex2007 markflex2007@
  wrote:
  
   Hi
  
   IP camera can provide a link/url with mjpeg format. I am not sure how
  air/flex can access it.
  
   The problem is how to load mjpeg link in Flex/Air now.
  
   mjpeg is motion jpeg. I try different ways and I can not load the link
  in flex.
  
   Please help.
  
   Thanks
  
   Mark
  
 
   
 





[flexcoders] Re: Flex Virtual Camera

2012-01-12 Thread markflex2007
any way flex can access Virtual Camera? Thanks

Mark

--- In flexcoders@yahoogroups.com, Dave Cates dave.cates@... wrote:

 Hey Mark,
 
 Camera.getCamera will only work for physically connected devices to the 
 machine where the Flash app is running - like a USB webcam.
 
 What you want to do is access the IP camera via a StageWebView component - 
 basically a webkit browser. Just point the component at the URL for the 
 camera.
 
 http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/media/StageWebView.html
 
 That will display the camera output as it would do in a standard browser.
 
 Hope that helps!
 
 Dave.
 
 On 11 Jan 2012, at 19:42, markflex2007 wrote:
 
  Hi,
  
  I have a ip camera and it is hard to access it with Flex app directly now.
  
  I plan to the following things.
  
  1. install virtual camera software in local pc.
  2. use virtual camera access the ip camera.
  3. use Flex access Virtual camera.
  
  Do you think if it is possible. I am not sure if the following code can 
  work with virtual camera. any idea?
  
  var cam:Camera = Camera.getCamera();
  
  Thanks for help
  
  Mark
  
  --- In flexcoders@yahoogroups.com, Fernando Lobos fernandolobos@ wrote:
  
   Flash media server is your best friend
   
   On Wed, Jan 11, 2012 at 4:14 PM, markflex2007 markflex2007@wrote:
   
**
   
   
Is someone know how to use flex access virtual camera? Thanks
   
Mark
   
--- In flexcoders@yahoogroups.com, Zuberul Islam zuberul@ wrote:

 hi all,

 the problem isnt solved yet. my virtual camera works well with all
 other applications. but flex crashes to detect them.

 whats the property that flex searches for ? or is there any special
 interface property that must be preset ??

 Thanks in Advance.


 --- In flexcoders@yahoogroups.com, Zuberul Islam zuberul@
 wrote:
 
  Hello All,
 
  i have written a virtual webcam application as a directshow filter 
  have registered it in windows.
 
  from flex when i call Camera.names the flex application crashes.
 
  but when the virtual camera's are unregistered the application runs
  well.
 
  so what's the problem with these virtual cameras ??
 
  Thanks.
 

   

   
  
  
 





[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G
Hi Jason,

The only configuration is that I had to drop several of their jar files into 
the endorsed directory of Tomcat. 

Ron


--- In flexcoders@yahoogroups.com, Merrill, Jason jason.merrill@... wrote:

 Unless I'm not understanding it right, ZKoss looks like it requires some web 
 server configuration in order to run.  Flex doesn't, which is nice for people 
 like me who work in server environments they can't control.  But it looks 
 like awesome tech! Am I right about it needing server side configuration?
 
 Jason Merrill
 Instructional Technology Architect II
 Bank of America  Global Learning
 
 
 
 
 
 ___
 
 From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On 
 Behalf Of Ron G
 Sent: Wednesday, January 11, 2012 9:15 PM
 To: flexcoders@yahoogroups.com
 Subject: [flexcoders] Re: Flex alternatives
 
 
 
 Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a 
 Java shop, on the server side, it seemed logical to use a Java based 
 framework on the client-side.
 
 The thing I really like about ZK or ZKoss is that it has equivalent 
 components to Flex. In fact, it actually has more components than Flex.
 
 It implements an approach that I really like of separating the UI into 
 appearance and behavior - much like the Spark components of Flex. Well, not 
 exactly, but sort of. :) Here's what I mean. For each UI object, it has a 
 client side (widget) and server side (component). I won't go into further 
 detail, but it gives you a nice separation of concerns that you can avail 
 yourself of. This feature also greatly insulates the rendered pages from 
 x-browser compatibility issues.
 
 Check it out for yourself at their site (zkoss.org).
 
 Ron
 
 --- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, Sal 
 sal.celli@ wrote:
 
  hi,
  as i can sadly see from the message history bottom grid, many programmers 
  are leaving flex.
  So this thread is to ask you all, if you have already found a valid 
  alternative to flex for RIA development.
 
 
 
 --
 This message w/attachments (message) is intended solely for the use of the 
 intended recipient(s) and may contain information that is privileged, 
 confidential or proprietary. If you are not an intended recipient, please 
 notify the sender, and then please delete and destroy all copies and 
 attachments, and be advised that any review or dissemination of, or the 
 taking of any action in reliance on, the information contained in or attached 
 to this message is prohibited. 
 Unless specifically indicated, this message is not an offer to sell or a 
 solicitation of any investment products or other financial product or 
 service, an official confirmation of any transaction, or an official 
 statement of Sender. Subject to applicable law, Sender may intercept, 
 monitor, review and retain e-communications (EC) traveling through its 
 networks/systems and may produce any such EC to regulators, law enforcement, 
 in litigation and as required by law. 
 The laws of the country of each sender/recipient may impact the handling of 
 EC, and EC may be archived, supervised and produced in countries other than 
 the country in which you are located. This message cannot be guaranteed to be 
 secure or free of errors or viruses. 
 
 References to Sender are references to any subsidiary of Bank of America 
 Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are 
 Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a 
 Condition to Any Banking Service or Activity * Are Not Insured by Any Federal 
 Government Agency. Attachments that are part of this EC may have additional 
 important disclosures and disclaimers, which you should read. This message is 
 subject to terms available at the following link: 
 http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you 
 consent to the foregoing.





[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G
Hi James,

I certainly respect the decision of those who are sticking with Flex, but I 
would suggest that developers do so with the recognition that they may be 
developing with a technology that isn't going to be around that long. 

I could write at length about this, but, in a nutshell, here's why. On the one 
hand, you have an open-source project that is geared toward enterprise 
application development, but it is completely dependent on a proprietary 
runtime. That runtime is manufactured by a company who has stated its future is 
digital media and digital marketing, and that it believes the future of 
enterprise web application development is HTML5. It then begs the question, 
How long will they bloat their Flashplayer to support an open-source Flex 
community's enterprise web application development goals and wishes? 

To accommodate the Flex community, Adobe gets nothing in return for its 
expenditure of time and money in designing, developing, testing the features 
the Flex community requires now and in the future. It also means that, by 
supporting Flex in their runtime, the Flashplayer has an unnecessarily larger 
footprint than would otherwise be required.

So, ask yourself if you truly believe Flex will be a supported product by Adobe 
in 5-10 years from now. I highly doubt it. 

On the other hand, I think if a developer uses Flash Pro to develop digital 
media for their applications, they can probably count on that being around 
indefinitely. But, not Flex.

Ron



--- In flexcoders@yahoogroups.com, James Ong yanlilei64@... wrote:

 Using ZK and Java is great. I'm still sticking to Flex for developing
 desktop applications and gaming.
 Of course, many will still using it for animations, there is no such thing
 as abandon, some developers
 are just over use Flash and end up hurting user experience than necessary.
 
 When it comes to web application, I stick to PHP but will definitely use
 Flex for mobile, desktop and
 components within the web browser.
 
 
 On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@... wrote:
 
  **
 
 
  Staying with Flex.  Not looking elsewhere.
 
  ** **
 
  *Michael*
 
  ** **
 
  *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] *On
  Behalf Of *Ron G
  *Sent:* Wednesday, January 11, 2012 8:15 PM
  *To:* flexcoders@yahoogroups.com
  *Subject:* [flexcoders] Re: Flex alternatives
 
  ** **
 

 
  Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a
  Java shop, on the server side, it seemed logical to use a Java based
  framework on the client-side.
 
  The thing I really like about ZK or ZKoss is that it has equivalent
  components to Flex. In fact, it actually has more components than Flex.
 
  It implements an approach that I really like of separating the UI into
  appearance and behavior - much like the Spark components of Flex. Well, not
  exactly, but sort of. :) Here's what I mean. For each UI object, it has a
  client side (widget) and server side (component). I won't go into further
  detail, but it gives you a nice separation of concerns that you can avail
  yourself of. This feature also greatly insulates the rendered pages from
  x-browser compatibility issues.
 
  Check it out for yourself at their site (zkoss.org).
 
  Ron
 
  --- In flexcoders@yahoogroups.com, Sal sal.celli@ wrote:
  
   hi,
   as i can sadly see from the message history bottom grid, many
  programmers are leaving flex.
   So this thread is to ask you all, if you have already found a valid
  alternative to flex for RIA development.
  
 
  
 
   
 





Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread ganaraj p r
Flex is an awesome product.Period. Atleast until version 3.
Then they bloated it. The new spark component makes it easy to do the
skinning but it costs a big deal in download time.

I am not sure there is anything flex specific in the Flash Player Runtime.
Flex is totally written with AS3 and the flash player runs AS3.

The path I would suggest the Apache Flex guys to go is towards creating a
Flex to JS/HTML5 Cross compiler. This would be something that would help
them quite a lot. Write code with AS3 and output to JS.

There are quite a lot of Flex apps out there ( especially in the corprate
world ). Given that adobe has given up on Flex ( which means they wont have
any premium support ) these guys will be looking for a solution that can
work as good as their current applications. Ofcourse, the big players (
especially in the financial industry ) are going to be slow to move. They
wont change something just because Adobe wont support it quite in the
future. They would be looking to change. This is the point where the Apache
Flex community needs to catch up on. Flex is currently the biggest load on
a ship called Flash Player Runtime.

There is a significantly large hole in this ship. That would not have been
the case, if Adobe had not shot itself in the foot, but that is a different
topic altogether. Now, if one of the biggest load happens to unload quite
fast onto another boat the rest of the smaller entities on the ship can
jump on. If not, the other smaller entities wont die. They will just become
a fish :) . Everything evolves, the question is how do you want to evolve!

On Thu, Jan 12, 2012 at 5:38 PM, Ron G rgri...@sinclairoil.com wrote:

 **


 Hi James,

 I certainly respect the decision of those who are sticking with Flex, but
 I would suggest that developers do so with the recognition that they may be
 developing with a technology that isn't going to be around that long.

 I could write at length about this, but, in a nutshell, here's why. On the
 one hand, you have an open-source project that is geared toward enterprise
 application development, but it is completely dependent on a proprietary
 runtime. That runtime is manufactured by a company who has stated its
 future is digital media and digital marketing, and that it believes the
 future of enterprise web application development is HTML5. It then begs the
 question, How long will they bloat their Flashplayer to support an
 open-source Flex community's enterprise web application development goals
 and wishes?

 To accommodate the Flex community, Adobe gets nothing in return for its
 expenditure of time and money in designing, developing, testing the
 features the Flex community requires now and in the future. It also means
 that, by supporting Flex in their runtime, the Flashplayer has an
 unnecessarily larger footprint than would otherwise be required.

 So, ask yourself if you truly believe Flex will be a supported product by
 Adobe in 5-10 years from now. I highly doubt it.

 On the other hand, I think if a developer uses Flash Pro to develop
 digital media for their applications, they can probably count on that being
 around indefinitely. But, not Flex.

 Ron


 --- In flexcoders@yahoogroups.com, James Ong yanlilei64@... wrote:
 
  Using ZK and Java is great. I'm still sticking to Flex for developing
  desktop applications and gaming.
  Of course, many will still using it for animations, there is no such
 thing
  as abandon, some developers
  are just over use Flash and end up hurting user experience than
 necessary.
 
  When it comes to web application, I stick to PHP but will definitely use
  Flex for mobile, desktop and
  components within the web browser.
 
 
  On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@... wrote:
 
   **
  
  
   Staying with Flex. Not looking elsewhere.
  
   ** **
  
   *Michael*
  
   ** **
  
   *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com]
 *On
   Behalf Of *Ron G
   *Sent:* Wednesday, January 11, 2012 8:15 PM
   *To:* flexcoders@yahoogroups.com
   *Subject:* [flexcoders] Re: Flex alternatives
  
   ** **
  
   

  
   Yes, we have also abandoned Flex in favor of ZKoss. Since we are
 already a
   Java shop, on the server side, it seemed logical to use a Java based
   framework on the client-side.
  
   The thing I really like about ZK or ZKoss is that it has equivalent
   components to Flex. In fact, it actually has more components than Flex.
  
   It implements an approach that I really like of separating the UI into
   appearance and behavior - much like the Spark components of Flex.
 Well, not
   exactly, but sort of. :) Here's what I mean. For each UI object, it
 has a
   client side (widget) and server side (component). I won't go into
 further
   detail, but it gives you a nice separation of concerns that you can
 avail
   yourself of. This feature also greatly insulates the rendered pages
 from
   x-browser compatibility issues.
  
   Check it out for 

RE: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Merrill, Jason
Yep, and with no ability to access or make mods to the server like that, it 
would be a no-go for us unfortunately.

Jason Merrill
Instructional Technology Architect II
Bank of America  Global Learning





___

From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf 
Of Ron G
Sent: Thursday, January 12, 2012 12:13 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Flex alternatives



Hi Jason,

The only configuration is that I had to drop several of their jar files into 
the endorsed directory of Tomcat.

Ron

--- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, 
Merrill, Jason jason.merrill@... wrote:

 Unless I'm not understanding it right, ZKoss looks like it requires some web 
 server configuration in order to run. Flex doesn't, which is nice for people 
 like me who work in server environments they can't control. But it looks like 
 awesome tech! Am I right about it needing server side configuration?

 Jason Merrill
 Instructional Technology Architect II
 Bank of America Global Learning





 ___

 From: flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com 
 [mailto:flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com] On 
 Behalf Of Ron G
 Sent: Wednesday, January 11, 2012 9:15 PM
 To: flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com
 Subject: [flexcoders] Re: Flex alternatives



 Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a 
 Java shop, on the server side, it seemed logical to use a Java based 
 framework on the client-side.

 The thing I really like about ZK or ZKoss is that it has equivalent 
 components to Flex. In fact, it actually has more components than Flex.

 It implements an approach that I really like of separating the UI into 
 appearance and behavior - much like the Spark components of Flex. Well, not 
 exactly, but sort of. :) Here's what I mean. For each UI object, it has a 
 client side (widget) and server side (component). I won't go into further 
 detail, but it gives you a nice separation of concerns that you can avail 
 yourself of. This feature also greatly insulates the rendered pages from 
 x-browser compatibility issues.

 Check it out for yourself at their site (zkoss.org).

 Ron

 --- In 
 flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.commailto:flexcoders%40yahoogroups.com,
  Sal sal.celli@ wrote:
 
  hi,
  as i can sadly see from the message history bottom grid, many programmers 
  are leaving flex.
  So this thread is to ask you all, if you have already found a valid 
  alternative to flex for RIA development.
 


 --
 This message w/attachments (message) is intended solely for the use of the 
 intended recipient(s) and may contain information that is privileged, 
 confidential or proprietary. If you are not an intended recipient, please 
 notify the sender, and then please delete and destroy all copies and 
 attachments, and be advised that any review or dissemination of, or the 
 taking of any action in reliance on, the information contained in or attached 
 to this message is prohibited.
 Unless specifically indicated, this message is not an offer to sell or a 
 solicitation of any investment products or other financial product or 
 service, an official confirmation of any transaction, or an official 
 statement of Sender. Subject to applicable law, Sender may intercept, 
 monitor, review and retain e-communications (EC) traveling through its 
 networks/systems and may produce any such EC to regulators, law enforcement, 
 in litigation and as required by law.
 The laws of the country of each sender/recipient may impact the handling of 
 EC, and EC may be archived, supervised and produced in countries other than 
 the country in which you are located. This message cannot be guaranteed to be 
 secure or free of errors or viruses.

 References to Sender are references to any subsidiary of Bank of America 
 Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are 
 Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a 
 Condition to Any Banking Service or Activity * Are Not Insured by Any Federal 
 Government Agency. Attachments that are part of this EC may have additional 
 important disclosures and disclaimers, which you should read. This message is 
 subject to terms available at the following link:
 http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you 
 consent to the foregoing.



--
This message w/attachments (message) is intended solely for the use of the 
intended recipient(s) and may contain information that is privileged, 
confidential or proprietary. If you are not an intended recipient, please 
notify the sender, and then please delete and destroy all copies and 
attachments, and be advised that any review or 

RE: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Merrill, Jason
I think it will be interesting to see how many people actually show up at MAX 
this year.

Jason Merrill
Instructional Technology Architect II
Bank of America  Global Learning





___

From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf 
Of ganaraj p r
Sent: Thursday, January 12, 2012 1:15 PM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Re: Flex alternatives



Flex is an awesome product.Period. Atleast until version 3.
Then they bloated it. The new spark component makes it easy to do the skinning 
but it costs a big deal in download time.

I am not sure there is anything flex specific in the Flash Player Runtime. Flex 
is totally written with AS3 and the flash player runs AS3.

The path I would suggest the Apache Flex guys to go is towards creating a Flex 
to JS/HTML5 Cross compiler. This would be something that would help them quite 
a lot. Write code with AS3 and output to JS.

There are quite a lot of Flex apps out there ( especially in the corprate world 
). Given that adobe has given up on Flex ( which means they wont have any 
premium support ) these guys will be looking for a solution that can work as 
good as their current applications. Ofcourse, the big players ( especially in 
the financial industry ) are going to be slow to move. They wont change 
something just because Adobe wont support it quite in the future. They would be 
looking to change. This is the point where the Apache Flex community needs to 
catch up on. Flex is currently the biggest load on a ship called Flash Player 
Runtime.

There is a significantly large hole in this ship. That would not have been the 
case, if Adobe had not shot itself in the foot, but that is a different topic 
altogether. Now, if one of the biggest load happens to unload quite fast onto 
another boat the rest of the smaller entities on the ship can jump on. If not, 
the other smaller entities wont die. They will just become a fish :) . 
Everything evolves, the question is how do you want to evolve!

On Thu, Jan 12, 2012 at 5:38 PM, Ron G 
rgri...@sinclairoil.commailto:rgri...@sinclairoil.com wrote:


Hi James,

I certainly respect the decision of those who are sticking with Flex, but I 
would suggest that developers do so with the recognition that they may be 
developing with a technology that isn't going to be around that long.

I could write at length about this, but, in a nutshell, here's why. On the one 
hand, you have an open-source project that is geared toward enterprise 
application development, but it is completely dependent on a proprietary 
runtime. That runtime is manufactured by a company who has stated its future is 
digital media and digital marketing, and that it believes the future of 
enterprise web application development is HTML5. It then begs the question, 
How long will they bloat their Flashplayer to support an open-source Flex 
community's enterprise web application development goals and wishes?

To accommodate the Flex community, Adobe gets nothing in return for its 
expenditure of time and money in designing, developing, testing the features 
the Flex community requires now and in the future. It also means that, by 
supporting Flex in their runtime, the Flashplayer has an unnecessarily larger 
footprint than would otherwise be required.

So, ask yourself if you truly believe Flex will be a supported product by Adobe 
in 5-10 years from now. I highly doubt it.

On the other hand, I think if a developer uses Flash Pro to develop digital 
media for their applications, they can probably count on that being around 
indefinitely. But, not Flex.

Ron


--- In flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com, James 
Ong yanlilei64@... wrote:

 Using ZK and Java is great. I'm still sticking to Flex for developing
 desktop applications and gaming.
 Of course, many will still using it for animations, there is no such thing
 as abandon, some developers
 are just over use Flash and end up hurting user experience than necessary.

 When it comes to web application, I stick to PHP but will definitely use
 Flex for mobile, desktop and
 components within the web browser.


 On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@... wrote:

  **
 
 
  Staying with Flex. Not looking elsewhere.
 
  ** **
 
  *Michael*
 
  ** **
 
  *From:* flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com 
  [mailto:flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com] *On
  Behalf Of *Ron G
  *Sent:* Wednesday, January 11, 2012 8:15 PM
  *To:* flexcoders@yahoogroups.commailto:flexcoders%40yahoogroups.com
  *Subject:* [flexcoders] Re: Flex alternatives
 
  ** **
 
  

 
  Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a
  Java shop, on the server side, it seemed logical to use a Java based
  framework on the client-side.
 
  The thing I really like about ZK or ZKoss is that it has equivalent
  components to Flex. In fact, it actually has 

RE: [flexcoders] Flex 4.5: Flex in 5 Days

2012-01-12 Thread Jeff Hindman
I went through the entire series a few months ago . no crashes, no problems.

 

From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On
Behalf Of Davidson, Jerry
Sent: Thursday, January 12, 2012 5:58 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Flex 4.5: Flex in 5 Days

 

  

I'm going through the Flex in 5 Days tutorial on the Adobe website.  Has
anyone else done this?  I ask because I get 1-2 crashes for ever session in
every day.  I don't get the warm and fuzzies when a product crashes so
often.  I assume it was all written in LC, but it's the same company.

 

Does anyone know of less buggy tutorials?  They can't be YouTube based as
our firewall blocks that.  I'd love to see one for 4.0 as we might not
upgrade to 4.5, but even that is closer than 3.5.

 

TIA,

Jerry

 



image001.jpgimage002.jpg

[flexcoders] date problem?

2012-01-12 Thread luvfotography
Why does:
trace((new Date(2012,01,15)).toString());
and
trace((new Date('2012','01','15')).toString());

return:

Wed Feb 15 00:00:00 GMT-0800 2012

February??  



[flexcoders] Re: date problem?

2012-01-12 Thread luvfotography
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/Date.html#methodSummary

says: 

If you pass two or more arguments, the Date object is assigned a time value 
based on the argument values passed, which represent the date's year, month, 
date, hour, minute, second, and milliseconds.

--- In flexcoders@yahoogroups.com, luvfotography ygroups@... wrote:

 Why does:
 trace((new Date(2012,01,15)).toString());
 and
 trace((new Date('2012','01','15')).toString());
 
 return:
 
 Wed Feb 15 00:00:00 GMT-0800 2012
 
 February??





RE: [flexcoders] Flex 4.5: Flex in 5 Days

2012-01-12 Thread Glenn Williams
So did I.

 

I just wanted to try it out. 

 

It may have helped that Ive been using flex for
years but Im sure I just followed the whole course
and can't remember do any work-rounds or anything
like that.

 

I thought, for a free training set is was actually
really good. I don't really know of anything any
better video wise without actually paying for a
Lynda one or something like that. It covered the
basics in enough details to defiantly get you well
started

 

From: flexcoders@yahoogroups.com
[mailto:flexcoders@yahoogroups.com] On Behalf Of
Jeff Hindman
Sent: 12 January 2012 20:23
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Flex 4.5: Flex in 5 Days

 

  

I went through the entire series a few months ago
. no crashes, no problems.

 

From: flexcoders@yahoogroups.com
[mailto:flexcoders@yahoogroups.com] On Behalf Of
Davidson, Jerry
Sent: Thursday, January 12, 2012 5:58 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Flex 4.5: Flex in 5 Days

 

  

I'm going through the Flex in 5 Days tutorial on
the Adobe website.   Has anyone else done this?  I
ask because I get 1-2 crashes for ever session in
every day.  I don't get the warm and fuzzies when
a product crashes so often.  I assume it was all
written in LC, but it's the same company.

 

Does anyone know of less buggy tutorials?  They
can't be YouTube based as our firewall blocks
that.  I'd love to see one for 4.0 as we might not
upgrade to 4.5, but even that is closer than 3.5.

 

TIA,

Jerry

 





Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Alex Harui
I can’t think of anything the FlashPlayer could unload from its footprint that 
wouldn’t just “break the web” for lots of other non-Flex swfs.  Adobe has no 
interest in “breaking the web” and thus it will continue to invest in not doing 
so.

I’m not sure of your definition of “supported product”.  If you mean that you 
can get a support contract from Adobe, we are still deciding on whether to 
offer extended support.  If you mean that Adobe will be developing and selling 
Flex, it has already stopped.  Adobe will be continuing to release 
FlashBuilder, but all significant Flex work will be done in the Apache project.

So, how long will Flex be around?  Probably forever, since once you get in the 
enterprise infrastructure, it is hard to get out.  There are still COBOL 
programs running in the world.  How long will Flex be a choice as a development 
technology?  It could be forever as well, it will depend on how you define what 
Flex is.  If you say that it is ActionScript and the Flash Platform, then when 
HTML5 delivers on its promise of power and productivity, the need for Flash in 
the browser will likely diminish, but AIR will still remain an attractive way 
to develop cross-platform desktop apps.  But under the definition that Flex is 
a development paradigm (declarative markup for UI, some script mixed in that 
supports OOP), Flex may transform to become a popular paradigm for creating 
HTML5 apps.

On 1/12/12 9:38 AM, Ron G rgri...@sinclairoil.com wrote:






Hi James,

I certainly respect the decision of those who are sticking with Flex, but I 
would suggest that developers do so with the recognition that they may be 
developing with a technology that isn't going to be around that long.

I could write at length about this, but, in a nutshell, here's why. On the one 
hand, you have an open-source project that is geared toward enterprise 
application development, but it is completely dependent on a proprietary 
runtime. That runtime is manufactured by a company who has stated its future is 
digital media and digital marketing, and that it believes the future of 
enterprise web application development is HTML5. It then begs the question, 
How long will they bloat their Flashplayer to support an open-source Flex 
community's enterprise web application development goals and wishes?

To accommodate the Flex community, Adobe gets nothing in return for its 
expenditure of time and money in designing, developing, testing the features 
the Flex community requires now and in the future. It also means that, by 
supporting Flex in their runtime, the Flashplayer has an unnecessarily larger 
footprint than would otherwise be required.

So, ask yourself if you truly believe Flex will be a supported product by Adobe 
in 5-10 years from now. I highly doubt it.

On the other hand, I think if a developer uses Flash Pro to develop digital 
media for their applications, they can probably count on that being around 
indefinitely. But, not Flex.

Ron

--- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , James 
Ong yanlilei64@... wrote:

 Using ZK and Java is great. I'm still sticking to Flex for developing
 desktop applications and gaming.
 Of course, many will still using it for animations, there is no such thing
 as abandon, some developers
 are just over use Flash and end up hurting user experience than necessary.

 When it comes to web application, I stick to PHP but will definitely use
 Flex for mobile, desktop and
 components within the web browser.


 On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@... wrote:

  **
 
 
  Staying with Flex.  Not looking elsewhere.
 
  ** **
 
  *Michael*
 
  ** **
 
  *From:* flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com  
  [mailto:flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com ] 
  *On
  Behalf Of *Ron G
  *Sent:* Wednesday, January 11, 2012 8:15 PM
  *To:* flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com
  *Subject:* [flexcoders] Re: Flex alternatives
 
  ** **
 

 
  Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a
  Java shop, on the server side, it seemed logical to use a Java based
  framework on the client-side.
 
  The thing I really like about ZK or ZKoss is that it has equivalent
  components to Flex. In fact, it actually has more components than Flex.
 
  It implements an approach that I really like of separating the UI into
  appearance and behavior - much like the Spark components of Flex. Well, not
  exactly, but sort of. :) Here's what I mean. For each UI object, it has a
  client side (widget) and server side (component). I won't go into further
  detail, but it gives you a nice separation of concerns that you can avail
  yourself of. This feature also greatly insulates the rendered pages from
  x-browser compatibility issues.
 
  Check it out for yourself at their site (zkoss.org).
 
  Ron
 
  --- In flexcoders@yahoogroups.com 

[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G
I think you make my point for me by comparing the future of Flex to COBOL. Yes, 
it's still around, but we all wish it wasn't and curse it everytime we have to 
deal with it. As you say, it is hard to get out. So, yes, I still have 
projects written in Flex that will undoubtedly continue to run for years to 
come. But, it's hardly a justification for continuing to develop in COBOL...er, 
uh, I mean Flex.

As you say, the need for Flash in the browser will likely diminish. Again, 
you help make my point against using Flex or FlashBuilder. I find it amusing 
that some have suggested that Flex and FlashBuilder could be retooled to render 
HTML5 pages. It confounds me as to why I would want to write MXML and AS3 so it 
can be translated to HTML and JS. If that is the desired end product, then I 
suggest developers just develop in HTML and JS to begin with. Translated code 
is never as efficient as code specifically written in that sytax. 

Ron


--- In flexcoders@yahoogroups.com, Alex Harui aharui@... wrote:
 
 So, how long will Flex be around?  Probably forever, since once you get in 
 the enterprise infrastructure, it is hard to get out.  There are still COBOL 
 programs running in the world.  How long will Flex be a choice as a 
 development technology?  It could be forever as well, it will depend on how 
 you define what Flex is.  If you say that it is ActionScript and the Flash 
 Platform, then when HTML5 delivers on its promise of power and productivity, 
 the need for Flash in the browser will likely diminish, but AIR will still 
 remain an attractive way to develop cross-platform desktop apps.  But under 
 the definition that Flex is a development paradigm (declarative markup for 
 UI, some script mixed in that supports OOP), Flex may transform to become a 
 popular paradigm for creating HTML5 apps.
 
 On 1/12/12 9:38 AM, Ron G rgrimes@... wrote:
 
 
 
 
 
 
 Hi James,
 
 I certainly respect the decision of those who are sticking with Flex, but I 
 would suggest that developers do so with the recognition that they may be 
 developing with a technology that isn't going to be around that long.
 
 I could write at length about this, but, in a nutshell, here's why. On the 
 one hand, you have an open-source project that is geared toward enterprise 
 application development, but it is completely dependent on a proprietary 
 runtime. That runtime is manufactured by a company who has stated its future 
 is digital media and digital marketing, and that it believes the future of 
 enterprise web application development is HTML5. It then begs the question, 
 How long will they bloat their Flashplayer to support an open-source Flex 
 community's enterprise web application development goals and wishes?
 
 To accommodate the Flex community, Adobe gets nothing in return for its 
 expenditure of time and money in designing, developing, testing the features 
 the Flex community requires now and in the future. It also means that, by 
 supporting Flex in their runtime, the Flashplayer has an unnecessarily larger 
 footprint than would otherwise be required.
 
 So, ask yourself if you truly believe Flex will be a supported product by 
 Adobe in 5-10 years from now. I highly doubt it.
 
 On the other hand, I think if a developer uses Flash Pro to develop digital 
 media for their applications, they can probably count on that being around 
 indefinitely. But, not Flex.
 
 Ron
 
 --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , 
 James Ong yanlilei64@ wrote:
 
  Using ZK and Java is great. I'm still sticking to Flex for developing
  desktop applications and gaming.
  Of course, many will still using it for animations, there is no such thing
  as abandon, some developers
  are just over use Flash and end up hurting user experience than necessary.
 
  When it comes to web application, I stick to PHP but will definitely use
  Flex for mobile, desktop and
  components within the web browser.
 
 
  On Thu, Jan 12, 2012 at 10:16 AM, michael_regert@ wrote:
 
   **
  
  
   Staying with Flex.  Not looking elsewhere.
  
   ** **
  
   *Michael*
  
   ** **
  
   *From:* flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com  
   [mailto:flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com 
   ] *On
   Behalf Of *Ron G
   *Sent:* Wednesday, January 11, 2012 8:15 PM
   *To:* flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com
   *Subject:* [flexcoders] Re: Flex alternatives
  
   ** **
  
 
  
   Yes, we have also abandoned Flex in favor of ZKoss. Since we are already a
   Java shop, on the server side, it seemed logical to use a Java based
   framework on the client-side.
  
   The thing I really like about ZK or ZKoss is that it has equivalent
   components to Flex. In fact, it actually has more components than Flex.
  
   It implements an approach that I really like of separating the UI into
   appearance and behavior - much like the Spark components of Flex. 

Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Alex Harui
I’ve never used COBOL, but I haven’t heard anyone say they really liked working 
in with it.  That’s not true for Flex so even if it gets marginalized because 
it always remains locked to ActionScript and FlashPlayer, it may not be the 
subject of cursing.

I’m not in disagreement that in the long term, the advantages of 
Flex/ActionScript/FlashPlayer will be diminished by advances in the HTML/CSS/JS 
stack.  That’s why Adobe has made a major strategic shift to become the tooling 
leader in the HTML stack.  But that doesn’t mean that you should stop using 
Flex/ActionScript/FlashPlayer right now.

Many folks who work with HTML/CSS/JS, even using the many libraries and 
development methodologies available for it, still feel like the Flex paradigm 
is superior.  Apparently, even Google agrees because they are trying to create 
their own version of that paradigm with DART.  While translated code is never 
as good, the productivity advantages of a better paradigm have been pretty much 
proven to be worth it, otherwise, Flex wouldn’t have been that successful 
either since MXML isn’t as efficient as pure ActionScript, and Google wouldn’t 
have invested so much in writing their website logic in Java and/or Google 
Closure and/or DART.

There is general support in the Apache Flex project for exploring ways of using 
the Flex paradigm to create HTML5 apps.  Those working on the project are 
motivated to future-proof their investment in Flex.  I don’t see any technical 
issue blocking us from translating the paradigm to HTML5, and I invite all 
those who like the Flex paradigm to participate.  But at the same time, there 
is lots of work to be done, lots of solutions to be built, and lots of money to 
be made on the Flex/AS/FP stack while we wait for the HTML5 stack to deliver on 
its promises.


On 1/12/12 3:37 PM, Ron G rgri...@sinclairoil.com wrote:






I think you make my point for me by comparing the future of Flex to COBOL. Yes, 
it's still around, but we all wish it wasn't and curse it everytime we have to 
deal with it. As you say, it is hard to get out. So, yes, I still have 
projects written in Flex that will undoubtedly continue to run for years to 
come. But, it's hardly a justification for continuing to develop in COBOL...er, 
uh, I mean Flex.

As you say, the need for Flash in the browser will likely diminish. Again, 
you help make my point against using Flex or FlashBuilder. I find it amusing 
that some have suggested that Flex and FlashBuilder could be retooled to render 
HTML5 pages. It confounds me as to why I would want to write MXML and AS3 so it 
can be translated to HTML and JS. If that is the desired end product, then I 
suggest developers just develop in HTML and JS to begin with. Translated code 
is never as efficient as code specifically written in that sytax.

Ron

--- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Alex 
Harui aharui@... wrote:

 So, how long will Flex be around?  Probably forever, since once you get in 
 the enterprise infrastructure, it is hard to get out.  There are still COBOL 
 programs running in the world.  How long will Flex be a choice as a 
 development technology?  It could be forever as well, it will depend on how 
 you define what Flex is.  If you say that it is ActionScript and the Flash 
 Platform, then when HTML5 delivers on its promise of power and productivity, 
 the need for Flash in the browser will likely diminish, but AIR will still 
 remain an attractive way to develop cross-platform desktop apps.  But under 
 the definition that Flex is a development paradigm (declarative markup for 
 UI, some script mixed in that supports OOP), Flex may transform to become a 
 popular paradigm for creating HTML5 apps.

 On 1/12/12 9:38 AM, Ron G rgrimes@... wrote:






 Hi James,

 I certainly respect the decision of those who are sticking with Flex, but I 
 would suggest that developers do so with the recognition that they may be 
 developing with a technology that isn't going to be around that long.

 I could write at length about this, but, in a nutshell, here's why. On the 
 one hand, you have an open-source project that is geared toward enterprise 
 application development, but it is completely dependent on a proprietary 
 runtime. That runtime is manufactured by a company who has stated its future 
 is digital media and digital marketing, and that it believes the future of 
 enterprise web application development is HTML5. It then begs the question, 
 How long will they bloat their Flashplayer to support an open-source Flex 
 community's enterprise web application development goals and wishes?

 To accommodate the Flex community, Adobe gets nothing in return for its 
 expenditure of time and money in designing, developing, testing the features 
 the Flex community requires now and in the future. It also means that, by 
 supporting Flex in their runtime, the Flashplayer has an unnecessarily larger 
 footprint than would otherwise be 

[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G


So, I think we have a similar vision for where things are going with respect to 
Adobe supporting HTML5 for the enterprise. But, I fail to see why Flex and 
FlashBuilder would have any part of that. Why not just fall back to your 
excellent product, Dreamweaver, and enhance it as the IDE for building HTML5 
style web applications? No translation is then required. 

I too like the FlashBuilder/Flex paradigm for development. But, it seems to me 
that, sooner or later, what you end up with is the FlashBuilder paradigm that 
allows the user to code with a pseudo OO type of HTML5 as an alternative option 
to MXML and AS3, since we agree that it's not the translation from as3 to HTML5 
that makes sense, but the paradigm itself. 

As for that doesn't mean you should stop using Flex/ActionScript/FlashPlayer 
right now, I would disagree. Over the past dozen years, I have already gone 
through 4 generations of web architecture:

1) CGI 
2) server side XSLT transformation rendering a DHTML web page for client side
3) Flash 2004 until Adobe abandoned the push for developers to use Flash for 
applications and created...
4) Flex

I would like to settle upon a single client-side technology that I can rely 
upon to be here in 15 years. Novell and Adobe have failed me in this regard. 
The only piece of my stack to not drop the ball on me is Java, which is why we 
are going with a Java based framework where the UI logic can reside server 
side. 

Do you know how hard it is to hire someone that can come in and be competent in 
all 4 of my web architecture generations? Very difficult. So, it's better to 
stop developing in Flex now so that I have less older generation architectures 
to eventually convert to ZKoss. Once that is done, finding someone who can help 
maintain all of our projects becomes a much easier task. 

Anyway, I very much appreciate hearing from an Adobe Flex SDK staff member. You 
have helped clarify that the direction I am taking is the right one. Hopefully, 
it's convinced a few others to not waste time writing in a technology that will 
one day require migration of an even greater backlog of  projects to their 
inevitably new chosen technology stack.

Ron

--- In flexcoders@yahoogroups.com, Alex Harui aharui@... wrote:

 I'm not in disagreement that in the long term, the advantages of 
 Flex/ActionScript/FlashPlayer will be diminished by advances in the 
 HTML/CSS/JS stack.  That's why Adobe has made a major strategic shift to 
 become the tooling leader in the HTML stack.  But that doesn't mean that you 
 should stop using Flex/ActionScript/FlashPlayer right now.
 
 Many folks who work with HTML/CSS/JS, even using the many libraries and 
 development methodologies available for it, still feel like the Flex paradigm 
 is superior.  Apparently, even Google agrees because they are trying to 
 create their own version of that paradigm with DART.  While translated code 
 is never as good, the productivity advantages of a better paradigm have been 
 pretty much proven to be worth it, otherwise, Flex wouldn't have been that 
 successful either since MXML isn't as efficient as pure ActionScript, and 
 Google wouldn't have invested so much in writing their website logic in Java 
 and/or Google Closure and/or DART.
 
 There is general support in the Apache Flex project for exploring ways of 
 using the Flex paradigm to create HTML5 apps.  Those working on the project 
 are motivated to future-proof their investment in Flex.  I don't see any 
 technical issue blocking us from translating the paradigm to HTML5, and I 
 invite all those who like the Flex paradigm to participate.  But at the same 
 time, there is lots of work to be done, lots of solutions to be built, and 
 lots of money to be made on the Flex/AS/FP stack while we wait for the HTML5 
 stack to deliver on its promises.




Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Rishi Tandon
Well Ron, I don't agree with you.
There is a difference between a reality and our own perception.
I have seen a huge demand for flex based solution in 
Education (hmh, piersons)
Finance (j p morgon, boa)
Healthcare (hospira)
Entertainment (directv)
Ecommerce ( eBay ) and the list goes on and on...

If as of today companies decide to change the strategy and port all the 
existing flex based application into HTML 5, then it would take around 5 years 
to do so as HTML 5 is still not mature for web and desktop.
Check the percent of browser which support HTML 5.
N what about desktop apps that are so beautifully created using adobe air.

My personal thought is that some people are trying to take advantage of this 
bad rumours and advertising the dead tools which were existed for years.

Please be patience and watch the change.
N Stop spreading the rumours.

Regards
Rishi Tandon
Software Development Adviser Flex 


Sent from my iPad

On 13-Jan-2012, at 7:40 AM, Ron G rgri...@sinclairoil.com wrote:

 
 
 So, I think we have a similar vision for where things are going with respect 
 to Adobe supporting HTML5 for the enterprise. But, I fail to see why Flex and 
 FlashBuilder would have any part of that. Why not just fall back to your 
 excellent product, Dreamweaver, and enhance it as the IDE for building HTML5 
 style web applications? No translation is then required. 
 
 I too like the FlashBuilder/Flex paradigm for development. But, it seems to 
 me that, sooner or later, what you end up with is the FlashBuilder paradigm 
 that allows the user to code with a pseudo OO type of HTML5 as an alternative 
 option to MXML and AS3, since we agree that it's not the translation from as3 
 to HTML5 that makes sense, but the paradigm itself. 
 
 As for that doesn't mean you should stop using Flex/ActionScript/FlashPlayer 
 right now, I would disagree. Over the past dozen years, I have already gone 
 through 4 generations of web architecture:
 
 1) CGI 
 2) server side XSLT transformation rendering a DHTML web page for client side
 3) Flash 2004 until Adobe abandoned the push for developers to use Flash for 
 applications and created...
 4) Flex
 
 I would like to settle upon a single client-side technology that I can rely 
 upon to be here in 15 years. Novell and Adobe have failed me in this regard. 
 The only piece of my stack to not drop the ball on me is Java, which is why 
 we are going with a Java based framework where the UI logic can reside server 
 side. 
 
 Do you know how hard it is to hire someone that can come in and be competent 
 in all 4 of my web architecture generations? Very difficult. So, it's better 
 to stop developing in Flex now so that I have less older generation 
 architectures to eventually convert to ZKoss. Once that is done, finding 
 someone who can help maintain all of our projects becomes a much easier task. 
 
 Anyway, I very much appreciate hearing from an Adobe Flex SDK staff member. 
 You have helped clarify that the direction I am taking is the right one. 
 Hopefully, it's convinced a few others to not waste time writing in a 
 technology that will one day require migration of an even greater backlog of 
 projects to their inevitably new chosen technology stack.
 
 Ron
 
 --- In flexcoders@yahoogroups.com, Alex Harui aharui@... wrote:
 
  I'm not in disagreement that in the long term, the advantages of 
  Flex/ActionScript/FlashPlayer will be diminished by advances in the 
  HTML/CSS/JS stack. That's why Adobe has made a major strategic shift to 
  become the tooling leader in the HTML stack. But that doesn't mean that you 
  should stop using Flex/ActionScript/FlashPlayer right now.
  
  Many folks who work with HTML/CSS/JS, even using the many libraries and 
  development methodologies available for it, still feel like the Flex 
  paradigm is superior. Apparently, even Google agrees because they are 
  trying to create their own version of that paradigm with DART.  While 
  translated code is never as good, the productivity advantages of a better 
  paradigm have been pretty much proven to be worth it, otherwise, Flex 
  wouldn't have been that successful either since MXML isn't as efficient as 
  pure ActionScript, and Google wouldn't have invested so much in writing 
  their website logic in Java and/or Google Closure and/or DART.
  
  There is general support in the Apache Flex project for exploring ways of 
  using the Flex paradigm to create HTML5 apps. Those working on the project 
  are motivated to future-proof their investment in Flex. I don't see any 
  technical issue blocking us from translating the paradigm to HTML5, and I 
  invite all those who like the Flex paradigm to participate. But at the same 
  time, there is lots of work to be done, lots of solutions to be built, and 
  lots of money to be made on the Flex/AS/FP stack while we wait for the 
  HTML5 stack to deliver on its promises.
 
 


Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Tunde Majolagbe


Hi All,



someone said adobe will not support flex in 5 to 10 years time and hence it 
poses a threat to flex developers. 
I beg to deffer because we need to clearly distinct a vendor from her products. 
A vendor changes focus to another phase of technology 
does not mean the vendor will outrightly discard her old and stable 
products.Its discouraging though that flex will not practically evolve to a 
better 
framework if adobe denies support in the nearest future but the consolation is 
the relative strength,robustness and stability of the framework when compared 
with other RIAs

If technologies like cobol, powerbuilder,Vb6, classic ASP (though not RIAs) are 
still existing in the industry even though they are no longer in vogue
i dont see a framework that is rich, stable ,platform independent and shows 
cross browser compatibility  face out in the market at all.
Look, i cant imagine a standard browser (in existence or still to come) that 
will deny compatibility with flash and yet expect to be widely used?
No browser vendor will shoot herself on the leg by taking such a weak strategy.

If you see a possible end for flex, what would you say of silverlight? (lol) 
Yet silverlight users are optimistic that Microsoft will find 
a way to integrate the framework to all other browsers 

The advent of RIAs addresses a critical need that is so significant, it saves 
you from the hassles of html/JS/CSS in the areas of presentation consistency 
across browsers and business security (though .swf files can be decompiled but 
its not a piece of cake) and i strongly believe flex is the most powerful RIA 
in the market, i cant even compare zkoss with it.
Such frameworks are not abandoned, they come to stay !!!

 

 
Warm Regards
Tunde Majolagbe
+2348028320370, 018782170.
 
*Exchange a Dollar, we still have ONE each, exchange an idea, we have TWO each.
*Calm Down!!!  It’s just a mirage, like other worries it will soon fade away.   



 From: Alex Harui aha...@adobe.com
To: flexcoders@yahoogroups.com flexcoders@yahoogroups.com 
Sent: Thursday, 12 January 2012, 16:19
Subject: Re: [flexcoders] Re: Flex alternatives
 

  
I’ve never used COBOL, but I haven’t heard anyone say they really liked working 
in with it.  That’s not true for Flex so even if it gets marginalized because 
it always remains locked to ActionScript and FlashPlayer, it may not be the 
subject of cursing.

I’m not in disagreement that in the long term, the advantages of 
Flex/ActionScript/FlashPlayer will be diminished by advances in the HTML/CSS/JS 
stack.  That’s why Adobe has made a major strategic shift to become the tooling 
leader in the HTML stack.  But that doesn’t mean that you should stop using 
Flex/ActionScript/FlashPlayer right now.

Many folks who work with HTML/CSS/JS, even using the many libraries and 
development methodologies available for it, still feel like the Flex paradigm 
is superior.  Apparently, even Google agrees because they are trying to create 
their own version of that paradigm with DART.  While translated code is never 
as good, the productivity advantages of a better paradigm have been pretty much 
proven to be worth it, otherwise, Flex wouldn’t have been that successful 
either since MXML isn’t as efficient as pure ActionScript, and Google wouldn’t 
have invested so much in writing their website logic in Java and/or Google 
Closure and/or DART.

There is general support in the Apache Flex project for exploring ways of using 
the Flex paradigm to create HTML5 apps.  Those working on the project are 
motivated to future-proof their investment in Flex.  I don’t see any technical 
issue blocking us from translating the paradigm to HTML5, and I invite all 
those who like the Flex paradigm to participate.  But at the same time, there 
is lots of work to be done, lots of solutions to be built, and lots of money to 
be made on the Flex/AS/FP stack while we wait for the HTML5 stack to deliver on 
its promises.


On 1/12/12 3:37 PM, Ron G rgri...@sinclairoil.com wrote:



 
 
   

I think you make my point for me by comparing the future of Flex to COBOL. 
Yes, it's still around, but we all wish it wasn't and curse it everytime we 
have to deal with it. As you say, it is hard to get out. So, yes, I still 
have projects written in Flex that will undoubtedly continue to run for years 
to come. But, it's hardly a justification for continuing to develop in 
COBOL...er, uh, I mean Flex.

As you say, the need for Flash in the browser will likely diminish. Again, 
you help make my point against using Flex or FlashBuilder. I find it amusing 
that some have suggested that Flex and FlashBuilder could be retooled to 
render HTML5 pages. It confounds me as to why I would want to write MXML and 
AS3 so it can be translated to HTML and JS. If that is the desired end 
product, then I suggest developers just develop in HTML and JS to begin with. 
Translated code is never as efficient as code specifically written 

[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G
Rishi Tandon,

Seems to me, from your signature, that you have an invested interest in Flex 
continuing. I would say that makes it difficult for you to see the difference 
between a reality and our own perception, as you so aptly put it.

The least Adobe could do, after kicking Flex out to go live with the neighbor 
is be honest with their customers and say, We recommend that you stop 
developing in Flex because targeting web applications for the Flashplayer is a 
dead-end endeavor. We recommend that you begin any new projects (not already in 
progress) in HTML5 or another technology. Instead, being embarrassed at 
pulling the rug out from under their developer base, they feed them the lie 
that they're going to be there for the Flex developers in the long haul. Anyone 
with reading comprehension knows such a declaration, in light of other 
statements from Adobe, is a request that we practice cognitive dissonance 
voluntarily. 

Flee maya, Rishi. 

Ron

--- In flexcoders@yahoogroups.com, Rishi Tandon rishitandon123@... wrote:

 Well Ron, I don't agree with you.
 There is a difference between a reality and our own perception.
 I have seen a huge demand for flex based solution in 
 Education (hmh, piersons)
 Finance (j p morgon, boa)
 Healthcare (hospira)
 Entertainment (directv)
 Ecommerce ( eBay ) and the list goes on and on...
 
 If as of today companies decide to change the strategy and port all the 
 existing flex based application into HTML 5, then it would take around 5 
 years to do so as HTML 5 is still not mature for web and desktop.
 Check the percent of browser which support HTML 5.
 N what about desktop apps that are so beautifully created using adobe air.
 
 My personal thought is that some people are trying to take advantage of this 
 bad rumours and advertising the dead tools which were existed for years.
 
 Please be patience and watch the change.
 N Stop spreading the rumours.
 
 Regards
 Rishi Tandon
 Software Development Adviser Flex 
 
 
 Sent from my iPad




Re: [flexcoders] Re: Flex alternatives

2012-01-12 Thread Alex Harui
Flex and FlashBuilder are not part of Adobe’s HTML strategy per-se.  
FlashBuilder is being directed towards Gaming in Flash, Flex is being donated 
to the community.  It is the community that has lots of investment in the 
Flex/AS/FP stack that are looking reworking the Flex paradigm to output to the 
HTML/CSS/JS stack.

Meanwhile Adobe is not only updating Dreamweaver (see the PhoneGap features 
added in 5.5) but also looking at new tools for new development methodologies.  
While classic Java has been around for a while, and HTML/CSS/JS will likely 
meet your 15 year requirement, the question remains whether you will be willing 
to use more efficient and powerful development frameworks and methodologies 
over those years.  If you don’t, you might lose competitive advantage as your 
competition gets their products finished better or faster, but if you do, you 
run the risk of choosing a new set of tools that turns out not to have lasting 
power.  Tough call, no right answer, the choice is yours.

It looks like the Apache Flex folks are going to try to provide one of those 
new sets of tools by making it possible to use the Flex paradigm for the HTML 
stack.


On 1/12/12 6:10 PM, Ron G rgri...@sinclairoil.com wrote:








So, I think we have a similar vision for where things are going with respect to 
Adobe supporting HTML5 for the enterprise. But, I fail to see why Flex and 
FlashBuilder would have any part of that. Why not just fall back to your 
excellent product, Dreamweaver, and enhance it as the IDE for building HTML5 
style web applications? No translation is then required.

I too like the FlashBuilder/Flex paradigm for development. But, it seems to me 
that, sooner or later, what you end up with is the FlashBuilder paradigm that 
allows the user to code with a pseudo OO type of HTML5 as an alternative option 
to MXML and AS3, since we agree that it's not the translation from as3 to HTML5 
that makes sense, but the paradigm itself.

As for that doesn't mean you should stop using Flex/ActionScript/FlashPlayer 
right now, I would disagree. Over the past dozen years, I have already gone 
through 4 generations of web architecture:

1) CGI
2) server side XSLT transformation rendering a DHTML web page for client side
3) Flash 2004 until Adobe abandoned the push for developers to use Flash for 
applications and created...
4) Flex

I would like to settle upon a single client-side technology that I can rely 
upon to be here in 15 years. Novell and Adobe have failed me in this regard. 
The only piece of my stack to not drop the ball on me is Java, which is why we 
are going with a Java based framework where the UI logic can reside server side.

Do you know how hard it is to hire someone that can come in and be competent in 
all 4 of my web architecture generations? Very difficult. So, it's better to 
stop developing in Flex now so that I have less older generation architectures 
to eventually convert to ZKoss. Once that is done, finding someone who can help 
maintain all of our projects becomes a much easier task.

Anyway, I very much appreciate hearing from an Adobe Flex SDK staff member. You 
have helped clarify that the direction I am taking is the right one. Hopefully, 
it's convinced a few others to not waste time writing in a technology that will 
one day require migration of an even greater backlog of  projects to their 
inevitably new chosen technology stack.

Ron

--- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Alex 
Harui aharui@... wrote:

 I'm not in disagreement that in the long term, the advantages of 
 Flex/ActionScript/FlashPlayer will be diminished by advances in the 
 HTML/CSS/JS stack.  That's why Adobe has made a major strategic shift to 
 become the tooling leader in the HTML stack.  But that doesn't mean that you 
 should stop using Flex/ActionScript/FlashPlayer right now.

 Many folks who work with HTML/CSS/JS, even using the many libraries and 
 development methodologies available for it, still feel like the Flex paradigm 
 is superior.  Apparently, even Google agrees because they are trying to 
 create their own version of that paradigm with DART.  While translated code 
 is never as good, the productivity advantages of a better paradigm have been 
 pretty much proven to be worth it, otherwise, Flex wouldn't have been that 
 successful either since MXML isn't as efficient as pure ActionScript, and 
 Google wouldn't have invested so much in writing their website logic in Java 
 and/or Google Closure and/or DART.

 There is general support in the Apache Flex project for exploring ways of 
 using the Flex paradigm to create HTML5 apps.  Those working on the project 
 are motivated to future-proof their investment in Flex.  I don't see any 
 technical issue blocking us from translating the paradigm to HTML5, and I 
 invite all those who like the Flex paradigm to participate.  But at the same 
 time, there is lots of work to be done, lots of solutions to be 

[flexcoders] Re: Flex alternatives

2012-01-12 Thread Ron G

I have used Flex since 2006, and I have used ZKoss within the last year. I can 
tell you that the learning curve of ZKoss is much lower than Flex, and the 
development cycle is even faster. In your spare time, if you're curious like me 
and like to check out different technologies, give it a whirl, just so you'll 
have a good comparison. I think you'll be impressed - even if you don't ever 
use it for a project. I think you'll agree that HTML/CSS/JS is not a faster 
development environment, regardless of IDE. 

Would truly love to hear your assessment of it at some point. 

Don't get me wrong. I was always a big fan of Flex and touted its virtues 
whenever I could over the past several years. So, I have nothing against it. 
I'll be using it for years as I maintain existing projects written in Flex. 
But, with respect, I think you do a disservice to continue  to tell developers 
to use Flex. You are only telling them to build a backlog of projects that will 
have to be converted  one day. But, I understand you work for Adobe and can't 
very well say exactly what you think developers should do. 

Ron

--- In flexcoders@yahoogroups.com, Alex Harui aharui@... wrote:

 Flex and FlashBuilder are not part of Adobe's HTML strategy per-se.  
 FlashBuilder is being directed towards Gaming in Flash, Flex is being donated 
 to the community.  It is the community that has lots of investment in the 
 Flex/AS/FP stack that are looking reworking the Flex paradigm to output to 
 the HTML/CSS/JS stack.
 
 Meanwhile Adobe is not only updating Dreamweaver (see the PhoneGap features 
 added in 5.5) but also looking at new tools for new development 
 methodologies.  While classic Java has been around for a while, and 
 HTML/CSS/JS will likely meet your 15 year requirement, the question remains 
 whether you will be willing to use more efficient and powerful development 
 frameworks and methodologies over those years.  If you don't, you might lose 
 competitive advantage as your competition gets their products finished better 
 or faster, but if you do, you run the risk of choosing a new set of tools 
 that turns out not to have lasting power.  Tough call, no right answer, the 
 choice is yours.
 
 It looks like the Apache Flex folks are going to try to provide one of those 
 new sets of tools by making it possible to use the Flex paradigm for the HTML 
 stack.