TO FLEX OR NOT TO FLEXWEDNESDAY, JULY 19 2006 @ 05:12 PMPeople I talk to have an idea of what is my position regarding Flex: is a great product, but if you work in Advertising, producing apps and websites that 99% of the time demand very distinctive characteristics, then Flex is not for you. Now, when I thought I had finally found the project that would allow me to catch up with all the new developments in the Flex realm, I won't be able to go on, because of some appearent shortcomings.
Here is a very quick exercise that I've put together to better explain what we are experiencing, and hopefully get some insight from you, experienced Flex developers.
The main reason we wanted to use Flex is to save us the time an effort that goes into building a solid drag and drop functionality, but with all the issues we have found on our first day of research, I am considering rolling out our own stuff, instead of having to hack into the Flex components. Has anybody else faced these obstacles before? Have you been able to work around them? Archived under: Usability, Flex, Flash. | Permalink | google | del.icio.us | digg ![]() MATTJULY 19 2006 @ 06:51 PMHow did you construct the tile list? Is it using icons for the images or is that an inline renderer? We can look into this.
I'm also curious about your use-case for multiple selection in Tree, but that's neither here nor there for the moment. MATTJULY 19 2006 @ 06:59 PMNever mind, we have it reproducing. We'll investigate.
TED PATRICKJULY 19 2006 @ 08:41 PMTechnically this is 100% feasable with Flex 2 but not by defualt. You will need to create a component subsclass and customize the drag logic to allow for dragging of multiply selected items. Creating custom controls is very easy like so:
package dragging { import mx.controls.TileList; public class CustomDragTile extends TileList { //custom drag handling here! :) } } What new developers to Flex often miss is that Flex is wildly extensible. Just because the default components do not support something doesn't mean your won't or can't. To Flex or Not to Flex is not the question, extend Flex and make new components. Its easy and its fun! Regards, Ted Patrick :) tpatrick@adobe.com COSMINJULY 20 2006 @ 02:39 AMBut how about the visual customization of the components. Like shapes and sizes. Colors would be easy with css.
TALOEJULY 20 2006 @ 03:49 AMTechnically this is 100% feasable with Flex 2 but not by defualt. You will need to create a component subsclass and customize the drag logic to allow for dragging of multiply selected items.
OSCAR TRELLESJULY 20 2006 @ 09:22 AMI understand that, however Flex should make the developer's easier, not more complicated, and these are basic Usability requirements.
For example, it seems a little silly that you have to explicitly set liveScrolling to true in order to scroll through the component while dragging an item; I just can't think of a single instance where you wouldn't want this to be the default behaviour. DMANJULY 20 2006 @ 11:53 AMActually, there has been many times I have had to turn off liveScrolling, mainly when you get into complex itemRenderers. You say that flex should make the job easier not more complicated, but I fail to see how this is harder than an AJAX drag and drop solution. I have developed on both sides of the fence and know that Flex is 100 times easier. I would suggest looking deeper into the drag and drop APIs for Flex and I guarantee you will find what you need.
No solution will offer you 100% what you want without getting down and dirty with the code and being a developer, you should know that... OSCAR TRELLESJULY 20 2006 @ 02:35 PMI do know that, that's why I am in the middle of a balancing act, to decide which way to go.
The question is how much of our vision are we willing to sacrifice in order to use a tool that has the potential to save us some development time, as opposed to building everything from scratch. If I'm gonna have to "get dirty" and work hard anyway, I'd rather realize my vision, following the path where there are less unknown unknowns. DMANJULY 20 2006 @ 04:53 PMWell, I guess I meant to say from your previous statement I don't see how flex is making things more complicated just because the shadow looks superimposed and it doesn't look 100% as you would expect it to. I would be looking at it from the perspective of "wow, I just got a drag and drop solution up and running with almost no code, now all I have to do is tweak it so that it looks like what I want". I don't know of any solutions that will be perfect "out of box".
Now on to a solution =D Flex has a pretty cool way of using something called a DragProxy. It's a mxml component that can be used as the component that is shown when you start the drag sequence. So what you can do is create a MXML component that stacks the images on top of each other (slightly offset so you can see all the images under). So the result should be something like a stack of images instead of scattared images (that look really bad). Now about the superimposed shadow, not sure what you can do there, but after using it for a few seconds, it was quite easy to use. Didn't trip me up. Hope that helped OSCAR TRELLESJULY 20 2006 @ 06:02 PMI really appreciate you taking time to help out, I really do, but the fact that it "didn't trip you up" is not good enough; I got used to it too, but we are not my target audience, whatever we are building has to make sense to people that are far less familiar with the nuances of UI behaviour.
I'm going to look into DragProxy, I missed that part somehow. However, dragging and dropping not the only issue (although probably the most notorious), and it seems like we would have to extend and tweak quite a few things to make Flex work for us, and then it comes down to a our schedule constrains and the learning curve associated to Flex development. For example, we need to be able to 'drag-select' several items from any given component, and although I know how I would do it efficiently (from scratch) in Flash, but have no idea on how to approach the problem within Flex. Another thing we just realized is that the sample I have posted takes way too long to load, even though it only has 2 components on it. So, there's nothing really major, but rather a collection of little things that are driving us away, for the moment. I'm still researching though, and we will have to make a final decision soon. DMANJULY 20 2006 @ 07:58 PMYeah, the learning curve from Flash to Flex I imagine can be quite a tuff one. I came from a J2EE / OOP background so Flex has been a natural fit for myself, but probably not so much if you don't have much expirience in those areas. Not saying you do or don't, just expressing more of an understanding on your situation. If this is a pretty nasty deadline for you, then you might want to go with Flash and try to make the Flex jump when you have more time. Flash to Flex can be a decent paradigm jump. But I promise you, once you make the jump and get through a few of the key concepts, Flex will save you massive amounts of dev time :) GL
DANIEL ROSENSTARKAUGUST 14 2006 @ 12:15 PMIt's true that extending components in Flex is VERY easy, and even if you're not going to override ANY behavior, it's nice because it keeps your code clean and organized. I have never worked with Flash directly, but with Flex development has been SO easy. Compared to what I do know of Client-side UI -- Microsoft Winforms and Java Swing -- Flex is much more comprehensible and nicer all around.
Sorry for rambling. My point: there is no multiple selection tree in Flex right now, and I also need it. Ironically, this was also the case with Winforms (.NET 1 and 2), and the answer was... build it yourself! That's right, coloring the backgrounds and doing the shift and control keys and the mouse clicks and all that stuff. In the next few weeks I'm going to give it a shot with Flex 2.0 and if I have any success I'll share my code. KOTOWSKYSEPTEMBER 11 2006 @ 06:51 PMHas anyone yet been able to implement the drag selection without Shift and Ctrl keys pressed in a List? Overriding methods of ListBase.as class did not seem to help. Thank you.
DANIEL ROSENSTARKSEPTEMBER 11 2006 @ 08:03 PMYou can implement ANYTHING you want in Flex but sometimes overriding is not enough. In that case -- don't try this at home -- take the original source code, throw it in a new package, and change it as you wish!
I'm doing this to get a multiple selection tree in Flex (just a question of turning that feature back on, as it was turned off in the beta), and it works perfectly. I did have to bring over several classes due to cross-class references, but it was just a few. Check out the results in http://kbase.confusionists.com/enterprise.html. It's free for the forseeable future. SVETOSLAV SOTIROVSEPTEMBER 30 2006 @ 09:55 AMBack to the original idea to Flex or not to Flex.
Offcourse you should Flex especially if you have an application to build. I'm sure there will be problems and probably you will have to extend some of components and yes you must have a good team of developers to be able to do so but no doubt Flex is a big step in the right direction. Even though we have our own Flash Framework : http://www.gugga.com/flashblog/ we are going to use Flex for certain type of jobs. I think the question is not to Flex or not the real question is when to Flex or not. JUSTIN WINTERMARCH 23 2007 @ 03:36 PMJust wanted to post an update that the buggy drag/drop tileList issues have been resolved in the 2.01 release. The DragProxy looks and behaves much nicer.
HAMZAAPRIL 19 2007 @ 10:38 AMPlease send me the source !!!
HAMZAAPRIL 19 2007 @ 10:38 AMPlease send me the source !!!
WHOLESALE REPLICA CHANEL SUN GLASSESJUNE 1 2007 @ 11:42 AMgood graphics although little too much
WHOLESALE REPLICA CHANEL SUN GLASSESJUNE 1 2007 @ 11:42 AMgood graphics although little too much
MATRIX SUN GLASSESJUNE 1 2007 @ 11:50 AMvery good graphics although little too much
CHEVROLET PICK UP TRUCKJUNE 1 2007 @ 11:56 AMnot bad graphics although little too much
7 HARRY POTTER PREORDERJUNE 1 2007 @ 12:01 PMlook it, good graphics although little too much
|
LANGUAGESARTICLES
BOOK REVIEWSSYNDICATIONFLASH
FLASH (ESPA�OL)
ADOBE
AGGREGATORS
USER GROUPS |
|



