I do the same but i hold all my gwt modules in a single project. One of these gwt modules is the common module. Named Common . hehe
I don't need to jar anything in order to be shared. And eclipse helps refactoring things from one module to the Common. All modules are compiled and errors are showed from all modules at the same time. sorry my english. On 26 nov, 00:56, rakesh wagh <[EMAIL PROTECTED]> wrote: > 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 > > ... > > leer más » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
