You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by jweekend <jw...@cabouge.com> on 2007/10/30 23:36:19 UTC
Just 1 hour to introduce Wicket (Friday)
A development team I did some work with (in a top 5 investment bank) today
asked me to give them a 1 hour intro to Wicket on Friday morning. I have
been telling them it's the way to go for a while and they have finally
"found" an opportunity. I want to make sure I use that hour to best effect,
for them and for Wicket.
The goal is to give them enough of an intro to painlessly get started on
their evaluation, armed with some high-level understanding of how to do
things in Wicket.
They have not used Wicket at all but they all have good web-app experience
and some have a lot of Swing experience too (in fact we were working on a
pretty powerful Swing framework for Credit Risk apps when I was there a
couple of years ago). They will probably want to use Wicket for some
internal support/monitoring/maintenance apps to start with.
So ... what do you think I must NOT omit in my 1 hour talk.
I will unfortunately not be able to help out with their upcoming projects,
but I'd quite like to help them make the right choice of web-framework
anyway because they're nice people and they deserve to give Wicket a good
chance.
Regards - Cemal
http://jWeekend.co.uk jWeekend.co.uk
PS I expect to be asked to do this (or similar) for at least 2 other banking
project teams in London and 1 software house over the next few months. It
seems that more and more people I have been telling Wicket about are
gradually becoming receptive to the idea of starting upcoming new projects
with something smarter than their existing frameworks.
--
View this message in context: http://www.nabble.com/Just-1-hour-to-introduce-Wicket-%28Friday%29-tf4721724.html#a13499281
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Just 1 hour to introduce Wicket (Friday)
Posted by jweekend <jw...@cabouge.com>.
I have had a lot of very positive feedback about the 1 hour Wicket
presentation I gave on Friday and I believe that team will now start
evaluating Wicket and are quite excited about it!
Members of 2 other teams asked if they could also attend but the turn-out
was already way beyond what anybody (including the project manager) had
expected, just from that one team, so there was standing room only in the
conference-room we had booked. I guess we may be asked for a repeat show
soon.
The posts on this thread and the http://manning.com/dashorst/ WIA reworked
chapter 1 Eelco sent me (not quite yet available publicly, I believe) were
very helpful. I also used a few slides from
http://cwiki.apache.org/WICKET/slides-and-presentations.html the wiki and
drew a few UML diagrams that made the Swing developers there feel at home.
So, thanks to everyone for all the helpful input and resources.
One hour is not long and flies quickly by during such presentations, so I
had only about 15 minutes at the end to show-off a bit of code and how easy
turning a link into an Ajax (and then Indicating Ajax) link is, mainly based
on Al's AjaxToggleButton demo from a recent Wicket Users event. The
attendees' seemed to be quite impressed by this (which we all probably just
take for granted now). Their questions (on state/scalability/clustering,
pretty urls, bookmarkable pages, security, Ajax, special tags ...) were
varied and very astute, IMO, considering some of them hadn't even heard of
Wicket before the presentation was arranged, and I think they were quite
impressed with Wicket.
Regards - Cemal
http://jWeekend.co.uk jWeekend.co.uk
PS Does the latest beta release (4) still work with the
http://wicket.apache.org/quickstart.html quickstart instructions. I saw
some posts suggesting that the pom is broken (slf4j and/or log4j versions)
and I'd like to warn them upfront so they don't get the wrong first
impressions, especially with something they can fix so easily if they know
what the problem is and that could waste so much time and cause unnecessary
frustration if they don't have any clue why it isn't "just working" (as I
told them things usually do in Wicket).
Eelco Hillenius wrote:
>
> I like these points.
>
>> 1. All code is Java, which enables end-to-end refactoring and gives
>> you clean html.
>
> And static typing gives you also good means to navigate your code. Use
> your
> IDE to find the uses, overrides, etc. Make unsupported (due to API breaks)
> methods final so that your clients break hard. Users of your components
> can
> use code completion and javadoc hoovers. All the good Java stuff.
>
>> 2. Composition enables reuse. When I took a panel and moved it from a
>> tab on a page to a modalwindow on the page by changing a couple of
>> lines of code it made a big impact.
>
> Another thing that is good about composition is that it makes it easier to
> divide work. You don't have to work from page to page, but rather can pick
> an course to very fine components.
>
>> 3. Components have session state. Hence the content of the session is
>> determined by what components are on the page -- and further the
>> session is cleaned out as components leave scope. (And if state is
>> kept in url parameters then session is not used, in case anyone
>> complains about session size. State must be somewhere, no?)
>
> In the new version of Wicket In Action's chapter one, I state this:
>
> "Wicket bridges the impedance mismatch between the stateless Hypertext
> Transfer
> Protocol (HTTP) and stateful Java programming." I added this after Dhanji
> Prasanna asked me what I planned to say about that, which finally got that
> light-bulb fired: 'that's indeed the core-core problem that Wicket tries
> to
> solve'.
>
> Unfortunately, the new chapter wasn't included in the last MEAP download,
> but I'm sending it to Cemal directly. I hope I do a better job than before
> explaining the key points of Wicket.
>
> Another (potential) interesting point is that Wicket is secure by default.
> Here is an excerpt of chapter 12 (authentication and authorization):
>
> "With Wicket, if you don't code using bookmarkable pages, you use session
> relative pages - Wicket's default way of coding web applications. Page
> instances are kept on the server and you ask Wicket (through your browser)
> for a certain page by providing the page number, version and the component
> that is the target of the request. This works in the opposite way of the
> REST architectural pattern, which states that servers should not keep
> state,
> but clients provide servers with the relevant state when they issue
> requests. As we saw in the first chapter, REST is great for scalability,
> but
> lousy for the programming model. And now we get to another problem with
> REST: the pattern is inherently unsafe, whereas Wicket's server state
> pattern is safe by default.
>
> For instance, if you implement the functionality of removing an object
> using
> a link like this:
>
> final MyObject myObject = …
> new Link("remove") {
> myDao.remove(myObject);
> }
>
> you never need to be worried about pimple faced fourteen year olds trying
> to
> 'hack' your web application. They would have to hijack the session, guess
> the - session relative - page ids and version numbers, and the relevant
> component paths. Very unlikely anyone ever will pull that off. And you can
> even make your Wicket application more secure by encrypting requests with
> for instance CryptedUrlWebRequestCodingStrategy. It simply doesn't get any
> safer.
>
> The REST variant of building your application would use bookmarkable pages
> like this:
>
> public DeleteMyObjectPage(PageParameters p) {
> super(p);
> Long id = p.getLong("id");
> myDao.remove(MyObject.class, id);
> }
>
> The latter example, which is similar to how you would use "actions" or
> "commands" with model 2 frameworks, is unsafe in two distinct ways. The
> location of DeleteMyObjectPage can be guessed, thus exposing that
> functionality to misuse. And even if users are authorized to access that
> page and access itself is not a problem, they might only be authorized to
> delete certain instances of MyObject. Without explicit protection, they
> could guess ids or even write a script to delete whole parts of the
> database. That means extra coding and potential security holes that can be
> overlooked, whereas the 'session relative way' doesn't require you to do
> anything extra in this respect."
>
> Personally, I think this is a great feature. Though in all fairness,
> session
> relative pages also makes testing harder.
>
> Eelco
>
>
--
View this message in context: http://www.nabble.com/Just-1-hour-to-introduce-Wicket-%28Friday%29-tf4721724.html#a13571862
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Just 1 hour to introduce Wicket (Friday)
Posted by Eelco Hillenius <ee...@gmail.com>.
I like these points.
> 1. All code is Java, which enables end-to-end refactoring and gives
> you clean html.
And static typing gives you also good means to navigate your code. Use your
IDE to find the uses, overrides, etc. Make unsupported (due to API breaks)
methods final so that your clients break hard. Users of your components can
use code completion and javadoc hoovers. All the good Java stuff.
> 2. Composition enables reuse. When I took a panel and moved it from a
> tab on a page to a modalwindow on the page by changing a couple of
> lines of code it made a big impact.
Another thing that is good about composition is that it makes it easier to
divide work. You don't have to work from page to page, but rather can pick
an course to very fine components.
> 3. Components have session state. Hence the content of the session is
> determined by what components are on the page -- and further the
> session is cleaned out as components leave scope. (And if state is
> kept in url parameters then session is not used, in case anyone
> complains about session size. State must be somewhere, no?)
In the new version of Wicket In Action's chapter one, I state this:
"Wicket bridges the impedance mismatch between the stateless Hypertext
Transfer
Protocol (HTTP) and stateful Java programming." I added this after Dhanji
Prasanna asked me what I planned to say about that, which finally got that
light-bulb fired: 'that's indeed the core-core problem that Wicket tries to
solve'.
Unfortunately, the new chapter wasn't included in the last MEAP download,
but I'm sending it to Cemal directly. I hope I do a better job than before
explaining the key points of Wicket.
Another (potential) interesting point is that Wicket is secure by default.
Here is an excerpt of chapter 12 (authentication and authorization):
"With Wicket, if you don't code using bookmarkable pages, you use session
relative pages - Wicket's default way of coding web applications. Page
instances are kept on the server and you ask Wicket (through your browser)
for a certain page by providing the page number, version and the component
that is the target of the request. This works in the opposite way of the
REST architectural pattern, which states that servers should not keep state,
but clients provide servers with the relevant state when they issue
requests. As we saw in the first chapter, REST is great for scalability, but
lousy for the programming model. And now we get to another problem with
REST: the pattern is inherently unsafe, whereas Wicket's server state
pattern is safe by default.
For instance, if you implement the functionality of removing an object using
a link like this:
final MyObject myObject = …
new Link("remove") {
myDao.remove(myObject);
}
you never need to be worried about pimple faced fourteen year olds trying to
'hack' your web application. They would have to hijack the session, guess
the - session relative - page ids and version numbers, and the relevant
component paths. Very unlikely anyone ever will pull that off. And you can
even make your Wicket application more secure by encrypting requests with
for instance CryptedUrlWebRequestCodingStrategy. It simply doesn't get any
safer.
The REST variant of building your application would use bookmarkable pages
like this:
public DeleteMyObjectPage(PageParameters p) {
super(p);
Long id = p.getLong("id");
myDao.remove(MyObject.class, id);
}
The latter example, which is similar to how you would use "actions" or
"commands" with model 2 frameworks, is unsafe in two distinct ways. The
location of DeleteMyObjectPage can be guessed, thus exposing that
functionality to misuse. And even if users are authorized to access that
page and access itself is not a problem, they might only be authorized to
delete certain instances of MyObject. Without explicit protection, they
could guess ids or even write a script to delete whole parts of the
database. That means extra coding and potential security holes that can be
overlooked, whereas the 'session relative way' doesn't require you to do
anything extra in this respect."
Personally, I think this is a great feature. Though in all fairness, session
relative pages also makes testing harder.
Eelco
Re: Just 1 hour to introduce Wicket (Friday)
Posted by jweekend <jw...@cabouge.com>.
As always on this forum we have managed to come up with some really helpful
information and ideas in double quick time! Thanks for all the input ... I
will now merge everything in with my original thoughts and see what I can
realistically expect to cover in 1 hour. I also hope this bag of ideas will
be useful to others who want to see Wicket get the support it deserves
and/or those who are trying to convince their PMs/teams that there really is
a better way to develop web apps and how much sense it makes (in terms of
$s, quality and job satisfaction, on top of all the technical stuff brought
up in this thread).
Any more thoughts are obviously more than welcome, but either way, I hope to
post about how it goes soon (probably not until next week as Al and I are
running the http://jweekend.co.uk/dev/JW703/ weekend Wicket course on
Saturday and Sunday and then we have to prepare for the our
http://jweekend.co.uk/dev/LWUGReg/ London Wicket Users Group event on
Tuesday evening where I hope to talk about Trees in Wicket).
Thanks again for all the high quality feedback.
Regards - Cemal
http://jWeekend.co.uk jWeekend.co.uk
Jan Kriesten wrote:
>
>
> hi cemal,
>
>> Not bad for an hour, but there are probably even more "essentials" that
>> need
>> to be mentioned at least. What have we missed?
>
> i find a key selling point to customers that you can easily run unit-tests
> on
> your projects - especially if the customers are in banking business. also,
> wicket's secure by default, so that might count, too. :-)
>
> when i did my presentation, it came out that presenting a more complex
> example
> showed the 'big picture' with wicket. so you might not want to implement a
> small
> ajax-component but show an integrated one and show how it's implemented
> and
> (re)used in the application, same for behaviours (e.g.
> JavascriptEventConfirmation in onclick). This saves you presentation time
> and
> you get a bigger 'ahaaaa!'.
>
> best regards, --- jan.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Just-1-hour-to-introduce-Wicket-%28Friday%29-tf4721724.html#a13517074
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Just 1 hour to introduce Wicket (Friday)
Posted by Jan Kriesten <ja...@renitence.de>.
hi cemal,
> Not bad for an hour, but there are probably even more "essentials" that need
> to be mentioned at least. What have we missed?
i find a key selling point to customers that you can easily run unit-tests on
your projects - especially if the customers are in banking business. also,
wicket's secure by default, so that might count, too. :-)
when i did my presentation, it came out that presenting a more complex example
showed the 'big picture' with wicket. so you might not want to implement a small
ajax-component but show an integrated one and show how it's implemented and
(re)used in the application, same for behaviours (e.g.
JavascriptEventConfirmation in onclick). This saves you presentation time and
you get a bigger 'ahaaaa!'.
best regards, --- jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Just 1 hour to introduce Wicket (Friday)
Posted by jweekend <jw...@cabouge.com>.
Scott,
That's a powerful and well made argument. Thank you, I'm in!
I was going to show a simple-arithmetic-test panel (a simple captcha
replacement mechanism developed because I can never make out the Wicket
ones) and how that can be reused. This went down well at our first
http://jweekend.co.uk/dev/LWUGReg/ London Wicket User Group (LWUG) event.
We used instances of the same component on both the jWeekend "contact
us/preview your message" page and on the "LWUG registration confirmation"
page.
I always show-off markup-inheritance because I like it!
The quality and helpfulness of this forum must get a big mention and also
the Wicket examples and gradually improving quality/organisation of the
docs/wiki. And, http://manning.com/dashorst/ Wicket In Action .
I'll probably not go too deeply into state (concerns) in 1 hour (except that
if they're worried, they're being presumptuous and premature ;-) but I'll
certainly mention/describe detachable models.
A simple Ajax component is a must (I may borrow the AjaxOnOffToggleLink
example http://herebebeasties.com Al Maw built in front of the audience at
another LWUG), which also includes a bit of i18n but that may not be key for
this audience).
I agree that "behaviours" is an essential topic, but I doubt I can do them,
as well as all the above (and a mvn archetype/quickstart/eclipse demo),
justice in 1 hour. I may draw a class diagram to show the general concepts
and mention behaviours.
Integration with Ajax libraries is not something I have played with yet, but
agree it would be cool. While we're on the topic,
http://dhtmlx.com/docs/products/dhtmlxTreeGrid/samples/drag_n_drop/treeGrid_drag.html
this 'd be nice as a Wicket component.
I'll probably also run down a more comprehensive list of things Wicket let's
you do easily and well (IoC, security, bookmarkable pages etc...) without
any detail at all, just so they know what is in the box.
Nick also mentioned the
http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-phonebook
phonebook app - another good idea.
Gerolf mentioned "Xavier's slides for the talk at javazone'07" which I may
dig out too.
Not bad for an hour, but there are probably even more "essentials" that need
to be mentioned at least. What have we missed?
Regards - Cemal
http://jWeekend.co.uk jWeekend.co.uk
Scott Swank wrote:
>
> 1. All code is Java, which enables end-to-end refactoring and gives
> you clean html.
>
> 2. Composition enables reuse. When I took a panel and moved it from a
> tab on a page to a modalwindow on the page by changing a couple of
> lines of code it made a big impact.
>
> 3. Components have session state. Hence the content of the session is
> determined by what components are on the page -- and further the
> session is cleaned out as components leave scope. (And if state is
> kept in url parameters then session is not used, in case anyone
> complains about session size. State must be somewhere, no?)
>
> 4. Simple AJAX and nice integration with JS libraries such as Dojo.
>
> 5. i18n: resource bundles, component-level, page-level, application-level
>
> 6. Behaviors: What about a tab-order-preserving behavior to keep
> tabbing between fields from multiple panels sensible? That's
> (relatively) easy. What about a content-copying behavior to copy the
> purchaser's first/last name from the first item to all other items?
> That's easy too. This is because everything is Java, including how
> components act and how state (models) are maintained.
>
> I would focus on 1, 2 & 3; then give a quick look at some code that
> shows 4, then just mention 5 & 6.
>
> - Scott
>
>
>
>
> On 10/30/07, jweekend <jw...@cabouge.com> wrote:
>>
>> Nick,
>> In fact that's why someone from jWeekend first wrote to you in May when
>> you
>> were coming to the UK. I can imagine that there'll be lots to do in
>> 2008/9
>> for jWeekend and Wicket end-users.
>> In the meantime, after I tell them about you, what else must I NOT omit ?
>> ;-)
>> Regards - Cemal
>> http://jWeekend.co.uk jWeekend.co.uk
>>
>>
>>
>> Nick Heudecker wrote:
>> >
>> > The ONE thing you must not omit is telling them that I provide Wicket
>> > consulting. :)
>> >
>> > On 10/30/07, jweekend <jw...@cabouge.com> wrote:
>> >>
>> >>
>> >> A development team I did some work with (in a top 5 investment bank)
>> >> today
>> >> asked me to give them a 1 hour intro to Wicket on Friday morning. I
>> have
>> >> been telling them it's the way to go for a while and they have finally
>> >> "found" an opportunity. I want to make sure I use that hour to best
>> >> effect,
>> >> for them and for Wicket.
>> >>
>> >> The goal is to give them enough of an intro to painlessly get started
>> on
>> >> their evaluation, armed with some high-level understanding of how to
>> do
>> >> things in Wicket.
>> >>
>> >> They have not used Wicket at all but they all have good web-app
>> >> experience
>> >> and some have a lot of Swing experience too (in fact we were working
>> on a
>> >> pretty powerful Swing framework for Credit Risk apps when I was there
>> a
>> >> couple of years ago). They will probably want to use Wicket for some
>> >> internal support/monitoring/maintenance apps to start with.
>> >>
>> >> So ... what do you think I must NOT omit in my 1 hour talk.
>> >>
>> >> I will unfortunately not be able to help out with their upcoming
>> >> projects,
>> >> but I'd quite like to help them make the right choice of web-framework
>> >> anyway because they're nice people and they deserve to give Wicket a
>> good
>> >> chance.
>> >>
>> >> Regards - Cemal
>> >> http://jWeekend.co.uk jWeekend.co.uk
>> >>
>> >> PS I expect to be asked to do this (or similar) for at least 2 other
>> >> banking
>> >> project teams in London and 1 software house over the next few months.
>> It
>> >> seems that more and more people I have been telling Wicket about are
>> >> gradually becoming receptive to the idea of starting upcoming new
>> >> projects
>> >> with something smarter than their existing frameworks.
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Just-1-hour-to-introduce-Wicket-%28Friday%29-tf4721724.html#a13499281
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Nick Heudecker
>> > Professional Wicket Training & Consulting
>> > http://www.systemmobile.com
>> >
>> > Eventful - Intelligent Event Management
>> > http://www.eventfulhq.com
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Just-1-hour-to-introduce-Wicket-%28Friday%29-tf4721724.html#a13499552
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Scott Swank
> reformed mathematician
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Just-1-hour-to-introduce-Wicket-%28Friday%29-tf4721724.html#a13501123
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Just 1 hour to introduce Wicket (Friday)
Posted by Scott Swank <sc...@gmail.com>.
1. All code is Java, which enables end-to-end refactoring and gives
you clean html.
2. Composition enables reuse. When I took a panel and moved it from a
tab on a page to a modalwindow on the page by changing a couple of
lines of code it made a big impact.
3. Components have session state. Hence the content of the session is
determined by what components are on the page -- and further the
session is cleaned out as components leave scope. (And if state is
kept in url parameters then session is not used, in case anyone
complains about session size. State must be somewhere, no?)
4. Simple AJAX and nice integration with JS libraries such as Dojo.
5. i18n: resource bundles, component-level, page-level, application-level
6. Behaviors: What about a tab-order-preserving behavior to keep
tabbing between fields from multiple panels sensible? That's
(relatively) easy. What about a content-copying behavior to copy the
purchaser's first/last name from the first item to all other items?
That's easy too. This is because everything is Java, including how
components act and how state (models) are maintained.
I would focus on 1, 2 & 3; then give a quick look at some code that
shows 4, then just mention 5 & 6.
- Scott
On 10/30/07, jweekend <jw...@cabouge.com> wrote:
>
> Nick,
> In fact that's why someone from jWeekend first wrote to you in May when you
> were coming to the UK. I can imagine that there'll be lots to do in 2008/9
> for jWeekend and Wicket end-users.
> In the meantime, after I tell them about you, what else must I NOT omit ?
> ;-)
> Regards - Cemal
> http://jWeekend.co.uk jWeekend.co.uk
>
>
>
> Nick Heudecker wrote:
> >
> > The ONE thing you must not omit is telling them that I provide Wicket
> > consulting. :)
> >
> > On 10/30/07, jweekend <jw...@cabouge.com> wrote:
> >>
> >>
> >> A development team I did some work with (in a top 5 investment bank)
> >> today
> >> asked me to give them a 1 hour intro to Wicket on Friday morning. I have
> >> been telling them it's the way to go for a while and they have finally
> >> "found" an opportunity. I want to make sure I use that hour to best
> >> effect,
> >> for them and for Wicket.
> >>
> >> The goal is to give them enough of an intro to painlessly get started on
> >> their evaluation, armed with some high-level understanding of how to do
> >> things in Wicket.
> >>
> >> They have not used Wicket at all but they all have good web-app
> >> experience
> >> and some have a lot of Swing experience too (in fact we were working on a
> >> pretty powerful Swing framework for Credit Risk apps when I was there a
> >> couple of years ago). They will probably want to use Wicket for some
> >> internal support/monitoring/maintenance apps to start with.
> >>
> >> So ... what do you think I must NOT omit in my 1 hour talk.
> >>
> >> I will unfortunately not be able to help out with their upcoming
> >> projects,
> >> but I'd quite like to help them make the right choice of web-framework
> >> anyway because they're nice people and they deserve to give Wicket a good
> >> chance.
> >>
> >> Regards - Cemal
> >> http://jWeekend.co.uk jWeekend.co.uk
> >>
> >> PS I expect to be asked to do this (or similar) for at least 2 other
> >> banking
> >> project teams in London and 1 software house over the next few months. It
> >> seems that more and more people I have been telling Wicket about are
> >> gradually becoming receptive to the idea of starting upcoming new
> >> projects
> >> with something smarter than their existing frameworks.
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Just-1-hour-to-introduce-Wicket-%28Friday%29-tf4721724.html#a13499281
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > Nick Heudecker
> > Professional Wicket Training & Consulting
> > http://www.systemmobile.com
> >
> > Eventful - Intelligent Event Management
> > http://www.eventfulhq.com
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Just-1-hour-to-introduce-Wicket-%28Friday%29-tf4721724.html#a13499552
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Scott Swank
reformed mathematician
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Just 1 hour to introduce Wicket (Friday)
Posted by jweekend <jw...@cabouge.com>.
Nick,
In fact that's why someone from jWeekend first wrote to you in May when you
were coming to the UK. I can imagine that there'll be lots to do in 2008/9
for jWeekend and Wicket end-users.
In the meantime, after I tell them about you, what else must I NOT omit ?
;-)
Regards - Cemal
http://jWeekend.co.uk jWeekend.co.uk
Nick Heudecker wrote:
>
> The ONE thing you must not omit is telling them that I provide Wicket
> consulting. :)
>
> On 10/30/07, jweekend <jw...@cabouge.com> wrote:
>>
>>
>> A development team I did some work with (in a top 5 investment bank)
>> today
>> asked me to give them a 1 hour intro to Wicket on Friday morning. I have
>> been telling them it's the way to go for a while and they have finally
>> "found" an opportunity. I want to make sure I use that hour to best
>> effect,
>> for them and for Wicket.
>>
>> The goal is to give them enough of an intro to painlessly get started on
>> their evaluation, armed with some high-level understanding of how to do
>> things in Wicket.
>>
>> They have not used Wicket at all but they all have good web-app
>> experience
>> and some have a lot of Swing experience too (in fact we were working on a
>> pretty powerful Swing framework for Credit Risk apps when I was there a
>> couple of years ago). They will probably want to use Wicket for some
>> internal support/monitoring/maintenance apps to start with.
>>
>> So ... what do you think I must NOT omit in my 1 hour talk.
>>
>> I will unfortunately not be able to help out with their upcoming
>> projects,
>> but I'd quite like to help them make the right choice of web-framework
>> anyway because they're nice people and they deserve to give Wicket a good
>> chance.
>>
>> Regards - Cemal
>> http://jWeekend.co.uk jWeekend.co.uk
>>
>> PS I expect to be asked to do this (or similar) for at least 2 other
>> banking
>> project teams in London and 1 software house over the next few months. It
>> seems that more and more people I have been telling Wicket about are
>> gradually becoming receptive to the idea of starting upcoming new
>> projects
>> with something smarter than their existing frameworks.
>> --
>> View this message in context:
>> http://www.nabble.com/Just-1-hour-to-introduce-Wicket-%28Friday%29-tf4721724.html#a13499281
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Nick Heudecker
> Professional Wicket Training & Consulting
> http://www.systemmobile.com
>
> Eventful - Intelligent Event Management
> http://www.eventfulhq.com
>
>
--
View this message in context: http://www.nabble.com/Just-1-hour-to-introduce-Wicket-%28Friday%29-tf4721724.html#a13499552
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Just 1 hour to introduce Wicket (Friday)
Posted by Nick Heudecker <nh...@gmail.com>.
The ONE thing you must not omit is telling them that I provide Wicket
consulting. :)
On 10/30/07, jweekend <jw...@cabouge.com> wrote:
>
>
> A development team I did some work with (in a top 5 investment bank) today
> asked me to give them a 1 hour intro to Wicket on Friday morning. I have
> been telling them it's the way to go for a while and they have finally
> "found" an opportunity. I want to make sure I use that hour to best
> effect,
> for them and for Wicket.
>
> The goal is to give them enough of an intro to painlessly get started on
> their evaluation, armed with some high-level understanding of how to do
> things in Wicket.
>
> They have not used Wicket at all but they all have good web-app experience
> and some have a lot of Swing experience too (in fact we were working on a
> pretty powerful Swing framework for Credit Risk apps when I was there a
> couple of years ago). They will probably want to use Wicket for some
> internal support/monitoring/maintenance apps to start with.
>
> So ... what do you think I must NOT omit in my 1 hour talk.
>
> I will unfortunately not be able to help out with their upcoming projects,
> but I'd quite like to help them make the right choice of web-framework
> anyway because they're nice people and they deserve to give Wicket a good
> chance.
>
> Regards - Cemal
> http://jWeekend.co.uk jWeekend.co.uk
>
> PS I expect to be asked to do this (or similar) for at least 2 other
> banking
> project teams in London and 1 software house over the next few months. It
> seems that more and more people I have been telling Wicket about are
> gradually becoming receptive to the idea of starting upcoming new projects
> with something smarter than their existing frameworks.
> --
> View this message in context:
> http://www.nabble.com/Just-1-hour-to-introduce-Wicket-%28Friday%29-tf4721724.html#a13499281
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Nick Heudecker
Professional Wicket Training & Consulting
http://www.systemmobile.com
Eventful - Intelligent Event Management
http://www.eventfulhq.com
RE: Just 1 hour to introduce Wicket (Friday)
Posted by Maeder Thomas <th...@ecofin.ch>.
One thing I always think is totally awesome is this: you develop your
demo application, introduce some AJAX, etc. Just be sure to use stuff
that has non-AJAX fallbacks. Then, at the end you can just turn off
javascript and everything still just works. Dropped my jaw for sure;-)
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org