Re: Does the server side language matter?
Hi Thomas, Thanks for spelling that out. I do agree that GWT RPC might be less cache-friendly out of the box. As far as the folder templates story, while I understand that the ACL list is cacheable for hours at a time, it seems to me that if folder content is allowed to change in realtime, or if user roles are updated in realtime, then the interactions for content are going to be mostly un-cacheaable, and being able to cache ACLs doesn't seem to buy all that much. I think making safe RPC requests via GET should be an option in GWT. I'm not sure how to do that, and I'm also aware that there are XSS concerns around doing that. If I were in your shoes, I would probably build a special intermediary for serving GWT facing content and let that have a pure REST relationship with the independently evolving head end. Just a thought... Walden On Sep 17, 12:42 pm, Thomas Broyer [EMAIL PROTECTED] wrote: On 17 sep, 16:21, walden [EMAIL PROTECTED] wrote: On Sep 17, 5:37 am, Thomas Broyer [EMAIL PROTECTED] wrote: 3. POST for everything, even for things that should have been GETs, PUTs or DELETEs; this makes HTTP caches unusable (which you might want, but not necessarily). etc. PUTS and DELETES are not required by REST. As for POST versus GET for inquiries, even within REST there are tradeoffs and minor misfits. You may use a POST form when you have a lot of parameters, even though your intention is to invoke a safe method, which POST does not give you by HTTP contract. In brief: GWT-RPC is RPC (method calls), it's not resource-oriented. It tunnels within HTTP requests, but it isn't HTTP. Well, it's the same as SOAP, without the bloated XML serialization and minus the extensibility. These answers are bsically REST religion. Assuming I have no religion, why do I care? GWT-RPC is good for prototyping, because it's easy to set up; but it isn't web-style, so it won't scale as well as RESTful web services (a book that I highly recommend, along with blog posts from Joe Gregorio). On the face of it, I disagree that it won't scale. I didn't say it won't scale at all, just that it won't scale *as well as* a RESTful web service. I would like to have a scenario. The whole thing is about caching and the like (intermediaries, etc.). For example, we're building an app that manages employee folders (containing files such as contracts, resumes, IBANs, etc.) through workflows. Each employee folder is based on a template, meaning all employee folders have the same subfolders; this template however cannot be replicated at the GWT level because it has to evolve independently of the GWT client and moreover you can only see some subfolders depending on who you are and which employee you're looking at (you might see the contracts subfolder for secretaries but not for managers). On the other hand, the ACLs are only changed during a nightly batch update (when the admin changes the ACL rules, they won't be effective until the nightly job runs). This means that for a given an authenticated user and employee folder, the list of subfolders won't ever change during the whole day. This list being dependent on the authenticated user (well, actually, his role, the user groups he belongs to), there's a resource (a URL) for each user+employee pair (let's say: /subfolders? employee=12345678i-am=userA), and the server can thus send an Expires: next midnight header. Now, the user browser will use it's own, internal, non-shared cache to serve each subsequent request. Now, our app is for a big corporation with several companies and sites, so we do have intermediaries. We could then just as easily tell them to cache those lists provided you're authenticated (Cache- Control: proxy-revalidate; or even better an extension token if we have some control over the intermediaries: Cache-Control: private, role=myRole), and change our URLs to share them among users (/ subfolders?employee=12345678role=myRole). That way, with only little changes, all users (with the same role) passing through the intermediary use its cache rather than going to the origin server. Another scenario: if we know for sure than a given resource will only be ever accessed through a given intermediary, we can safely ask it to cache the resource: POST requests (or PUTs or DELETEs) will go through this intermediary and invalidate its cache. Just some thoughts... (and only because with GWT-RPC everything is a POST, and as a result with no need to scale the application server)- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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
Re: Does the server side language matter?
On 18 sep, 14:06, walden [EMAIL PROTECTED] wrote: Hi Thomas, Thanks for spelling that out. I do agree that GWT RPC might be less cache-friendly out of the box. And that was my main point (if you're a pragmatic developer ;-) ) (along with conditional GETs which you'd have to emulate with GWT- RPC: add an ifModifiedSince parameter to all your methods and a lastModified timestamp to your returned objects; ...and now you're effectively tunneling HTTP within HTTP ;-) ) As far as the folder templates story, while I understand that the ACL list is cacheable for hours at a time, it seems to me that if folder content is allowed to change in realtime, or if user roles are updated in realtime, then the interactions for content are going to be mostly un-cacheaable, and being able to cache ACLs doesn't seem to buy all that much. Yes, of course, it was an example (derived from our app). As you point out, we do have realtime-changing roles which make our resources uncacheable (or at least not as cacheable as in my example). As for the realtime-changing folder content, that's not really a problem if you design your resources carefully (if the subfolders are cacheable for hours but not their contents, then just make them distinct resources); but conditional GETs –which you don't have with GWT-RPC– could still save bandwidth (for sure) and processing time (if you've carefully designed your server, i.e. first check If-Modified-Since and the like then, only if you need to send fresh data, do the computing and processing and serialization/formatting). I think making safe RPC requests via GET should be an option in GWT. I'm not sure how to do that, Without a server-side API to communicate the Last-Modified/ETag and check them against If-Modified-Since/If-None-Match/etc. request headers *before* actually requesting data and process and serialize/ format it, it wouldn't be of much help... and I'm also aware that there are XSS concerns around doing that. really? Related to authentication through a method argument rather than HTTP-level (RFC2616 / RFC2617) authentication? If I were in your shoes, I would probably build a special intermediary for serving GWT facing content and let that have a pure REST relationship with the independently evolving head end. Just a thought... We're not yet scaling that big yet actually ;-) so non-cached resources will work for now (and our server-side framework only allows us to save bandwidth with conditional GETs, not save server-side processing :-( ), but using ROA rather than SOA will ease scaling in the (not that far) future. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
On Tue, Sep 16, 2008 at 1:41 PM, John [EMAIL PROTECTED] wrote: Thanks for the suggestions everyone. Definitely some things to think about in them. I probably should have explained that I am looking at things more from an architecture design view. I am not likely going to do very much coding on this myself, but I don't want to end up with the ball of mud that can be JavaScript, which is likely without GWT - probably an assumption but based on a lot of feedback from people with some experience in large JavaScript projects that have multiple developers involved. I realise that in principle pretty much any language could be used server side and GWT could still be used, but it seems initially at least that a lot of the benefit of a single language with a single IDE would be lost doing that. The other probable advantage to Java + GWT over say Django + GWT is that a developer with the skills to work on the back end could also work on the front end and vice versa. In my mind there is a fairly large difference between a Java expert and someone that knows some Java in the same way that there is a difference between a Django expert and someone that knows some Django in terms of efficiency of code as well as development and debugging time. Hence I am wary of getting someone to code the back end in Django as well as the front end in Java (GWT). The question I suppose really comes down to how much simpler it would be keeping things all in Java v. splitting it between two languages? I think it really depends on the existing skills within your company. The main thing to remember is that GWT is really a compiler that generates client side javascript. Web 2.0 brought js to the client. Web 2.5 (as I call it) brings Rich Internet Applications. However, when developing a website, the basic skills are still required, HTML, CSS, RSS, browser protocols, http headers, and the list goes on. Using GWT today is similar to using JS two years ago. The web developer worked in whatever language they were using, and, Oh, by the way, to get these cool new features, I have to learn and use javascript. It is similar today. If you are building web apps with framework X and want the new coolness offered by GWT, then, well you brush up on your Java and code away. You probably don't want to say, ah, gosh, I need to change my whole framework cause this cool client side technology is using Java. I never heard that argument from anyone using javascript with Web 2.0, and I'm sure it could have been made for extJS. But as I say, I never saw that promoted. My point, which is from the non Java camp, is that I code about 100 lines of Java client code for every 1 line of server side code. While I have not coded a Java server, I have not heard anyone mention that java server code is so minuscule that you really don't even need to include it in your decision making. If you have java server talent in house and it won't slow down development, I say use it. But sometimes I think Java is like a drug and it's users get caught up in it and don't see the costs it forces on them. I used to code C++ years ago, and I have dabbled with Java over the last 15 years. But, GWT is the first time I have used Java in anger. It has a simple C style syntax and is straightforward, albeit cumbersome, to code in. The real hurdle for people new to this technology, is not due to GWT or Java, but is the asynchronous even-based coding style. That takes people some time to adjust too. I have read that Swing programmers adapt readily to GWT, so you you may want to consider swing experience if you are hiring. Bottom line, move forward from your strengths, don't change whole frameworks expecting to obtain the holy grail of synergy, because I don't see anyone claiming those benefits, let alone achieving them. $0.02 Cheers -- Jim Freeze --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
Hi Lothar On Tue, Sep 16, 2008 at 2:27 PM, Lothar Kimmeringer [EMAIL PROTECTED] wrote: Oh boy, you lost me. I'm not sure your point, but dynamic languages have the ability to test the server side in a runtime environment. Maybe we should talk about the word test here. Do you mean trying out something and see a result without the need of compiling and deploying something, than we have different understandings of that. When I speak of testing I mean something like JUnit (http://www.junit.org/). Nope, we are talking the same language. I use unit testing and system testing. I think the only difference is that dynamic languages don't compile. Granted, that prevents some bugs, but not all bugs. To find the other bugs, test-frameworks help a lot and if you change something half a year later breaking already functioning code, the test-case shows you that. And I think that the developing of testcases for the server-side of a GWT-project when using the GWT-RPC-mechanism is easier than other mechanisms like normal servlets. I can't comment on your comparison of GWT-RPC-mechanism and 'normal servlets', but I use a couple of different frameworks that full server side testing is very straightforward. So, I'm just not seeing that there is a great advantage in testing-efficiency between server X and server J. But, I could be missing something. -- Jim Freeze --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
Hi gregor On Tue, Sep 16, 2008 at 3:16 PM, gregor [EMAIL PROTECTED] wrote: I have to ask on what basis you presume to venture such forthright views on this post given that by your own admission you don't have either the knowledge or the experience to back them up. I understand that you like dynamic languages like python and ruby, that you prefer them to statically typed languages like Java, that you are comfortable with REST etc. Fine, that's your choice. Based upon my experience with client side coding in Java, the comments I read in this news group and my discussions with other Java programmers. I really don't think there is going to be a magical reduction in the amount of code required for the server as compared to the amount of code that is required for the client, but I could be wrong. I haven't read it here or anywhere else as an advantage. I suppose I could ask you the same. What is your experience with dynamic frameworks that you would presume that the Java experience is far superior? (with my luck, you will have authored a dynamic language and written two web frameworks for it). But that is not what this post is about. John (the OP) is asking a simple question: given he has a relatively simple back end (basically some database tables) and that he has decided to use GWT to develop the client, would it pay him to use Django to manage his DB transactions server side over using Java and JDBC? IMO the answer is almost certainly not, and to reiterate the reasons: 1) Each table definition can be mapped to a Data Transfer Object class (typically representing a row of a table) used both ends of the wire. In a simple case this is easily done using JDBC and the Data Access Object pattern. 2) The whole application can be debugged soup to nuts from Java from any IDE 3) GWT RPC is very fast, flexible and reliable, and DTO's (accessed from the DB via DAO's) are easily and efficiently retrieved and stored from GWT RPC Servlets. IMO these advantages trump any minor edge Django might give you over hand coding JDBC/SQL in Java for managing DB transactions for a system as John describes given you are going to use GWT for the client. The win (AFAIK) with Django/Python is when you use it for both client and server. My response is that because GWT is a client side technology and that anyone is free to belly up to the bar and drink from its goodness, that no language has much of a case to say, use our framework, it is better. But, that seems to be what you are saying. Your framework has advantages, my framework has advantages. It's difficult to judge seeing as the value is in the eye of the beholder. I hope I'm not communicating the 'mine is better' line. I hope that I am communicating that there are alternatives to the Java server side, they have complete tests, the code you write will be less and it will develop in faster time. Don't just drink the java coolaide. :) Jim, it's fine to argue for dynamic web languages and frameworks and REST over GWT/Java (although this is not the right group for it) but it seems to me your lack of experience in Java server side technology is causing unnecessary confusion here. GWT is a client side framework. It works with any type of back end. Many people get confused that you have to use one type of backend. Well, you don't. And you may just be better off if you don't use Java for server side. Maybe. -- Jim Freeze --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
On 16 sep, 18:14, walden [EMAIL PROTECTED] wrote: Thomas, On Sep 16, 11:10 am, Thomas Broyer [EMAIL PROTECTED] wrote: (I you ask me my opinion: GWT-RPC is not RESTful so I don't use it, but the hability to share a class between client and server code is appealing; I'm not using such a thing either though) How do you arrive at that opinion? You can use or not use GWT RPC for whatever reason you like. But when you say you don't use GWT RPC because it's not RESTful, I think that carries no real meaning other than general FUD. It would be better to state the specific tradeoffs that don't work for you. I'm just concerned that some might avoid a very useful technology for a very questionable reason. Can you please shed some more light? 1. RPC: the method is in the request body, not as an HTTP method (not always possible though). 2. If I want a collection resource (GETting the resource returns me a representation of the list) and individual entry resources (that I could GET, PUT and DELETE –using method override in older Safari–, and eventually POST for other needs...), I need 2 RemoteService classes, and then using the EntryService means changing the service location before each method call; this is not the way GWT-RPC has been thought, GWT-RPC isn't resource-oriented, it's, well, RPC... 3. POST for everything, even for things that should have been GETs, PUTs or DELETEs; this makes HTTP caches unusable (which you might want, but not necessarily). etc. In brief: GWT-RPC is RPC (method calls), it's not resource-oriented. It tunnels within HTTP requests, but it isn't HTTP. Well, it's the same as SOAP, without the bloated XML serialization and minus the extensibility. GWT-RPC is good for prototyping, because it's easy to set up; but it isn't web-style, so it won't scale as well as RESTful web services (a book that I highly recommend, along with blog posts from Joe Gregorio). I guess generators could be used to make RESTful web services as easy as GWT-RPC (I didn't investigate yet, as our server-side language is... JavaScript!) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
On Sep 17, 5:37 am, Thomas Broyer [EMAIL PROTECTED] wrote: On 16 sep, 18:14, walden [EMAIL PROTECTED] wrote: Thomas, On Sep 16, 11:10 am, Thomas Broyer [EMAIL PROTECTED] wrote: (I you ask me my opinion: GWT-RPC is not RESTful so I don't use it, but the hability to share a class between client and server code is appealing; I'm not using such a thing either though) How do you arrive at that opinion? You can use or not use GWT RPC for whatever reason you like. But when you say you don't use GWT RPC because it's not RESTful, I think that carries no real meaning other than general FUD. It would be better to state the specific tradeoffs that don't work for you. I'm just concerned that some might avoid a very useful technology for a very questionable reason. Can you please shed some more light? 1. RPC: the method is in the request body, not as an HTTP method (not always possible though). What is the design tradeoff though? Why does a pragmatic developer care? 2. If I want a collection resource (GETting the resource returns me a representation of the list) and individual entry resources (that I could GET, PUT and DELETE –using method override in older Safari–, and eventually POST for other needs...), I need 2 RemoteService classes, and then using the EntryService means changing the service location before each method call; this is not the way GWT-RPC has been thought, GWT-RPC isn't resource-oriented, it's, well, RPC... I can't really understand any of that. What do you need to do that REST gives you and GWT RPC fails? 3. POST for everything, even for things that should have been GETs, PUTs or DELETEs; this makes HTTP caches unusable (which you might want, but not necessarily). etc. PUTS and DELETES are not required by REST. As for POST versus GET for inquiries, even within REST there are tradeoffs and minor misfits. You may use a POST form when you have a lot of parameters, even though your intention is to invoke a safe method, which POST does not give you by HTTP contract. In brief: GWT-RPC is RPC (method calls), it's not resource-oriented. It tunnels within HTTP requests, but it isn't HTTP. Well, it's the same as SOAP, without the bloated XML serialization and minus the extensibility. These answers are bsically REST religion. Assuming I have no religion, why do I care? GWT-RPC is good for prototyping, because it's easy to set up; but it isn't web-style, so it won't scale as well as RESTful web services (a book that I highly recommend, along with blog posts from Joe Gregorio). On the face of it, I disagree that it won't scale. I would like to have a scenario. I guess generators could be used to make RESTful web services as easy as GWT-RPC (I didn't investigate yet, as our server-side language is... JavaScript!)- Hide quoted text - GWT RPC has to be considered as part of the optional COD variant of REST. In a nutshell, interactions between a GWT client and server are private interactions between components which are not expected to independently co-evolve. The scaleability is one level up, where the GWT host HTML file appears as a regular Web resource. Thanks for your answers. I think the way GWT has advanced AJAX, these REST questions need serious reconsideration. Walden - Show quoted text - --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
Hello Jim, My favorite IDE is certainly not eclipse, and probably not the best to use with Django. The server side can be quickly written and tested independent of the client side. I consider that a plus. You misunderstood what gregor meant. Gregor meant that if you have a Java back-end, you can seamlessly debug your application going from the client side to the server side using any Java IDE (Eclipse, NetBeans, IDEA, etc). You cannot do this if your front-end is GWT and back-end is Python. JSON can be made as fast and json libraries for python already exist. So, I seriously doubt anyone is writing JSON serialization from scratch. Your server side code probably only needs to be modified with self.data.to_json. GWT-RPC is actually faster and smaller then JSON (unless you use JS overlays, which just calls eval). See this: http://sites.google.com/site/io/gwt-and-client-server-communication Using a restful approach, you don't pass objects between client and server. The stateless server serves up requests for data. No need to complicate the issue. If you're using a front-end agnostic approach (i.e. JSON based), then you wouldn't pass objects between the client and server. However, if you are able to take advantage of GWT-RPC, with a Java back-end, you would be able to pass objects to the Java server for persistence and get objects back for data requests. This has huge advantages in code maintenance and ease of use. Django provides a good ORM and an MVC framework. With it, about the only thing you will need to account for is that you support json format requests. That's an extra layer that you wouldn't have to do if you just used Django. I would use the independence of GWT to let you choose a backend that supports your experience. If server side development with Java is as slow as client side development with GWT, I would suggest that there are better alternatives for the server side. I'd argue the Java back-end has a large number of very high quality libraries that make server side development easy and efficient. However, if your experience lies in Django and Python development, you might be better off with a Django solution. Java back-ends are great for enterprise quality applications. However, if you're hacking something together, Python is better choice. GWT development is only slow if you are unfamiliar with it. Besides, GWT is a toolkit, not a framework. It's hard to compare it to Django, which already includes many features like validation, etc. GWT can be used to build said frameworks, and from there GWT apps would be a lot easier and faster to make. On Sep 15, 2:53 pm, Jim Freeze [EMAIL PROTECTED] wrote: My comments are inline below. Please pardon me if they are not popular to the Java perspective. On Mon, Sep 15, 2008 at 12:39 PM, gregor [EMAIL PROTECTED] wrote: As Ian states, you can use whatever you like back end. Django is a popular framework, but perhaps you should consider using either Django or GWT+Java since in mixing the two maybe you loose quite a lot. 1) Being able to debug the entire application (GUI + server) from your favourite IDE is a very big plus - you loose that if you use Django back end My favorite IDE is certainly not eclipse, and probably not the best to use with Django. The server side can be quickly written and tested independent of the client side. I consider that a plus. 2) GWT RPC is very fast and efficient, a big plus for GWT. You would need to use,say, JSON if you had a Django back end which means you will have to write your own JSON serialization stuff, something GWT RPC does for you. JSON can be made as fast and json libraries for python already exist. So, I seriously doubt anyone is writing JSON serialization from scratch. Your server side code probably only needs to be modified with self.data.to_json. 3) For each object passed between client and server, you will need to maintain two copies, one for Django and one in Java for GWT client. Using a restful approach, you don't pass objects between client and server. The stateless server serves up requests for data. No need to complicate the issue. 4) AFAIK much of the appeal of Django (apart from its persistence mechanism) lies in how it binds persistent objects and other artifacts to UI widgets for you - you could not take advantage of this with a GWT UI Django provides a good ORM and an MVC framework. With it, about the only thing you will need to account for is that you support json format requests. I guess if you are a Django expert and can crank out server code PDQ with it, there is case for mixing it with GWT, but otherwise I would choose one or the other. I would use the independence of GWT to let you choose a backend that supports your experience. If server side development with Java is as slow as client side development with GWT, I would suggest that there are better alternatives for the server side. Jim
Re: Does the server side language matter?
On Tue, Sep 16, 2008 at 8:02 AM, Arthur Kalmenson [EMAIL PROTECTED] wrote: Hello Jim, Hello Arthur My favorite IDE is certainly not eclipse, and probably not the best to use with Django. The server side can be quickly written and tested independent of the client side. I consider that a plus. You misunderstood what gregor meant. Gregor meant that if you have a Java back-end, you can seamlessly debug your application going from the client side to the server side using any Java IDE (Eclipse, NetBeans, IDEA, etc). You cannot do this if your front-end is GWT and back-end is Python. I know the NetBeans IDE has a ruby debugger. If the backend was Ruby, I suppose that it would still not be possible to 'seamlessly' debug from client to server, right? Actually, this is a totally foreign concept to me. The data from client to server is marshalled over an http request and off to a completely different process. Are you saying that the debugging environment handles that? What does it do about asynchronous calls? Do they appear to be synchronous when debugging? JSON can be made as fast and json libraries for python already exist. So, I seriously doubt anyone is writing JSON serialization from scratch. Your server side code probably only needs to be modified with self.data.to_json. GWT-RPC is actually faster and smaller then JSON (unless you use JS overlays, which just calls eval). See this: http://sites.google.com/site/io/gwt-and-client-server-communication It's so easy to work with json, that you can construct a tiny bit of client code to rebuild json object and then use overlays to eval. It's essentially the same as RPC, just without the mystery. Using a restful approach, you don't pass objects between client and server. The stateless server serves up requests for data. No need to complicate the issue. If you're using a front-end agnostic approach (i.e. JSON based), then you wouldn't pass objects between the client and server. However, if you are able to take advantage of GWT-RPC, with a Java back-end, you would be able to pass objects to the Java server for persistence and get objects back for data requests. This has huge advantages in code maintenance and ease of use. I don't have any experience to know how huge of an advantage that really is. Django provides a good ORM and an MVC framework. With it, about the only thing you will need to account for is that you support json format requests. That's an extra layer that you wouldn't have to do if you just used Django. Huh? I would use the independence of GWT to let you choose a backend that supports your experience. If server side development with Java is as slow as client side development with GWT, I would suggest that there are better alternatives for the server side. I'd argue the Java back-end has a large number of very high quality libraries that make server side development easy and efficient. However, if your experience lies in Django and Python development, you might be better off with a Django solution. Java back-ends are great for enterprise quality applications. However, if you're hacking something together, Python is better choice. GWT development is only slow if you are unfamiliar with it. Besides, GWT is a toolkit, not a framework. It's hard to compare it to Django, which already includes many features like validation, etc. GWT can be used to build said frameworks, and from there GWT apps would be a lot easier and faster to make. My point here is two fold. First, Java coding is not slow because of the programmer, but because of the 100x increase in the amount of code that is required to do the same job as in a dynamic language. Granted, 100x is not always the case, it is just the case for my client side vs server side code. My comment to the original poster (since I know nothing about java server side coding) is that if java server side coding requires as much coding as the client side, then you can probably code much faster using an alternative server side framework. The other issue is GUI's, in this case GWT. Being a backend programmer for many years, I forget the amount of work involved to get a simple GUI up an running. So, part of the perceived development slowness I am experiencing has nothing to do with Java, but Java is certainly not offering a lot of assistance when it comes to reducing the amount of code I need to write. -- Jim Freeze --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
On 15 sep, 20:53, Jim Freeze [EMAIL PROTECTED] wrote: JSON can be made as fast and json libraries for python already exist. So, I seriously doubt anyone is writing JSON serialization from scratch. Your server side code probably only needs to be modified with self.data.to_json. ...but if your client needs to send JSON, you need a JSON-serializer (which hopefully GWT provides you, but not the most performant, as it relies on JSONValue wrappers for each and every single thing you'll want to serialize (or parse, as it works both ways). com.google.gwt.json.JSON is unfortunately hard to use and generates a lot of overhead. For those familiar with c.g.g.j.JSON and JS overlays, here's an example: I'm getting a JsArrayString from the server (using an eval() from an application/json payload), the application's user add/remove values through the UI and when done, he clicks save. I then have to serialize the JsArrayString back to JSON to 'HTTP PUT' it back to the server. I'm now doing it with this code: (new JSONArray(arr)).toString(); This means that for each String stored in the array a JSONString is created, only to be toString()ified and thrown away. It also means my compiled app contains code for JSONString and JSONArray as well as some code from JSONParser, JSONNumber, JSONObject and JSONBoolean. I'm thinking about switching to application/x-www-form-urlencoded to reduce the overhead. 3) For each object passed between client and server, you will need to maintain two copies, one for Django and one in Java for GWT client. Using a restful approach, you don't pass objects between client and server. The stateless server serves up requests for data. No need to complicate the issue. If you exchange JSON payloads, you're exchanging serialized objects. Not objects in the OOP sense of the term (implying inheritance, polymorphism, encapsulation, etc.), but still objects (call them DTOs if you prefer). What gregor was talking about though wasn't about object instances: with GWT-RPC (or using your own generator), you can have a single DTO _class_ shared between client-side and server-side code. (I you ask me my opinion: GWT-RPC is not RESTful so I don't use it, but the hability to share a class between client and server code is appealing; I'm not using such a thing either though) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
On Tue, Sep 16, 2008 at 10:10 AM, Thomas Broyer [EMAIL PROTECTED] wrote: On 15 sep, 20:53, Jim Freeze [EMAIL PROTECTED] wrote: JSON can be made as fast and json libraries for python already exist. So, I seriously doubt anyone is writing JSON serialization from scratch. Your server side code probably only needs to be modified with self.data.to_json. ...but if your client needs to send JSON, you need a JSON-serializer (which hopefully GWT provides you, but not the most performant, as it relies on JSONValue wrappers for each and every single thing you'll want to serialize (or parse, as it works both ways). com.google.gwt.json.JSON is unfortunately hard to use and generates a lot of overhead. [elided] (I you ask me my opinion: GWT-RPC is not RESTful so I don't use it, but the hability to share a class between client and server code is appealing; I'm not using such a thing either though) You answered for me. :) Yes, when using REST, json is only from server to client. Never the other way. What that means in reality, is that I don't have a client side algorithm that generates a massive amount of data change that needs to be marshalled back to the server. Usually changes are from the user. -- Jim Freeze --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
Thomas, On Sep 16, 11:10 am, Thomas Broyer [EMAIL PROTECTED] wrote: (I you ask me my opinion: GWT-RPC is not RESTful so I don't use it, but the hability to share a class between client and server code is appealing; I'm not using such a thing either though) How do you arrive at that opinion? You can use or not use GWT RPC for whatever reason you like. But when you say you don't use GWT RPC because it's not RESTful, I think that carries no real meaning other than general FUD. It would be better to state the specific tradeoffs that don't work for you. I'm just concerned that some might avoid a very useful technology for a very questionable reason. Can you please shed some more light? Walden --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
Thanks for the suggestions everyone. Definitely some things to think about in them. I probably should have explained that I am looking at things more from an architecture design view. I am not likely going to do very much coding on this myself, but I don't want to end up with the ball of mud that can be JavaScript, which is likely without GWT - probably an assumption but based on a lot of feedback from people with some experience in large JavaScript projects that have multiple developers involved. I realise that in principle pretty much any language could be used server side and GWT could still be used, but it seems initially at least that a lot of the benefit of a single language with a single IDE would be lost doing that. The other probable advantage to Java + GWT over say Django + GWT is that a developer with the skills to work on the back end could also work on the front end and vice versa. In my mind there is a fairly large difference between a Java expert and someone that knows some Java in the same way that there is a difference between a Django expert and someone that knows some Django in terms of efficiency of code as well as development and debugging time. Hence I am wary of getting someone to code the back end in Django as well as the front end in Java (GWT). It sounds like I am really arguing with myself :o) The question I suppose really comes down to how much simpler it would be keeping things all in Java v. splitting it between two languages? Regards, John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
Hello Jim, Jim Freeze schrieb: Oh boy, you lost me. I'm not sure your point, but dynamic languages have the ability to test the server side in a runtime environment. Maybe we should talk about the word test here. Do you mean trying out something and see a result without the need of compiling and deploying something, than we have different understandings of that. When I speak of testing I mean something like JUnit (http://www.junit.org/). I think the only difference is that dynamic languages don't compile. Granted, that prevents some bugs, but not all bugs. To find the other bugs, test-frameworks help a lot and if you change something half a year later breaking already functioning code, the test-case shows you that. And I think that the developing of testcases for the server-side of a GWT-project when using the GWT-RPC-mechanism is easier than other mechanisms like normal servlets. Can you re-phrase your question, but help me out about what you mean when you start talking about Java server side things. I don't have any experience with that side of the fence with Java. I think we were talking of different things when speaking of testing, so rephrasing might bring up nothing new ;-) Regards, Lothar --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
Jim, your words Oh boy, you lost me. I'm not sure your point, but dynamic languages have the ability to test the server side in a runtime environment. I think the only difference is that dynamic languages don't compile. Granted, that prevents some bugs, but not all bugs. Can you re-phrase your question, but help me out about what you mean when you start talking about Java server side things. I don't have any experience with that side of the fence with Java. If you're using a front-end agnostic approach (i.e. JSON based), then you wouldn't pass objects between the client and server. However, if you are able to take advantage of GWT-RPC, with a Java back-end, you would be able to pass objects to the Java server for persistence and get objects back for data requests. This has huge advantages in code maintenance and ease of use. I don't have any experience to know how huge of an advantage that really is. I have to ask on what basis you presume to venture such forthright views on this post given that by your own admission you don't have either the knowledge or the experience to back them up. I understand that you like dynamic languages like python and ruby, that you prefer them to statically typed languages like Java, that you are comfortable with REST etc. Fine, that's your choice. But that is not what this post is about. John (the OP) is asking a simple question: given he has a relatively simple back end (basically some database tables) and that he has decided to use GWT to develop the client, would it pay him to use Django to manage his DB transactions server side over using Java and JDBC? IMO the answer is almost certainly not, and to reiterate the reasons: 1) Each table definition can be mapped to a Data Transfer Object class (typically representing a row of a table) used both ends of the wire. In a simple case this is easily done using JDBC and the Data Access Object pattern. 2) The whole application can be debugged soup to nuts from Java from any IDE 3) GWT RPC is very fast, flexible and reliable, and DTO's (accessed from the DB via DAO's) are easily and efficiently retrieved and stored from GWT RPC Servlets. IMO these advantages trump any minor edge Django might give you over hand coding JDBC/SQL in Java for managing DB transactions for a system as John describes given you are going to use GWT for the client. The win (AFAIK) with Django/Python is when you use it for both client and server. Jim, it's fine to argue for dynamic web languages and frameworks and REST over GWT/Java (although this is not the right group for it) but it seems to me your lack of experience in Java server side technology is causing unnecessary confusion here. regards gregor On Sep 16, 4:08 pm, Jim Freeze [EMAIL PROTECTED] wrote: On Tue, Sep 16, 2008 at 8:02 AM, Arthur Kalmenson [EMAIL PROTECTED] wrote: Hello Jim, Hello Arthur My favorite IDE is certainly not eclipse, and probably not the best to use with Django. The server side can be quickly written and tested independent of the client side. I consider that a plus. You misunderstood what gregor meant. Gregor meant that if you have a Java back-end, you can seamlessly debug your application going from the client side to the server side using any Java IDE (Eclipse, NetBeans, IDEA, etc). You cannot do this if your front-end is GWT and back-end is Python. I know the NetBeans IDE has a ruby debugger. If the backend was Ruby, I suppose that it would still not be possible to 'seamlessly' debug from client to server, right? Actually, this is a totally foreign concept to me. The data from client to server is marshalled over an http request and off to a completely different process. Are you saying that the debugging environment handles that? What does it do about asynchronous calls? Do they appear to be synchronous when debugging? JSON can be made as fast and json libraries for python already exist. So, I seriously doubt anyone is writing JSON serialization from scratch. Your server side code probably only needs to be modified with self.data.to_json. GWT-RPC is actually faster and smaller then JSON (unless you use JS overlays, which just calls eval). See this: http://sites.google.com/site/io/gwt-and-client-server-communication It's so easy to work with json, that you can construct a tiny bit of client code to rebuild json object and then use overlays to eval. It's essentially the same as RPC, just without the mystery. Using a restful approach, you don't pass objects between client and server. The stateless server serves up requests for data. No need to complicate the issue. If you're using a front-end agnostic approach (i.e. JSON based), then you wouldn't pass objects between the client and server. However, if you are able to take advantage of GWT-RPC, with a Java back-end, you would be able to pass objects to the Java server for persistence and get objects back for data requests. This
Re: Does the server side language matter?
My comments are inline below. Please pardon me if they are not popular to the Java perspective. On Mon, Sep 15, 2008 at 12:39 PM, gregor [EMAIL PROTECTED] wrote: As Ian states, you can use whatever you like back end. Django is a popular framework, but perhaps you should consider using either Django or GWT+Java since in mixing the two maybe you loose quite a lot. 1) Being able to debug the entire application (GUI + server) from your favourite IDE is a very big plus - you loose that if you use Django back end My favorite IDE is certainly not eclipse, and probably not the best to use with Django. The server side can be quickly written and tested independent of the client side. I consider that a plus. 2) GWT RPC is very fast and efficient, a big plus for GWT. You would need to use,say, JSON if you had a Django back end which means you will have to write your own JSON serialization stuff, something GWT RPC does for you. JSON can be made as fast and json libraries for python already exist. So, I seriously doubt anyone is writing JSON serialization from scratch. Your server side code probably only needs to be modified with self.data.to_json. 3) For each object passed between client and server, you will need to maintain two copies, one for Django and one in Java for GWT client. Using a restful approach, you don't pass objects between client and server. The stateless server serves up requests for data. No need to complicate the issue. 4) AFAIK much of the appeal of Django (apart from its persistence mechanism) lies in how it binds persistent objects and other artifacts to UI widgets for you - you could not take advantage of this with a GWT UI Django provides a good ORM and an MVC framework. With it, about the only thing you will need to account for is that you support json format requests. I guess if you are a Django expert and can crank out server code PDQ with it, there is case for mixing it with GWT, but otherwise I would choose one or the other. I would use the independence of GWT to let you choose a backend that supports your experience. If server side development with Java is as slow as client side development with GWT, I would suggest that there are better alternatives for the server side. Jim regards gregor On Sep 15, 4:59 pm, Jim Freeze [EMAIL PROTECTED] wrote: On Mon, Sep 15, 2008 at 7:38 AM, John [EMAIL PROTECTED] wrote: I am trying to evaluate some options for a project that has just started (but is only in the planning stages atm) and it seems that most of the complexity will be in the front end (in JavaScript), so the back end doesn't seem to matter that much anymore as it will be fairly small and be acting primarily as an interface with the database. Currently the back end is planned in Django, but could be switched to Java. I use merb (similar to Ruby on Rails) and Sequel as my ORM for the server. I wrote a simple RESTful RequestBuilder and some very straightforward JSON layer for my models on the client side. My time, allocated between client and server, it 99:1. GUI's (and Java) are not the most succinct programming environments. I think I am coding about 1K LoC on the client for about 10 LoC on the server. Jim The question really is whether anyone has had experience with using another language in the server side while using GWT (and hence Java) on the client side code. If so, was it more painful that it would have been simply using Java for the entire application, or didn't it make much of a difference? Regards, John -- Jim Freeze -- Jim Freeze --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Does the server side language matter?
I would use the independence of GWT to let you choose a backend that supports your experience. If server side development with Java is as slow as client side development with GWT, I would suggest that there are better alternatives for the server side. Development in GWT is only as slow as the developer doing it. If you're having trouble developing a GWT client then no, a Java server solution probably isn't right for you either. On Mon, Sep 15, 2008 at 2:53 PM, Jim Freeze [EMAIL PROTECTED] wrote: My comments are inline below. Please pardon me if they are not popular to the Java perspective. On Mon, Sep 15, 2008 at 12:39 PM, gregor [EMAIL PROTECTED] wrote: As Ian states, you can use whatever you like back end. Django is a popular framework, but perhaps you should consider using either Django or GWT+Java since in mixing the two maybe you loose quite a lot. 1) Being able to debug the entire application (GUI + server) from your favourite IDE is a very big plus - you loose that if you use Django back end My favorite IDE is certainly not eclipse, and probably not the best to use with Django. The server side can be quickly written and tested independent of the client side. I consider that a plus. 2) GWT RPC is very fast and efficient, a big plus for GWT. You would need to use,say, JSON if you had a Django back end which means you will have to write your own JSON serialization stuff, something GWT RPC does for you. JSON can be made as fast and json libraries for python already exist. So, I seriously doubt anyone is writing JSON serialization from scratch. Your server side code probably only needs to be modified with self.data.to_json. 3) For each object passed between client and server, you will need to maintain two copies, one for Django and one in Java for GWT client. Using a restful approach, you don't pass objects between client and server. The stateless server serves up requests for data. No need to complicate the issue. 4) AFAIK much of the appeal of Django (apart from its persistence mechanism) lies in how it binds persistent objects and other artifacts to UI widgets for you - you could not take advantage of this with a GWT UI Django provides a good ORM and an MVC framework. With it, about the only thing you will need to account for is that you support json format requests. I guess if you are a Django expert and can crank out server code PDQ with it, there is case for mixing it with GWT, but otherwise I would choose one or the other. I would use the independence of GWT to let you choose a backend that supports your experience. If server side development with Java is as slow as client side development with GWT, I would suggest that there are better alternatives for the server side. Jim regards gregor On Sep 15, 4:59 pm, Jim Freeze [EMAIL PROTECTED] wrote: On Mon, Sep 15, 2008 at 7:38 AM, John [EMAIL PROTECTED] wrote: I am trying to evaluate some options for a project that has just started (but is only in the planning stages atm) and it seems that most of the complexity will be in the front end (in JavaScript), so the back end doesn't seem to matter that much anymore as it will be fairly small and be acting primarily as an interface with the database. Currently the back end is planned in Django, but could be switched to Java. I use merb (similar to Ruby on Rails) and Sequel as my ORM for the server. I wrote a simple RESTful RequestBuilder and some very straightforward JSON layer for my models on the client side. My time, allocated between client and server, it 99:1. GUI's (and Java) are not the most succinct programming environments. I think I am coding about 1K LoC on the client for about 10 LoC on the server. Jim The question really is whether anyone has had experience with using another language in the server side while using GWT (and hence Java) on the client side code. If so, was it more painful that it would have been simply using Java for the entire application, or didn't it make much of a difference? Regards, John -- Jim Freeze -- Jim Freeze --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
