Re: Ask TSS: Resource based GUIs vs. Code Generation Go to top ] Posted by: Kit Davies

Posted on: November 29 2006 16:13 EST

in response to Jack Rosenzweig Well, I think the reason it is the way it is, is that all the Java money went server-side, J2EE, etc. Plenty of investment in JSP, JSF and other templating technologies for web-based stuff. Swing GUIs became a bit passe. I see a slight change though as people get bored with plain HTML and want RIAs. If it isn't AJAX in the browser then I suspect that there is a fairly large minority of Java client apps whose GUI is built using some kind of declarative language. There are quite a few options now such as SwiXML and Thinlets. Personally I'd like to see such a feature for Eclipse, or Spring RCP. Kit Reply to this Reply to original

Who needs code generators anyway? Go to top ] Posted by: Peter Looyenga

Posted on: November 30 2006 12:03 EST

in response to Kit Davies Java is a very modulair build language which makes it ideal for basicly grouping these building blocks together and thus forming a GUI, no need to re-generate the same code over and over again IMVHO. Just put the right "blocks" together. The Bean Builder is IMO a very good example of that. Another example, to a certain degree, is given by the NetBeans Swing GUI Builder which is formerly known as Project Matisse. It basicly generates the entire method which creates the GUI and defines all of its listener methods and allows you to insert your own code in every method invoked by an event triggered by the GUI. So while I do agree that these kind of code generators are scarce I seriously wonder if we actually need them. IMO all you need are good building blocks. Reply to this Reply to original

Re: Who needs code generators anyway? Go to top ] Posted by: James Watson

Posted on: November 30 2006 12:32 EST

in response to Peter Looyenga So while I do agree that these kind of code generators are scarce I seriously wonder if we actually need them. IMO all you need are good building blocks. I think you missed the point here. No one said the generators are scarce. The point of the post was that they are too prevalent. What I don't understand is why people will go to all the effort to write a generator to write code that will build a gui at runtime. Why not just go one step further and write code that builds a gui at runtime based on structured input? It's not much harder and it's much more useful. I think you missed the point here. No one said the generators are scarce. The point of the post was that they are too prevalent. What I don't understand is why people will go to all the effort to write a generator to write code that will build a gui at runtime. Why not just go one step further and write code that builds a gui at runtime based on structured input? It's not much harder and it's much more useful. Reply to this Reply to original

Resources are crap! Go to top ] Posted by: Gili _

Posted on: December 01 2006 09:52 EST

in response to Kit Davies I can't believe you are honestly trying to push GUI code into cryptic XML files or VC++ style resource files. Do you know how happy I am we *don't* have that kind of crap in Java? Ever try diffing two GUI resource files? It's a nightmare. Code generators are smart because at least you get type safety (compile-time checking) and they're easier to DIFF. The only thing that might require some improvement is more flexibility to insert user code around generated code and/or making generated code look a bit nicer. Aside from that I honestly don't see what your complaints are :) Just my 2 cents. Gili Reply to this Reply to original

Re: Resources are crap! Go to top ] Posted by: James Watson

Posted on: December 01 2006 11:41 EST

in response to Gili _ I can't believe you are honestly trying to push GUI code into cryptic XML files or VC++ style resource files. Do you know how happy I am we *don't* have that kind of crap in Java? Ever try diffing two GUI resource files? It's a nightmare.



Code generators are smart because at least you get type safety (compile-time checking) and they're easier to DIFF. The only thing that might require some improvement is more flexibility to insert user code around generated code and/or making generated code look a bit nicer. Aside from that I honestly don't see what your complaints are :) Just my 2 cents.



Gili If the generator wrote a simple 'script' and not a ton of classes, I might be OK with it. The problem is that it's not nearly as flexible as creating a document that describes the gui. That structure can then be rendered as needed in (theoretcially) any language and gui framework, even AJAX, perhaps. That would be a more complicated task than what I'm really imagining but you still get a good amount of flexibility even if it's Swing specific. As far as diffs are concerned, XML can sometimes be hard to diff because it's often munged onto a single line and the order of same type siblings is not significant. I've resolved these issues in the past with a pretty printer that sorted such siblings prior to running a diff. If the generator wrote a simple 'script' and not a ton of classes, I might be OK with it. The problem is that it's not nearly as flexible as creating a document that describes the gui. That structure can then be rendered as needed in (theoretcially) any language and gui framework, even AJAX, perhaps. That would be a more complicated task than what I'm really imagining but you still get a good amount of flexibility even if it's Swing specific. As far as diffs are concerned, XML can sometimes be hard to diff because it's often munged onto a single line and the order of same type siblings is not significant. I've resolved these issues in the past with a pretty printer that sorted such siblings prior to running a diff. Reply to this Reply to original

