Ext.define(‘App.patch.app.Controller’, {
requires: [
'Ext.app.Controller'
]
}, function () {
// By now Ext.app.Controller has been loaded
Ext.app.Controller.override({
init: function() {
this.callOverridden();
console.log(this.self.getName() + ‘ created’);
}
});
});

I didn’t used Direct, I preferred to stay with traditional JSON stores backed up with JAX-RS and JPA.

Only problem I got was how to persist a complex graph which somebody in the forums resolved overriding Json writer’s getRecordData() & writeRecords.

Which one is your data access philosophy? I mean:

Server ExtJS: JSON?
Server database: Plain SQL, Hibernate, JPA?

But again, when the wind is over, I am sure the first word reset from all customers (enterprises): Hey you, the salesman, we need a solution that works, not a technique

Does your clear framework targets Java 5 or 6 platform? In Java 6 there is even better way of generation your code (apt is embedded in javac) and you can just put a jar file with a framework in a class path and code will be generated during normal compilation process – no extra step involved.

I understand the purpose of storeConfig but that string concatenation doesn’t look natural. Do you think it would be better to have separate annotations or a separate attributes?

Thank you

I think your company has made the right decision. But we are a consulting firm and don’t want to lose customers who are not that savvy and are moving with the trend. We understand that moving from Flex to Ext JS is like going “Back from to the past” – I’m just rephrasing Ted Patrick from Sencha who went the same path and said “I realized that I lived in the future”.

Slower performance (on IE) doesn’t bother me that much – I’m sure Sencha will fix it soon and it’ll be as fast as JavaScript can be with these rich components they offer. Having said that, I’m not married to Ext JS, and as soon as I see another JavaScript framework with similar offerings – I’ll give it a try.

Needless to say that our firm is developing pretty cool stuff using Flex and AIR, and we’ll gladly take new customers who are willing to use this great technology accidentally developed by Adobe as someone put it . Just look at this demo (press the button Play) of the Trading application that we created for a Wall Street startup: http://www.itbsecurities.com/platform.html. It’s all Flex talking to Java.

Good luck with your Flex projects!

In the company I work for, we decided that Flex 4.5 will be more than good enough until the end of 2013. After all, Flex 4.5 is recent. And even if the Metro version of IE10 won’t run Flash Player, the legacy version of IE10 will, and enterprises are slow to upgrade their deployed browsers. By then, we expect the HTML 5 / Javascript enterprise frameworks to have somewhat matured and we will reconsider. We will see if the HTML 5 hype will have deflated and the Apache Flex project will have gained traction or if the hype was right.

I am not convinced frameworks like ExtJS are the swiss knives they pretend to be when I read this:

Serious performance degrading leads me to doubt Sencha’s Future
http://www.sencha.com/forum/archive/index.php/t-173933.html?s=8e9a5341667c6528502441e4b46fa4d5

PS: “You can’t piss against the wind”: I like the russian expression there

Everyone has heard of HTML5 and wants it, it allows them to sound cutting edge… but from the implementation side… it’s another story.

Have heard about zk framework? If yes what do you think about that?

Best regards,

Roy

http://www.zkoss.org/
http://www.zkoss.org/zkdemo/grid

If in the past creating a framework that supported MVC Dependency Injection would make a framework popular, this won’t be the key to success in the future. The next generation frameworks will make sure that your Flex app still works even if Adobe’s Flash Player 5+ doesn’t support a feature that Apache Flex SDK needs.

This is what the modern JavaScript frameworks do under the hood. Instead of just calling a function abc(), the code first checks if such a function even exists. If not, the PlanB-code gets invoked. Most likely, the upcoming Apache Flex code itself will have to incorporate such preventive measures.

http://www.infoq.com/presentations/Lessons-Learned-from-Java-EE

Mobile, VM platforms (like Flash or Silverlight) is the way to go if you want a consistent, stable environment. (Admittedly the technical superior solution isn’t always an industry’s choice.) So that problem is already solved w/Flash – I think what Flex is missing, is something like SpringSource – a company that charges for and offers enterprise support.

