>> Hello,
>>
>> So wait are you going to create library on top of swing that will load
>> XML
>> files and create the ui from them?
>
> Look at e4 XWT or
http://www.soyatec.com/eface. Or there is another
> project named as XSWT:
http://sourceforge.net/projects/xswt/>
>> Or are you going to make an XML that the ve edits and generates the ui
>> code
>> from that?
>
> In this mode, VE will edit directly UI in XML. The render will take care
> of the display. It will not deal with UI in Java.
>
>> The only issue with the second approach is editing java gui files from
>> other
>> programs.
>
> I think you are not familiar with Declarative UI. Please take a look on
> the products I mentioned above, it will help you to get in a new paradise.
>
> yves
>>
>> 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>>>
>> _______________________________________________
>> 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@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/ve-dev