swixml is nice... Go to top ] Posted by: anti neuron

Posted on: November 29 2006 18:34 EST

in response to Konstantin Ignatyev but i found that in the end you just move your bugs to the much harder to debug xml file. What is really needed is a wysiwyg editor, a bindings language and a hierarchical component model of those gui-xmls (think of parameters for xml components) Don't know about vista but Interface Builder has been around for so many years and it still provides a so much better experience than anything on the pure java side. apple has stopped to support their cocoa-java gui framework that was using Interface Builder on top of Swing-subclasses. Technologies like Webobject's direct-to-java (the cousin of direct-to-web) and Enterprise-Objects (with client side code and properties) never got enought attention. Reply to this Reply to original

BuoyBuilder for resource-based GUIs Go to top ] Posted by: Jonathan Duty

Posted on: November 29 2006 21:55 EST

in response to anti neuron What is really needed is a wysiwyg editor, a bindings language and a hierarchical component model of those gui-xmls (think of parameters for xml components) You should check out BuoyBuilder (www.buoybuilder.com). It also serializes its components to XML, but provides both a layout tool to design your GUI using drag and drop and a document loader that actually loads the GUI from XML and, at runtime, dynamically attaches it to your controller. The layout tool also has the ability to dynamically register callback methods for events so your controller doesn't have to implement ActionListener interfaces and inspect events. It also includes goodies like automatic localization, extended layout managers, and the ability to incorporate custom widgets. From reading some of the posts the creators modeled it after Apple's Cocoa and Interface Builder. You should check out BuoyBuilder (www.buoybuilder.com). It also serializes its components to XML, but provides both a layout tool to design your GUI using drag and drop and a document loader that actually loads the GUI from XML and, at runtime, dynamically attaches it to your controller. The layout tool also has the ability to dynamically register callback methods for events so your controller doesn't have to implement ActionListener interfaces and inspect events. It also includes goodies like automatic localization, extended layout managers, and the ability to incorporate custom widgets. From reading some of the posts the creators modeled it after Apple's Cocoa and Interface Builder. Reply to this Reply to original

Web Application Go to top ] Posted by: Luca Garulli

Posted on: November 30 2006 05:12 EST

in response to Jack Rosenzweig Romaframework uses the MDA approach: create your domain object model and plug the other aspects. Current release of Roma generates the GUI as Web Application (100% Ajax, using Echo2 rendering engine). The GUI is generate automagically reading your domain POJOs. CRUD are generated by the Wizards (code generator). Customization of generated HTML is done by annotations in classes and by editing the stylesheet. Ciao, Luca Garulli AssetData.it Reply to this Reply to original

I don't agree Go to top ] Posted by: Holger Engels

Posted on: November 30 2006 09:21 EST

in response to Jack Rosenzweig The controller code should be completely independent of the GUI code, and not be hampered in any way by the tool that generates the GUI. Controller code is never independent of the GUI! Its only purpose is to control the GUI. The manipulations, one can make to the GUI, which do not affect the controller code, are really minor. There is no single reason, why controller code should not depend on the GUI! Things that will make GUI coding more efficient are: o Usage of meta information from the business model o An intelligent data binding mechanism o Inheritance Ideally, you have a mechanism, that accumulates meta information from different sources: o Reflection (properties and their types, enums, primitives are not nullable) o OR- Mapping if applicable (nullability, precision, scale, length, relations) o Annotations (format, validation) o Authorization o Localization .. and automatically utilizes them, when building the UI. We've made good experience with this approach in our Controller code is never independent of the GUI! Its only purpose is to control the GUI. The manipulations, one can make to the GUI, which do not affect the controller code, are really minor. There is no single reason, why controller code should not depend on the GUI! Things that will make GUI coding more efficient are: o Usage of meta information from the business model o An intelligent data binding mechanism o Inheritance Ideally, you have a mechanism, that accumulates meta information from different sources: o Reflection (properties and their types, enums, primitives are not nullable) o OR- Mapping if applicable (nullability, precision, scale, length, relations) o Annotations (format, validation) o Authorization o Localization .. and automatically utilizes them, when building the UI. We've made good experience with this approach in our OSBL Reply to this Reply to original

