Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ve-dev] VE 1.5 development plan

Hello,
 
So wait are you going to create library on top of swing that will load XML files and create the ui from them?
Or are you going to make an XML that the ve edits and generates the ui code from that?
The only issue with the second approach is editing java gui files from other programs.

On Wed, Jul 8, 2009 at 12:00 PM, <yves.yang@xxxxxxxxxxx> wrote:
> 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:

In eclipse, you can use Local history to come backt o previous version or
use CVS/SVN.

yves
>
>>  Yet the problem is if a desync happens or you lose one of the files
>> will
>> you be able to continue work?
>> 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
>


_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev


Back to the top