Re: [ve-dev] VE 1.5 development plan

[yves.yang@xxxxxxxxxxx]

Hi Joe,
>
> The VE uses an EMF model internally, and can persist/load this without any
> Java source code.  The source code generation is done through adapters
> that listen to changes to the EMF model, which is what the UI gestures
> such as changing properties in the property sheet, dragging GEF objects
> around, etc... manipulate.  The .java file parsing creates the EMF model
> and also fills the adapters with pointers to source code elements to allow
> the meet in the middle type of re-geneation that is supported.
>
> It should be possible to read another persisted format, e.g. XSWT, and
> generate the VE's EMF model from this.  The AUIML visual builder did
> something similar to this, and then on save it turned everything back into
> its format (no need to incremental listening to the model which the Java
> VE uses).  It was always the intention that the VE's model could be
> persisted in formats other than .java files, and when the mobile tools
> project were looking at VE this is an area they were interested in
> pursuing.
>
Yes, exactly. We have already developed two XML UI editors based on VE.
One of them is XSWT (we'll contribute it in VE soon).

The issue we observed is the complexity. It is a good design for Java
based UI. But for other, it could be much simple. Precisely, the using of
JEM is not necessary with UI in XML.

Best regards
Yves YANG
----
Soyatec - http://www.soyatec.com
>
> yves.yang@xxxxxxxxxxx
> Sent by: ve-dev-bounces@xxxxxxxxxxx
> 08/07/2009 11:15
> Please respond to
> Discussions people developing code for the Visual Editor project
> <ve-dev@xxxxxxxxxxx>
>
>
> To
> "Discussions people developing code for the Visual Editor project"
> <ve-dev@xxxxxxxxxxx>
> cc
>
> Subject
> 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?
>
> 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
>
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
> _______________________________________________
> ve-dev mailing list
> ve-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ve-dev
>