On Mon, Nov 15, 2010 at 11:42 AM, TedM <ted.malask...@gmail.com> wrote: > The current implementation has the following functionality > > 1. dynamic forms > 2. dynamic workflow > 3. submission of form data > 4. submission of attachments > 5. client and server validation > > And UI editor on the way. > > But the current implementation is a project that I'm the architect > for. The prototype I put on Google App Engine is a Prototype based on > a prototype that I used to sell the idea to my company. > > To open source this, I would like to do it in the following order. > 1. Schedule a meeting with you Google guys the first or second week of > December > 2. Draw up my designs and clean up my prototype. > 3. Then I'll meet with you guys so I can get my design and vision > aligned with yours. > 4. Then I'll build it to your vision > > What do you think?
This is just a general comment from me personally -- I recognize that there are times that you need dynamic functionality, but realize that you pay a significant cost for it. Typical structures used to handle dynamic content don't optimize well, and the compiler is unable to remove a lot of code because it might be used depending on the data received from the server. Personally, when you can get away with it, you are much better off either generating static code from dynamic data (which of course means recompiling your app) or rendering the dynamic parts on the server. I don't know if either of those are feasible for your use case. Just because something is expensive doesn't meant it shouldn't be in GWT -- if what you need to do is expensive, that doesn't change the fact that you still need to do it. However, it would need to be done in a way so that most people, who do not actually need that functionality, do not wind up using it by mistake or paying the cost because some library they use does. An example is reflection -- it would be possible to implement reflection in GWT, but the problem is that then almost all of the useful optimizations the compiler does goes away. You can never remove a method that isn't referenced (including after inlining it where you can) because there might be a reflective call to it, you can no longer tighten argument types based on the callsites, etc. So, rather than promoting functionality that people definitely want but encourages them to write code that compiles poorly, we chose to leave out reflection. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
