Re: [ve-dev] VE 1.5 development plan

[yves.yang@xxxxxxxxxxx]

> Well the gui code should also exist in the .java file but not really used,
> except for compiling and as a backup in case the XML file becomes lost.
> It can also be used as a cache to speed up initial loading of the editor
> (not recreating the code from scratch every time, but thats a bit desync
> prone so it really requires good code that wont cause such desync and if
> it
> does happen what i said in my previous mail still stands:

The Decalraation UI has a major feature is the abstraction: the separation
of the UI specification and UI technology. It doesn't make sense to keep
Java UI.

>> Yet the problem is if a desync happens or you lose one of the files
>> will
>> you be able to continue work?

The desync and lost are issue of development environment or tooling. They
are not part of design or architecture.

yves
>> If you do than that approach works very well.
>> Basically it means being able to restore either one of the files from
>> the
>> other one. (Including complete user code (events and such) (If possible
>> making it handle any .java not just ones originally made by the ve)
>> It shouldn't be to hard to achieve (At least the Different file to .java
>> part :P)
>>
>> Better yet is to prevent desyncs in the first place and if they do
>> happens
>> fix them automatically.
>>
>> One of the problems i saw in many editors was that they only handle
>> files
>> that were created in them.
>> Since most of the GUI code i saw was made by hand or with a different
>> editor it makes them quite pointless unless for projects that you make
>> sure
>> everybody use the same one or for once made solely by yourself.
>>
>> Im quite sure you will be able to do it well, and not give us some data
>> loss inducing piece of software :P.
>
>
> On Tue, Jul 7, 2009 at 10:05 PM, Eric Clayberg
> <clayberg@xxxxxxxxxxxxxxxxxx>wrote:
>
>>
>> Making an extra file to store the gui in (like netbeans does) is bad if
>>> that file goes out of sync or is lost that .java file basiclly becomes
>>> useless.
>>>
>>
>> I hope what they mean is to use XML to represent the GUI as a complete
>> alternative to Java and not have two files (XML and Java) representing
>> the
>> same thing. The former can work, but the latter is downright dangerous
>> as is
>> the case with NetBeans. One of the basic principles of data
>> normalizations
>> is that it is always a bad idea to have two data structures (or two
>> files)
>> represent the exact same thing. That is a recipe for disaster as they
>> will
>> always get out of sync eventually or the primary file (the XML .form
>> file in
>> the case of NetBeans) will always get lost.
>>
>> I am not against the idea of delarative ui, im only against what
>> netbeans
>>> gui desginer does (That extra .form file that sometimes goes out of
>>> sync or
>>> is lost and leaves you stuck)
>>>
>>
>> The NetBeans GUI builder is quite primitive under the covers (with a
>> very
>> sexy exterior) as it can't even parse its own generated Java code. That
>> makes its reliance on .form files particularly dangerous. We have
>> rescued
>> many dead-in-the-water NetBeans projects with WindowBuilder's ability to
>> both read and write the NetBeans GUI style.
>>
>> Regards,
>>
>> -Eric Clayberg
>>  Sr. Vice President of Product Development
>>  Instantiations, Inc.
>>  mailto:clayberg@xxxxxxxxxxxxxxxxxx
>>  http://www.instantiations.com
>>  Eclipse Productivity. Enterprise Quality.
>>
>>  Author: "Eclipse: Building Commercial Quality Plug-ins"
>>  http://www.awprofessional.com/title/032142672X
>>  Author: "Eclipse Plug-ins"
>>  http://www.awprofessional.com/title/0321553462
>> _______________________________________________
>>  ve-dev mailing list
>> ve-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ve-dev
>>
> _______________________________________________
> ve-dev mailing list
> ve-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ve-dev
>