Discussions

News: eFace 1.0.0 released: XAML/WPF in Java

  1. eFace 1.0.0 released: XAML/WPF in Java (6 messages)

    eFace is a XAML/WPF solution in Java. The first release is available for download now : http://www.soyatec.com/eface/installation/. This release includes an abstract UI library compatible with WPF, a XAML loader and SWT renderer. An XAML editor like XAMLPad is bundled in the package to simplify the developer's life in Eclipse. The entire package can be considered as a XAML platform in Eclipse for RCP Applications. eFace's main features include:
    • Full support of XAML syntax and semantic
    • Styling and templating
    • Layout system
    • Threading safe
    • Complete data binding mechanism
    • Collection view
    • Rich UI library
    Some webdemos are available: http://www.soyatec.com/eface/webdemo. The Web/Ajax renderer is scheduled by Q1 2008.

    Threaded Messages (6)

  2. SWT?[ Go to top ]

    I can't imagine a shop inside the enterprise needing to have coverage across WPF and SWT, I would imagine it would go one way or the other. If anything, I would think that it would lean towards Swing or JavaFX, but even then? I know there are SWF converters for XAML (frame by frame) but even then, I would think that any type of conversion would be looking towards a migration instead of interoperability, but then again I could be mistaken.
  3. Re: SWT[ Go to top ]

    I see there are two issues in your post:
    1. Interoperability
    2. XAML's Added-values for Java
    1. Interoperability between .NET and Java
    I can't imagine a shop inside the enterprise needing to have coverage across WPF and SWT, I would imagine it would go one way or the other.
    We think all modeling solution providers (UML, BPM, etc.) may have interest in this solution to generate directly executable application. With this solution, one generator can be used for both platforms.
    If anything, I would think that it would lean towards Swing or JavaFX, but even then? I know there are SWF converters for XAML (frame by frame) but even then, I would think that any type of conversion would be looking towards a migration instead of interoperability, but then again I could be mistaken.
    I think you are talking about the graphical aspect. In fact, GUI consists of several areas: Controls, graphic animation and documentations. Now right, we focus only on "Controls", which is used in general for EAI applications such as CRM, ERP. 2. XAML's Added-values for Java At present, there is always a question to ask when you start a Java application: which technology to use for GUI? There are two categories: Desktop and Web. For Desktop, you have obviously two choices: SWT and Swing (including JavaFX). For Web application, there are a lot of possibilities: Struts, JSF, Ajax, Flex, GWT etc... You may be lost in this huge list. Once your decision is made, all others factors will be fixed around this technology: the team composition, development tools and the deployment environment . It is very heavy to rollback afterwards. So this decision is critical for the entire life of the application. So what's wrong? The answer is simple: an abstract and generic UI solution is missing in the Java world. This is our main goal. With eFace, you can start your application in the simplest environment in terms of GUI, for example SWT or Swing. At this stage, you can focus your energies on your domain logic. The decision of the final GUI solution can be made at the deployment time.
  4. Re: SWT[ Go to top ]

    Hi Yves. I see your point, however, I personally don't see how practical interoperability is, mostly in terms of uptake. I would think, that even in a shop that is solely dedicated to Java on the backend, that the front end desktop technology would lean more towards either a straight Eclipser RCP solution, or NB Rich Client, or JavaFX, or something else that is Swing based (Spring, etc). If not, then some other platform such as Flex, or WPF directly, either through MS Expression/XBAP or Silverlight. The reason I bring this up is that the front end is usually decided upon and fixed without a need to interop at the level of generic UI specification as in UML or BPM. As for the value add, I definitely agree, it is missing, however, I still don't find it personally compelling. If I were looking at XAML, I would stick with a WPF based front end. I guess it would be intriguing to be able to do the same code behind techniques as one can in C#, but still, it seems that for the desktop Java space JavaFX is closer to the right tool for the job. Last point, I guess I would be more enthusiastic about the interop if there was something I'm obviously missing about the compelling need someone would have to be able to define the front end UI in XAML and generate multiple clients off of it.
  5. Re: SWT[ Go to top ]

    Hi Yves. I see your point, however, I personally don't see how practical interoperability is, mostly in terms of uptake.
    The interoperability is a huge subject. It touches several aspects such as programming language, UI presentation, persistence, behavior services, etc. It cannot be resolved in one product. eFace contributes only on UI aspect.
    I would think, that even in a shop that is solely dedicated to Java on the backend, that the front end desktop technology would lean more towards either a straight Eclipser RCP solution, or NB Rich Client, or JavaFX, or something else that is Swing based (Spring, etc). If not, then some other platform such as Flex, or WPF directly, either through MS Expression/XBAP or Silverlight. The reason I bring this up is that the front end is usually decided upon and fixed without a need to interop at the level of generic UI specification as in UML or BPM.
    We had experienced the same problem several years ago with database. We worked directly with a specific database through SQL. Nowadays, we take in general the generic persistence layer framework such as Hibernate, JPA, JDO and SDO to make the application independent. It is (will be) the same with UI.
    As for the value add, I definitely agree, it is missing, however, I still don't find it personally compelling. If I were looking at XAML, I would stick with a WPF based front end. I guess it would be intriguing to be able to do the same code behind techniques as one can in C#,
    eFace is Java solution. It implements only the UI abstract library same as WPF, which is necessary for our XAML loader. You develop your application as usual in Java.
    but still, it seems that for the desktop Java space JavaFX is closer to the right tool for the job.
    From my prospective, JavaFX is a good product for developer. But I wonder how it could be used by UI designers because of the programming language. The integration with visual tools isn't straight forward as XAML, which is one of the key benefits of the separation between UI and business logic.
    I guess I would be more enthusiastic about the interop if there was something I'm obviously missing about the compelling need someone would have to be able to define the front end UI in XAML and generate multiple clients off of it.
  6. Perfect example..[ Go to top ]

    eFace is a XAML/WPF solution in Java.
    This is a perfect example of the kind of news items that were supposed to be discouraged by "our humble editors" as per discussions couple of weeks ago. I don't have a glue what these acronyms mean, or what the software does. I can only add one more acronym: WTF. /Henri Karapuu
  7. RE: Perfect example..[ Go to top ]

    Hi henri,
    This is a perfect example of the kind of news items that were supposed to be discouraged by "our humble editors" as per discussions couple of weeks ago.
    Obviously, I have a lot to learn. I don't know why it should be discouraged. I appreciate if you can give some more indications. Yves YANG