I'm embarking on a project to develop a desktop application but my expertise have been in the web application development realm. I was about to refresh my knowledge on Swing programming when I learned on JavaFX which seems to be a much better alternative. At least version 2.0 seems to fit that bill. My dilemma is that there are no books out on the topic. I was wondering if reading up on 1.3 first would be of help? Or is the syntax too, architecture, etc too different? I understand that there was something called JavaFX Script which is now gone in lieu of a Java API which is a bit why I'm wondering if reading up on 1.3 might be a futile effort?
Does anyone have any recommendations on learning resources other that JavaFX api, sample applications and such?
Obviously the syntax has changed, but if you already know Java, coding with JavaFX 2.0 will look familiar.
The one take away from existing books, is that most of the framework, controls, shapes, and effects, etc., from JavaFX 1.3 was ported over to JavaFX 2.0. So the basic knowledge of the framework can be gleaned from one of the older books. That would help you in at least knowing what component to use and then allow you to research it further to see how it now works in JavaFX 2.0.
There is also a lot of helpful documents at javafx.com. New books will be out within the next six months or so and may be available on-line sooner than that.
Related
I am currently working on a RIA project in flex, but have recently come across openlaszlo. It seems a lot of large projects have chosen it over flex, such as the streaming music service Pandora. I'm interested in why. So far the biggest advantage I have seen is that it has an abstraction layer for support of flash 6,7, 8, 9 and dhtml and has been in development for a longer time (so possibly more stable).
Has anyone had much experience using both, or just openlaszlo even? is the support for dhtml and older flash versions really that big of an advantage with the popularity of flash 9 these days? Might this just be because of many developers are already comfortable with javascript/ajax? Besides language preferences, why openlaszlo and not flex?
Thanks for any tips!
Ryan
When companies like Pandora chose OpenLaszlo, Flex was still a commercial product (even the compiler). The Flex versions 1.0 and 1.5 were not very stable, and only with the 2.0 release of Flex the platform got a lot more stable. Macromedia upset a lot of developers, since Flex 2.0 was no compatible with 1.5, and all applications had to be rewritten for the new release. In that situation quite a few companies thought that OpenLaszlo is not a bad choice.
The most powerful feature of OpenLaszlo is the LZX language. The language supports classes, animation of any numeric property, constraints using a attribute="${}" syntax, mixin support, datasets with datapath (xPath syntax based) mapping. Some of the key developer of the LZX langauge had been working on Apple's Dylan language before, and a lot of the powerful concepts of Dylan have made it into the LZX language.
I've done both OpenLaszlo and Flex development. Flex has excellent tooling support by various IDE vendors. But the ActionScript 3 language can be very limiting, as in Java you spend a lot of time thinking about your class model. OpenLaszlo emphasizes instance based development (very fast for prototyping, while it's still possible to build very complex applications with 100k+ lines of LZX code). The largest OpenLaszlo applications I'm aware of are Laszlo Webtop (120K+ lines of LZX code), and IBM Websphere Commerce Edition (http://ibm.co/Kid5tc). I've heard that other companies have created equally large applications using OpenLaszlo.
Since version 4.2 OpenLaszlo integrates the Flex SDK. The OpenLaszlo compiler generates the LZX code into JavaScript 2, and then into ActionScript 3 code. If you compile an application to both DHTML and SWF10+, you can profit from the better type checking of the Flex compiler, even if your application will only be deployed for the DHTML/HTML5 runtime.
OpenLaszlo is very stable. The last major release (4.0) has been in March 2007, although the OpenLaszlo team considered the 4.2 release to be equal to a major version upgrade, since it added the ActionScript 3 and SWF9 support to the platform. 4.2 was released in December 2008, the current stable release is the 4.9 version - although many community members and Laszlo are already using OpenLaszlo 5.0 (trunk, unreleased) in production.
After Adobe's announcement to contribute the Flex SDK to the Apache Foundation (now an Apache Foundation Incubator project), Adobe announced that they had been working on a cross-compilation feature for the next generation Flex compiler called "FalconJS". Adobe said as well, that FalconJS (which will probably be contributed to Apache Flex in Q4 2012) will not be able to cross-compile existing Flex applications into JavaScript. A simple list example of FalconJS (as demoed in December 2011) generated into 5 MB of uncompressed JavaScript code, wich could be boiled down to 2.5 MB using the Google Closure compiler's advanced mode. A similar OpenLaszlo example in the DHTML runtime compiles to less than 750k of JavaScript code.
I think your term of 'a lot of large projects' is very relative. Yes, some large companies have used it, but I don't consider any of them large projects. If you look at all of them in the OpenLaszlo showcase, they seem fairly simple interfaces to me. Also note that OpenLazslo compiles Flash, not Flex and associated framework.
To me, OpenLaszlo is an alternative for creating simple RIAs in a way that the end code can be compiled into Flash or Javascript. Haxe is another alternative to this, and I think it does a better job than OpenLaszlo.
With that said, there's a problem with these "generic" write once, compile to Flash/Javascript framework; it doesn't harness any of the power/advantages of each specific platform. Flash is constantly changing and so is Javascript with the addition of html5 tags and css3. If you ever have experience in both, you'll notice that they're very different in the way they do things and on algorithm might work well with Flash, might not with Javascript.
My point being, if you are to choose a technology, go for the one that's more appropriate. If your project has a need to have both Javascript and Flash, then this might be a good choice, but remember that you'll then be losing the 'power' of each. For instance, Flex has a very good skinning architecture and a set of tools that is essential for enterprise development. Javascript can do some pretty neat stuff with selectors, css3, and some other frameworks like jQuery.
In my experience, post compilers like OpenLaszlo eliminates those strengths. Plus, if there's a new thing that comes outs (like say, hardware accelerated video/3d for javascript/flash), you have to wait for the people at OpenLazslo to update before you can use it (if they use it).
I started developing RIAs with OpenLaszlo as it offered a cross browser run-anywhere kind of framework. The user experience delivered with it was also very good.
I moved to Flex (when it was in Beta) because:
Every capability of OpenLaszlo was available in Flex.
Flex had an extra advantage as it was a supported commercial product from a leading digital media content creation company Macromedia & later acquired by Adobe.
Flash Builder (a.k.a Flex Builder) built on Eclipse provided a good development productivity improvement. (so spending one time license fee on it is not at all an issue)
Above all Flex had better server-side integration / remoting capability.
Flex had plenty of tutorials & sample codes so ramping up a new developer was very easy.
Now Flex is also community driven open source project under Apache Software Foundation
OpenLaszlo now provides an extra feature over Flex (until FalconJS cross compiler is released) that it can run both Flash & Ajax runtime environment with a single code base .
But still Flex has an added advantage of having very good development environment (with integration to other Adobe designer tools) and good server side integration capability so for enterprise applications, Flex is a clear winner.
I was reading these days about large projects implementation in python and Flex, and very often people praise the use of framework (like Cairngorm, PureMVC or others) over traditional OOP coding.
I think i dont really understand the advantage of using FW, which is the strong point over classic programming? how big should be the project in order to use FW? it is intended mainly for web-applications? or can be used for desktop apps as well?
hope, all these doubts dont sound stupid to you, i am not Computer engineer, just electronic, so my knowledge of sw architecture is very limited.
Br
Using a framework is not really any different from classic OOP programming.
When you write projects in a similar environment, you will probably see yourself writing a framework (or a set of tools) over and over again.
A framework is really just code reuse - instead of you writing the logic for managing a common task, someone else (or you) has written it already for you to use in your project.
A well designed framework will keep you focused on your task, rather than spending time solving problems that has been solved already.
I would add my 2 cents here, using a framework will also help a better organized collaborative environment too. Your team mates will get to know about the code easily if you are following a standard framework.
In enterprise applications using framework helps meeting the deadline and better code quiality.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Well, I know it's a preview, and I know it says that it's not yet ready for production, and yet I dare ask the question.
I need to start building a pretty big application, which is planned to go live at around sep-oct 2010.
Lets say I will not release the application to production until the stable version of symfony 2.0 will be released - is it a good idea (well, I'll settle for a viable idea) for me to start building the application using the 2.0 version ?
How big is the chance I will need to rewrite/replace code I've written due to core changes in the framework ?
Thanks.
Edit: the other option right now, is to use symfony 1.4.
I have thought and tried Zend Framework, but I refuse to re-invent each and every module, which will cost me a lot of programming hours (if not days/weeks).
From Fabien's presentation of Symfony 2 at symfony live: use symfony 1.4 for your next project.
From Symfony 2 github page: things WILL change.
Now consider the following:
symfony 1.4 will be supported until late 2012, that's 2 years after your project's release
Symfony 2 does not have code generation, forms, unit tests, etc so everything that you'll do to cover up these fields, you'll have to redo when the official ways are coming (that answers your second question)
so as everyone already said here, go for 1.4
symfony 1.3 or 1.4 is the right choice for now. 1.3 if you've used symfony 1.0 before, 1.4 if not. I am personally not a fan of the from sub-framework in symfony 1.1+ for many reasons, but you may find it entirely agreeable. That's a personal choice, then.
symfony 2.0 is not stable, and many of the features it is introducing are not those which would really interest a developer, I feel, at this stage at least. sf2.0 is however a impressive exercise in making the next generation of web frameworks; but, not in making the sites you make more feature-rich or easier to develop. It may make them faster and more elegant under the hood, but this is not necessarily the primary advantage of a framework to a developer. An example of this is dependency injection. It's a further abstraction of the already excellent symfony core code components, and its inclusion only increases my respect for the symfony core team and their advances - but for an end-user it probably leaves many scratching their heads over the advantage.
The main advantage of symfony once you appreciate the basic framework is the community and its plugins, and this I think is the dealbreaker for sf2.0 right now. Yes, I know it is essentially built from 'plugins', but you will lack several crucial plugins I'm sure, and either have to write them yourself or adapt existing to suit. This is the reason you reject Zend Framework.
Still, just my opinion. I've been a symfony 1.0 and 1.1 developer (mostly 1.0) for over 3 years, and it still hasn't let me down.
That's a million dollar question my friend. It's a gamble, plain and simple. I've used a number of php MVC's (cake,zend, and symfony) and they all operate roughly the same way. What's nice about symfony is it's focus on being modular, not reinventing the wheel and it's ease of use.
I can't cite any examples of larger companies using it, however I personally would use it over cakePHP or Zend at this point. I feel like it has a strong community, it's not in danger of being abandoned (at the moment) and I generally enjoy working with the framework. Which, at the end of the day, is usually all that matters.
Like I said, I don't know how well is scales up or out but it's faster than cakePHP or Zend. It's a gamble regardless of which framework you pick, so, good luck.
Unless there is something specific in Symfony 2.0 that you need for your application, I would suggest that you go with 1.4 and work with a stable version from the get-go. From what I understand, Symfony 2.0 might not be out until the very end of the year. Symfony 1.4 will be officially supported until end of 2012, leaving you plenty of time to upgrade/rewrite for 2.0 later, if you wish to do so.
I have tried Symfony 2 for a week now (I'm a full-time symfony developper) and here are the main reasons why you should continue using symfony 1.x before migrating to 2.0:
Twig is unstable. You can't use form_render, form_error, etc. But it's pretty easy using a PHP view!
Get user's culture (locale) is a pain in the a**.
PHP templates are not fun as Twig to code. Example with this translation function:
PHP: <?php echo $view['translator']->trans('text') ?>
TWIG: {% trans 'text' %}
Bad documentation
It seems not so bad like this, but trust me... it takes me so much time to debug those stuff to realize in the end that it was wrong inside Symfony 2 himself.
By the time you release your project, version 2.0 is most likely will not be stable anyway. And consider that version 1.4 has long terms support for 3 years, which you can count on if you are starting up a new project. Other than that, with symfony 2.0, things are not going to be same :) it is going to be so much different than current versions. You might not like it :) or it might not be suitable for your project.
Or you can just use Lithium...you know, it's better than all of the frameworks on the page mentioned... BUT the question IS about v2.0 readiness not about cake or other frameworks (as mentioned by other posts, though I figured I'd get my jab in too).
I personally wanted to use 2.0 on a major project, but will likely turn out not because of fear (always a bad reason).
My point is this. Nothing is stable. Not even 1.4. EVERYTHING in this world is subject to change and there's always patches and fixes for everything. If we didn't use beta/alpha software, ESPECIALLY in an open source community, we'd never progress.
So. It's a risk. The trick is you gotta be good enough to handle any problems that may crop up. I think that's just the name of the game. You're either the type of developer who goes off and installs Wordpress and Drupal and says look at me mommy grown up pants...Or you're the type that goes out and is on the cutting (or bleeding) edge and sucks it up and gets it done. Rolls with the bad times and smiles (from ear to ear) during the good.
End of the day it's your job. Don't ever let anyone tell you how to do it. You do it how you want.
I want to throw together a .net website as an interface to a subsystem I manage.
I'm planning to use ASP.net (on .net 2.0) because this is the shop's standard.
I would like to use an ORM because I was playing with Django a little bit ago and realize the time saver and code simplifier it was. I realize I may not get the time saving aspect because of the setup but I think it should make maintenance easier.
Can someone recommend a stable, very easy to learn/setup ORM product that works with ASP.NET 2.0. I prefer open source, but as long as the product is free it's fine.
Because learning something is dependent on the learner I want to share that I'm an experienced developer. I use a lot of languages and generally learn quickly with good material.
I'd recommend Castle Active Record.
It's built ontop of NHibernate, which is a pretty popular one, but Castle's AR is faster to get off the ground with in my opinion.
I used it on my last ASP.NET project so can vouch for usefulness there. :)
Edit - Here's a quick link to "Getting started".
I recommend NHibernate. It is full featured, very mature and (in my experience) quite stable. Take a look at the summer of nhibernate screencasts (also free) and you'll have enough knowledge to get up and running in no time!
One of the stated goals of the PureMVC framework is to avoid platform dependencies in order to be portable. Considering that because of language and API differences application code will always be heavily dependent on the platform, and that avoiding platform dependencies makes the framework reinvent the wheel and/or only provide a least-common-denominator feature set, in what way does the portability of the framework benefit me as an application developer?
I've worked with PureMVC. They're trying to implement their stuff in quite a lot of languages. You may be right about the least common denominator, but overall, it's not a bad framework, and I've seen a really nice AS3 app in PureMVC.
I don't think they're talking about portability in terms of porting actual code. The idea there is more that you're using a generalized MVC architecture, which you could apply to other projects and other languages.
They're trying to say that if you become familiar with the PureMVC pattern, you could potentially come into a new PureMVC codebase, even if it's another language, and you would already know the lay of the land.
You might also say that developers who develop good PureMVC skills are likely to develop good habits which will translate as they go from language to language. But then again, maybe not.. for the reasons you mentioned.
We've been using PureMVC on two projects now and in my opinion the attempted language-independence is quite a burden.
The promise of jumping straight in a project because the framework is already know does not seem relevant to me if the languages are not already pretty similar (C# to java would make sense, as3 to php not) -- I agree that it is useful to have known ways of solving things, but for that the 'plain' patterns are good enough.
However, I also don't really agree with the usage of the various patterns the project uses, so our choice to not use it on the next project might be related to both issues, and not just the attempt at language/platform independence.
PureMVC's portability will help you when you migrate to or reimplement in another language.
I can't count the number of platforms and languages I've written code for that are now extinct and for which, even if I still had the source code it would be mostly worthless and have to be rewritten from the ground up today, since the code was usually 100% platform specific.
But all application code need not be heavily dependent upon the platform. View components and services (the boundaries of your application) will necessarily be, but your application logic which is sandwiched between the boundaries need not be.
The scope of PureMVC is really quite narrow; merely to help you split your code into the three tiers proscribed by the MVC meta-pattern. There is no reason why this code has to be tied deeply to your platform in order to be optimal.
When it comes time to migrate, you'll appreciate that the framework actors and their roles, responsibilities and collaborations remain the same. This leaves you to deal with syntactic differences of the language, recreating the view components and services. At least you won't have to completely re-architect.
And for the case of reimplementing in a different language, imagine you're trying to capture a significant part of the mobile market with your app. The market is so fractured, you'll have to implement the same program on 2 or more of Windows Mobile, iPhone, Flash, and Java. Sure you'll probably have separate teams in charge of the apps, but why have a totally different architecture? With PureMVC, you could have a single architecture for all versions of your application.
-=Cliff>
PureMVC is the only real option for Flash Platform developers who choose not to use the Flex Framework. For certain projects the size cost of Flex is too expensive (it happens!).
I like to prototype in Flex and then rip it out and replace my views with custom components when the application is near completion. PureMVC makes this really easy to do with it's Mediator pattern. I'm not sure there is any other framework that would allow me this workflow.
Personally, I think PureMVC went too far with it's portability goals: I enjoy that fact that it works with Flash AND Flex (for the reasons mentioned above), but feel that it should have stopped there, and made use of the native Flash Player event architecture.
Are there examples of people using PureMVC to build and port applications across multiple platforms?
My company is building a Flex application that we may need to port to other platforms:
Silverlight (likely)
Mobile (maybe)
Desktop (maybe -- not just AIR!)
TV sets (maybe eventually)
I am considering PureMVC as a framework if it can ease porting and maintenance. I am curious to know if other people have ported a PureMVC app to a different platform and what their experience was with porting and then having development proceed in parallel for the app on multiple platforms.
Cheers,
Karthik
PureMVC does not rely on a platform for its internal workings (Flash Events etc).
So, while it does not make porting any easier per-say, it can assist simply by showing us its friendly and familiar face wherever we may choose to go ;-)