And while the Falcon JavaScript compiler (target JavaScript for the Flex SDK, like GWT does with Java) is still yet to be seen, I think that should do something to calm people down after the FUD slinging session we had a few months ago. The Flex SDK & development methodology will be preserved even if browser plugins die. Actually simply getting that compiler to a stable state would probably be big news. Targeting Flash or JS makes Flex one of the most versatile and mature web SDKs out there.

I couldn’t care less about Flex and Flash dev on mobile, or adding new features to Flash mobile. Mobile is a lot of hype these days. Good riddance to something that was stealing valuable resources from Flex/Flash Enterprise/Desktop. You could argue that Flex and Flash are overkill on these little devices, for such simple little apps. They can barely run crummy JS toys.

It’s akin to an un-needed government agency being shut down and privatized (open sourced, here), and people are reacting with predictable unproven FUD. The worst thing about the news is the news (and the over-reation) itself. I admit maybe, that could be enough to cripple the SDK going forward, if Fx proponents keep acting grumpy about these changes… so stop. No good can come from negativity.

As to Flash Builder, I have no trust in Adobe. They couldn’t make it to work properly on Desktop in 6 years. Now they’re facing a plethora of different mobile devices which should be properly emulated. This is tough.

With the native extensions, you’ll be running into this pointing-fingers game over and over again.

Having said that, I can’t say, “Don’t use AIR”. Let the money talk: just take a piece of paper and do some math calculating the cost of developing these applications with and without AIR. Do you have the right skill set in house? If not, do you have a budget to hire people with different skill sets to develop natively? If the answer is No to these questions, stick to Adobe AIR and learn to live with Flash Builder.

I’m just curious, because I’m struggling with that decision everyday despite AIR having native extensions now. I just don’t want to get screwed and I’m finding it challenging to use the Flashbuilder 4.6 to build mobile AIR apps for android using native extensions. I find I spend more time trying to get the android debugger to play nice than I do coding. And it also seems like Adobe can’t resolve any issues on their bug forum. They blame all the external sdks or don’t seem to be able to fix any problems. Just frustrating…

I can tell you that I’m leaning toward discarding flashbuilder4.6 and starting fresh with Xcode and eclipse(or intelij). What about you. Any advice in this area?

Thanks
Ron

I design and implement very complex and pixel perfect user interfaces – and Catalyst has saved me weeks worth of work. It has its quirks but to implement components and UI it has real business value.

FXG is a great move forward. Halo was a dump of horse shit compared to spark components (if we omit the disaster that IndexChangeEvent are vs itemclick).

In other words I’m truly sorry to hear that they’re dropping FC. Not for the promises it had given and never delivered, but for the actual use I have for it. Creating skins in minutes rather than hours.

Does Farata have any plan in doing this Flex-to-ExtJs workshop in Texas?

Thank you!

WBR

Nono

What really struck me was the lack of I guess “engineering progression” in the HTML/JS/CSS world with respect to RIA’s. Components allow for quick production of mockups and decrease application development time, MVC structures allow for loose coupling and help increase code quality, tooling such as test and IDE’s allow for total developmental control. When you go and look at most JS frameworks you get none of the above and that is very disheartening because you can end up feeling like you are solving a problem that doesn’t need to be solved.

MS and Adobe both pulled out of the RIA market by killing both their projects. While Adobe didn’t outright kill Flex, its PR stunt has added so much uncertainty, that it will be awhile before people feel its politically prudent to suggest starting and maintaining Flex projects. I hope that MS or Adobe (especially Adobe) take note of the development gap in creating RIAs with JS and create some kind of library and tooling to do so.

ash, there is no need to develop anything over light libraries or say we adopt them – you just use them when necessary – but low level libraries solve the problems they are created for and should not be used for anything else unless it is natural fit.
Sincerely,
Anatole

Thank you for sharing your thoughts.
I am assuming you have looked at YUI.
From what I know, YUI is on par with what Ext JS offers at least from the UI scope but I am sure that
there are other differences that made Farata to lean towards Ext JS.
So I was wondering if you could share your thoughts on that?

Again thank you!