Hello,
  totally agree with you, Eric.
I use equally both AS and DV to create apps and I don't try to convince people 
that one way is "better" than the other one. Both are useful.
The extra work needed to maintain DV may not match the benefits for now, but it 
will be needed at some point to compete with other technos.



JC Lang


>________________________________
> De : Eric <eh.fx...@gmail.com>
>À : dev@flex.apache.org 
>Envoyéle : Mercredi 4 septembre 2013 19h33
>Objet : Re: UI Designer ("Design View" replacement)
> 
>
>I wasn't really trying to start a discussion on the merits or use of DV, 
>but I don't mind.
>
>I've heard this sentiment before and we'll just have to agree to 
>disagree.  I've been a Flex dev since just before version 3, so I hope 
>I'm worth SOME salt. Everyone that I have worked with, although less 
>advanced, has used design view for complex layouts.  I've used custom 
>components with it as well, and never expect them to work 100% correctly 
>- the main point of DV was to do the component positioning & sizing.  I 
>use DV sometimes to locate a component in code or to rename the ID of a 
>component (click on comp in DV, go back to source and it moves you to 
>the line of the tag).
>
>I suspect we're using the feature differently, or for different types of 
>projects. I use bindings, but rarely use custom events, and I know our 
>apps run great on some rather bogged down PCs.  For a mobile project or 
>even most web projects, since they tend to have simpler UIs, DV may not 
>have much value.  I rarely use the "advanced" DV features, but DV is 
>essential to me to allow for rapid form layout/prototyping and efficient 
>changes to very complex screens.  I use the snap and align features 
>quite a bit too, although it is fussy until you get used to it.  I'm 
>100% certain it increases my productivity.
>
>Where I work, sometimes our users have an operational need to have lots 
>of "stuff" visible at once.  Often these pages are buried inside the 
>application.  Repeatedly tweaking size and position from code, and then 
>running the app would have taken far too much "drilling down" into the 
>application workflow to be productive.  Honestly, I can't imagine how 
>certain apps could be developed productively otherwise.  There could be 
>20 or 30 fields/labels with datagrid(s), buttons, etc. and there's 
>simply no way to redesign the UI to get around it without slowing the 
>users down or confusing them.  The dynamic UI stuff just wouldn't work 
>for our apps, and it tends to confuse or annoy based on feedback; I only 
>make use of it under special circumstances.
>
>So I don't know, I guess there will always be two camps here.  But don't 
>forget that quite a few competing SDKs have such design tools. 
>ExtJS/GWT and GWT come to mind here.
>
>-Eric
>
>On 9/3/2013 10:30 PM, Nick Collins wrote:
>> I would respectfully disagree. Every Flex engineer worth their salt that I
>> have ever worked with dumped the design view after about week 3 of learning
>> Flex.
>>
>> Typically after that point when you start integrating your code with real
>> live data sources that are driving your UI the design view rapidly becomes
>> worthless. You start drawing your UI dynamically based on the data that is
>> provided, learn that the demos they do with data binding will never be used
>> in the real world because of the performance hits you get by just putting a
>> [Bindable] on everything without custom events tied to them, etc. and the
>> design view would just fall apart with those real world scenarios.
>>
>>
>> On Tue, Sep 3, 2013 at 8:58 PM, Eric <eh.fx...@gmail.com> wrote:
>>
>>> I wasn't able to find anything recent about a UI design tool for Apache
>>> Flex.  There seemed to be some discussion of this awhile back, but how far
>>> did it get?  Are there any links to a project or source?  Sorry if this has
>>> been brought up 100 times already.  I think a tool like this will be
>>> crucial (in "the enterprise space") to help power the widespread adoption
>>> that Falcon will hopefully bring.
>>>
>>
>
>
>
>

Reply via email to