You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Frank Silbermann <fr...@fedex.com> on 2010/12/20 17:45:59 UTC
Converting Wicket Application to fat client (Swing/WebStart)
I have a Wicket application at work that has been well-received by its internal users. Because I am not much of a web programmer, and because it is for internal use only, I built a bunch of general-purpose panels and base pages which I use to assemble the application-oriented pages using no additional HTML. Many of the general-purpose panels simply provide the HTML for general purpose Wicket components (e.g. sets of radio-buttons and sets of checkboxes) with a simplified API façade that provides only the flexibility needed in my application.
My application-oriented pages therefore emphasize the business logic, with very little code whatsoever dealing with display logic. Yes, the resulting pages are ugly, but they are functional and reliable so my users don't care.
Now I have a new requirement. A group would like to use this application with the proviso that no open-source software be used! (They have a short list of permitted exceptions containing standard stuff such as Struts.) Since I chose Wicket so that I could use more-or-less a Swing style of programming, I figured it would be easier to translate my application into a fat-client application using Swing and deliver it via WebStart -- rather than, say, re-implementing it in JSP or JFS. :-(
There will only be a few users, and they work for the company; I'm not terribly concerned about maximizing performance.
Do you have any suggestions about the most straight-forward way of translating a Wicket application to Swing? I suppose that I would represent each page as a JFrame, and each panel as a JPanel.
In my panels I have a number of components (buttons, checkboxes, radio buttons...), many (but not all) of which post back immediately on change, and a very few AJAX components that redraw only a bit of the page. What would be the most direct method of modeling page post-back (and partial post-back, for the AJAX components) in Swing?
This question is kind of ironic, since Wicket was created to provide a more Swing-like approach to web programming, and now I'm wondering about Wicket-like approach to Swing programming! :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Converting Wicket Application to fat client (Swing/WebStart)
Posted by Peter Karich <pe...@yahoo.de>.
Am 20.12.2010 19:36, schrieb Jeremy Thomerson:
> On Mon, Dec 20, 2010 at 10:45 AM, Frank Silbermann
> <fr...@fedex.com> wrote:
>> I have a Wicket application at work that has been well-received by its internal users. Because I am not much of a web programmer, and because it is for internal use only, I built a bunch of general-purpose panels and base pages which I use to assemble the application-oriented pages using no additional HTML. Many of the general-purpose panels simply provide the HTML for general purpose Wicket components (e.g. sets of radio-buttons and sets of checkboxes) with a simplified API façade that provides only the flexibility needed in my application.
>>
>> My application-oriented pages therefore emphasize the business logic, with very little code whatsoever dealing with display logic. Yes, the resulting pages are ugly, but they are functional and reliable so my users don't care.
>>
>> Now I have a new requirement. A group would like to use this application with the proviso that no open-source software be used! (They have a short list of permitted exceptions containing standard stuff such as Struts.) Since I chose Wicket so that I could use more-or-less a Swing style of programming, I figured it would be easier to translate my application into a fat-client application using Swing and deliver it via WebStart -- rather than, say, re-implementing it in JSP or JFS. :-(
> Then they don't want to use "this application". They want a "new
> application". And the real problem is why do they say "no open-source
> software"? What I would do in this case is counter with a budget
> proposal for the project. Start off with "implement web framework
> that works with "this application" from scratch since we can't use
> open source software" == $8,428,748
> (http://www.ohloh.net/p/wicket#cocomo). Then add the other pieces
> that you'll be replacing.
BTW: the JSF implementation myfaces and ... aehm the whole jdk is open
source ...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Converting Wicket Application to fat client (Swing/WebStart)
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
> Therefore, I'm trying to think of a back-up strategy in case they refuse to approve Wicket
We are hiring ;))
**
Martin
which they might well do for the sake of reason (1), even if Apache's
role in Wicket relieves concern (2).
>
> I chose Wicket because the "standard" Java web frameworks then in existence horrified me (and still do). Perhaps I should have used Java Swing with WebStart from the beginning, but I'd heard that
> WebStart still had problems. (I expect it has been improved since then, but at this point I no longer care.) I don't want a difficult rewrite, especially not one that forces me to give up the DRY (don't repeat yourself) principle.
>
> Yeah, it might cost $8 million to re-implement Wicket in-house :-), but I was hoping that maybe it would be much cheaper to re-implement my base components in a fat-client technology -- since that would eliminate most of the problems Wicket was created to solve.
>
> -----Original Message-----
> From: Jeremy Thomerson [mailto:jeremy@wickettraining.com]
> Sent: Monday, December 20, 2010 12:36 PM
> To: users@wicket.apache.org
> Subject: Re: Converting Wicket Application to fat client (Swing/WebStart)
>
> On Mon, Dec 20, 2010 at 10:45 AM, Frank Silbermann
> <fr...@fedex.com> wrote:
>>
>> I have a Wicket application at work that has been well-received by its internal users. Because I am not much of a web programmer, and because it is for internal use only, I built a bunch of general-purpose panels and base pages which I use to assemble the application-oriented pages using no additional HTML. Many of the general-purpose panels simply provide the HTML for general purpose Wicket components (e.g. sets of radio-buttons and sets of checkboxes) with a simplified API façade that provides only the flexibility needed in my application.
>>
>> My application-oriented pages therefore emphasize the business logic, with very little code whatsoever dealing with display logic. Yes, the resulting pages are ugly, but they are functional and reliable so my users don't care.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Converting Wicket Application to fat client (Swing/WebStart)
Posted by Frank Silbermann <fr...@fedex.com>.
Well, I started it 5 years ago when the policy on open source had not yet been nailed down. As I've been improving it since then and the production infrastructure group did not have servers to run it on, we been running it on dev/test machines, and production managers have nonetheless been making good use of it.
Since then, the architecture group has tightened their standards with two purposes in mind:
(1) Standardize the tool sets so that developers become a more easily replaceable commodity, and
(2) Satisfy the lawyers, who fear the implications of a rogue open-source license whose terms might put the company in legal trouble.
New government regulations are also forcing upper management to monitor software installations much more closely. Therefore, any use of open source software must be approved by the architecture board, a board which is NOT responsible for our department's budget or convenience. I have to consider the possibility that they will take a tough line.
Therefore, I'm trying to think of a back-up strategy in case they refuse to approve Wicket, which they might well do for the sake of reason (1), even if Apache's role in Wicket relieves concern (2).
I chose Wicket because the "standard" Java web frameworks then in existence horrified me (and still do). Perhaps I should have used Java Swing with WebStart from the beginning, but I'd heard that
WebStart still had problems. (I expect it has been improved since then, but at this point I no longer care.) I don't want a difficult rewrite, especially not one that forces me to give up the DRY (don't repeat yourself) principle.
Yeah, it might cost $8 million to re-implement Wicket in-house :-), but I was hoping that maybe it would be much cheaper to re-implement my base components in a fat-client technology -- since that would eliminate most of the problems Wicket was created to solve.
-----Original Message-----
From: Jeremy Thomerson [mailto:jeremy@wickettraining.com]
Sent: Monday, December 20, 2010 12:36 PM
To: users@wicket.apache.org
Subject: Re: Converting Wicket Application to fat client (Swing/WebStart)
On Mon, Dec 20, 2010 at 10:45 AM, Frank Silbermann
<fr...@fedex.com> wrote:
>
> I have a Wicket application at work that has been well-received by its internal users. Because I am not much of a web programmer, and because it is for internal use only, I built a bunch of general-purpose panels and base pages which I use to assemble the application-oriented pages using no additional HTML. Many of the general-purpose panels simply provide the HTML for general purpose Wicket components (e.g. sets of radio-buttons and sets of checkboxes) with a simplified API façade that provides only the flexibility needed in my application.
>
> My application-oriented pages therefore emphasize the business logic, with very little code whatsoever dealing with display logic. Yes, the resulting pages are ugly, but they are functional and reliable so my users don't care.
>
> Now I have a new requirement. A group would like to use this application with the proviso that no open-source software be used! (They have a short list of permitted exceptions containing standard stuff such as Struts.) Since I chose Wicket so that I could use more-or-less a Swing style of programming, I figured it would be easier to translate my application into a fat-client application using Swing and deliver it via WebStart -- rather than, say, re-implementing it in JSP or JFS. :-(
Then they don't want to use "this application". They want a "new
application". And the real problem is why do they say "no open-source
software"? What I would do in this case is counter with a budget
proposal for the project. Start off with "implement web framework
that works with "this application" from scratch since we can't use
open source software" == $8,428,748
(http://www.ohloh.net/p/wicket#cocomo). Then add the other pieces
that you'll be replacing.
> There will only be a few users, and they work for the company; I'm not terribly concerned about maximizing performance.
>
> Do you have any suggestions about the most straight-forward way of translating a Wicket application to Swing? I suppose that I would represent each page as a JFrame, and each panel as a JPanel.
>
> In my panels I have a number of components (buttons, checkboxes, radio buttons...), many (but not all) of which post back immediately on change, and a very few AJAX components that redraw only a bit of the page. What would be the most direct method of modeling page post-back (and partial post-back, for the AJAX components) in Swing?
>
> This question is kind of ironic, since Wicket was created to provide a more Swing-like approach to web programming, and now I'm wondering about Wicket-like approach to Swing programming! :-)
Sorry, I don't have any actual technical advice for you here. It just
seems like the kind of project that shouldn't happen. Your department
manager should be fighting back against arbitrarily bad requirements.
--
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket? Use Brix! http://brixcms.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Converting Wicket Application to fat client (Swing/WebStart)
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Mon, Dec 20, 2010 at 10:45 AM, Frank Silbermann
<fr...@fedex.com> wrote:
>
> I have a Wicket application at work that has been well-received by its internal users. Because I am not much of a web programmer, and because it is for internal use only, I built a bunch of general-purpose panels and base pages which I use to assemble the application-oriented pages using no additional HTML. Many of the general-purpose panels simply provide the HTML for general purpose Wicket components (e.g. sets of radio-buttons and sets of checkboxes) with a simplified API façade that provides only the flexibility needed in my application.
>
> My application-oriented pages therefore emphasize the business logic, with very little code whatsoever dealing with display logic. Yes, the resulting pages are ugly, but they are functional and reliable so my users don't care.
>
> Now I have a new requirement. A group would like to use this application with the proviso that no open-source software be used! (They have a short list of permitted exceptions containing standard stuff such as Struts.) Since I chose Wicket so that I could use more-or-less a Swing style of programming, I figured it would be easier to translate my application into a fat-client application using Swing and deliver it via WebStart -- rather than, say, re-implementing it in JSP or JFS. :-(
Then they don't want to use "this application". They want a "new
application". And the real problem is why do they say "no open-source
software"? What I would do in this case is counter with a budget
proposal for the project. Start off with "implement web framework
that works with "this application" from scratch since we can't use
open source software" == $8,428,748
(http://www.ohloh.net/p/wicket#cocomo). Then add the other pieces
that you'll be replacing.
> There will only be a few users, and they work for the company; I'm not terribly concerned about maximizing performance.
>
> Do you have any suggestions about the most straight-forward way of translating a Wicket application to Swing? I suppose that I would represent each page as a JFrame, and each panel as a JPanel.
>
> In my panels I have a number of components (buttons, checkboxes, radio buttons...), many (but not all) of which post back immediately on change, and a very few AJAX components that redraw only a bit of the page. What would be the most direct method of modeling page post-back (and partial post-back, for the AJAX components) in Swing?
>
> This question is kind of ironic, since Wicket was created to provide a more Swing-like approach to web programming, and now I'm wondering about Wicket-like approach to Swing programming! :-)
Sorry, I don't have any actual technical advice for you here. It just
seems like the kind of project that shouldn't happen. Your department
manager should be fighting back against arbitrarily bad requirements.
--
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket? Use Brix! http://brixcms.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org