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

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:
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
_______________________________________________


Back to the top