Independent controller definition Go to top ] Posted by: Jonathan Duty

Posted on: November 30 2006 10:18 EST

in response to Holger Engels Controller code is never independent of the GUI! Its only purpose is to control the GUI. The manipulations, one can make to the GUI, which do not affect the controller code, are really minor. There is no single reason, why controller code should not depend on the GUI! I think the definition an "independent controller" is getting misunderstood. Correct, the controller should receive events from the GUI, process them and update accordingly. However, the Controller should not be concerned with laying out the GUI, localizing it, or even the structure of it. Once your controller starts doing that, it really because an extension of the view. I think the definition an "independent controller" is getting misunderstood. Correct, the controller should receive events from the GUI, process them and update accordingly. However, the Controller should not be concerned with laying out the GUI, localizing it, or even the structure of it. Once your controller starts doing that, it really because an extension of the view. Reply to this Reply to original

Re: Ask TSS: Resource based GUIs vs. Code Generation Go to top ] Posted by: James Watson

Posted on: November 30 2006 11:06 EST

in response to Erik van Oosten This is a very good question given that Swing is completely designed for dynamic gui generation. Using it to hard code guis makes very little sense. Honestly, I think it comes down to a lack of imagination. It's not confined to this topic. Take the 'pojo' revolution. It's really the JavaBean revolution and JavaBeans are IMHO, the worst idea ever introduced into Java. I don't know exactly who came up with it but they must have confused Java with SmallTalk. Hibernate and Swing work with objects that act as hard-coded maps with all the problems of map based design and almost none of the flexibility. It's beyond stupid that adding a new query to a system starts with 'write a class with getters and setters'. It's the same thing as with Swing, let's take something flexible elegant and dynamic and cut-off it's legs with 10,000 lines of code. It's become the Java MO. Sorry to get off-topic here but I needed to get that off my chest. Reply to this Reply to original

The client side is not just GUI Go to top ] Posted by: S. Yayla

Posted on: November 30 2006 11:30 EST

in response to Jack Rosenzweig The client side is not just GUI. This is the one thing that is easy to loose out of sight. If you think of the typical business system as a channnel of communication between the database and the user, the server side acts as a proxy between the database and the network, while the client side acts as a proxy between the user and the network. This should remind us that objects handled by the program logic are as complex either side. It is at this point that the biggest basic failure of user side designs materialize. This is also why code generators become a problem, resource based GUI engines stay relatively unknown, and practically every major project choses to hand code their user side once again, inventing their own resource schemes, sometimes also GUI frameworks. The problem becomes clearest when you consider complicated objects that for example are finite state machines. For each significant state, the significant attributes, and the possible state transitions one needs mechanisms to communicate, check, remmber, bookkeep, apply business logic, show, and react to user inputs. In this picture, the GUI specific code takes care of the verbs 'show' and 'react'. The client specific code is, in addition to the GUI specific, possibly the business logic. The rest is essentially similar to the server side. Out of the whole the 'show' and 'react' bit is essentially a thin layer between the GUI library (SWING, SWT, Motif, etc..) and the business objects handled. The client is actually a server (remember X-server?) serving reactions from the user as the database side (serveside) requests them. It also has a model of the users point of view (Window/Display manager). It desperately wants to be asynchronous just like the user. Most tools, platforms, techniques that are supposed to help building GUI's, clients, user side applications only help at parts of this big picture. In my opinion this is the problem. The code generating GUI tools falls short because widgets/subpanels are shadows of the objects, not the other way. The resource based GUI tools are useful but not fully so because objects of the business often can not be fully described with them. Reply to this Reply to original

Re: The client side is not just GUI Go to top ] Posted by: James Watson

Posted on: November 30 2006 11:37 EST

