Re: Just 1 hour to introduce Wicket (Friday)

[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