2 Replies Latest reply on Apr 10, 2009 10:08 AM by jim1234

    Simplified interface

    jim1234 Level 1

      LiveCycle has tons of features and is very flexible.  As a result the Workbench is very crowded, with tons of tabs, information, fields, etc.  I find that with many of the properties I have no idea what they are for or what the repercussions of changing a value might do.  There is simply too much information with names that don't mean anything such as "Application web root" or "Target URL" or "Content Root URI" or "XPath expressions".  I've worked some in web applications with these concepts but I have no idea how they relate to LiveCycle or what LiveCycle will do with the information.


      In other words I'm finding LiveCycle Workbench some what difficult to use.


      It would be really nice if you could have "basic" properties with more english type terms for the most common properties and hide the more advanced properties unless requested.  Also it would be nice to have some sort of wizard to walk you through the basics of setting up a process.  Trying to figure out how to create the xpath expressions to pass data between process nodes I find rather esoteric as well.  Variable types are somewhat bewelidering as well like what is the difference between form and xfaForm and why should you use one over the other?  There needs to be a simlified version of all this for all the standard types of operations.  I even find it a little hard trying to figure out what service to use for what I want to do.


      I find the same sort of issues with the Java API.  Many of the classes are very complex and creating the client to comsue the web service or Java class can be difficult as well.  Many return complex types such as multi dimensional arrays.  It's hard trying to map all these data types with clients that are not java based.  Also, many times you only need one piece of information, but the webservice returns all kinds of stuff so you have to create your client to be compatible with a lot of stuff you don't need.  There should be a simplified set of classes that returns the most common information so you don't have to create such complex clients.


      If I'm incorrect in any of this, please let me know.


      Any thoughts?



        • 1. Re: Simplified interface
          MarcelBoucher Adobe Employee



          Actually, we hear you loud and clear. We are currently working on the next version of LiveCycle ES and one of the main focus areas is usability of Workbench, Designer and Flex Builder around building LiveCycle applications. We will be hosting a beta later this summer, I will be posting details about the beta on this forum once we are closer to that date.


          We have made A LOT of changes in the property pages and have dramatically simplified the steps required to render and submit forms.


          I totally agree with you in regards to the Java APIs. However, we have not targeted the Java API to improve usability in the next release. Actually, we strongly believe that Rich Internet Applications is a major differentiator for LiveCycle ES. To that end, we have also dramatically improved the integration of Flex Builder and LiveCycle ES. For example, we have automated the generation of data type handling classes and proxy classes to communicate with a LiveCycle ES server. Unfortunately, this does not help you in the Java API scenario. Maybe, we could create a sample Java framework that would provide helper classes that you could use?

          • 2. Re: Simplified interface
            jim1234 Level 1

            Classification:  UNCLASSIFIED

            Caveats: NONE


            Thanks for the reply.  I think LiveCycle has a lot of potential, but a streamlined interface would really help.


            As to the Java API, some sort of helper classes for the Java classes would probably do.  You could leave all the current classes as is and simply add a simplified layer that calls the current classes but would return simplified values.


            I noticed that there is a set of helper classes on riaforge, do those essentially try to accomplish this?


            One more nice feature would be to have datasource configuration through the adminui.  I had to figure out how to add datasources to JBoss in the xml file for this.  Then I had to read that you have to add the java:/ in front of the datasource name in the JDBC node in Workbench.  Took a little time to figure it all out.