Re: [ve-dev] VE 1.5 development plan

[Joe Winchester <WINCHEST@xxxxxxxxxx>]

Hi,

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.

Best regards,

Joe

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