my bad... that was a typo which i realized only after clicking the send button(and was too lazy to post the second response).
"just include the js" = "just include the jar". Following attributes in your gwt.xml while in development simplify compile some what: <set-property name="user.agent" value="ie6" /> <set-property name="gwt.suppressNonStaticFinalFieldWarnings" value="true" /> On Nov 24, 2:23 pm, adam <[EMAIL PROTECTED]> wrote: > Rakesh, This was a totally great response and I'm really thankful that > you took the time to write it. > > > divide your project into distinct modules that do not rely on each > > other, do it! A good example is managing administration activities > > could be a separate module. This way you take away the load from main > > application. > > I see what you mean, but it's often pretty tough to come up with > modules whose dependency graph is disconnected from the rest of the > project. They do appear from time to time, I suppose. > > > this common project, do our development, test it in hosted mode(with a > > demo app) and just include the js. This way we shift at least 30% of > > our development to this very small project that is easy on hosted mode > > refresh, debugging, and over all development. I hope you get my point > > here. > > Please let me know if I understand the "just include the js" part > correctly. You are saying that you keep your UI widget lib in a > separate project, compile it to javascript, and then include that > javascript in the html for your main project? If this is correct, how > do you expose the methods? Do you just add functions to $wnd in JSNI > or are you using Cromwell's GWT Exporter? I use the "passive view" > pattern, which means it's usually pretty easy for me to try out my > widgets in a harness; I usually keep a second module in my main > Eclipse project for this purpose. > > > 4. At time of development compile only for IE(through a property ingwtex > > I'm sorry, but I didn't catch you here. I think your original message > may have become a bit garbled here. > > Thanks again. > Adam > > On Nov 24, 12:47 pm,rakeshwagh<[EMAIL PROTECTED]> wrote: > > > I will agree on the final thing about listeners and feel that it is > > more of personal preference. In my experience we had good luck and > > happy results using listeners to decouple our widgets and hence > > screens. Basically like any other java based application you need a > > lead in your team who will always take care of the over all design and > > make sure that listeners are not abused; that parents do not pass > > themselves as references to the child for purpose of method > > invocation; and many other best practice that come by little practice. > > Withgwt, client side programming deserves equal or more respect(hence > > design and lead resources) compared to its server side counter part. > > > About the size of generated javascript code. As I said I am not going > > to go in comparison with any other lib, because that would be apple vs > > bananas(I love both fruits btw). If your app is compiled as 160kb js, > > I think it is not huge. It is probably just okay. The best thing I > > like aboutgwtis that it does not include a staticgwt.js of its own > > (like most other toolkits does, take dojo for instance).Gwtmaps your > > java code as effeciently as possible to corresponding javascript(again > > without including its own static js lib). I agree with you that lazy > > loading would be a good idea. Moreover I also agree with you that > > hosted mode refresh time sucks as your app size increaseas(and that > > happens pretty soon!). We all face this issue, and I think thatgwt > > team will put a solution in coming months. See my comments in this > > thread:http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa... > > > Here are some suggestions: > > 1.Usemodules right from the beginning if possible. If you could > > divide your project into distinct modules that do not rely on each > > other, do it! A good example is managing administration activities > > could be a separate module. This way you take away the load from main > > application. > > 2. Create a "separate project" for commongwtwidgets. If you are > > relying on vanillagwtfor widgets(not usinggwt-ext etc), you would > > most probably end up writing lot of common widgets that you would like > > to reusein your project. We created a separate project just for this > > purpose. So whenever we write a reusable(1+ times) widget, we go to > > this common project, do our development, test it in hosted mode(with a > > demo app) and just include the js. This way we shift at least 30% of > > our development to this very small project that is easy on hosted mode > > refresh, debugging, and over all development. I hope you get my point > > here. > > 3.uselazy initialization of variable where ever possible. This > > reduces lot of start up time. > > 4. At time of development compile only for IE(through a property ingwtex > > More over we created a entirely different project that would contain > > the common widgets that we develop and can be reused. I think > > > Finally: > > - I reiterate, it is futile to comparegwtwith any other js > > libraries. For us,gwteliminates theuseof many server side layers > > and xml configurations etc that we would traditionally do in a struts > > like app framework. > > - If I am allowed to be philosophical: "GWTis a change in paradigm > > for web app developments" > > - It also makes our server side code simple to a level where we have > > to just provide the implementation to a bunch of interface methods. > > Our server and client teams can work totally independent of each > > other. > > - Moreover when we float requirement, all we need is a person who is > > good in java, and nothing else.(yes there is a learning curve for this > > person, but that is true with any thing else). > > - Beforegwt, javascript was my personal favorite for the flexibility > > and ease of that language. However it didn't take me to long to > > realize how nasty it would get to debug others code and how difficult > > does it get to add new features to a already written js based > > application. Frankly it is a nightmare and ppl tend to stay away from > > touching pre written js based applications. > > - Last year we developed agwtbased application and shipped it > > offshore for maintenance and the response from our offshore team was > > really good(compared to our earlier experiences). All were new togwt > > but they could go in and do bug fixes and add new features without > > much hand holding(and without hating or messing the existing code). > >RakeshWagh > > > On Nov 24, 11:20 am, adam <[EMAIL PROTECTED]> wrote: > > > > HiRakesh, Thanks for your response. > > > > > Adam, did you even tryGWT? > > > > As I said earlier in this thread, I've developed applications inGWT. > > > My most recent one (still in development) is matchomat.com. This > > > application has some rollover buttons, dialogs, form checking,gwt > > > rpc, history, and it even usesgwt-coded jsonp to communicate with an > > > erlang server. All of the js is written inGWT. I described the client- > > > side architecture in the reply to Adam T earlier in this thread. I've > > > also made a large pure-GWT-history app before. > > > > > created by jquery itself.gwt'slist you posted is not created by > > > > google or thegwtteam. > > > > They should really post a list! > > > > > - Generated js is super-super fast and tiny(relatively)! You end up > > > > writing fast and small apps. compare it with flex and or any other > > > > toolkit of your choice. (btw, comparing it with lo level libs like > > > > prototype.js is wrong) > > > > The javascript for matchomat, which is compiled in obfuscated mode, is > > > around 160kb. I don't like having to wait at my browser for all this > > > javascript to load. Take a look at Netflix or Facebook; very ajax-y > > > and yet they seem to load instantaneously. I believe I could have hand- > > > coded essentially identical functionality for matchomat with a smaller > > > javascript file had I been using a js toolkit like jquery. > > > Furthermore, Flex allows you to dynamically load modules -- I do this > > > in langolab.com. AlthoughGWT.runAsync is in the trunk, it hasn't been > > > released yet. I have a friend who is on a team creating a b2bgwtapp > > > where the monolithic javascript file weighs in at over a megabyte. > > > This is untenable for a public-facing app. > > > > > - Every thing is so modular and object oriented. you can write long > > > > lasting apps and manage huge application easily. > > > > I respectfully disagree with you. First of all, to run my project in > > > hosted mode I have to wait about 30 seconds for java->js compilation. > > > This may not sound like a lot but I feel like it really interrupts my > > > design->debug->design cycle. With hand-coded javascript, there is no > > > need for this extra compilation step. In order to test my app on other > > > browsers withGWT, I need to compile in web mode, which takes about > > > 1-3 minutes on my very very fast machine. > > > > > - Creating reusable widgets is a snap. And that is what you do > > > > withgwtmost of the time. > > > > Although creating them is a snap, as we noted earlier in this thread > > > actually using them in an app where html is generated on the server > > > (like, for SEO) can be a PITA, at least with all techniques that I > > > think of. It must especially be a PITA with very large apps that > > > consist of dozens or even hundreds of distinct pages, like the one I'm > > > currently starting. I wonder if anyone else has some thoughts about > > > how to ease the pain of usingGWTwith apps like these. > > > > > - Some really great features that are unique togwt: locale mgmt, > > > > history token management, image bundle, exception handling and rpc > > > > mechanism > > > > Thank you for reminding me of local mgmt, history, and the image > > > bundle. You are right, these are really useful features. I think I > > > might continue withGWTon account of these. > > > > > - Strongly typed java is always better compared to js. You end up > > > > making less mistakes as 80% errors are resolved by eclipse as you type > > > > your code. > > > > Thank you for reminding me of this also. This is a huge advantage. > > > > > - Never seen a better way of debugging my code. > > > > Firebug is pretty useful for debugging js. > > > > > - Listeners architecture(if you understand and implement correctly) is > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