in response to S. Yayla In my opinion this is the problem. The code generating GUI tools falls short because widgets/subpanels are shadows of the objects, not the other way. The resource based GUI tools are useful but not fully so because objects of the business often can not be fully described with them. I'm not sure I follow but it seems to me that the entire swing architecture could easily be described with an XML schema which could then be used to script GUI construction. Can you give an example of something that could not? The Action class (often overlooked) could be used to link the GUI to the code. The big problem I've seen in GUIs is that they have hard references to business processes at best and at worst they actually have business logic embedded in the code. I'm not sure I follow but it seems to me that the entire swing architecture could easily be described with an XML schema which could then be used to script GUI construction. Can you give an example of something that could not? The Action class (often overlooked) could be used to link the GUI to the code. The big problem I've seen in GUIs is that they have hard references to business processes at best and at worst they actually have business logic embedded in the code. Reply to this Reply to original

Re: The client side is not just GUI Go to top ] Posted by: S. Yayla

Posted on: November 30 2006 19:20 EST

in response to James Watson In my opinion this is the problem. The code generating GUI tools fall short because widgets/subpanels are shadows of the objects, not the other way. The resource based GUI tools are useful but not fully so because objects of the business often can not be fully described with them.



I'm not sure I follow but it seems to me that the entire swing architecture could easily be described with an XML schema which could then be used to script GUI construction. Can you give an example of something that could not? The Action class (often overlooked) could be used to link the GUI to the code. The big problem I've seen in GUIs is that they have hard references to business processes at best and at worst they actually have business logic embedded in the code. I agree that you can do quite a lot of useful things. The problem that I am pointing at remains. "Action class .. to link the GUI to the code" illustrates it neatly. What you call "code" is the sunken part of the iceberg. It is a bit too big and support is only partial. Examples are custom widgets to represent your complicated objects by specifying their looks and behaviours in XML in such a way that you can connect these to details of messages to and from the database side with a minimum of custom code. Most tools leave slightly complicated things to yourself. The business of the database side is to keep, and watch the books/intelligence of the company. The business of the user side is to present these to, and maintain the dialogue with the user in perfect cognitive ergonomy. Mixing the business rules of one, into the logic of the other is likely to have a delayed cost. May be I should have written "-user side- business logic". I agree that you can do quite a lot of useful things. The problem that I am pointing at remains. "Action class .. to link the GUI to the code" illustrates it neatly. What you call "code" is the sunken part of the iceberg. It is a bit too big and support is only partial. Examples are custom widgets to represent your complicated objects by specifying their looks and behaviours in XML in such a way that you can connect these to details of messages to and from the database side with a minimum of custom code. Most tools leave slightly complicated things to yourself. The business of the database side is to keep, and watch the books/intelligence of the company. The business of the user side is to present these to, and maintain the dialogue with the user in perfect cognitive ergonomy. Mixing the business rules of one, into the logic of the other is likely to have a delayed cost. May be I should have written "-user side- business logic". Reply to this Reply to original

Re: The client side is not just GUI Go to top ] Posted by: James Watson

Posted on: December 01 2006 09:29 EST

in response to S. Yayla I agree that you can do quite a lot of useful things. The problem that I am pointing at remains. "Action class .. to link the GUI to the code" illustrates it neatly. What you call "code" is the sunken part of the iceberg. It is a bit too big and support is only partial. I don't follow you here. A GUI framework need not and should not support the core logic of the application. Examples are custom widgets to represent your complicated objects by specifying their looks and behaviours in XML in such a way that you can connect these to details of messages to and from the database side with a minimum of custom code. Most tools leave slightly complicated things to yourself. How is that worse than leaving everything to yourself? It seems to me that a good XML gui builder framework should support custom components instead of trying to do everything for you. This 'you don't have to think' approach to tool design drives me nuts and is the norm. Perhaps that is the issue you have run into. The business of the database side is to keep, and watch the books/intelligence of the company. The business of the user side is to present these to, and maintain the dialogue with the user in perfect cognitive ergonomy. Mixing the business rules of one, into the logic of the other is likely to have a delayed cost. May be I should have written "-user side- business logic". You've lost me. I don't know what this has to do with drawing a gui on the screen. Maybe I'm not being clear. I don't follow you here. A GUI framework need not and should not support the core logic of the application.How is that worse than leaving everything to yourself? It seems to me that a good XML gui builder framework should support custom components instead of trying to do everything for you. This 'you don't have to think' approach to tool design drives me nuts and is the norm. Perhaps that is the issue you have run into.You've lost me. I don't know what this has to do with drawing a gui on the screen. Maybe I'm not being clear. Reply to this Reply to original

