Re: HTML identifiers are not generated properly for some SmartGWT components
Please take a look at the Automated Testing overview for SmartGWT: http://www.smartclient.com/smartgwtee-latest/javadoc/com/smartgwt/client/docs/AutomatedTesting.html If you aren't using one of the tools here, pay special attention to the Other Tools section, which explains that SmartGWT uses locators instead of DOM IDs. This allows you to create tests that aren't invalidated by DOM changes due to applying different look and feel, or working around new browser bugs. On Wednesday, July 24, 2013 10:29:12 AM UTC-7, MJ C wrote: We are trying to implement Test Automation and one key point is to ensure each HTML element has a unique ID (that we can always rely upon in our Test Automation scripts for element identification). -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: GWT vs SmartGWT
Hi Kumar, SmartGWT has an extensive subsystem for interacting directly with WSDL web services from the browser. Some samples here: http://www.smartclient.com/smartgwtee/showcase/#data_integration_server_wsdl_weather This is all part of the free LGPL product, assuming you don't need a server-side proxy or can handle your own proxying. Specifically for WSDL there is nothing really comparable for plain GWT, or for GXT that I can find. You'll see people recommended contacting WSDL services from the server side: http://stackoverflow.com/questions/3600723/gwt-and-webservices-wsdl More generally, Alfredo gave a fairly balanced view: it depends on how demanding your requirements are. If you need to do everything that SmartGWT grids can do, or even just a few key features (like say, freeze columns on the fly + inline filtering) you are years of RD away from that if you start with plain GWT. We know because we did the RD :) This is true even if you use incubator functionality. On Monday, October 29, 2012 2:47:08 AM UTC-7, kumar thatikonda wrote: Hi All, Can you please let me know which of the option( GWT or SmartGWT) is better, considering the below scenario. 1. Will be used for designing screens and client-side validations. 2. Performance ( page loading , grid loading) should be good. 3. Need to communicate with server through wsdls(web services.) -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/xSnb4UeByzcJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Smart GWT / GWT Ext.... which one is better?
(d) does not apply to SmartGWT. No GWT update has ever broken SmartGWT or broken backcompat. (e) does not apply to SmartGWT. Nightlies are available for all editions - see smartclient.com/builds (c) presumably means customizing a widget by messing with it's DOM or overriding internal methods. SmartGWT has a big range of documented and supported customization APIs that don't involve low-level hacking, and if these break, we consider it a bug and fix it. (a) (b) [performance stuff] needs to be considered in light of what actually drives performance for your application. SmartGWT is designed for complex enterprise applications, so we do not optimize for first-ever page load experience (doesn't apply to apps used repeatedly and for long sessions). Instead we optimize for maximal data reuse, since round-trips to the app server database are almost always the thing to optimize in enterprise apps. A deeper discussion is in the SmartGWT QuickStart Guide, Evaluating SmartGWT chapter. In a nutshell: - the drawbacks of Sencha are not the drawbacks of SmartGWT - get clarity on what performance characteristics will matter for your end users, *then* look at performance from that perspective. If you hyper-optimize the wrong thing, your app will be slow for your end users. On Sunday, September 16, 2012 10:26:02 AM UTC-7, Andrei wrote: I prefer the third option: I don't use either of them. I build very complex user interfaces, and so far I never regretted going with pure GWT. Here are a few advantages of this option: (a) Much smaller compiled code size. This also means faster compile times for developers and faster page load times for users. (b) Better performance. I had 3 years of experience with Sencha. Their widgets look nice (why we chose them in the first place), but in some complex UIs with lots of data you start to notice the lag relative to pure GWT. Remember that showcase widgets usually represent a very simple use case. (c) Easier customizations. The simpler the widget, the easier it is to modify it as you need. There is a lower probability of breaking something. (d) There is a lower probability that the next release of a library would break your code. I remember how much pain we had with Sencha's updates (2.0, 2.1, etc.) I hope it's much better now as Sencha moved closer to pure GWT implementation of their widgets. (e) Faster updates. Once a new feature is available in GWT, you can use it right away. With libraries you have to wait until their updates. I suggest that you use one of these libraries in two cases: 1. Your knowledge of CSS is not great, so you want a professional look for your app out of the box. 2. You see some widgets in these libraries that you absolutely must use, and you don't want to spend your time building them in pure GWT. P.S. Don't let GWT Designer drive your choice of a library. Once you learn GWT, you may end up never using the Designer. I find it much easier and faster to build new views in Ui:Binder, and then simply hit a refresh button in a browser to see how my page looks like. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/N01iJIj6y5wJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Smart GWT / GWT Ext.... which one is better?
(d) no release of GWT has ever broken SmartGWT. We don't rely on much from GWT other than Java-JavaScript translation, so there is little room for something to break. (c) This may refer to breakage from customizations like modifying a component's DOM or overriding internals. In SmartGWT we have documented extension points, and if they break, we consider it a bug and fix it (e) We provide nightly builds at smartclient.com/builds, so there is never a delay. (a), (b) [performance stuff] We focus on optimizing for enterprise applications, where first-time-ever page load is not much of a concern because the users repeatedly return to the app and use it for longer sessions. Similarly we focus on reducing trips to the server and/or database since this is usually the bottleneck in an enterprise application. A deeper discussion of this is in the SmartGWT QuickStart Guide, Evaluating SmartGWT chapter. In a nutshell: - your experience with Sencha breakage doesn't apply to SmartGWT - carefully consider what will actually drive performance for end users. If you heavily optimize the wrong thing, your users will have a slow application. On Sunday, September 16, 2012 10:26:02 AM UTC-7, Andrei wrote: I prefer the third option: I don't use either of them. I build very complex user interfaces, and so far I never regretted going with pure GWT. Here are a few advantages of this option: (a) Much smaller compiled code size. This also means faster compile times for developers and faster page load times for users. (b) Better performance. I had 3 years of experience with Sencha. Their widgets look nice (why we chose them in the first place), but in some complex UIs with lots of data you start to notice the lag relative to pure GWT. Remember that showcase widgets usually represent a very simple use case. (c) Easier customizations. The simpler the widget, the easier it is to modify it as you need. There is a lower probability of breaking something. (d) There is a lower probability that the next release of a library would break your code. I remember how much pain we had with Sencha's updates (2.0, 2.1, etc.) I hope it's much better now as Sencha moved closer to pure GWT implementation of their widgets. (e) Faster updates. Once a new feature is available in GWT, you can use it right away. With libraries you have to wait until their updates. I suggest that you use one of these libraries in two cases: 1. Your knowledge of CSS is not great, so you want a professional look for your app out of the box. 2. You see some widgets in these libraries that you absolutely must use, and you don't want to spend your time building them in pure GWT. P.S. Don't let GWT Designer drive your choice of a library. Once you learn GWT, you may end up never using the Designer. I find it much easier and faster to build new views in Ui:Binder, and then simply hit a refresh button in a browser to see how my page looks like. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/J5PA5KI8sSUJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: SmartGWT
Isomorphic Support routinely receives kudos from customers and the community, with 20-30 forum posts a day coming right from the dev and support teams. When we aren't helping individuals, we're creating new samples and writing new docs for everyone. This person (sbt) is not a customer, posted multiple duplicates of an elementary question covered prominently in introductory documentation, was referred politely to such documentation, posted follow-ups indicating he still hadn't read the docs he was referred to, then became abusive when both the community and Isomorphic ignored him. But don't take my word for it, here are the threads: http://forums.smartclient.com/showthread.php?t=22138 http://forums.smartclient.com/showthread.php?t=22095 http://forums.smartclient.com/showthread.php?t=22139 http://forums.smartclient.com/showthread.php?t=22106 Note these are partly duplicates - we had to delete 5 other verbatim duplicates. The more you look into criticisms of SmartGWT, the more you will find they are as baseless as this one. We offer a very high quality product, rapid innovation, and a responsive support team that aggressively fixes issues. SBT is almost certain to fly off the handle now, so just FYI, I do not plan to reply. On Monday, May 21, 2012 3:21:49 AM UTC-7, sbt wrote: It is free but their support is pathetic I experienced it. On Saturday, May 19, 2012 3:12:36 AM UTC+5, Akram.Moncer wrote: hello, is SmartGwt free for the commercial use ? thanks -- Akram MONCER Personne On Saturday, May 19, 2012 3:12:36 AM UTC+5, Akram.Moncer wrote: hello, is SmartGwt free for the commercial use ? thanks -- Akram MONCER Personne On Saturday, May 19, 2012 3:12:36 AM UTC+5, Akram.Moncer wrote: hello, is SmartGwt free for the commercial use ? thanks -- Akram MONCER Personne On Saturday, May 19, 2012 3:12:36 AM UTC+5, Akram.Moncer wrote: hello, is SmartGwt free for the commercial use ? thanks -- Akram MONCER Personne -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/r1zuSjOykAEJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To smart GWT or not
Sorry that's quite absurd: SmartGWT is often introduced to solve performance problems, and it solves them. SmartGWT is intentionally designed to have a one-time-ever download of a feature rich runtime in exchange for reducing subsequent server requests. For example, Adaptive Filtering greatly reduces the costliest types of database hits: http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_featured_category .. and allows you to introduce an extremely powerful data highlighting system with no server load at all: http://blog.isomorphic.com/?p=234 If your application is the kind we target - complex enterprise applications which are used repeatedly and for significant lengths of time - this provides a gigantic performance boost, and once-ever download of cachable JavaScript files is a negligible factor. Look at a deployed SmartGWT application and you've got users humming along, ripping through the interface and nothing being downloaded anymore because it's all cached. And everyone is getting fast responses from the database because the Smart GWT framework is minimizing database load. The larger your application becomes, the more these benefits accrue. And, by the time you've built an application with comparable functionality with core GWT or another GWT-based framework, you're going to be downloading the same size runtime as SmartGWT anyway. On Dec 1, 1:44 pm, aarnott andrew.wj.arn...@gmail.com wrote: I've found Smart GWT to have rather poor performance and it comes at the added cost of massive javascript libraries (even when they are gzipped). If you are anything like me, you will probably find that you lose time in the long run by going with Smart GWT because you will want to get rid of it later to boost performance. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: anything like smartgwt but totally compatible with gwt?
That JMeter testing sounds invalid. You're simulating the repeated download of static resources that in reality happens once ever per user. SmartGWT is designed for applications that are used more than once per user, and/or that users spend at least a few minutes with. In that scenario, features like Adaptive Filtering greatly reduce the number of requests sent *after* page load, while the user is using the application: http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_featured_category For the enterprise applications SmartGWT is designed for, it's the most scalable solution available, because it reduces expensive database search operations in exchange for a once-ever download of static, cacheable files. Finally, on interoperability, the original poster never said what concrete components he had trouble with, but as others have posted, if you need to add selected GWT widgets to your SmartGWT interface, that works fine. 100% interoperability is a bit of a myth. There's a bunch of widgets available for GWT with varying degrees of quality. If you grab random third-party or incubator GWT widgets and start mixing them into complex layouts, you're going to run into problems as well. On Nov 14, 11:46 am, Sunit Katkar sunitkat...@gmail.com wrote: I have found that pure GWT works best, at least for our application. Since our app is used by thousands of users at a given time, we wanted to keep the code that gets downloaded and interpreted on the browser to a minimum. Also to avoid having to look up different vendors for fixes, etc. we chose to use just Google GWT. Yes, we had to write a few CSS styles on our own, but given the type of application and the scalability requirements, we found that pure GWT works best. The money spent on a graphic artists services for creating good looking light weight CSS and icons has paid back already. For the admin side of our app we had the first version with SmartGWT, but have now migrated that to pure GWT. SmartGWT is a good toolkit but to address scalability and load conditions, our tests (using GWTRPCCommLayer and JMeter, combination et-al) found that pure GWT was definitely performing better. So we did away with SmartGWT. - Sunit Katkarhttp://sunitkatkar.blogspot.com/ On Sat, Nov 13, 2010 at 6:13 AM, gcstang gcst...@gmail.com wrote: Not sure about UIBinder never tried it, however I know if you use SmartGWT and put GWT panels on it they work. I've also tried the GWT Code Splitting, GWT Visualizations and GWT Log and they all work as well. Hope that helps some. On Nov 12, 4:27 pm, Sachin Dole sachin.d...@gmail.com wrote: but isnt it true that you cant use uibinder with smartgwt? isnt it true that if you use smartgwt widgets and put them inside of a gwt panel, things dont look as you'd expect them to? we have avoided mixing plain gwt widgets with smartgwt widgets because widgets dont show up in the right place or dont show up at all. plus, smart gwt's styling mechanism doesnt apply to the gwt widgets. i guess my interoperability i meant mixing smartgwt and gwt widgets together in the same app within each other... thanks for your input! On Thu, Nov 11, 2010 at 11:48 AM, Dan Billings debil...@gmail.com wrote: Yeah I find it fully interoperable. On Nov 11, 7:17 am, gcstang gcst...@gmail.com wrote: Not sure what you mean by interoperable, if you could give examples it would help. I've been using SmartGWT for a while on an Admin type tool for our commerce suite and so far it has been very useful. On Nov 10, 11:29 am, Sachin Dole sachin.d...@gmail.com wrote: Hey Guys, At our workplace, we use smartgwt and like it because of the widgets it provides but hate it cuz its not interoperable with gwt. Is there another library that is 100% interoperable with gwt? Or, has anyone used smartgwt in a manner totally inter-operable with gwt? I know, there are degrees of interoperability that one can live with, however, i am looking for the extreme case (100% interoperable). Thank you folks. Sachin -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com google-web-toolkit%2bunsubscr...@googlegroups.comgoogle-web-toolkit%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to
Re: Memory Leak IE7 GWT 2.0.4
Just one more note on this: in SmartGWT calling destroy() on a parent automatically destroy()s all children recursively, all widgets that generate children (eg ListGrids generate a header) automatically destroy those children with themselves, and removed tabs automatically destroy their panes unless you tell them not to. The net result of this is that there's no need for a manual destroy() call anywhere in the Showcase, or in most applications that use the pattern of generating new tabs. Further, in any situation where you're trying to permanently get rid of a component, where you would otherwise call something like layout.removeMember(member) you just call member.destroy() instead (and this takes care of layout removal as well). Just wanted to clarify all this since there was speculation the strategy would be rife with problems and very hard for users to get right. It's understandable that experience with some previous framework would make someone think so, but it's very easy in SmartGWT, and we think an explicit destroy() is the right approach in terms of giving us the opportunity to work around browser garbage collection bugs. On Sep 7, 7:22 pm, ckendrick charles.kendr...@gmail.com wrote: Just a note onSmartGWT- Built-in GWT widgets rely on the browser to garbage collect a detached DOM tree. In older browsers like IE6/7 we found a number of cases where this didn't work completely, so we opted for manual destroy(). It's possible that as of IE8/9 all such leaks are gone (personally I find this unlikely :), but, we're not really interested in finding out. And yes, we have tools that make leaks obvious - the Watch Tab in the Developer Console, which shows a tree of all components. You tend to spot leaked components right away while using the tool for other purposes. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Memory Leak IE7 GWT 2.0.4
Just a note on SmartGWT -
Built-in GWT widgets rely on the browser to garbage collect a detached
DOM tree. In older browsers like IE6/7 we found a number of cases
where this didn't work completely, so we opted for manual destroy().
It's possible that as of IE8/9 all such leaks are gone (personally I
find this unlikely :), but, we're not really interested in finding
out.
And yes, we have tools that make leaks obvious - the Watch Tab in the
Developer Console, which shows a tree of all components. You tend to
spot leaked components right away while using the tool for other
purposes.
On Sep 3, 5:12 am, Joel Webber j...@google.com wrote:
@Marcos:
I wish I could do more to help with memory leaks in SmartGWT, but
that's way beyond the knowledge of anyone on our team. SmartGWT's a
wrapper around a huge Javascript library that, from your earlier post,
appears to require destroy() calls on widgets as part of its memory-
leak strategy (IIUC). That strategy's rife with problems and very hard
for users to get right in practice (I've tried it in other frameworks,
and always found myself squashing leaks ad infinitum). Do the SmartGWT
tools not provide some mechanism for tracing and finding leaks?
On Aug 30, 9:10 am, chrisr chris.robert.rowl...@gmail.com wrote:
This may be a valid solution, however its not an ideal one, as this
application is already significantly large, and its not going to be
easy to refactor all of the existing code to work this way. It will
be easy to keep this in mind while going forward, however.
As I said above, I was trying to reproduce the way a lot of the code
I'm working with has been written. Also, while I thought this was
reproducing the situation we are seeing in our live app (using GWT
1.5.4) it turns out this only produces the memory leak in development
mode using the most recent GWT. I will have to see if this produces a
leak when compiled using 1.5.4. If not then I'll probably need to
find a new simple case that reproduces the leak we're seeing.
On Aug 28, 11:48 am, Michael W mwang_2...@yahoo.com wrote:
I doubt following code causing the memory leak.
In reloadRight method, you create and assign new DecoratedTabPanel()
to tabPanel every time.
protected void reloadRight(){
++rightPanelCount;
rPanel.clear();
tabPanel = new DecoratedTabPanel();
You may reuse existing tabPanel instead of create new one.
On Aug 27, 4:21 pm, chrisr chris.robert.rowl...@gmail.com wrote:
Hi Joel, i appreciate your help.
I was running in development mode and it appears that this memory
bloat goes away when not using development mode.
We have been developing our application using older GWT (1.5.4 I
belive) so I'm used to using the old hosted mode. I didn't realize
the in browser development mode might have this side effect.
The goal of this was to reproduce a memory leak that we have in our
application (when compiled, of course) using as simple a case as
possible, in the newest version of GWT, if possible. I erroneously
thought this was accomplishing that.
Does the fact that this growth occurs in development mode suggest
anything about why I might see similar growth in a compiled GWT 1.5.4
application?
On Aug 27, 12:52 pm, Joel Webber j...@google.com wrote:
Hmm... I've tried to reproduce this on IE7 and IE8 (both quirks
standards), to no avail. I doubt it's anything in the outer HTML file,
but just in case, here's what I used:
!DOCTYPE HTML
html
head
titleHello/title
script type=text/javascript language=javascript src=hello/
hello.nocache.js/script
/head
body
div id='container'/div
/body
/html
The initial calls to getSomeText() were causing a huge number of slow-
script warnings on IE, so I was only able to run through a few
iterations. I then dropped the count by a factor of 10 to get the SSWs
under control, and the memory usage appears quite stable after a
couple of hundred clicks. (~30MB). Can you think of anything else that
might be different in your setup?
On 27 août, 08:20, chrisr chris.robert.rowl...@gmail.com wrote:
Sorry for posting this twice. If a moderator wants to/can remove
the
duplicate go ahead.
On Aug 25, 2:56 pm, chrisr chris.robert.rowl...@gmail.com wrote:
I created a simple application in an attempt to reproduce a memory
leak issue in our decently large GWT application.
This test application basically contains a split panel with a
button
on the left, and a tab panel full of large blocks of text on the
right.
Clicking the reload button fires the reloadRight method, and does
a
panel.clear() to remove the old tab panel and a panel.add() to
Re: HELP Problem JPA with the datasource of smartGWT
You should post this in the SmartGWT forums at forums.smartclient.com. On Jun 14, 8:09 am, samounas elmokhtari.as...@gmail.com wrote: Can u help me please? On 14 juin, 14:55, samounas elmokhtari.as...@gmail.com wrote: Hi, I have a problem with the file mapping of JPA anddatasource.xmlof smartGWT. changes made in the mapping file in JPA does not appear in the datasourceor in the database. Please can anybody help me find the solution? -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: GWT or SmartGWT and Oracle - Stored procedures
Be sure to compare the cost of the product to the value of your time spent re-creating the same functionality, maintaining it, and missing out on all features we keep adding to the SQL subsystem. As well as not finishing your project as soon, slipping deadlines etc. As well as delivering a weaker final application because you spent time re- creating features of Pro/Power. In most cases, for a professional developer, the license cost is very low compared to all of these costs. However if you still need to find a way to cut corners, just use Pro, priced at $745. It's true, you miss out on the extremely powerful SQL templating feature, but you can write a small amount of JDBC code as a DMI for the cases where you want to call a stored procedure, and you'll still have all the standard CRUD operations, automatic server validation, queuing, exports, and other features of Pro. On Jun 17, 6:21 am, kensai yanesha archenr...@googlemail.com wrote: Well, I went trough many tutorials and howtos on internet. The one was amazing and it solved all my needs.DataSourcedefinition is in XML and I can execute CRUD operations using storedc procedures on the database side. I am talking about project SmartClient. One can defineDataSourceusing this way: DataSource dbName=mydb tableName=mytbl ID=myDS dataSourceVersion=1 generatedBy=SC_SNAPSHOT-2009-12-17/EVAL Deployment 2009-12-17 serverType=sql fields field name=wssSourceID type=integer/field field name=watchID type=integer/field /fields operationBindings operationBinding operationType=update allowMultiUpdate=true customSQLcall spUpdateWSSWatchSources($values._watchID, $wssSourceIDs)/customSQL /operationBinding /operationBindings /DataSource This is very easy to write, but licence for one developer could be very expensive, I think about almost 2000 dolars for the Power version which supports the SQL templating, exactly putting into the XML definiton of thedatasourceelement customSQL I can forget buying this for this project, maybe in the future. But what next? How to proceed withSmartGWTand SQL engine? Current answer is using EoD SQL as ORM subsystem. There are some bad things about loosing lazzy loading feature, etc., but in my case it seems to be the best way now as you can see at:http://lemnik.wordpress.com/2009/09/18/eod-sql-applied-%E2%80%93-part... Any your suggestion would be helpful. Kensai On 17 čvn, 09:32, kensai yanesha archenr...@googlemail.com wrote: The database could be any SQL engine, so the dataserver type schould be sql not hibernate. On 17 čvn, 06:18, kensai yanesha archenr...@googlemail.com wrote: Hello, I am new to GWT at all. My approach is to have an editable grid on the client side and one or more tables on the database side (Oracle in my case). Could someone post really working project with all files which supports all 4 standard operations (select, insert, update, delete)? In my case I want to do all these operations using stored procedures to avoid SQL injection attacks. Any external link or pure sample will help. I was not able to find any complete project which is I think best to learn it as complex logic. Thank you very much. Kensai -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: gwt webgl smartgwt
What layout issue on what browser with what code? This is not a known issue, so to get it addressed, post a test case to the SmartGWT forums: http://forums.smartclient.com/forumdisplay.php?f=14 On May 11, 12:25 pm, Alan Chaney a...@mechnicality.com wrote: Hi I've started to build an application using GWT 2 which will needs an HTML 5 canvas element to display WebGL. I was intending to use smartgwt for the bulk of the UI. Sadly, smartgwt gives layout problems when I add the !doctype html required by HTML 5 to the main html page of my app. Hopefully this will be fixed in a future version of smartgwt, but does anyone have any ideas for a workaround? For example, could I create a widget which wrapped an iframe and set the URL of the iframe to a page with an html 5 doctype? I could then use this widget to embed my webgl viewer. Any suggestions welcome! Thanks! Alan -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/google-web-toolkit?hl=en. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: GWT Grid vs. SmartGWT grid
Someone off-list took some of my comments the wrong way. I'd just like to clarify, as long as GWT is targeting the ultralight use case of an application that must be as fast as possible on first access, it makes sense for GWT to rely on browser layout and just provide direct CSS for skinning. It's not something I'm saying is a flaw in GWT or a bad design decision, in fact, it's the same decision I would make in addressing that use case. The reason is simply that it takes a certain irreducible amount of code to really build layouts that don't depend on native browser behavior, and that's too much to deliver for the ultralight use case. It's just different designs for different use cases. I hope the core GWT widgets continue to focus on the ultralight use case, because there's just nothing comparable, especially for mobile. On Mar 12, 12:44 pm, ckendrick charles.kendr...@gmail.com wrote: And here are the authors to disagree :) 1) Yes, we make intentional departures from the GWT way, such as.. 2)SmartGWThas better cross-browser consistency than GWT itself. Why? Because GWT relies on native browser behavior and CSS for layout, and this is where all the quirks come from. We do layout with layout manager classes, more in the style of Java Swing. Yes, GWT has layout managers, but what they're actually doing in many cases is relying on the browser interpretation of sizes and layout rules. Also, re-skinning your application with GWT is straight CSS, whereasSmartGWTprovides an abstraction that separates styling-as-such from layout. 3) The library is cached, so you only increase the first-ever load time. If you have a site where you are trying to display something as fast as possible for a visitor who comes only once, this may matter. If you're building an enterprise application and people use it regularly, it doesn't matter, the extreme productivity benefits of theSmartGWTgrid (and other components) are much more important. On broadband,SmartGWTapplications come up faster than the launch time of Word or Acrobat, so it's right in line with user expectations for enterprise/desktop applications. As far as the future, my take is that GWT cannot both retain an ultralight footprint *and* provide the features of an enterprise platform likeSmartGWT- static code analysis just isn't a strong enough approach to code trimming to enable this. I covered this in depth here: http://www.mail-archive.com/google-web-toolkit@googlegroups.com/msg34... You've also got to consider the state of the art, of course. Will your customers be doing a head-to-head comparison on functionality and productivity between your competitor, who usedSmartGWT, and your app, which uses plain GWT grids? That's going to go very badly against you. On Mar 12, 1:58 am, Nathan Wells nwwe...@gmail.com wrote: I would say you are correct on the disadvantages ofSmartGwt. There are those (most notably the author(s)) who I know disagree with me. GWTers recognize the need for a more robust, data-backed table solution, and it's currently in the works, targeted for 2.1. Our company decided to go withSmartGwtfor now, then migrate to a more Gwtfull solution later. On Mar 12, 1:29 am, mariyan nenchev nenchev.mari...@gmail.com wrote: Try scroll paging table from gwt incubator, i think it was updated to gwt 2.0. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: GWT Grid vs. SmartGWT grid
And here are the authors to disagree :) 1) Yes, we make intentional departures from the GWT way, such as.. 2) SmartGWT has better cross-browser consistency than GWT itself. Why? Because GWT relies on native browser behavior and CSS for layout, and this is where all the quirks come from. We do layout with layout manager classes, more in the style of Java Swing. Yes, GWT has layout managers, but what they're actually doing in many cases is relying on the browser interpretation of sizes and layout rules. Also, re-skinning your application with GWT is straight CSS, whereas SmartGWT provides an abstraction that separates styling-as-such from layout. 3) The library is cached, so you only increase the first-ever load time. If you have a site where you are trying to display something as fast as possible for a visitor who comes only once, this may matter. If you're building an enterprise application and people use it regularly, it doesn't matter, the extreme productivity benefits of the SmartGWT grid (and other components) are much more important. On broadband, SmartGWT applications come up faster than the launch time of Word or Acrobat, so it's right in line with user expectations for enterprise/desktop applications. As far as the future, my take is that GWT cannot both retain an ultralight footprint *and* provide the features of an enterprise platform like SmartGWT - static code analysis just isn't a strong enough approach to code trimming to enable this. I covered this in depth here: http://www.mail-archive.com/google-web-toolkit@googlegroups.com/msg34128.html You've also got to consider the state of the art, of course. Will your customers be doing a head-to-head comparison on functionality and productivity between your competitor, who used SmartGWT, and your app, which uses plain GWT grids? That's going to go very badly against you. On Mar 12, 1:58 am, Nathan Wells nwwe...@gmail.com wrote: I would say you are correct on the disadvantages of SmartGwt. There are those (most notably the author(s)) who I know disagree with me. GWTers recognize the need for a more robust, data-backed table solution, and it's currently in the works, targeted for 2.1. Our company decided to go with SmartGwt for now, then migrate to a more Gwtfull solution later. On Mar 12, 1:29 am, mariyan nenchev nenchev.mari...@gmail.com wrote: Try scroll paging table from gwt incubator, i think it was updated to gwt 2.0. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
[ANN] Smart GWT Pro/EE 2.1 released
In addition to new client-side features already detailed here: http://www.jroller.com/sjivan/entry/smart_gwt_2_1_released New server features: * New built-in server-side validators isUnique makes it trivial to enforce common cases like having a unique user name. http://www.smartclient.com/smartgwtehtml#ISUNIQUE hasRelatedRecords can enforce that inter-record references are valid http://www.smartclient.com/smartgwte...SRELATEDRECORD * Declarative custom server validation: use a Velocity expression or Java method http://www.smartclient.com/smartgwte...lang.String ) http://www.smartclient.com/smartgwte...l#serverObject * Declarative security settings (zero code integration with JAAS / J2EE security) http://www.smartclient.com/smartgwte...Authentication http://www.smartclient.com/smartgwte...l#requiresRole * Bulletproof setup guide with troubleshooting section http://www.smartclient.com/smartgwte...wtEESetup.html To download the free evaluation or read overviews of the functionality, go here: http://forums.smartclient.com/showthread.php?t=4839 -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Smart GWT Pro/EE 2.1 released
Apologies for the second posting. Some links were mangled, they are corrected below. In addition to new client-side features already detailed here: http://www.jroller.com/sjivan/entry/smart_gwt_2_1_released New server features: * New built-in server-side validators isUnique makes it trivial to enforce common cases like having a unique user name. http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/types/ValidatorType.html#ISUNIQUE hasRelatedRecords can enforce that inter-record references are valid http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/types/ValidatorType.html#HASRELATEDRECORD * Declarative custom server validation: use a Velocity expression or Java method http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/widgets/form/validator/Validator.html#setServerCondition(java.lang.String) ]http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/ client/docs/serverds/Validator.html#serverObject * Declarative security settings (zero code integration with JAAS / J2EE security) http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/docs/serverds/DataSource.html#requiresAuthentication http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/docs/serverds/OperationBinding.html#requiresRole * Bulletproof setup guide with troubleshooting section http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/docs/SgwtEESetup.html To download the free evaluation or read overviews of the functionality, go here: http://forums.smartclient.com/showthread.php?t=4839 -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Ext/GXT/ExtGWT v2.1.0 vs. SmartGWT v2.0
Carl, On skins, you don't sound as though you've looked at the Showcase since 2.0, when we made a series of improvements which now has most users commenting that our skins are sharper than GXTs. On grids, this is the first time I've ever seen someone claim the GXT grids are better, I really don't think you took more than a cursory look at the samples. Here are some of the largest features missing from GXT's grids (there are many many more): Adaptive Filtering http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_featured_category Databound Dragging http://www.smartclient.com/smartgwt/showcase/#grid_db_dragging_featured_category Custom nested components (embed anything) http://www.smartclient.com/smartgwt/showcase/#featured_nested_grid http://www.smartclient.com/smartgwt/showcase/#grid_nested_form_new_category Pluggable data models (build a master-detail component for any data model) http://www.smartclient.com/smartgwt/showcase/#featured_master_detail Frozen columns with editing, drag and drop and all other features still supported http://www.smartclient.com/smartgwt/showcase/#grid_frozen_editing Multi-level sort http://www.smartclient.com/smartgwt/showcase/#grid_multisort_new_category Automatic cache synchronization on update http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/data/ResultSet.html Multi-level filtering http://www.smartclient.com/smartgwt/showcase/#grid_nested_filter_builder Multiple rows of headers http://www.smartclient.com/smartgwt/showcase/#grid_appearance_header_spans User-specified formula and summary columns http://www.smartclient.com/smartgwt/showcase/#grid_appearance_formula_sumamry_builder Also, once again, these features work *together*. There are many combinations of GXT features that don't (eg Live Grid and most major grid features), and if you go with some hack from the forums to enable one of the missing features, you'll find even less compatibility with other features (and no support). Just didn't want anyone to think the grids are even close to comparable. The features above are all part of the free LGPL edition by the way. On Feb 14, 7:00 pm, Carl Pritchett bogusggem...@gmail.com wrote: We have used GXT from 1.2 to 2.1.1 on a mid-sized project. Pros - I think the look and feel is sharp and responsive (much nicer thatSmartGWTIMHO - but look at the showcases and judge for youself). - Grids are the best I've seen (sorrySmartGWT) but no lockable columns (which Smart does have) - we had to write our own (I've posted them on the forums) - It's all java and it's trivial to debug / overrride features - Good community in the forums - Bugs get fixed if you are persistent enough Cons - Quirky bugs and behaviour changes in each version - need to check for regression when taking an upgrade. - Only first point release if available if you don't have a support contract (even if you buy the product) and there can be a long wait (for your business / customers) between versions. - Mostly trivial examples in showcase that aren't like an app you will build (though to be fair same can be said for most GWT frameworks) - Not much doco / java doc, which can make complex apps / layouts difficult to get right - some unexpected behaviours -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Ext/GXT/ExtGWT v2.1.0 vs. SmartGWT v2.0
Um, so, it was pointed out to me that I missed some major ones. Even some I wrote personally :) Drag Reorder of columns http://www.smartclient.com/smartgwt/showcase/#grid_appearance_columnorder The CubeGrid (multi-dimensional data model support) http://www.smartclient.com/index.jsp#basicCube http://www.smartclient.com/index.jsp#analytics A whole range of autoFit behaviors (not just this sample, the whole folder) http://www.smartclient.com/smartgwt/showcase/#grid_autofit_filter Also, the fact that all of these features also apply to TreeGrids (eg frozen columns and full-row editing). Also, SmartGWT's data connector architecture and it's ability to support multiple caches on the same large data set, with independent search criteria, sort direction, etc. This is needed for dozens of use cases involving large data sets, such as moving records from one category to another by drag and drop. GXT's Store is extremely primitive by comparison and a lot of manual effort is required to achieve something like this: http://www.smartclient.com/smartgwtee/showcase/#row_drag_save I have probably missed another 9 major grid features, and this only covers feature advantages related to grids, however this and my previous post are probably the best answer to the original question: what are the technical advantages. On Feb 15, 12:02 pm, ckendrick charles.kendr...@gmail.com wrote: Carl, On skins, you don't sound as though you've looked at the Showcase since 2.0, when we made a series of improvements which now has most users commenting that our skins are sharper than GXTs. On grids, this is the first time I've ever seen someone claim the GXT grids are better, I really don't think you took more than a cursory look at the samples. Here are some of the largest features missing from GXT's grids (there are many many more): Adaptive Filtering http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_fe... Databound Dragging http://www.smartclient.com/smartgwt/showcase/#grid_db_dragging_featur... Custom nested components (embed anything) http://www.smartclient.com/smartgwt/showcase/#featured_nested_grid http://www.smartclient.com/smartgwt/showcase/#grid_nested_form_new_ca... Pluggable data models (build a master-detail component for any data model) http://www.smartclient.com/smartgwt/showcase/#featured_master_detail Frozen columns with editing, drag and drop and all other features still supported http://www.smartclient.com/smartgwt/showcase/#grid_frozen_editing Multi-level sort http://www.smartclient.com/smartgwt/showcase/#grid_multisort_new_cate... Automatic cache synchronization on update http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/dat... Multi-level filtering http://www.smartclient.com/smartgwt/showcase/#grid_nested_filter_builder Multiple rows of headers http://www.smartclient.com/smartgwt/showcase/#grid_appearance_header_... User-specified formula and summary columns http://www.smartclient.com/smartgwt/showcase/#grid_appearance_formula... Also, once again, these features work *together*. There are many combinations of GXT features that don't (eg Live Grid and most major grid features), and if you go with some hack from the forums to enable one of the missing features, you'll find even less compatibility with other features (and no support). Just didn't want anyone to think the grids are even close to comparable. The features above are all part of the free LGPL edition by the way. On Feb 14, 7:00 pm, Carl Pritchett bogusggem...@gmail.com wrote: We have used GXT from 1.2 to 2.1.1 on a mid-sized project. Pros - I think the look and feel is sharp and responsive (much nicer thatSmartGWTIMHO - but look at the showcases and judge for youself). - Grids are the best I've seen (sorrySmartGWT) but no lockable columns (which Smart does have) - we had to write our own (I've posted them on the forums) - It's all java and it's trivial to debug / overrride features - Good community in the forums - Bugs get fixed if you are persistent enough Cons - Quirky bugs and behaviour changes in each version - need to check for regression when taking an upgrade. - Only first point release if available if you don't have a support contract (even if you buy the product) and there can be a long wait (for your business / customers) between versions. - Mostly trivial examples in showcase that aren't like an app you will build (though to be fair same can be said for most GWT frameworks) - Not much doco / java doc, which can make complex apps / layouts difficult to get right - some unexpected behaviours -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr
Re: Ext/GXT/ExtGWT v2.1.0 vs. SmartGWT v2.0
Just to sum up, the only people in this thread reporting negative hands-on experiences with SmartGWT have all gone against our explicit advice in the documentation, FAQ, and in some cases, personal attention in the forums. The only person with hands-on experience claiming there are bugs turned out to be talking about a particular, narrow Calendar enhancement that he was displeased had not received more attention. The actual samples should be self-explanatory. The functionality demonstrated is extremely broad and deep, the code required is clear and concise, it's difficult to find a bug and what few exist are addressed quickly. See for yourself. http://www.smartclient.com/smartgwt/showcase/ http://www.smartclient.com/smartgwtee/showcase/ -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Ext/GXT/ExtGWT v2.1.0 vs. SmartGWT v2.0
@Jeff, ahhughes: as far as the built-in GWT widgets, they are well- designed and fine for simple things, but if your requirement is to have a grid that supports full-row inline editing, grouping, filtering, frozen columns, paging through large datasets, resizable/ reorderable headers with persistence, nested headers, all of this active at once - or if you need even a significant subset of this functionality - this will take you a minimum of 2 years with core GWT and you will achieve it really only with a ground-up custom widget that you will need to maintain. So it's just a matter of recognizing that many people have requirements that go way, way beyond the core GWT widgets. Google employees have posted a number of times acknowledging this. Note that even if you don't have hard requirements for these features, the fact is that they make your application better, and you will never have to deal with a user request for such a feature: it's already there. ahhughes as far as your #2, please point to examples. Almost everyone who has *actually tried* SmartGWT remarks on the extremely low number of bugs. @Tercio, mariyan: unclear on why you found server integration with the SmartGWT LGPL version difficult. All you need to do is expose your EJBs as REST services and there are countless tutorials on the web on how to do this, as well as frameworks that can do this from Java annotations. People achieve this all the time. Tercio in particular, I'm guessing this was you: http://forums.smartclient.com/showthread.php?t=5632 You took the wrong approach, and our Support staff told you it wasn't a good idea and gave you appropriate alternatives. As far as useless features, if you think they're useless, you frankly have not absorbed what they actually do. Remember, Isomorphic is a consulting company too. We build applications in defense, life sciences, insurance, financials and many other verticals. We use the features of Pro/EE *every single time*. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Ext/GXT/ExtGWT v2.1.0 vs. SmartGWT v2.0
Re: widgets inside grid rows: not only is it out of the box in SmartGWT, there are multiple out of the box modes for it, including nested editable grids. http://www.smartclient.com/smartgwt/showcase/#featured_nested_grid http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/types/ExpansionMode.html In the latest nightlies you can play with yet another level of sophistication, for release in 2.1: 1. general purpose APIs for attaching components to any individual cell or row, with multiple sizing modes 2. support for automatic pooling of components at the record level, for use cases where you have components in most/every row and you are paging through a large dataset and need to re-use a pool of components attached to the currently visible records If it's a positive experience to have to fix a lot of bugs, and have to add missing features, can't wait to see what you guys say when you evaluate SmartGWT for your next project ;) -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Ext/GXT/ExtGWT v2.1.0 vs. SmartGWT v2.0
@Tercio I'm not able to follow the distinction you wish to make between behavior and functionality, but in terms of what the Java language calls an override, yes SmartGWT supports it. Demonstrated here among many other places: http://www.smartclient.com/smartgwt/showcase/#grid_appearance_hilite_add As far SmartGWT's free vs commercial breakdown is exceeding the simple: the commercial versions include Java Server functionality. It's explained clearly here: http://www.smartclient.com/product/ We also make a nice clean, clear distinction in the showcases. Everything in this one is free: http://www.smartclient.com/smartgwt/showcase/ This one has commercial functionality: http://www.smartclient.com/smartgwtee/showcase/ There is no mystery or risk regarding what is free and what is not, or whether it's useful. Some other mis-statements in this thread: 1. the free version of SmartGWT supports databinding as well. Approaches are covered here: http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/docs/ClientDataIntegration.html 2. someone mentioned already having a server. SmartGWT's server- side functionality integrates with any pre-existing server-side functionality and provides features that don't exist in any server- side library, so it applies regardless of whether you have a server or not. Two examples: Client and server-side validation driven from a single definition, so you don't have to set up validation logic in both places: http://www.smartclient.com/smartgwtee/showcase/#data_integration_form_validation Automated aggregation of client-side requests into a compound request to make transaction handling easier, cut down on HTTP requests and simplify the re-use of data services: http://www.smartclient.com/smartgwtee/showcase/#row_drag_save And a deeper explanation of how SmartGWT's server-side features apply even if you have a pre-existing persistence system and business logic: http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/docs/FeaturesCustomPersistence.html OK, that's it from the misconception police for today :) On Feb 1, 6:24 am, Tom Schindl tomson...@gmail.com wrote: Though many people think that Overloading/Overwriting and JSNI don't really fit together. I think they do if you are a bit creative. If you are interested in how I solved this problem for QxWT you should take a look at this series of posts. [1]http://tomsondev.bestsolution.at/2010/01/05/background-to-qxwt-and-gw... [2]http://tomsondev.bestsolution.at/2010/01/10/qxwt-explained-part-2/ [3]http://tomsondev.bestsolution.at/2010/01/12/qxwt-explained-part-3/ [4]http://tomsondev.bestsolution.at/2010/01/15/qxwt-explained-part-4/ The overloading/overwriting use case is discussed in [3]. I have no deeper insights in SmartGWT but I guess writing something like this is possible for their set of widgets as well (Probably one can extract the code I've written for QxWT and make it useable to any JSNI-Wrapper and even improve the functionality e.g. calling back to JavaScript without writing any line of code, ... a rather advanced example can be found here [5]). BTW QxWT is completely free - everything is dual licensed under EPL and LGPL. Tom [5]https://svn.tomsondev.com/svn/ufacekit/qx/org.ufacekit.qx.viewers/src... On Mon, Feb 1, 2010 at 2:44 PM, Tercio terciofi...@gmail.com wrote: - Both GXT and Smart GWT are pure gwt (no underlying native JS library, so expect equivalent speed/performance from the GWT compiler). Nope, SmartGWT is a wrapper to SmartClient JS Library. ckendrick and I have different understandings about override ... :-P We already discussed this some time ago ... SmartGWT you can't override it's functionality, just it's behavior. SmartGWT is more feature rich than GXT, but I don't like their licensing terms, I prefer GXT one, not only because the price, but the features, we just need a UI framework, the server we already have one. Regards. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/google-web-toolkit?hl=en. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Ext/GXT/ExtGWT v2.1.0 vs. SmartGWT v2.0
With SmartGWT you can also extend widgets and override methods in pure Java. Just a tour through the SmartGWT and SmartGWT Pro/EE showcases should be enough to identify a number of feature advantages which may matter for your application. http://www.smartclient.com/smartgwt/showcase/ http://www.smartclient.com/smartgwtee/showcase/ On Jan 29, 4:58 am, Siegfried Bolz siegfried.b...@googlemail.com wrote: I am currently using GXT 2.1.0 on a big customer project and my experience is, that it is a great framework to produce fast results. There are some bugs in each release but you have the possibility to override the methods to fix the bug by yourself. If you want to extend a widget, it is possible. One reason where i think this could be a problem in the future, is that GXT use Listeners instead of Handlers. With release 3, i think there could be a big API change coming. On 29 Jan., 01:16, ahhughes ahhug...@gmail.com wrote: For future reference At the time of writing the following are available: GWT v2.0 and. SmartGWT v2.0 (http://code.google.com/p/smartgwt/underApache License) Ext GWT v2.1.0 (http://www.extjs.com/products/gxt/underweird LGPL License) I don't want to discuss Ext GWT's weird license. It's weird, there's no updates... e.t.c. e.t.c. The question is, if why would you purchase it over SmartGWT? I am looking for technical reasons such as features, performance, jsni wrap vs pure compiled gwt, or especially full GWT 2.0 compatibility e.t.c. Help would be great as there are so many re-packed versions of these things floating around as well as the fact a lot of information is out of date (and so will this thread be in the not so distant future). Thanks heaps in advance :) -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: SmartGWT?!
On Jan 12, 3:43 pm, Open eSignForms yoz...@gmail.com wrote: If you need the widgets now, SmartGWT seems like a fine solution, and the LGPL is a nice license if you don't otherwise need their server-side/enterprise features. Pure GWT just doesn't have those grids and such yet, but it sounds like the basics are coming in 2.1. ... It would be so much easier if GWT were 2 years older smile. Time will tell, but looking at the widget upgrades in GWT 1.0 to 2.0, they are not at all on a trajectory to catch up to SmartGWT or even to ExtGWT. They seem to be focused principally on core GWT enhancements, and they are falling further behind on widgets and robust data binding features. It's unclear whether Google even intends to deliver enterprise-grade widgets. As I've covered, adding full-on enterprise-class widgets is mutually exclusive with continuing to handle the ultralight use case - if your grid is capable of filter, sort, grouping, inline editing, frozen columns and all the other features expected from grids in enterprise software, it's not going to be ultralight. People routinely state that the GWT compiler removes unused code, but this is extremely misleading, what it really does is remove code that it *determines by static analysis can never be called*. Static analysis is very weak when it comes to the intertwined features of advanced widgets, and it won't remove the bulk of the code related to major cross-cutting features, even if those features are disabled in your application. As a simple example, if the grid supports frozen columns, all the grid code related to event handling, selection, column sizing and re-sizing and various other subsystems necessarily takes into account frozen columns - it's pervasive. Substantially all of that code will be present at runtime even if your application does not use the frozen column feature. So, if GWT eventually offers a widget set for high-end enterprise applications, I would expect a separate widget set rather than upgrades to existing widgets - otherwise they'd alienate the existing user base of people with the ultralight use case. And if you want a mixture of ultralight and enterprise-grade widgets that you use separately, there's nothing to wait for, that's what you already have with core GWT and alternative widget sets like SmartGWT. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Use smartgwt or not
Incorrect, SmartGWT allows both. Purchasing a license does not imply that you *must* use the closed-source server-side portion. If you use just the capabilities of SmartGWT LGPL, you can offer the LGPL licensing terms to customers that prefer it, and you can purchase a license from Isomorphic to obtain different terms for customers who do not want the LGPL license. Several of our customers do this for precisely this reason (needing an all-OSS version of their product). On Jan 4, 3:44 pm, Open eSignForms yoz...@gmail.com wrote: As for SmartGWT, their LGPL product looks great and would pose no issue, but if you want their more advanced stuff for server-side code, you'd need to go commercial, which itself is not bad for us, but then it makes it impossible for us to offer our code as open source -- we want to do both open source for the open source community, but know that we have to offer commercial licenses to our business customers who demand that their systems be allowed to be proprietary. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: SmartGWT?!
On Jan 12, 12:39 pm, Kenny G ken.grei...@gmail.com wrote: I found it well worth the time to use, even though I did not use the Datasource features to populate grids. Whoah! Kenny you should really try the DataSource feature next time, you have so far used less than half of what even the free (LGPL) version provides, let alone the commercial versions. DataSources are the cornerstone of the entire architecture. On the other comments: it has been said before but bears repeating: the GWT compiler is not magic. It will not produce better JavaScript than hand-written JavaScript from proficient JavaScript developers. Coding in JavaScript directly we have the opportunity to take advantage of how JavaScript applies to the particular thing we are coding, as opposed to the GWT's compiler's task of trying to come up with code that translates a Java approach to a problem which may be quite indirect and inefficient as compared to the obvious approach in JavaScript. And also: Yes, the SmartGWT core runtime does not benefit from code splitting, although your application code will. However, this is irrelevant for the type of application SmartGWT targets: sophisticated enterprise applications. If your final application consists of a number of screens involving grids, forms, validation and so forth, you are going to reach a similar core size regardless of whether you use SmartGWT or another technology. If you have an ultralight use case, like adding a small amount of interactivity to an otherwise content-based site, you want to go with core GWT or even something lighter like JQuery - any toolkit that includes enterprise-grade grids and forms is going to have a large irreducible core size as soon as you touch more than a handful of APIs. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Use smartgwt or not
On Dec 26 2009, 3:51 am, gaill...@audemat.com gaill...@audemat.com wrote: You can't stat about 'uninformed choice', quick doesn't mean dirty Even creating new widgets could be made easily with GWT, with SmartGWT we must have good javascript skill to achieve the same task This statement is unequivocally false, as anyone can see by looking at the many code samples being shared between users on the SmartGWT forums - lots and lots of users creating sophisticated new widgets entirely in Java without needing to know any JavaScript. This is what I meant by a possibly uninformed decision.. most likely this person ran across a forums thread talking about core framework enhancements under consideration, caught a mention of JavaScript in that context, and misconstrued it as applying to any kind of custom widget. In reality, you can subclass SmartGWT widgets, override methods, call superclass methods, compose them, etc, all in Java. You can also embed normal GWT widgets inside SmartGWT containers (people do this for Google Maps, certain types of charts, etc). -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Use smartgwt or not
If the choice was made quickly it was probably an uninformed choice. We don't have anyone complaining that there is less customization so perhaps you could clarify that. With SmartGWT Pro and EE, you can literally open up a visual tool and create a fully functional CRUD interface to Hibernate by just picking an existing Hibernate entity from a list. That's not offered in any other GWT product, and it would be hard to argue that anything could be simpler or faster than that.. On Dec 19, 7:00 am, gaill...@audemat.com gaill...@audemat.com wrote: I use GXT (Ext GWT from extJS) for several months with JBOSS 5.1, the choice was made quickly between SmartGWT and GXT, GXT offers greater customization and management of bindings are perfect with annontations provided by GXTForms 0.2. There is no need to use Gilead or Hibernate4gwt. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Who is using smartgwt?
Sorry Tercio, I can't spend more time helping you understand the architecture here, but suffice it to say, try building the example I suggested (drag and drop between two very large user groups that can't be loaded in advance) and you'll see why widget-specific caches are an absolute necessity. Each widget is looking at a particular subset of the data available from the model, managed by a ResultSet which serves as a projection of the model data needed for that particular view. You will find the same approach in every system that handles large datasets, from Swing to JDBC and everywhere else - it's really worth your time to investigate this and understand it. I'd also appreciate it if you could stop asserting things that are just clearly false. SmartGWT has many, many Java override points that allow you to deeply customize behavior - not getters/setters but fundamentals like which cells are editable (listGrid.canEditCell()), how data is transmitted (various DataSource APIs), many aspects of how HTML is generated (getInnerHTML, cellFormatters, many others), and of course, countless events. I think you have some misconceptions which date back to right after 1.0 was released - not every override point from SmartClient is yet available in SmartGWT, but we are getting closer to that all the time. On Aug 16, 8:45 pm, Tercio Filho terciofi...@gmail.com wrote: On Aug 16, 7:39 pm, ckendrick charles.kendr...@gmail.com wrote: @tercio You're still missing the key point. Let's try again: It is absolutely 100% required in an enterprise application that different components have different caches, potentially partially overlapping, on the same dataset. A simple example is an interface for dragging and drop users between two different groups where both groups are very large and cannot be loaded in their entirety. In SmartGWT this is a single DataSource, and two ResultSets on that DataSource. Each ResultSet loads the first batch of members of each group and is capable of paging in the rest as needed. As I said in my first post, we cannot compare SmartGWT DataSource with the GXT Store, as they do different jobs, DataSource in SmartGWT is just a Proxy, or in GXT the Loader and the Reader, that's the function of the DataSource in SmartGWT, retrieve data when somebody need it. It is not a drawback that SmartGWT has separate caches per component. It's the correct architecture, and is a necessity where large datasets are involved. I disagree that this is the right way to do things, I cannot accept the fact that the widget manages it's data cache, widget is just a widget, it has nothing to do with model data. As I mentioned previously, if the datasets involved are small, you can use a clientOnly DataSource, and then there is only one central cache. This is the trivial case, which is the only one GXT currently handles. In either case (clientOnly or not) APIs exist in SmartGWT that allow fetching data directly from the DataSource without the use of a component - you can both call methods like DataSource.fetchData(), or you can directly create a ResultSet. Coupling problem, why should I, a data manipulator, must care about this?? I just need the data, that's why the GXT Store is better, you have a store, a reader and a loader, layers of decoupling. One taking care of another... Once you've absorbed all this, I think you will agree, the SmartGWT architecture is the correct one and the GXT architecture has limitations. Another mistatements: in SmartGWT you can extend the built-in widgets and other classes and override methods. People do this all the time. And you CAN'T change a widget behavior in SmartGWT, at least in Java... you have a lot of methods that you can override, but it's just property setter/getters for JS code, it's internal behavior is inside JS code, so, no go. Even extend is uncertain. I have no idea why you think more code would be involved with SmartGWT for server integration. People constantly say the reverse. There may other misconceptions there that I could address, if you were to explain why you think this is. About the server code I mentioned, i didn't made myself clear, I'd like to say exactly this(Less work for the developer). I wish I have a better english.. :-P Regardless, most professional, enterprise developers can easily justify a purchase of SmartGWT Pro, where the amount of SmartGWT-specific server code involved is literally zero for many cases, and very small for the others. Sure, a professional can justify, I didn't said the opposite. Anyways, let's see what Chris think about all this, it's all about point of view. Regards, Tercio --~--~-~--~~~---~--~~ 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
Re: Who is using smartgwt?
@tercio You're still missing the key point. Let's try again: It is absolutely 100% required in an enterprise application that different components have different caches, potentially partially overlapping, on the same dataset. A simple example is an interface for dragging and drop users between two different groups where both groups are very large and cannot be loaded in their entirety. In SmartGWT this is a single DataSource, and two ResultSets on that DataSource. Each ResultSet loads the first batch of members of each group and is capable of paging in the rest as needed. It is not a drawback that SmartGWT has separate caches per component. It's the correct architecture, and is a necessity where large datasets are involved. As I mentioned previously, if the datasets involved are small, you can use a clientOnly DataSource, and then there is only one central cache. This is the trivial case, which is the only one GXT currently handles. In either case (clientOnly or not) APIs exist in SmartGWT that allow fetching data directly from the DataSource without the use of a component - you can both call methods like DataSource.fetchData(), or you can directly create a ResultSet. Once you've absorbed all this, I think you will agree, the SmartGWT architecture is the correct one and the GXT architecture has limitations. Another mistatements: in SmartGWT you can extend the built-in widgets and other classes and override methods. People do this all the time. I have no idea why you think more code would be involved with SmartGWT for server integration. People constantly say the reverse. There may other misconceptions there that I could address, if you were to explain why you think this is. Regardless, most professional, enterprise developers can easily justify a purchase of SmartGWT Pro, where the amount of SmartGWT-specific server code involved is literally zero for many cases, and very small for the others. On Aug 16, 12:27 pm, Tercio Filho terciofi...@gmail.com wrote: @ckendrick The way SmartGWT works, every component caches it's data, independently if another component is using the same data. If you need some resultset, you need to access a component that cached this data, ie. Grid. When you have multiples components bounded to the same store you will have several server trips. The way that GXT has been developed, they let you implement what is needed for you, for example the Store need an Loader, that need an Reader. With that architecture, you can implement it the way you want. By the way, SmartGWT let you do this in a different matter, overloading the processRequest, and processResponse, which in my point of view is simpler, but very effective. See, both have pros and cons. For sure, with SmartGWT you have much more code than with GXT (Especially in server side). For me, GXT has more flexibilities, as it's coded in pure Java, so I can extend a class or something and change it's functionality. I think that Chris has a lot of opinions about both systems, and will be happy with either. Regards., Tercio On Aug 15, 6:36 pm, ckendrick charles.kendr...@gmail.com wrote: @Tercio On GXT Store vs SmartGWT DataSource, the SmartGWT architecture is the correct one here and is a superset of GXT's. When you have a large dataset you frequently have multiple components working with independent, smaller slices of that large dataset, each with different criteria and sort order, and each independently managing paging and a partial cache. In SmartGWT each of these is called a ResultSet. A ResultSet can be shared between components, and some components automatically re-use ResultSets in an LRU fashion when the component needs a subset of a dataset that has already bean loaded. All ResultSets observe the DataSource and automatically update their caches when a change occurs that affects their slice of the dataset. http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/data/... When you are working with smaller datasets, you can simply tell a DataSource to go into clientOnly mode and it behaves like GXT's simple Store: http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/data/... We believe that GXT will eventually have to revise their architecture to match SmartGWT, most likely breaking backwards compatibility at that time. Take a close look and think about the use cases surrounding large datasets and I think you'll reverse your opinion on which architecture is the correct one, and is more advanced. Bear in mind also: we offer SmartGWT under the LGPL for free, and this free product has a lot more features that what you have to pay for with GXT (unless you can accept GPL - very rare). For the $745 price tag of SmartGWT Pro, you're getting a huge amount of Java-based server functionality and a visual design tool (Visual Builder). It's simply not valid to compare price tag of SmartGWT Pro to GXT; it's more
Re: Who is using smartgwt?
for the speed it's also for the size of the application. If you wanna developed huge project SmartGWT is the way to go, but remember that your minimum app is going to be 1mb in size because of the SmartGWT core files. On Aug 14, 10:34 pm, ckendrick charles.kendr...@gmail.com wrote: Hi Malte, As far as once-ever load time, if you're building an enterprise application with several screens and lots of productivity features, you're going to be using substantially all of SmartClient - if it was written in Java, the impact of the GWT compiler's static analysis would be negligible. If you're building something more trivial, just a few components and basic interactions, it doesn't really matter what you use, anything will do. On performance, SmartGWT is already more than fast enough in terms of UI interactions. It doesn't matter whether a menu appears in 40 milliseconds or 60, humans literally cannot perceive that difference. So, while I would argue that future changes to the GWT compiler are not going to beat SmartClient's hand-coded JavaScript, it doesn't matter anyway, it makes no perceptible difference. What does matter for real world performance is a feature like Adaptive Filtering, which radically cuts down on trips to the server, improving responsiveness and scalability: http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_fe... SmartGWT has half a dozen other features that make similar, real world impacts on performance. This is what actually matters in a deployed application. On Aug 14, 10:59 am, Malte mlegenhau...@gmail.com wrote: Hi all, For a few month a had the same problems: GXT or SmartGWT and I choose GXT. Ok now why? The main reason was the speed. Cause the extjs team recreated the whole library in pure GWT code, what make it amazing fast. But that was for a few month. Currently SmartGWT has nearly the same performance, but I think the main reason is that the browsers are now much faster (I am using Firefox 3.5). Currently I am thinking again, but I am not a fan of wrapper libraries. I know there is a lot of work in creating SmartGWT, but there are some disadvantages: 1. When the GWT compiler gets better and can optimize more and more, the SmartGWT library will not get any of these advantages. 2. Loading time! Sure after the first load the load time will be equal to pure GWT application. But the first time is the time where the user decides to stay on this page or not... in most cases there is no second chance. 3. Upcoming features like runAsync bring no advantages. Greetz Malte --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Who is using smartgwt?
Hi Malte, As far as once-ever load time, if you're building an enterprise application with several screens and lots of productivity features, you're going to be using substantially all of SmartClient - if it was written in Java, the impact of the GWT compiler's static analysis would be negligible. If you're building something more trivial, just a few components and basic interactions, it doesn't really matter what you use, anything will do. On performance, SmartGWT is already more than fast enough in terms of UI interactions. It doesn't matter whether a menu appears in 40 milliseconds or 60, humans literally cannot perceive that difference. So, while I would argue that future changes to the GWT compiler are not going to beat SmartClient's hand-coded JavaScript, it doesn't matter anyway, it makes no perceptible difference. What does matter for real world performance is a feature like Adaptive Filtering, which radically cuts down on trips to the server, improving responsiveness and scalability: http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_featured_category SmartGWT has half a dozen other features that make similar, real world impacts on performance. This is what actually matters in a deployed application. On Aug 14, 10:59 am, Malte mlegenhau...@gmail.com wrote: Hi all, For a few month a had the same problems: GXT or SmartGWT and I choose GXT. Ok now why? The main reason was the speed. Cause the extjs team recreated the whole library in pure GWT code, what make it amazing fast. But that was for a few month. Currently SmartGWT has nearly the same performance, but I think the main reason is that the browsers are now much faster (I am using Firefox 3.5). Currently I am thinking again, but I am not a fan of wrapper libraries. I know there is a lot of work in creating SmartGWT, but there are some disadvantages: 1. When the GWT compiler gets better and can optimize more and more, the SmartGWT library will not get any of these advantages. 2. Loading time! Sure after the first load the load time will be equal to pure GWT application. But the first time is the time where the user decides to stay on this page or not... in most cases there is no second chance. 3. Upcoming features like runAsync bring no advantages. Greetz Malte --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Modelling framework
For SmartGWT Pro and EE go here: http://www.smartclient.com/smartgwt/ For LGPL go here: http://code.google.com/p/smartgwt/ On Aug 5, 8:02 am, tall dave da...@lorgeousdays.com wrote: is it still possible to download the non-Pro/EE version of SmartGWT? the page at: http://www.smartclient.com/smartgwt/download.jsp isn't working. On Aug 4, 9:16 pm, ckendrick charles.kendr...@gmail.com wrote: We do give you the ability get in and override any part of the generated SQL as a Velocity template. Simple example: http://www.smartclient.com/smartgwtee/showcase/#large_valuemap_sql Tour de force (dynamic reporting with filter, sort and data paging, no server code required): http://www.smartclient.com/smartgwtee/showcase/#sql_dynamic_reporting I think that would cover you for lot of use cases. If there's something more we should be doing here I'd love to know. Note that we also have upcoming support for XML DB (Berkeley OSS and Oracle flavors). It's just another type of DataSource, which generates XQuery instead of SQL. --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Modelling framework
With SmartGWT you can represent a data structure as a DataSource. A DataSource can be tied to any kind of data provider - not just different JPA implementers but also WSDL web services, REST services, non-JPA persistence systems like Ibatis, etc. The persistence engine is pluggable, so you can swap strategies, even swap platforms (eg Java to PHP backend) without changing the UI. With SmartGWT Pro you can generate SQL tables or Hibernate entities from a DataSource, or vice versa, that is, generate a DataSource from existing SQL tables or Hibernate entities. Then you can just drag the DataSource onto a grid component and you've got the ability to do CRUD operations without writing any code, and you can add business logic from there. Probably the best single overview is here: http://www.jroller.com/sjivan/entry/smartgwt_out_of_beta_v1 On Aug 4, 7:40 am, Kaspar Fischer kaspar.fisc...@dreizak.com wrote: The thing is, there IS a framework for what you are trying to do (i.e. represent a data structure without being tied to implementation). It's called Java. If you're looking for the ability to quickly add fields to customer's data structures, that's dependent on low coupling and other good programming /techniques/ not a given framework --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Modelling framework
Hi John, For live connections to SQL, Hibernate and other data providers see the SmartGWT Pro/EE showcase: http://www.smartclient.com/smartgwtee/showcase/ As well as Sanjiv's blog on SmartGWT Pro/EE, which is the link I meant to post before: http://www.jroller.com/sjivan/entry/introduction_to_smartgwt_enterprise_edition Note that the SmartGWT non-Pro/EE showcase shows clientOnly DataSources, but as I mentioned, DataSources are pluggable/swappable. Every interaction you see in the SmartGWT showcase with a clientOnly DataSource also works with SQL, Hibernate or custom DataSource in SmartGWT EE. On Aug 4, 4:16 pm, John Ivens john.wagner.iv...@gmail.com wrote: There are no examples that I know of actually showing a connection, for example with a sample mysql database or really anything else. Please correct me if I'm wrong. On Tue, Aug 4, 2009 at 3:42 PM, ckendrick charles.kendr...@gmail.comwrote: With SmartGWT you can represent a data structure as a DataSource. A DataSource can be tied to any kind of data provider - not just different JPA implementers but also WSDL web services, REST services, non-JPA persistence systems like Ibatis, etc. The persistence engine is pluggable, so you can swap strategies, even swap platforms (eg Java to PHP backend) without changing the UI. With SmartGWT Pro you can generate SQL tables or Hibernate entities from a DataSource, or vice versa, that is, generate a DataSource from existing SQL tables or Hibernate entities. Then you can just drag the DataSource onto a grid component and you've got the ability to do CRUD operations without writing any code, and you can add business logic from there. Probably the best single overview is here: http://www.jroller.com/sjivan/entry/smartgwt_out_of_beta_v1 On Aug 4, 7:40 am, Kaspar Fischer kaspar.fisc...@dreizak.com wrote: The thing is, there IS a framework for what you are trying to do (i.e. represent a data structure without being tied to implementation). It's called Java. If you're looking for the ability to quickly add fields to customer's data structures, that's dependent on low coupling and other good programming /techniques/ not a given framework --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Modelling framework
We do give you the ability get in and override any part of the generated SQL as a Velocity template. Simple example: http://www.smartclient.com/smartgwtee/showcase/#large_valuemap_sql Tour de force (dynamic reporting with filter, sort and data paging, no server code required): http://www.smartclient.com/smartgwtee/showcase/#sql_dynamic_reporting I think that would cover you for lot of use cases. If there's something more we should be doing here I'd love to know. Note that we also have upcoming support for XML DB (Berkeley OSS and Oracle flavors). It's just another type of DataSource, which generates XQuery instead of SQL. On Aug 4, 5:17 pm, John Ivens john.wagner.iv...@gmail.com wrote: Sweet!!! I noticed that you have Oracle support. Do you have a way to support the Oracle XMLType, at least a way that is more direct than the way that I have done this before, where I kludged Hibernate to be able to store XML in the database? On Tue, Aug 4, 2009 at 4:38 PM, ckendrick charles.kendr...@gmail.comwrote: Hi John, For live connections to SQL, Hibernate and other data providers see the SmartGWT Pro/EE showcase: http://www.smartclient.com/smartgwtee/showcase/ As well as Sanjiv's blog on SmartGWT Pro/EE, which is the link I meant to post before: http://www.jroller.com/sjivan/entry/introduction_to_smartgwt_enterpri... Note that the SmartGWT non-Pro/EE showcase shows clientOnly DataSources, but as I mentioned, DataSources are pluggable/swappable. Every interaction you see in the SmartGWT showcase with a clientOnly DataSource also works with SQL, Hibernate or custom DataSource in SmartGWT EE. On Aug 4, 4:16 pm, John Ivens john.wagner.iv...@gmail.com wrote: There are no examples that I know of actually showing a connection, for example with a sample mysql database or really anything else. Please correct me if I'm wrong. On Tue, Aug 4, 2009 at 3:42 PM, ckendrick charles.kendr...@gmail.com wrote: With SmartGWT you can represent a data structure as a DataSource. A DataSource can be tied to any kind of data provider - not just different JPA implementers but also WSDL web services, REST services, non-JPA persistence systems like Ibatis, etc. The persistence engine is pluggable, so you can swap strategies, even swap platforms (eg Java to PHP backend) without changing the UI. With SmartGWT Pro you can generate SQL tables or Hibernate entities from a DataSource, or vice versa, that is, generate a DataSource from existing SQL tables or Hibernate entities. Then you can just drag the DataSource onto a grid component and you've got the ability to do CRUD operations without writing any code, and you can add business logic from there. Probably the best single overview is here: http://www.jroller.com/sjivan/entry/smartgwt_out_of_beta_v1 On Aug 4, 7:40 am, Kaspar Fischer kaspar.fisc...@dreizak.com wrote: The thing is, there IS a framework for what you are trying to do (i.e. represent a data structure without being tied to implementation). It's called Java. If you're looking for the ability to quickly add fields to customer's data structures, that's dependent on low coupling and other good programming /techniques/ not a given framework --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SmartGWT vs GWT-Ext Evaluation
If you use the free version, you use RestDataSource as the starting point for integration. RestDataSource simply specifies XML or JSON messages to send and receive with your server; it is totally agnostic as to how your server is implemented (it could, for instance, be PHP). http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/data/RestDataSource.html There is also a user-contributed DataSource that works with GWT-RPC: http://forums.smartclient.com/showthread.php?t=4814 If you have follow-up questions, please use the SmartGWT forums, not this one. --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
[Announce] SmartGWT Enterprise Edition available now
SmartGWT is an popular, open source, extremely rich widget library and databinding framework for GWT, available under the LGPL. SmartGWT Enterprise Edition (SmartGWT EE for short) is a commercially licensed version of SmartGWT that includes Java Server side functionality, additional tools, and a classic commercial license in lieu of the LGPL. For teams with existing Java functionality, SmartGWT EE provides greatly accelerated integration with SmartGWT’s visual components. In many cases it is possible to take existing Java methods in an application and bind a SmartGWT grid or form to those methods without writing any new code, simply by specifying what method to call in a DataSource XML file. For those using Hibernate, it’s even simpler. A Wizard within Visual Builder allows you to simply pick any registered Hibernate entity from a list, and SmartGWT EE will create a SmartGWT DataSource that provides full read-write binding to that Hibernate entity. Just provide the generated DataSource to a SmartGWT grid or form with no other configuration, and you have a full CRUD UI: create, retrieve, update, and delete Hibernate-managed entities. It can even execute the complex search criteria that the FilterBuilder allows a user to specify. A corresponding Wizard exists for binding to database tables stored in any popular database, again with full read-write binding. And in both cases, you can easily add business logic that runs before or after the Hibernate or SQL binding, which can modify the request before it executes, modify the output, or take any other action. Resources: Online Showcase http://smartclient.com/smartgwtee/showcase Download SmartGWT EE http://smartclient.com/releases/smartgwtee-1.0b1.zip Official announcement and pricing http://blog.isomorphic.com/?p=78 Aside from features covered in the release announcement, other features of SmartGWT EE are similar to the current edition of the SmartClient Server. See the Feature Summary here: http://www.smartclient.com/docs/6.5.1/a/b/c/go.html#group..iscServer --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Need for a great GWT GUI library
If SmartGWT seems slow, just disable Firebug or similar development utilities, and be sure you haven't done anything like completely disabling browser caching. For normal end users who don't have these tools or settings, it's quick. On Dec 19, 7:13 am, Juan Backson juanback...@gmail.com wrote: Smart-GWT - slow and memory intensive --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SmartGWT 1.0 Released
Lest anyone get the wrong idea from francesco, when using SmartGWT you can debug your GWT *application* code normally within hosted mode. If you had a need to debug the core SmartClient libraries (normal users will not have a need to do this), you'd use debugging tools like Firebug and SmartClient's Developer Console. Calling this being out in the cold is bit of hyperbole given that SmartClient's very long track record of success has always been based on this approach, which works well, and will work even better with the next crop of browsers, *all* of which have Firebug clones. Finally, on performance - the real world performance of enterprise RIAs is dominated by the number of trips to the server and the intensity of database load. In this extremely key aspect - again the primary determinant of real-world performance - SmartClient/SmartGWT has a very dominant lead, which is due to it's sophisticated data binding architecture (particularly adaptive client-side operations and intelligent data caching). By comparison, possible code size differences caused by a different mix of JSNI vs Java code is at best a 3rd or 4th tier performance concern, and is frequently has literally zero impact on actual performance of delivered applications. Using JSNI has distinct advantages - as Sanjiv touched on, we are able to optimize things at a very low level within the SmartClient runtime, and we can more easily profile and tune core framework code because it's not going through a Java-JavaScript translator. This is very much like the mix of native C++ and higher level languages like C# within a .NET CLR - different languages for different tasks. Personally, for the kinds of applications that SmartGWT is designed for, I see it as a tremendous architectural advantage. On Nov 24, 12:32 am, francescoNemesi [EMAIL PROTECTED] wrote: Hi Sanjiv, thanks for your reply, agree with your comments. Re-reading my post I agree it might look like I was, in a way, attachingsmartGWT. It was not meant to come through that way, nor was my intention to praise GXT. It was only meant to be a comparison between approaches, JSNI vs Pure GWT, and I definetely think that using JSNI as the foundation of any GWT framework is not the right thing to do. Smart Client is an amazing framework, but it is a JavScript framework. Using JSNI leaves you in the cold when you need to debug, as an example, but I am sure you know all that. I think you have done a great job withsmartGWT, it looks really great and I am sure it will have the success it deserves. Regards, Francesco On Nov 23, 8:34 pm, Sanjiv Jivan [EMAIL PROTECTED] wrote: Hi Fransceso, If you found a library that meets your needs, then good for you. Compile output size and runtime performance are two separate issues. A third party widget written in GWT Java, regardless of how small it compiles down to, doesn't magically make it run fast. Nor does it make it magically render perfectly on all browsers. As an example a TableGrid written in GWT Java could still perform really poorly, and not display consistently on all browsers. There are obviously several aspects to GWT that helps avoid leaks and such but this does not mean that any third party code written in GWT is 100% leak free. The GWT 1.6 event API is really neat andSmartGWTusers it. Well written code is what will perform well and display consistently across various browser. On the issue of performance, there are numerous posts made by paying GXT users that the performance of GWT-Ext is still better than GXT. You can search their forums. This is not to suggest that performance improvements cannot be made inSmartGWT. If you can give specifics, it would certainly help in resolving them. But without specifics like whether it was the initial load time, performance of specific widgets etc it will be difficult to act on. Feel free to post on theSmartGWTforums or create an issue on thesmartgwtgoogle code project. On the issue of compile output size : The SmartClient library is extremely stable and developed over the past 8 years. If you peruse their forums, you will find that pretty much all questions are met with an answer explaining how the user can accomplish what they're trying to do. Their library is virtually bug free. I realize this is a strong statement, but its true. Only some 4-5 issues were patched post-release. Compare this to the bugs forum of any of your favorite libraries.SmartGWTwill inherit these attributes once its past the few initial minor releases and issues are flushed out during this period. Due to the high level of stability of SmartClient, it can be viewed as the kernel of your web app which should be configured to be gzipped with an Expires Never header for a given version. This means that the browser will cache the kernel (SmartClient JS files) and the only code that gets downloaded is your application code, and not any code
