My company is considering upgrading to flex 4 ( mainly to use the richtextlayout ) I would like to know from your experiance what is the status of the product ( how far is it from official release ) and do you recomend using it now or wait till its complete its beta stage
Thanks
We're using flex 4 beta 2 for our upcoming project.
I must admit that it's not yet production stable, there are bugs, and some of them are showstoppers. (we had some problems with data grids at least).
Though it's quite usable and works.
So, if your new project is a long-standing one and you're ready to update from time to time to the latest nightly, so go for flex 4. It's very likely that Adobe will release the final version in 2-3 months timeframe and you can easily switch to it.
If your only concern is a TLF-enabled text area, then consider as an option porting using TLF directly in your flex 3 project. That was the way I've chosen for my last project.
I've backported RichEditableText component to flex 3 from flex 4. It wasn't that hard, cause it had little dependencies on flex 4.
Related
I have a lot of UI Automation JavaScript code which is no longer useable since support was dropped in Xcode.
I'm looking for any means possible to try an reuse as much of the code as possible.
I just wondered if there's is any sort of migration path or hack to make it useable ?
I haven't seen anything so far.
Well, I've waited enough for iOS QA Automation Engineers to share their professional view on the matter, but since none showed up, I'll give it a go.
First off, you are not alone. UI Automation support has been dropped since XCode 8 and a lot of other people had the same problem.
The main takeaway from all the materials I've read online is this:
The only version of Appium that will work with xcode 8 is 1.6.0. You can download the beta now. Instruments/UIAutomation have been removed and only Appium's XCUITest support will work moving forward.
Moving forward, the best document to get you started with your test case migration, or at least give you some helping tips is this one: Migrating your iOS tests from UIAutomation (iOS 9.3 and below) to XCUITest (iOS 9.3 and up) [UPDATED LINK].
The article covers some pretty hot topics considering your situation:
Element class name schema;
Page source;
Locator strategies (with xpath emphasis);
Dependencies, API differences, etc.
You will have to start using appium-xcuitest-driver instead of appium-ios-driver.
Installation & Setup:
Apart from the relevant info that you'll find on appium-xcuitest-driver's official GitHub repo, the bread and butter is here: Setting up iOS Real Devices Tests with XCUITest.
Getting started with a new framework/set of libs, or migrating from one tool-suite to another is always hard, but from past experiences, once you have a working setup and build your first test case, everything else will go smoothly afterwards.
Finally, I could pro-long the response, but the official documentation will always do a better job.
Hope is helps in any way, shape, or form. Cheers!
I do Drupal for a living and I like the system. However I've always been intrigued by Plone and wanted to learn it well to broad base my knowledge of CMSes in general. I've played around with Plone in the past and was both mesmerized and repulsed by it -- depending on the day.
But then again here is what I saw as the advantages of Plone
Python sweet Python
Built on battle hardened and uber mature Zope 2
Zope 3 style which is now available in Zope 2 also and therefore in Plone
Objects and not SQL
True separation of configuration and content (unlike Drupal where configuration and content is totally mixed up in the database)
Very powerful system to make custom content types (unfortunately not via a UI)
However it surprised me that there was nothing that I could find equivalent to views ( http://drupal.org/project/views ) and that taxonomy (i.e. classification) was not a first class citizen. Every Plone product seemed to take its own approach to taxonomy. All in all, though I loved its extreme and idealistic approach, it always struck me that everything was so darn difficult to accomplish in it.
I've really been hoping for Plone to succeed and every few months will explore its RSS feeds only to go back dejected.
I thought I'd test out Plone 4. The new feature list in Plone 4 was totally underwhelming to me ( http://plone.org/products/plone/features ).
Drupal 7 new features ( http://drupalcode.org/viewvc/drupal/drupal/CHANGELOG.txt?revision=1.373&view=markup) and Wordpress 3 ( http://codex.wordpress.org/Version_3.0 ) seem to have done tons more in their new major releases.
Moreover replacement to Archetypes through Dexterity ( http://plone.org/products/dexterity/documentation/faq/how-is-dexterity-related-to-archetypes/view ) is also a great step forward. So while Plone 4 itself may be an improvement over 3.x is it enough to keep Plone in the reckoning amongst other CMSes?
Which brings me to my question:
Is Plone on a steady decline? Whats the future of Plone? Am I wrong in my assessment that Plone is not adding functionality and features at the rate other top tier CMSes are?
This http://www.google.com/trends?q=plone seems to confirm my fears.
Should I give Plone 4 a try and make it my "second" CMS?
Let me get the bias out of the way first: I'm one of the co-founders of Plone, so make of that what you will. ;)
Plone 4 is in many ways an "intermediary" release — the original plan was to make it into a large release with new UI approach (new layout system Deco), improved type definition system (Dexterity) and improved theming story (currently referred to as XDV, name will probably change).
Along the way, we realized that we needed a smaller release before we did that, so the major improvements got pushed to a new Plone 5 milestone, and Plone 4 was turned into a infrastructure / cleanup type release.
With that goal in mind, the team delivered the fastest Plone yet (it trounces Drupal, Joomla and WordPress for speed), improved a lot of very important infrastructure (files are now stored outside of the database, it uses much less memory than it used to, and scales a lot better to large number of parallel requests).
The innovation is still ongoing, and now that Plone 4 is out, we're fully focused on delivering Plone 5, which should have a lot of the new features and improvements that were originally planned as Plone 4. In the meantime, we have an extremely solid and fast base to work from, and deploy customers on.
You can also make make use of a lot of the Plone 5 tech in Plone 4 already — examples include the aforementioned Dexterity type definition system, the XDV theming system, and several other infrastructure improvements like the Chameleon template language (adds ~50% speedup for most pages).
So, no — we're not adding features at any slower pace — if you look at the source code history and activity instead of Google Trends (which isn't a very useful metric for something as niche as a CMS system), you'll see that there are more active developers and more code improvements than ever before.
Yep Collections do most of what is described by that description of Drupals Views. One thing that collections don't do out of the box is the grouping/taxonomy. There are additional plugins that can help do that such as collective.collection.yearview. Taxonomy options could be stronger but in reality nested collections work for most use cases.
As for the future of plone? Plone's popularity has remained static for the last couple of years as it has gone through it's massive internal restructuring. It's lost developers and gained developers. Compared to the rise Drupal and CMS's in general that may look like decline. The important thing now is that, due to that restructuring, Plone is now very developer friendly. Due to Diazo/XDV which most Plone integrators are switching to, Plone is now very designer friendly. It's also now fast and just as secure and flexible as it always has been. Expect Plone to start getting a lot more outside attention and growth from now on.
As Limi mentioned the mantra has been 'Plone 4 is the evolutionary release, Plone 5 is the revolutionary release'. As DisplacedAussie said, look at 'Collections' in Plone, they are like saved searches and combined with the Collections Portlet are pretty powerful.
Coming up in Plone 5 is the Deco/Tiles system for content editing, this is going to be really pretty amazing, and you can see in initial preview of it here: http://www.mefeedia.com/watch/32696814
Basically the entire page is made up of composite elements, each one is a first class item and addressable with its own URL. They can be dragged about the page on a grid as you see fit.
-Matt
I'm not referring to CVS or SVN! The thing I would like to do is:
I want to have a version number of the application ex. 0.0.120
I want to see this version number only in the About box or similar
This version number should change everityme I hit debug or release. ex. my version was 0.0.120, after I hit debug in the FlexBuilder, the versionNumber should change to 0.0.121, but If I press Release Build, then the version should change to 0.1.0
The first number changes only when I manually change it
Don't know how is this possible but if you have a tip, let me know. Thanks!
Have a look at this article http://www.igorcosta.org/?p=220. I use this method to keep tract of compilation date of my swfs.
Credits goes to Paul Sivtsov.
I think Flex Builder doesn't have this out of the box, but you can build ant script for that and build your application with it:
http://blog.nirav.name/2008/02/how-to-auto-increament-version-build-id.html
This is typically something you support with frameworks such as maven.
There is actually a maven plugin for flex here
mico's trick is nice though
I was excited to find out that Adobe released the data visualization for free so I can use the fancy charts and all with my projects even though I don't have Flex Builder Professional. So I installed the new 3.4 sdk along with the data visualizations. Most all of my projects did fine except for one. This particular project uses localizations. Are there any new compiler arguments that I need to include? I current have -source-path=locale/{locale} -allow-source-path-overlap=true. I get the inconsistent linkage error below:
Inconsistant linkage in /Applications/Adobe Flex Builder 3/sdks/3.4.0/frameworks/locale/en_US/datavisualization_rb.swc$locale/en_US/core.properties - 'en_US$core_properties' is marked as extern, but 'en_USGBC$core_properties' is not.
Any help would be appreciated.
Try use -locale en_US
I ask this question in the hope of collecting all the incompatible changes/bugfixes in Flex 3.*, of which the maintainer of a Flex 2.0.1 application needs to be aware before upgrading. I'm thinking of issues of the following nature:
Bugs in 2.0.1 that had had some workaround, and have been fixed in 3.*, rendering the workaround not only useless but also erroneous.
Bugs introduced in 3.* that worked in 2.0.1, needing new workarounds.
Features that behave slightly differently (events, attributes, etc.).
Incompatible internal changes, that should not effect the progammer, unless they meddled a bit with the internal objects of the framework, like I did. :-)
Anything not fitting in any of these categories.
(I found several such issues, when I last tried this some time ago. Unfortunately I didn't take notes, and I forgot them since then, but I will update this post when I figure them out again. I reported one issue on the Adobe bug tracking site, it was unfortunately deferred.)
It would also be interesting to read about the advantages/drawbacks of such an upgrade. Are there any showstoppers?
here are some links that may help in your endeavors:
http://blogs.adobe.com/flexdoc/2008/02/migrating_from_flex_2_to_flex.html
http://blog.comtaste.com/2007/06/migrate_from_flex_2_to_flex_3.html
http://butterfliesandbugs.wordpress.com/category/flex-migration/
http://butterfliesandbugs.wordpress.com/2008/03/04/understanding-flex-3-migration-issues-part-i/
http://butterfliesandbugs.wordpress.com/2008/03/06/understanding-flex-3-migration-issues-part-ii/
http://butterfliesandbugs.wordpress.com/2008/03/16/understanding-flex-3-migration-issues-part-iii/
For the record, most of the migration problems from Flex 2 to 3 are minor, especially when compared to the problems of migrating from Flex 1.x to 2. I upgraded several applications with no problems at all. That being said, the above links should help note most of the problems you might run into.