Re: The client side is not just GUI Go to top ] Posted by: David Rozenberg

Posted on: December 06 2006 17:55 EST

in response to James Watson What are we talking about? Looking at all this discussion, I would like to ask this simple question - how much of guis do you need for your application and how complex should they be? From my personal experience, user interface in most cases is very simple and requires a very short list of fields with respective input from the user. In that case what you call a resource based gui is much more preferrable and easy to implement. The burden of bundling code with a gui form has a long history (starting from 1977 when the first work on dialogue generators was published). Smalltalk-80 also added to it. Projects like Thinlet are targetted in the right direction. I am not sure you need XML (with the burden of its parsing and conversion to XML) for describing the gui forms or resources. It can be done with much more primitive mark-up. The advantage of separating resources or dialogue forms from code that deals with presenting them to the user is not new in its essence. It was used starting from 1978 for building user interfaces on various hardware/software systems. Simply this work is not known to the Western software community just because it was done in Russia. There were a lot of comments about Struts as the nice way of building web applications. Don't you think that it is too heavy for them? There is a lot of statements that those frameworks utilize MVC, but nobody realizes that MVC is much more than just a pattern for guis. Reply to this Reply to original

Craft by Hand Go to top ] Posted by: Jason Hatton

Posted on: November 30 2006 15:35 EST

in response to Jack Rosenzweig I have had a lot of experience with GUI work (including GASP!! Visual Basic). On my latest project though we have been building a GUI using Swing and the JGoodies libraries. The binding library supports Martin Fowler's Presentation Model . The Forms library has a nice layout manager called FormLayout that has a very simple descriptor language. I have to say after doing VB development I much prefer developing with these Java tools over the drag and drop method even VB provides. You have more control over your code and it produces very nice looking GUIs. I think it's even possible to develop more functional feature rich apps like this over anything a drag and drop or a xml describe method can provide. Before the project started we reviewed a couple of Java layout tools and none of them cut the mustard. The most common problems were: 1. They only handled the simpler problems GUIs tackle. 2. They couldn't handle odd user requirements. Like dissimilar object graphs that needed to be joined together into the same view or grabbing values that are only related to the object graph during the user's session. 3. Inefficient code was generated. 4. Aesthetically the screens didn't look nice and trying to tweak the descriptor (i.e. XML) language either wasn't possible to make it look nice or produced other undesirable effects. I think most people who speak up about rich GUIs are already biased against them because the Web has become the bread and butter for most. There is however still a need for rich clients for things like high volume data entry. I have seen data entry people make even native clients look like them perform badly. Reply to this Reply to original

Re: Craft by Hand Go to top ] Posted by: James Watson

Posted on: November 30 2006 16:31 EST

in response to Jason Hatton You have more control over your code and it produces very nice looking GUIs. I think it's even possible to develop more functional feature rich apps like this over anything a drag and drop or a xml describe method can provide. Are you proposing that there are Swing object graphs that cannot be represented in XML or something else? Are you proposing that there are Swing object graphs that cannot be represented in XML or something else? Reply to this Reply to original

GWT solution Go to top ] Posted by: Jeff Dwyer

Posted on: November 30 2006 16:17 EST

in response to Jack Rosenzweig I've been working on a project in the Google Web Toolkit for the past couple months and I've enjoyed how these problems are dealt with. While it is a web tech, programming GWT feels just like programming Swing/SWT code. It's very impressive. Better yet, after it's compiled to javascript it's styled with CSS. It's not perfect, but you can make a lot of design/layout decsions without touching a line of code. Obviously this is a web tech so some things are different, but having a css-esque layer for swing to take care of positioning/alignment/etc would be appealing to me. Reply to this Reply to original

Re: Both are needed Go to top ] Posted by: James Watson

Posted on: December 01 2006 13:06 EST

in response to Paul Casal Code generation has been pretty useful and met considerable success in the Java world. I've seen very few cases where it was really needed and it almost always hamstrung me where it was used. It introduces that additional level of indirection that shields your code from the platform/s it'll eventually run. How does code generation shield your code? I've seen very few cases where it was really needed and it almost always hamstrung me where it was used.How does code generation shield your code? Reply to this Reply to original

