Re: Proposal: the browser as a desktop client
Johan, I'm not saying you should move *everything* over to the client. I'm saying that most form manipulation can take place without querying the database, especially on a per-request basis. Adding rows and cell validation tend to rely on at most one database lookup (during the initial request). Even if you *do* need to query the database before carrying out some operation (I dare say this is a minority situation) you can issue a web service call to do just that. Wicket's current implementation assumes that by default form manipulation should take place on the server. I am saying that by default it should take place on the client. The same functionality is still possible, it's just your default that changes. And as I mentioned, this approach has many benefits besides performance. Gili Johan Compagner wrote: because on the server the business logic runs Its a complete different paradigm if thinks that are now done in onclick() or onsubmit() would run on the client what would be possible then? Currently many people just call DAO's there (spring stuff and so on) johan On Thu, Oct 23, 2008 at 11:40 PM, cowwoc [EMAIL PROTECTED] wrote: GWT generates business logic, HTML and CSS from Java code; as opposed to letting you bind business logic written in Java against normal HTML files. It doesn't have a clean separation of concerns like Wicket. Ask yourself this, why does the client rely on the server to do dynamic form manipulation on its behalf? Is it because the server really cares about the intermediate form states or is it because we don't want to write this logic in Javascript? Gili Johan Compagner wrote: use GWT because thats the key difference between wicket and gwt I only see some things like validators that could be precompiled not th complete webapp and all your current page/panel/component/html code On Wed, Oct 22, 2008 at 3:44 PM, cowwoc [EMAIL PROTECTED] wrote: Hi, I'd like to propose we leverage existing Java to Javascript compilers to improve Wicket on a couple of fronts. If you think of the web browser as a desktop client involved in a client-server architecture then it becomes obvious that Wicket is currently asking the server to handle a lot of logic on behalf of the client. It does this because it's easier to develop in Java than in Javascript. In an ideal world, the server should only see HTML forms in two states: - their initial state (sent to the client) - their submitted state (merged into the database) The client would be able to communicate with web services in between to update the client-side state but most applications won't even need this. The vast majority of form manipulation (adding rows, data validation) can be handled completely on the client-end. I foresee the following benefits: - Vastly simplified logic: A lot of resources have been spent building the HTML parser and classes related to server-side form manipulation. All these are built in for free in JS. For example, interacting with HTML elements and IDs is far easier than in Java code. - Improved responsiveness for end-users - Improved server scalability - Nice URLs, both for humans and for web crawlers. This would also open up the door for RESTful implementations. This would be different from GWT. You would benefit from the modularity of Wicket, coding HTML and CSS in their native languages. The only difference is that you'd now be manipulating dynamic forms on the client-end instead of the server-end. Let me know what you think. Gili -- View this message in context: http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111040.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20140090.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20140645.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Proposal: the browser as a desktop client
Hi, I'd like to propose we leverage existing Java to Javascript compilers to improve Wicket on a couple of fronts. If you think of the web browser as a desktop client involved in a client-server architecture then it becomes obvious that Wicket is currently asking the server to handle a lot of logic on behalf of the client. It does this because it's easier to develop in Java than in Javascript. In an ideal world, the server should only see HTML forms in two states: - their initial state (sent to the client) - their submitted state (merged into the database) The client would be able to communicate with web services in between to update the client-side state but most applications won't even need this. The vast majority of form manipulation (adding rows, data validation) can be handled completely on the client-end. I foresee the following benefits: - Vastly simplified logic: A lot of resources have been spent building the HTML parser and classes related to server-side form manipulation. All these are built in for free in JS. For example, interacting with HTML elements and IDs is far easier than in Java code. - Improved responsiveness for end-users - Improved server scalability - Nice URLs, both for humans and for web crawlers. This would also open up the door for RESTful implementations. This would be different from GWT. You would benefit from the modularity of Wicket, coding HTML and CSS in their native languages. The only difference is that you'd now be manipulating dynamic forms on the client-end instead of the server-end. Let me know what you think. Gili -- View this message in context: http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111040.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal: the browser as a desktop client
I just to clarify one point. You would still have three types of components: HTML CSS Java You would still be binding the Java code against HTML IDs (clean separation of concerns). The only thing that would change is where the Java code executes. -- View this message in context: http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111247.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help fixing bug #1816
Johan, The fix looks good. I no longer get warnings under Glassfish. Thank you, Gili cowwoc wrote: According to http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletRequest.html#setCharacterEncoding(java.lang.String): This method must be called prior to reading request parameters or reading input using getReader(). My interpretation is that requesting the context path is okay, so long as you do not request the query parameters. I'll test your commit to be sure. Gili Johan Compagner wrote: is only getParameters() a problem? or cant we also ask for the context path/url? see my commit i just did it should fix your problem if it is only the getParameters of the getLastModified wat is a problem johan On Wed, Sep 24, 2008 at 6:53 AM, cowwoc [EMAIL PROTECTED] wrote: Hi, I spent a few hours tracking down the cause of https://issues.apache.org/jira/browse/WICKET-1816 but now I need someone from the Wicket team to help me fix it. Can someone please fix the lines of code I mention in the report and then send me back a patched version for testing? To be clear: this bug affects *all* platforms. Tomcat fails silently, which is even worse. Gili -- View this message in context: http://www.nabble.com/Need-help-fixing-bug--1816-tp19641982p19641982.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Need-help-fixing-bug--1816-tp19641982p19651029.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Need help fixing bug #1816
Hi, I spent a few hours tracking down the cause of https://issues.apache.org/jira/browse/WICKET-1816 but now I need someone from the Wicket team to help me fix it. Can someone please fix the lines of code I mention in the report and then send me back a patched version for testing? To be clear: this bug affects *all* platforms. Tomcat fails silently, which is even worse. Gili -- View this message in context: http://www.nabble.com/Need-help-fixing-bug--1816-tp19641982p19641982.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Injecting Wicket Pages using Google Guice
Hi, I've uploaded a patch that makes Wicket Pages (bookmarkable or otherwise) injectable using Google Guice: https://issues.apache.org/jira/browse/WICKET-1705 Thank you, Gili -- View this message in context: http://www.nabble.com/Injecting-Wicket-Pages-using-Google-Guice-tp17934024p17934024.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using Guice with IInitializer?
Hi, Can anyone think of a way to inject members into an IInitializer or at least gain access to an Injector instance inside it? As far as I can tell I can't even get access to the Servlet Context or Application from inside the IInitializer. I'm open to suggestions. Thanks, Gili -- View this message in context: http://www.nabble.com/Using-Guice-with-IInitializer--tp17867744p17867744.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Guice with IInitializer?
Sorry, the reason I initially missed this option is that
GuiceWebApplicationFactory was not saving the Injector into the servlet
context. I've since fixed this and this now works.
Thanks,
Gili
igor.vaynberg wrote:
IInitializer.onInitializer(Application app) {
ServletContext sc=((WebApplication)app).getServletContext();
}
-igor
On Mon, Jun 16, 2008 at 9:04 AM, cowwoc [EMAIL PROTECTED] wrote:
Hi,
Can anyone think of a way to inject members into an IInitializer or at
least
gain access to an Injector instance inside it? As far as I can tell I
can't
even get access to the Servlet Context or Application from inside the
IInitializer. I'm open to suggestions.
Thanks,
Gili
--
View this message in context:
http://www.nabble.com/Using-Guice-with-IInitializer--tp17867744p17867744.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Using-Guice-with-IInitializer--tp17867744p17869212.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Component easier to Generify
Brill, This is actually an API best practice. Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to protect users from themselves. - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: Have you considered moving from subclassing to composition in Wicket using CallableT? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take CallableT instead of T, so for example setVisible(boolean) would become setVisible(CallableBoolean) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create CallableT for constant values, such as Callable.valueOf(true) would return a CallableBoolean that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Component easier to Generify
Actually, it's the other way around. Authors make methods final not because *you* might make a mistake but rather because *they* might. Using final methods simplifies their design a lot because they don't have to do all the work you mentioned. Secondly, it leaves the API open to extension (without breaking backwards compatibility) in a way that would be lost if anyone could override the methods. I personally agree with your approach with the following major caveat: if developers are able to override any method then it must be understood that any implementation making assumptions not guaranteed by the API specification is liable to break in future releases. Keep in mind that very few things ever are guaranteed by the specification, so practically speaking this means that your code is very likely to break as new releases come out. To be honest, I personally prefer approach #2 over final methods for public projects because (in my experience) even open-source projects take forever to fix bugs or add features that you might need right away. I'm a strong believer that implementations that make incorrect assumptions deserve to break in subsequent releases. One final benefit of #1 worth mentioning, however, is that incorrect assumptions end up in a compile-time error (roughly speaking) and even smart developers make mistakes every once in a while. Consider what happens if you override foo() and forget to invoke super.foo() by mistake. Those kinds of mistakes happen all the time. I'm toying with the idea that approach #1 makes sense for in-house projects where you are a co-owner and can make changes very quickly while approach #2 makes sense for public projects when developers can't afford to wait on the project owner. Put another way, maybe #1 makes sense for mature APIs whereas #2 makes sense for experimental APIs (used to flesh out the various use-cases you need to support). Gili Brill Pappin wrote: I understand the reasoning, however I think best practice can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: Brill, This is actually an API best practice. Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to protect users from themselves. - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: Have you considered moving from subclassing to composition in Wicket using CallableT? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take CallableT instead of T, so for example setVisible(boolean) would become setVisible(CallableBoolean) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create CallableT for constant values, such as Callable.valueOf(true) would return a CallableBoolean that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Making Component easier to Generify
Have you considered moving from subclassing to composition in Wicket using CallableT? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take CallableT instead of T, so for example setVisible(boolean) would become setVisible(CallableBoolean) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create CallableT for constant values, such as Callable.valueOf(true) would return a CallableBoolean that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
And The Fastest Growing Web Framework Is...
This might be of interest to the Wicket community: http://www.javalobby.org/java/forums/t101110.html -- View this message in context: http://www.nabble.com/And-The-Fastest-Growing-Web-Framework-Is...-tf4392768.html#a12524620 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
