Good discussion... and at good time! My current preferences is to use Flex on frontend + Java on backend for projects targeted to end-users, but use Java both on frontend and backend for those projects where you can educate users or prepare their working places yourself.
Java on frontend - you have different options: 1) standalone Swing app 2) Java Web Start app (almost the same as standalone Swing app) 3) standalone app using Eclipse RCP + SWT 4) same as (3) but via Web Start 5) applets - but seems this is an anachronism :) You can use different protocols between Java client and Java server: RMI, Hessian, HTTP and others. As for Flex on frontend, you can use RTMP/AMF, HTTP and, partly, Hessian protocols. For now, Java is difficult to install for many end-users, I see this constantly even for programmers :) But Consumer JRE is coming soon - maybe the things are changing... (Consumer JRE - https://jdk6.dev.java.net/6uNea.html) Flex seems very buggy and NOT so feature-rich and stable as Java, but Flash Player is installed on many computers, so most users can start Flash/Flex apps easily. If Java apps will be installed like Flex ones, it will be time to forget about Flex :) Victor Martin Wood-Mitrovski wrote: > Thats a very interesting question and I would love to read what others have > to > say, my personal take on the situation is this.. > > When faced with a similar situation about 2 years ago I opted to build my > application using the Eclipse RCP framework. I definitely recommend > investigating that option as the infra-structure for a lot of the standard > application features is already there: undo / redo, copy / paste, drag and > drop, > ui controls (SWT), wizards etc..not forgetting that the whole eclipse plugin > ecosystem which you can use. > > Saying that, I dont think a transition to java itself is particularly > difficult, > but rather the concepts and knowledge required for programming Eclipse takes > quite some time to learn (although of course there are numerous examples > including eclipse itself) > > For me I think the time I saved from using RCP (i.e. how long would it take > me > to build those components by hand in flash) outweighed the time it took to > learn > how to use it, also once you know how to build eclipse plugins you can build > your own plugins to further automate development. > > I still do most of my work with flash, but personally I think it still has > some > way to come before I would consider it for a 'large-scale' desktop > application. > Im looking forward to when that day arrives and AIR is a good step forwards > but > I think the application infrastructure required on top of that isnt there yet. > > I look forward to hearing other perspectives. > > martin. > > sebastian wrote: > >> hello OS flashers! >> >> I have a high-level question and I would be very keen on hearing your >> advice on a heart felt subject of mine. >> >> Recently a group of people, including myself, decided to band together >> to make some software. It's all ecological minded, ethical business >> model and generally very exciting, flowery and ideal. >> :) >> >> Now most of us are good AS coders, OOP etc. but we are not "std" >> application developers. >> >> The scope of the project has grown, and our requirements list is >> becoming quite large. So we have arrived at a crucial decision point. >> >> We are thinking of releasing a bare-essential release at first of the >> application, but we would like to build something that we can eventually >> flush out to the full extent of our vision in later releases, and this >> has started to make me a bit concerned about the technology decision we >> should make. >> >> Essentially we want to code an application that is fully featured with >> all the standard application features of a typical CAD+calender system: >> undo/redo, copy-paste, save, edit, open, revert to save, save as, view >> option filters, print, print, view rotations, selection lists etc.etc.etc. >> >> The application has to run online but also off line [with off line data >> sets that would be installed/copied, periodically updated/dl'ed]. >> >> The data itself [= XML output files] has to be encrypted somehow and the >> application decryption method protected from hacking/code-sniffing [have >> not had the time to research if this is possible in flash] >> >> My question is, if by developing in flash we are painting ourselves into >> a corner? >> >> I also can't weigh the pros and cons of developing in standard >> application-lingo because my expertise is narrow-casted to AS. >> >> I find here and there sprinkles of code/libraries for undo/redo [Command >> Pattern], and it may very well be I can solve all the issues - but would >> all these things be easier and more future-proof in standard code? If >> so, much-much easier? Or only slightly so? >> >> Practically we have an issue that if we decide to not use AS for the >> application we are missing developers [hehe, no small issue] - so the >> thought has crossed my mind to code it anyways in flash [assuming it is >> not like drinking arsenic]; and then if the application is really >> successful/appreciated: porting it to standard application code IF we >> seem stuck at that point... >> >> Thoughts? >> >> Sorry this was a bit of a long post, but I wanted to make sure you all >> understood my situation well enough to guide me. >> :) >> >> BTW, if any of you are interested in joining an ethical AS project >> [everyone is part-owner // co-op style and the subject is ecological] - >> then naturally, please let me know! We still need one or two more coders >> [assuming this thread pans out pro:flash that is] >> ;) >> >> With kindness, >> >> Sebastian. >> >> _______________________________________________ >> osflash mailing list >> [email protected] >> http://osflash.org/mailman/listinfo/osflash_osflash.org >> >> > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org > > > > > > _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