XML won't help Go to top ] Posted by: Karl Banke

Posted on: December 03 2006 07:12 EST

in response to Jack Rosenzweig The core problem here is that still even more GUI builders for Java suck. And the idea of making it run time configurable using XML is even more sick, IMHO. Apple (or rather next step) has shown how to build guis easily using graphical tools years ago. The one thing that is needed desperately to be really productive is not the storage anyway (Netbeans can serialize the objects anyway), the problem is that there is no standard, high quality application model in the Java Space. Also, of course, "standard" java still misses some standard (non graphical) components one would need to be really effective using this approach. Reply to this Reply to original

Re: XML won't help Go to top ] Posted by: Paul Beckford

Posted on: December 03 2006 11:59 EST

in response to Karl Banke The core problem here is that still even more GUI builders for Java suck. And the idea of making it run time configurable using XML is even more sick, IMHO. Apple (or rather next step) has shown how to build guis easily using graphical tools years ago. The one thing that is needed desperately to be really productive is not the storage anyway (Netbeans can serialize the objects anyway), the problem is that there is no standard, high quality application model in the Java Space. Also, of course, "standard" java still misses some standard (non graphical) components one would need to be really effective using this approach. Hi Karl, If I uderstand you right, then I totaly agree. What is lacking in java is a real component model. By this I mean a way to link together objects after compile time. It all started with C++ and the idea that you could have a viable component model by using a static language with complex runtimes like COM and CORBA. It didn't work. NextStep showed that for a viable component model what you really need is a late-bound, dynamic programming language. Objective-C as used in OSX and NextStep is a late-bound, dynamic, OO language. The web guys have caught on to the benfits of late-binding and are using http, and URLs to create mashups from re-usable web components, yet we still do not have a viable way of doing the same thing with Java objects. I agree that Spring and XML is no subsititue. When will the mainstream wakeup to this basic fact? Paul. Hi Karl, If I uderstand you right, then I totaly agree. What is lacking in java is acomponent model. By this I mean a way to link together objectscompile time. It all started with C++ and the idea that you could have a viable component model by using a static language with complex runtimes like COM and CORBA. It didn't work. NextStep showed that for a viable component model what you really need is a late-bound, dynamic programming language. Objective-C as used in OSX and NextStep is a late-bound, dynamic, OO language. The web guys have caught on to the benfits of late-binding and are using http, and URLs to create mashups from re-usable web components, yet we still do not have a viable way of doing the same thing with Java objects. I agree that Spring and XML is no subsititue. When will the mainstream wakeup to this basic fact? Paul. Reply to this Reply to original

Re: XML won't help Go to top ] Posted by: Paul Beckford

Posted on: December 03 2006 18:10 EST

in response to S. Yayla How about JMS as the binding?

You will still need to configure JMS though. Hi Satilmis, Strange as it sounds, JMS would be a move in the right direction. Pure OO languages are based on message sends. So binding to another object is a matter of sending a message at runtime. To do this you do not need to know anything about the recieving object such as its class. Using message sends leads to true polymorphism, where the recieving object can take any form as long as it suppports the message protocol used by the sender. The anology with the web is clear. You can post to any URL what ever message you like as long as the receiving page supports the message protocol at runtime. Unfortunately like I said before this was a basic misunderstanding in C++, and the idea of object Class (implementation) became confused with Type (interface) and we ended up with the virtual function call instead of a message send as a way of meeting the needs of an optimising static compiler. Objective-C avoided the C++ route and stuck to pure message sends, Java didn't, and the rest is history. Paul. Hi Satilmis, Strange as it sounds, JMS would be a move in the right direction. Pure OO languages are based on message sends. So binding to another object is a matter of sending a message at runtime. To do this you do not need to know anything about the recieving object such as its class. Using message sends leads to true polymorphism, where the recieving object can take any form as long as it suppports the message protocol used by the sender. The anology with the web is clear. You can post to any URL what ever message you like as long as the receiving page supports the message protocol at runtime. Unfortunately like I said before this was a basic misunderstanding in C++, and the idea of object Class (implementation) became confused with Type (interface) and we ended up with the virtual function call instead of a message send as a way of meeting the needs of an optimising static compiler. Objective-C avoided the C++ route and stuck to pure message sends, Java didn't, and the rest is history. Paul. Reply to this Reply to original