Re: Apache Wicket is a Flawed Framework

[Eelco Hillenius]

> @Alex Objelean & Igor Vanyberg-2
> Yea, my bad on just posting something up here without looking at any
> previous posts.  Look, it was my rant and how I felt about things at the
> time.  Nothing personal.  This was actually the clean version for public
> consumption.  It was probably still too rude though.  Sorry about that.  I
> suppose it would be lame to spend a lot of time on a framework and then have
> some kid post up a “Wicket Sucks” post.

If you want to blow off steam and tell people you think X sucks,
that's fine, but do it on a blog or something. It's just bad style to
do this on a list that is meant to help out with X. If at all, the
developer list would be better, but even then, you may want to
consider having a chat with some of the developers first to see what
their reasons for some of the things you dislike may be. Anyway,
constructive criticism is good on a list like that, but I didn't get
much of the constructiveness...

> @Jonathan Locke
> I agree that Java is fast.  I don't worry about scaling and performance
> because of that.  To the people worrying about memory, I don't think that is
> a big deal.  Sure any framework is going to waste more memory than bare
> bones JSP/Servlets, but memory is cheap.  Eclipse is like the biggest hog
> ever and look at how successful it is.
>
> Also, I am sticking with Java.  I have a really good job and such.  The only
> reason I would ever move is if I could land a leet job in the Valley doing
> Python at some sweet start-up.  Not likely though.

Do you live in the Bay Area? Seems to me there's plenty of work for
folks wanting to do coding in other languages than Java, particularly
for startups.

> Java is better than some
> of the alternatives out there:
> http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto.  Scala is still
> too unstable.  The other Java web-frameworks are all flawed too.  I don't
> hate my job either.

Any choice will have it's own disadvantages. Also depends on what you
use a language for. I'm not sold on Scala, but I wouldn't think it's
not stable enough for production. May have to be careful doing
upgrades maybe.

> @sthomps
> LOL!  You know Eleco Hilenius wrote the “Wicket in Action” book?  For some
> reason I can't stop laughing.  Now everyone is going to think you are a
> badass at work.  The book is decent, but it would be nice if the next
> edition would have a chapter at the end that rewrites the “Cheese Store”
> into  “Cheese Store 2.0,” using all the advanced stuff that was explained in
> the latter chapters.  It would help Wicket newcomers like me.  It would also
> show how to do a real app with best-practices.

Well, I can tell you that I hated every minute of writing it :-) One
of these things one can do to 'just have done once in a life' and I'm
happy to hear from people that were helped by it, and hope it helped
the framework reach a certain stage of 'maturity', but never again
will I write tech book in my life.

Anyway, I always thought and still think that a good set of examples
and test cases are often more valuable to a project. Imho the first
chapter of Wicket In Action is the most important one, as it goes into
the why and rough outline of how. After that, I think you should hit
the examples and dig through the code. That at least works best for
me... then again, I'm very much an autodidact kind of guy and respect
that this is not the best way for everyone.

Now, since I'm typing anyway, here are my 2c on your points:

* "Violates Dry" -> It does a bit, but I believe for a reasonable
purpose. We've explored several alternatives at some point, but felt
this was the least of evils

* "Not previewable" -> Hah, this one is funny... point by point;
- "First, we don't have seperate designers at my company" -> so...
who's fault is that?
- "Second, it is better if the samer person" -> ah, so you think that
1 is a good idea. Well, I - as I'm sure most people who've worked on
projects with some scale will agree with - disagree with you on that.
Unless you are a fantastic UX persons. But most likely (just
statistics, sorry) as you're posting to a programming list, you're not
does development and design.
- "Third, if you use extends your page will not be priviewable..." ->
Yep. So if you use it, you lose that benefit. You could not use it, or
just suck it up and still be happy with the other benefits that a good
separation of concerns give you.

* "Violates MVC" -> Who cares about MVC purity. It hasn't been 'pure'
since the original article. Funny you mention Spring MVC, as I think
that having special constructs for 'flow' is just very silly unless
maybe you are writing a business process engine.

* "Excessively verbose and complicated" -> Verbosity is often there to
make it easier to understand what something is/ might do. I'm sure we
don't always succeed in that. Complicated is something that Wicket is
also. We've been trying to find the right balance between that and
power. Some things worked out better than ot

Re: Apache Wicket is a Flawed Framework

[Eelco Hillenius]

Really, is this what you do, go around posting to user lists of
frameworks you don't like? I imagine one can have a full time job
doing that.

Eelco


On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki  wrote:
> Violates Dry:  You must repeat the component hierarchy of your widgets that
> are in HTML in Java Code for no good reason.  If you move your widget around
> in the html it will break the Java and you get a stack trace if you change
> the nesting.  You have to keep these two files synched.  A JSP file is more
> maintainable.  At least the view code is in one place.
>
> Not previewable:  One of the supposed benefits of Wicket is a clean template
> that could make pages previewable for designers.  First, we don't have
> seperate designers at my company.  Second, it is better if the samer person
> does development and design.  Third, if you use extends your page will not
> be priviewable outside an application server running Wicket.  This supposed
> benefit does not exist.
>
> Violates MVC:  It smashes view and controller code into the same Java file.
> You have code that regulates page flow and code that changes css attributes
> in the same file.  Even Spring MVC had better separation of concerns.
> JSP/Servlets with Spring MVC is better.
>
> Excessively verbose and complicated:  What is a LoadableDetachableModel?
> The learning curve for Wicket is immense.
>
> Breaks POJOS:  A real POJO does not need to implement an interface or extend
> a class.  Wicket forces your beans to be Serializable.  This is like using
> EJBs in how it forced you to implement interfaces.
>
> Terrible AJAX:  Compared to a few lines of jQuery AJAX is excessively
> complicated and verbose in Wicket.  A lot of things like “AJAX” links should
> not be done via “AJAX” at all.  Hiding a div on the client would simply be
> done with JavaScript on the client.  Wicket better not require a server
> request for that.  You also have no JSON support and good luck debugging any
> JavaScript or AJAX in Firefox.  Instead you have to use the subpar Wicket
> debugging.
>
> HTML5:  No support for HTML 5 form elements unless you upgrade to Wicket
> 1.5.  You will get a stack trace.  The upgrade to Wicket 1.5 is painful and
> will break your code.  Good luck getting this to work with jQuery mobile.
>
> Bad Defaults:  Most pages are stateless.  The default for Wicket is
> stateful.  So if I want a decent URL and a bookmarkable page I have to mount
> the page and use a bookmarkable page link with page parameters.  Using page
> parameters is worse than how Spring MVC does binding.  I have to keep doing
> this over and over for each page.  There is too much work involved to get a
> decent stateless page with a nice URL. This should be the default.
>
> Interferes with other libraries:  It screws up your jQuery code.  It forces
> you into a restrictive way of doing web-development:  the Wicket Way.
>
> Causes a redeploy whenever you add anything:  Maybe Java developers are used
> to this, but in any other web development environment I do not need to
> redeploy after adding a text box to the page.  It is completely absurd.
> Only with JRebel is this alleviated.  No, embedded Jetty in debug mode still
> slow.  Even a simple JSP file has hot reloading on Tomcat and if I make a
> change to my view code the changes are immediately viewable in the browser
> when I refresh.  This is WITHOUT JRebel.
>
> HTTPSession Objects are not hard:  Most pages do not need state.  If you do
> use HTTPSession it is simple.  Can you use a map?  Then you can use
> HTTPSession.  This is less comlicated than most Wicket code.
>
> Stateful Component based framework are a terrible idea:  Even at the
> theoretical level this is a bad idea. It is a leaky abstraction over a
> simple request/response cycle.  It made something simple and made it overly
> complicated.  This remind me of Hibernate and ORMS.  I disagree that we
> should abstract things to this level and do everything in verbose Java.
> People are dropping Hibernate and going back to native SQL and Spring JDBC
> template.  SQL and the relational model are easy.  Working with HTTP
> requests is easy too.  What was wrong with JSPs/Servlets?  Keep it simple
> stupid.  We know JSF was too complicated and it was terrible.  Spring MVC is
> better and has rest support.  It just works with Spring and has great
> support for the JSON Jackson mapper.
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4080411.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apac

Re: An extensive RIA technology comparison matrix including Wicket

[Eelco Hillenius]

Ugh, I mean 'just do that in JavaScript'

On Thu, Oct 27, 2011 at 7:07 PM, Eelco Hillenius
 wrote:
>> To be honest, I don't think the comparison matrix is that bad. I would
>> consider a framework like Vaadin over Wicket if all I wanted a typical
>> desktop style only (menu bar, content frames + layout manager, fancy
>> widgets) only type of application, what they call "application
>> oriented", especially if it would benefit a lot from client-side UI
>> management.
>
> Or just do that in Java. I can tell you from experience that
> developing (and e.g. debugging!) with GWT is painful on many different
> levels. I like how Vaadin markets itself, what it's goals are etc, but
> I can't imagine not stumbling into the same kind of hassle that comes
> with developing with GWT. Might even make it worse, as it's yet
> another abstraction over it.
>
> My2c,
>
> Eelco
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: An extensive RIA technology comparison matrix including Wicket

[Eelco Hillenius]

> To be honest, I don't think the comparison matrix is that bad. I would
> consider a framework like Vaadin over Wicket if all I wanted a typical
> desktop style only (menu bar, content frames + layout manager, fancy
> widgets) only type of application, what they call "application
> oriented", especially if it would benefit a lot from client-side UI
> management.

Or just do that in Java. I can tell you from experience that
developing (and e.g. debugging!) with GWT is painful on many different
levels. I like how Vaadin markets itself, what it's goals are etc, but
I can't imagine not stumbling into the same kind of hassle that comes
with developing with GWT. Might even make it worse, as it's yet
another abstraction over it.

My2c,

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Google Chrome and Apache Wicket, an awesome combination

[Eelco Hillenius]

Imho the overall user experience in Chrome is better, including the
developer tools. Even if it might miss a feature of two :-)

Eelco


On Mon, May 23, 2011 at 10:52 AM, Martin Grigorov  wrote:
> Well, I don't share your opinion here :-)
>
> Chrome Dev tools have no "persist console content" - once you reload the
> page all the logs are gone. There is a RFE for that and I voted for it.
> Also I miss the 'Net' tab.
> Also Firefox's WebDeveloper tools are much better than current state in
> Chrome and its extensions.
>
> On Mon, May 23, 2011 at 8:45 PM, Brown, Berlin [GCG-PFS] <
> berlin.br...@primerica.com> wrote:
>
>> FYI...
>>
>> I usually ask questions but I thought I post a comment about google
>> chrome.  The chrome browser has default web debugging that is similar to
>> firebug.
>>
>> With Firebug, it is more difficult to detect the wicket ajax rendered
>> content but comes up automatically in chrome.  Also speed wise, chrome
>> renders much faster than IE or Firefox.  I tested Ajax oriented complex
>> content and chrome just works quickly.
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com 
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [ANN] Plugin WicketForge 0.9.2 available for IDEA 9+

[Eelco Hillenius]

Great job, thanks for maintaining it!

Eelco

On Tue, Apr 12, 2011 at 1:47 PM, Minas Manthos  wrote:
> Recent change notes:
>
> 0.9.2
> -Fixed: gutter jitter [Defect 77]
> -Fixed: Repeated F4 from class needs me to move cursor [Defect 62]
> -Fixed: WicketForge does not recognize FormComponentPanel as a Panel [Defect
> 70]
> -Fixed: Border hierarchy not recognised [Enhancement 68]
> -Minor changes
>
> 0.9.1
> -Fixed: Exception on ListView.populateItem() of inner classes. [Defect 67]
> -Fixed: Typo 'Auth Roles'. [Defect 66]
> -Added: Hitting 'Wicket Java/HTML Toggle' offers to create markup if not
> present. [Enhancement 64]
> -Minor changes
>
> * rate this plugin at http://plugins.intellij.net/plugin/?id=1545 ;-)
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/ANN-Plugin-WicketForge-0-9-2-available-for-IDEA-9-tp3445657p3445657.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Apache Wicket Cookbook Published!

[Eelco Hillenius]

Another baby, congrats!

Eelco

On Fri, Mar 25, 2011 at 10:44 AM, Igor Vaynberg  wrote:
> For the past nine months I have been quietly working on a book about
> Wicket. Unlike other books on the market this one does not attempt to
> teach you Wicket from the ground up. Instead, it is for developers who
> already know the basics and want to learn how to implement some of the
> more advanced use cases. Essentially, it contains recipes that show
> the reader how to implement solutions to some of, what I think are,
> the most commonly asked questions and stumbling blocks. This morning I
> was informed that the book has been published! You can read more about
> it and pick up a copy on PACKT's Site[1]. I hope you enjoy it, more
> details below...
>
> [1] https://www.packtpub.com/apache-wicket-cookbook/book
>
> ## Description ##
>
> Apache Wicket is one of the most famous Java web application
> frameworks. Wicket simplifies web development and makes it fun. Are
> you bored of going through countless pages of theory to find out how
> to get your web development done? With this book in hand, you don't
> need to go through hundreds of pages to figure out how you will
> actually build a web application. You will get practical solutions to
> your common everyday development tasks to pace up your development
> activities.
>
> Apache Wicket Cookbook provides you with information that gets your
> problems solved quickly without beating around the bush. This book is
> perfect for you if you are ready to take the next step from tutorials
> and step into the practical world. It will take you beyond the basics
> of using Apache Wicket and show you how to leverage Wicket's advanced
> features to create simpler and more maintainable solutions to what at
> first may seem complex problems.
>
> You will learn how to integrate with client-side technologies such as
> JavaScript libraries or Flash components, which will help you to build
> your application faster. You will discover how to use Wicket paradigms
> to factor out commonly used code into custom Components, which will
> reduce the maintenance cost of your application, and how to leverage
> the existing Wicket Components to make your own code simpler.
>
> A straightforward Cookbook with highly focused practical recipes to
> make your web application development easier with the Wicket web
> framework
>
> ## What you will learn from this book ##
>
> * Leverage Wicket to implement a wide variety of both simple and
> advanced use cases in a narrative that gets straight to the point
> * Make forms work in the crazy world of the Web by learning the ways
> of Wicket's form processing
> * Simplify localizing your Wicket applications
> * Take the boring out of your forms by discovering how to improve the
> user experience while simplifying your code at the same time
> * Leverage the built-in Table component to make displaying tabular data a snap
> * Think Wicket's Borders are not very useful? Learn to use them in
> unexpected places to simplify things
> * See how to integrate with Flash components and create interactive
> charts at the same time
> * Web 1.0 too boring? Learn how to tame Wicket's AJAX support and
> bring your application into Web 2.0
> * Simplify your security code by learning various security techniques
> * An application cannot be built with Wicket alone; see how to make it
> play nice with other frameworks
>
> ## Approach ##
>
> This is a hands-on practical guide to a large variety of topics and
> use cases. This book tries to use real-world examples when possible,
> but is not afraid to come up with a contrived pretext if it makes
> explaining the problem simpler. Unlike a lot of other books, this one
> does not try to maintain a continuous theme from chapter to chapter,
> such as demonstrating solutions on the same fictional application;
> doing so would be almost impossible given the wide variety of recipes
> presented here. Instead, this book concentrates on focused problems
> users are likely to encounter and shows clear solutions in a
> step-by-step manner. This book tries to teach by example and is not
> afraid to show a lot of code because, after all, it is for coders.
>
> ## Who this book is written for ##
>
> This book is for current users of the Apache Wicket framework; it is
> not an introduction to Wicket that will bore you with tons of theory.
> You are expected to have built or maintained a simple Wicket
> application in the past and to be looking to learn new and better ways
> of using Wicket. If you are ready to take your Wicket skills to the
> next level this book is for you.
>
> Cheers, and I hope you enjoy the book!
> -Igor
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.a

Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

[Eelco Hillenius]

> I have a c++ background and this kind of problem is even more dangerous in
> c++ (virtual calls don't work as normal in constructors). In Java also, I
> think making "this" known to the outside world before it is fully
> constructed is unsafe, as illustrated above.

It's a potential problem we've been aware of and consciously allowed
to exist in Wicket for a long time after our failed attempt to address
it on Wicket 2.0 (years ago). In the end I don't think it is a
concrete very often, and the difficulties that get introduced trying
to fix it are simply not worth it in our case.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Eelco Hillenius]

> Reading in the other thread that a session size of 100K or less
> is achievable, I'll admit defeat now: I have not been able to shrink some of
> my pages(!) to less than 200K, not to mention the sessions. Despite LDMs,
> CompoundPropertyModels, and no, there are no domain objects in there, and no
> finals.

How are you measuring this? Keep in mind that if you calculate when a
request is still processing, you might still be measuring temporary
data (e.g. for LoadableDetachableModel, you would also measure the
transientModelObject, and same for any proxies (Spring/ Guice) you
might use.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Is wicket suited for my needs?

[Eelco Hillenius]

> My aim would be to push requests towards statelessness as much as possible.
> Noticing this some guys have told me that "maybe wicket is not for this".
> Considering that atleast 20% of the requests will be session based, do you
> suggest using wicket.

You should also consider why you want to use Wicket in the first
place. If your UI requirements aren't all that complicated, and you
work with a very small team (say 2 people), Wicket may not buy you
much compared to - say - just using JSPs, JAXRS and jQuery. If on the
other hand, your development team is larger (say 3 or 4+ people), and/
or you have to maintain a complex UI, where you probably want to reuse
widgets, move them around at will etc, you can benefit considerably
from using a component based framework like Wicket.

I would agree with others here that 10K concurrent users shouldn't be
a problem; small cluster or maybe even a single machine should cut it,
though compared to not using a stateful framework, you'll have to deal
with session replication or sticky sessions in a cluster, and probably
(depending on well you implemented things of course!) less beefy
hardware requirements.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Oracle & Wicket Starter Application Project

[Eelco Hillenius]

> - using individual database users to represent real users - giving end-to-end 
> authentication & allowing the use of features such as SQL Trace & fine 
> grained auditing

Does that mean that the number of open connections always equals the
number of signed in users?

> - using database roles to restrict access to data, and not relying wholly on 
> application enforced security

So if you want to determine whether user X can see button Y, you have
to query the database for particular role membership?

Cheers,

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Detach() explanation

[Eelco Hillenius]

This also applies to models, which you should use if you can over
doing this directly in components. Also, besides serialization, the
default configuration in Wicket keeps the current page in memory
between requests. If you properly 'detach' (deflate might have been a
good alternative word), you drastically cut down on the memory you use
per session.

Eelco

On Wed, Dec 15, 2010 at 12:33 AM, Martin Grigorov  wrote:
> hi,
>
> each page with all its components is being serialized and stored somewhere
> (session, disk) at the end of a request.
> This is needed to be able to support stateful pages and to be able to return
> to previous page or version of a page with the browser back button.
>
> Each component and model has detach() method in which it can null-ify any
> member variable that is not needed to be stored, i.e. the value of this
> variable is either not important or can be restored by other means.
>
> On Sat, Dec 11, 2010 at 7:26 PM, kumar  wrote:
>
>>
>> Hi everyone,
>>
>> can I get an example how to implement the detach() method ? can someone
>> please post a detailed example ?
>> why and in which cases implementing detach() is important ?
>>
>> thanks.
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/Detach-explanation-tp3083568p3083568.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Interesting Report from JRebel...

[Eelco Hillenius]

More shocking to me is that so little bit know about Guice (well, this
actually is also my experience interviewing potential job candidates).
People are really missing something good.

Eelco

On Tue, Dec 14, 2010 at 6:33 AM, James Carman
 wrote:
> We were listed behind JSF, GWT, Struts 1, Seam, and Struts 2.  But, we
> beat out Grails, Stripes, and Tapestry.
>
> http://www.zeroturnaround.com/java-ee-productivity-report-2011/
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket-Hibernate Related LazyInitializationException

[Eelco Hillenius]

Yep, or least something comparable. You need to re-attach those
objects you're using to the session somehow, and often the easiest way
to do that is to just load them again if they were previously
detached. If you worry about the database being hit more than you
want, you are probably prematurely optimizing, and if you still worry,
you should fix this by through Hibernate's (or your own) second level
cache, not by keeping your model objects inflated between requests.

As a general rule, something we often repeat on this list, if you work
with Hibernate managed objects in Wicket models, use detachable models
(LDM is a common one) and make sure that these objects are 'deflated'
between requests, meaning that e.g. you only keep references to their
ids, or e.g. the algorithm to get the objects back again when needed.

Eelco


On Wed, Dec 1, 2010 at 10:13 PM, James Carman
 wrote:
> Just make sure your form's model is a LDM too.
>
> On Thu, Dec 2, 2010 at 12:23 AM, Nivedan Nadaraj  
> wrote:
>> Hi All
>>
>> I am guessing this is more of a Hibernate thing/issue but if some one has
>> encountered this and has a explanation that I can probably use from the
>> Wicket front would be great.
>>
>> https://forum.hibernate.org/viewtopic.php?f=1&t=1008473
>>
>>
>> I have a LazyIntializationException when i page through some items. I use
>> the PageableListView, the List item(s) are entities that are retrieved via
>> an association Person.phones which is  a Set type.
>> The funny thing is, the LIException is intermittent. I am also using
>> OpenSessionInViewFilter. Any thoughts?
>>
>> By the way the this is the load() implemenation, I have set the Model
>> Object's phoneList with a list of values fetched via the Service->DAO. I
>> have used this with other entities without association and it works  but I
>> guess is a different scenario(not associations)
>>
>> Model = new LoadableDetachableModel() {
>>   �...@override
>>            protected Object load() {
>>                return containerForm.getModelObject().getPhoneList();
>>            }
>>        };
>> }
>>
>> If someone has any thoughts would appreiciate hearing from you.
>>
>>
>> Cheers
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: ERROR: exceded the 65,535 byte limit Please Help me!

[Eelco Hillenius]

Your source file is too big, good job ;-) For the rest, see the other
replies. Get your basics down first, or you're going to look at a very
painful few months. Maybe hire a consultant to get you up to speed and
help you with the core architecture?

Cheers,

Eelco

On Sun, Nov 14, 2010 at 6:12 AM, Paolo  wrote:
> I use Eclipse Europe and Wicket 1.4.10
> I am newbie. I am try to make a ecommerce web site.
> I follow the example Cheese Shop in "Wicket in Action" manual.
> I put the products database in memory in a ArrayList in MainApplication.
> I works all ok, until the database was small. Now it include about 1000 
> products,
> so I had this error: ...exceded the 65,535 byte limit
>
> I found in google search some solution as to put the database in an external 
> text file with fields divided with semicolon ;
> like .csv files
> and read it from java class.
> One line for every product, and 32 fields of Strings, like I declared in 
> Class C:
> 
> public class C implements Serializable {
> private String cat1;
> private String art;
> private String cat2;
> private String cat3;
> 
> public C(String cat1, String art, String cat2, String cat3, String cat4, 
> String cat5, String cat6, String cat7, String cat8, String cat9, String 
> cat10, String descr_it, String descr_en, String nota_it, String nota_en, 
> String Ricerca, String nfoto, String multi, String disp, String codprezzi, 
> String prezzopub, String prezzoriv, String prezzoacq, String peso, String 
> fornitore, String noteotty, String agg1, String agg2, String agg3, String 
> agg4, String agg5, String quantita) {
>  super();
>  this.cat1 = cat1;
>  this.art  = art;
>  this.cat2 = cat2;
>  .
>
>
> So to implement it to my wicket MainApplication before to read from external 
> file, I am starting to convert source from this:
>
> public class MainApplication extends WebApplication {
> private List cheeses = Arrays.asList(
>                new 
> C("BBTAA","001","","","","","","","","","","Portafotografia 
> argento","","","","","","","","","19.00","","","1000","ard","verif","","","","","","0"),
>                new C("BBTAA","002","","","","","","","","","","Serie 
> sacchetti in 
> azzurro","","","","","","","","","15.00","","","1000","ard","verif","","","","","",0),
>                new C("BBTAA","003","","","","","","","","","","Serie 
> sacchetti in 
> rosa","","","","","","","","","10.00","","","1000","ard","verif","","","","","",0),
>        new C(.
>
> To this:
>
> public class MainApplication extends WebApplication {
> private List cheeses = new ArrayList();
>          cheeses.add (new 
> C("BBTAA","001","","","","","","","","","","Portafotografia 
> argento","","","","","","","","","19.00","","","1000","ard","verif","","","","","","0"));
>
> The last line (cheeses.add(...), give me this errors:
> Multiple markers at this line
>        - Syntax error on token "add", = expected after this token
>        - Syntax error on token(s), misplaced construct(s)
>
> Please Help me!
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Free wicket from component hierarchy hell

[Eelco Hillenius]

> But all really depends on your approach. Some people think dabbling in
> a swamp gives you a firm grip. I cosinder it the opposite: swamp has a
> firm grip on you.

I consider it asking for trouble. Wicket would sacrifice
predictability and conceptual surface for the sake of making a few
things slightly less annoying. :-)

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Free wicket from component hierarchy hell

[Eelco Hillenius]

>> I think it is a bad idea to enable something that makes developing a
>> little bit quicker/ easier but that makes problems potentially much
>> harder to debug.
>
> I don't see any difference in getting "hierarchy not matched"
> exception from either way. Ofcourse the main difference is that you
> would get much less such exceptions in the proposed scheme.

That's a fair point. So I guess that introducing a short cut like this
could be OK as long as the error diagnosis is very clear.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Free wicket from component hierarchy hell

[Eelco Hillenius]

> I don't think it is.  Keeping the two hierarchies in sync is not really that
> difficult.  The funny thing about the proposed approach is that it is in an
> effort to make things "simpler".  But, as you pointed out, the more complex
> things won't work with the proposed approach (without probably some huge
> amount of hacks).  So, the complex stays complex, and is then inconsistent
> with how all the other stuff works.

I agree. It's a bad idea. We should learn from other frameworks and
our own past mistakes that consistency is everything. There's no doubt
in my mind that this short cut would backfire at some point (and
probably sooner than later). Instead, the focus should be on improving
error diagnostics etc.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Free wicket from component hierarchy hell

[Eelco Hillenius]

> Web pages are 80% trivial. Small friction like doing unnecessary
> hierarcy matching is waste of time. 5 min per hour, 40 minutes per
> day, 800 minutes per month, 20 people team 16000 wasted minutes per
> month is 33 days per month wasted only because of wicket hierarchies.

As time and time again research shows is that the real cost is not in
the initial development, but in maintaining (which of course starts
often while you're still doing the initial development, as it also
includes refactoring on initial ideas etc).

I think it is a bad idea to enable something that makes developing a
little bit quicker/ easier but that makes problems potentially much
harder to debug. As a comparison, my main pet-peeve with Hibernate for
instance isn't that it doesn't save me enough lines of code, but that
debugging problems with it can be bloody hard. And in fact, this can
already be the case for Wicket as well, even as much around the
framework is centered around avoiding that.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Problem with two users logging in two tabs of same browser window

[Eelco Hillenius]

> Your browser doesn't identify a new tab as a new session. Therefore
> the servlet container doesn't know that it is a new user. If it is a
> valid usecase, you should build multi user session sharing in your
> app. If it is a bug, you should properly log out the first user when
> the new user is identified in the second tab.

Indeed. Pagemaps is the scoping mechanism within Wicket that maps to
tabs (and pages) within the same session, so while it would probably
be a bit clunky to code against initially (until you set up a bit of
abstraction around it), it should be useable to solve your problem.

FWIW, we've talked in the past about making pagemaps more explicitly
about supporting tabs and windows, but never got around taking that to
the next level, also because we didn't all agree on how much we should
focus on this in the first place.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Multi-tenancy with style

[Eelco Hillenius]

On Thu, Nov 4, 2010 at 8:57 AM, Igor Vaynberg  wrote:
> On Thu, Nov 4, 2010 at 8:27 AM, cretzel  wrote:
>>
>> We're building a multi-tenant capable application. The basic idea is to
>> identify the tenant for a request and put the tenant information into a
>> ThreadLocal.
>>
>> One requirement is to enable 'localization' per tenant, i.e. to allow
>> tenant-specific labels, like for example one tenant wants to display the
>> term 'client' instead of 'customer'. The first thing that comes to my mind
>> is using tenant-specific styles, i.e. to read the properties from files like
>> labels_tenant1.properties and labels_tenant2.properties.
>
> that is what style and variation are for.
>
>>
>> Any arguments against that? Is there any other multi-tenancy support in
>> Wicket?
>
> see above.

Yes. Though, using that limits you to having to have all the flavors
in your builds. Alternatively (more work, but more flexible), you can
pretty much do anything in Wicket dynamically, so you could e.g. load
a different style sheet or even panels based on the particular user.
If you have limited flavors, style and variation are the most elegant.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Welcome Martin Grigorov as a core team member

[Eelco Hillenius]

Welcome Martin, and thanks a bunch for keeping the project alive and kicking!

Eelco

On Mon, Jul 19, 2010 at 2:51 PM, nino martinez wael
 wrote:
> Grats Martin :)
>
> 2010/7/19 Jeremy Thomerson 
>
>> The Wicket team is happy to announce that Martin Grigorov was invited to
>> join the Wicket team as a committer and PMC member, and he accepted!
>>  Martin's relentless patience, high quality patches and sustained
>> energy haven't gone unnoticed.  He has continually provided valuable
>> insights and put a lot of effort into the project.  He helps out many on
>> the
>> mailing lists and IRC channel.
>>
>> In Martin's first two days with access, he's already made 16 commits and
>> closed several JIRA issues.  We look forward to his continued
>> contributions.
>>
>> Please join me in welcoming Martin to the team!
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Looking for a Software Engineer in San Francisco

[Eelco Hillenius]

Hi folks!

At Teachscape, we're looking for a good Java Software Engineer,
preferably with Wicket experience, in San Francisco. See:
http://sfbay.craigslist.org/sfc/sof/1794123343.html

Please shoot me an email if you're interested in this position.

Cheers,

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Very interesting question... my boss complain about one of my implementations...

[Eelco Hillenius]

>>> I had a terrible day because one of my bosses complain about how I have
>>> done
>>> one task of a project, we had to implement "something" that updates a field
>>> in the database, my brilliant idea was to create a thread inside the wicket
>>> init method that makes a query to the database every 3 hours and updates
>>> the
>>> fields.

I don't think it is horrible, though it sounds a bit like a quick fix.
It doesn't have to do with your web application of course, though
Wicket's application object is a natural place to do bootstrapping.

>> Struts timers (at least the ones I know of) are for timing how long a
>> webpage takes to render.  Perhaps he's confused with TimerTasks, which are
>> in Java, not Struts.

I think that in general using TimerTask is better than just spawning
of a thread.

> If you are using some logic to update the database "every N time",
> then I suggest using Quartz:
>  https://quartz.dev.java.net/
>  http://www.quartz-scheduler.org/overview/index.html

And using Quartz is even better.

> The only tricky part of Quartz has been deploying it properly on an
> application cluster -- to avoid having the same scheduled tasks run
> simultaneously.  If you have a "backend" app server you can purpose
> running scheduled tasks on, then it is simple.

Quartz does the job, and for my work I created a nice Guice
abstraction for it, but I've never been crazy about the API and
implementation (though it's stable and reasonably efficient). I wonder
if anyone has any real life experience with
http://sna-projects.com/azkaban they want to share?

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket "vendor lockin" and backwards compatibility, 1.4/1.5

[Eelco Hillenius]

> The main alternative we're comparing wicket to is using JSF. The "vendor
> lockin" problem is less of a risk there. If we implement our app with
> JSF2.0, we're pretty much guaranteed support and bug fixes for that for 10
> years by the commercial app server vendors. If we decide to use
> standards-based solution there's no risk of, for example, wicket suddenly
> going "out of fashion" and support and activity dying.

Like others point out, you'll always have the source code to fix
issues yourself (or hire someone to do it for you), and typically by
the time a version is EOL-ed, there may be a few annoyances left, but
typically not any real problems. FWIW, we are still on Wicket 1.3.x,
and it works fine.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Scalability

[Eelco Hillenius]

2010/4/11 François Meillet :
> Hi Wicketers,
>
> 1) I need to build a system which can perform
> -6000 different users per day
> and
> -200 concurent users

I can very easily run that on my laptop.

>
> The software used:
>
> wicket
> postgresql (mainly read operations)
> hibernate
> jms
>
> At the beginning there will be 2 computers  (I prefer horizontal scalability).
> What would be your advice for the hardware (hard drive will be 10.000 RPM).
> -processor ?
> -ram

For 200 concurrent sessions, 100 MB is probably already enough (20MB
would be for sessions if you average 100K per session). But give your
VM 1GB or more and you should be able to handle a much larger peak
(600?) easily

> 2) Also I would appreciate your advice for the server:
> I have the choice for the server: Tomcat + a JMS implementation like HornetQ, 
> or Jboss Application Server.
> I hesitate between the 2 solutions, as I don't need EJBs, but we never know 
> !!! .

If you don't need EJBs (and who would, I've always steered clear from
them and never regretted it), than don't worry about it. In the
unlikely case you ever do, just address it then by swapping out your
app server. Write your software generically enough so that you don't
depend on a single one.

If you know you need MQ and you want management of it integrated in
your application server, JBoss is worth considering. Also look at
Glassfish while you're at it.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: JavaOne in San Francisco

[Eelco Hillenius]

> And i to the N900..
> I want freedom, dont want to be controlled by fruit

That's because you're enough of a fruity yourself. For most people
though, an Apple a day is very healthy.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: JavaOne in San Francisco

[Eelco Hillenius]

I might be around even if not attending. Let's ping this list when the
event is nearing to see if we have enough people to meet up at a bar
or something :-)

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Memory usage

[Eelco Hillenius]

> What should be the maximum memory usage for this? At the moment it takes
> 422megabytes and this is definately too much for application without any
> load and traffic.

If there is no load and traffic, it isn't Wicket occupying your memory.

Try using something like YourKit (http://www.yourkit.com/) and see
what takes up all that memory. Another quick test you can do is see
how much it is when you start up. If it is much lower but grows over
time, you can try triggering a GC run (e.g. through JMX) and see if it
drops down to roughly the startup level. If it is, nothing to worry
about. If it doesn't, you either have a leak, or you're doing some
crazy caching or something.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Example of configuring JCaptcha within Wicket?

[Eelco Hillenius]

It's been a while, so I don't know how well it works with recent
versions (and whether I would do things differently today), but
there's a few pages on this in Wicket In Action. You can find example
source code here:
http://code.google.com/p/wicketinaction/source/browse/trunk/book-wicket-in-action/src/java/wicket/in/action/chapter09/jcaptcha/?r=110

Eelco

On Sun, Mar 7, 2010 at 11:53 AM, David Chang  wrote:
> Anybody used the JCaptcha tool? How did you do the customization? The 
> out-of-box config sucks.
>
> Could you please share your config and how to?
>
> Cheers!
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Client side events in Wicket, what do you think about that?

[Eelco Hillenius]

Hi,

> sounds like you want to rewrite gwt but using wicket model for
> handling markup instead of layout manages which is what gwt uses. it
> is probably much easier to write a library for gwt that implements the
> wicket markup model rather then the other way around...

Like this http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html?

>> script within the generated HTML. That does not suits. And BTW gwt compiler
>> is slow as hell (minutes!!!),

We have compile times from 10 minutes up to over an hour. No kidding.

>> how people are happy developing GWT applications?

Definitively spoils the fun. Especially because in our experience,
though GWT has the promise of write once for all browsers, you still
need to do quite a bit of testing and tweaking to make sure everything
looks good in different browsers. Also not very helpful is the fact
that the Google Eclipse plugin uses the jars copied to a war/libs
directory rather than the class path you define for your project,
which cost us a lot of time because we have our projects broken up in
smaller pieces (dependent projects), and every little change we have
in one of the dependent libs means having to create a build for them,
and then copying them to the war/libs dir. Hopefully this will be
fixed some day. And then there is that if you don't optimize, you
easily end up with over a MB initial download (just a medium sized
application). Oh, and I never would've guessed how much we depend on
introspection to take the plumbing code out until you have to do
without as in GWT.

Anyway, it's not all bad. The improvements for 2.0, including
UiBinder, look good, and the code we're ending up with is, though more
bloated than with Wicket, quite neat (good separation of concerns,
testable, componentized, etc). I feel we took a substantial hit in
developer productivity using GWT for our new projects rather than
Wicket, and I would probably pick Wicket again for my own projects,
but compared to the alternatives out there, GWT is still a pretty good
framework, where the larger the scale (development wise) of your
project, the larger the pay off is.

>> The next generation of HTML/JS would evolve towards client programming
>> capabilities. I like Wicket for its full freedom of HTML (contrary to GWT)
>> and I would like to use similar model when programming rich web client
>> applications. And it is less about the Wicket way of splitting html and
>> java. It is more about binding to dynamically loadable data with any deep of
>> structure displayed on users demand. The GWT way would require to program it
>> in any way when Wicket does it transparently.

Yeah, another thing I miss is lazy-ness... but that'd be hard to
reproduce when you would move from a request/ response model to JS
driven.

>> Another story is authorization
>> that can be done transparently. But web development evolves and client side
>> programming becomes more and more demanded. I tried to think about how
>> technically we could use the best of both worlds.
>>
>> What do you think about all that?

Sounds to me like enough ideas to base a new framework on ;-)
Personally I think that Wicket should keep focussed on the programming
model we have now. Drastically changing that just means building
another framework, and we can learn from other frameworks that that's
just not a very good idea. Also, I wouldn't really have an idea how to
implement this without basically copying GWT, which is probably hard
to beat at it's own game.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Questions about how wicket serialization works

[Eelco Hillenius]

> Wicket stores
> 1. the page,
> 2. component hierarchy,
> 3. and associated models (the state) in the page store."
>
> By "only the serialized form of the page hierarchy is stored.", you mean the 
> first two things?

The page == component hierarchy and associated models are part of it
because they are referenced by the components.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Offline capable web application

[Eelco Hillenius]

Who is talking about wrapping GWT components? What I'm saying is that
the kind of functionality you would use to create partially offline
applications, like HTML 5's web storage, you can wrap in a Wicket
component.

What's so strange about that? We do that all the time with JavaScript
widgets. So that you can package any resources with the component, can
discover it as a Wicket component in your class path and build a
little Java API around it, etc.

On Fri, Feb 19, 2010 at 11:05 PM, Igor Vaynberg  wrote:
> i just dont see the point of wrapping a page made up of gwt components
> in wicket wrappers. the *entire* front end has to live on the frontend
> in order for the application to work offline...so whats the point?
> anyways my two cents.
>
> cheers,
> -igor
>
> On Fri, Feb 19, 2010 at 9:43 PM, Eelco Hillenius
>  wrote:
>> On Fri, Feb 19, 2010 at 9:30 PM, Igor Vaynberg  
>> wrote:
>>> having data only on the client will not help you unless you also have
>>> behavior. these kinds of apps are really only feasible when you use a
>>> clientside framework like gwt.
>>
>> Any components you write wouldn't use the typical client/ server
>> interaction that regular Wicket components do, but I don't see why you
>> wouldn't be able to write a wrapper around this functionality so that
>> at least you'd be able to use such functionality within a Wicket
>> application.
>>
>> FWIW, I'm currently coding in GWT, something I really looked forward
>> to, because like most coders I like change, but man, I miss Wicket's
>> productivity. It's not a bad framework, but imho it's hard to beat
>> Wicket when it comes to churning out and integrating components.
>>
>> Eelco
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Offline capable web application

[Eelco Hillenius]

On Fri, Feb 19, 2010 at 9:30 PM, Igor Vaynberg  wrote:
> having data only on the client will not help you unless you also have
> behavior. these kinds of apps are really only feasible when you use a
> clientside framework like gwt.

Any components you write wouldn't use the typical client/ server
interaction that regular Wicket components do, but I don't see why you
wouldn't be able to write a wrapper around this functionality so that
at least you'd be able to use such functionality within a Wicket
application.

FWIW, I'm currently coding in GWT, something I really looked forward
to, because like most coders I like change, but man, I miss Wicket's
productivity. It's not a bad framework, but imho it's hard to beat
Wicket when it comes to churning out and integrating components.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: (Form) Use two TextFields for one object property? (SOLVED)

[Eelco Hillenius]

> A thousand thanks. Works like a charm.
> Though I don't fully understand how the values are
> passed through the components/models.

It's three components, one parent (that holds the ultimate value) and
two children (that both hold values used to calculate the parent
value.

> convertinput() {
>int mins=minutes.getconvertedinput();
>int secs=seconds.getconvertedinput();
>setconvertedinput(mins*60+secs);
> }

updates the parent (setConvertedInput) with one value that comes from
the minutes and seconds fields.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Offline capable web application

[Eelco Hillenius]

> I am working on an application that i want to enable to work offline. I want
> to use wicket for this. Any ideas. I would like uses to fill and submit
> forms even when working offline and then the data is synchronised later. Is
> it possible? all manner of suggestions/links are welcome.

Isn't that all a matter of making clients smart? If you'd do it
without a web framework you'd use a local (client side) data store,
and have a mechanism to synchronize data later. Whatever you would
write can be wrapped as Wicket components. It might even be feasible -
though I'm not saying easy per se- to create generic components for
this, but I'm not that familiar with the new HTML (or now deprecated
Google Gear) functionality to say for sure. Just a hunch that a
capable coder should be able to do it :-)

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [OT] Wicket changed my life !

[Eelco Hillenius]

Thanks for the kind words people. Definitively a key part of Wicket's
success has been an enthusiastic community.

> The learning curve was slightly steep once we started doing interesting UI
> interactions (and also that really annoying LazyLoad exception during tests
> that I still can't figure out), but it's worth the effort.

Detachable models are your friend.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: best way to detect session termination

[Eelco Hillenius]

You could use a HttpSessionBindingListener like Wicket does internally
(see AbstractHttpSessionStore). Or as a hack store references to the
session objects in the session listener. That's the easy fix, but
doesn't scale if you need session replication (unless maybe you use
e.g. Terracotta).

Eelco

On Sun, Feb 14, 2010 at 4:36 AM, Andreas Lüdtke  wrote:
> Hi Eelco,
>
> thanks for the hint. Now I can detect the end of a session. Unfortunately I
> can't access my own wicket session in that sessionDestroyed() method in order
> to get the info about the connected user. I've got ther error message
> "java.lang.IllegalStateException: you can only locate or create sessions in
> the context of a request cycle".
>
> Do you know how I can achieve this?
>
> Andreas
>
>> -Original Message-
>> From: Eelco Hillenius [mailto:eelco.hillen...@gmail.com]
>> Sent: Saturday, February 13, 2010 7:02 PM
>> To: users@wicket.apache.org; sam.lued...@t-online.de
>> Subject: Re: best way to detect session termination
>>
>> http://www.xyzws.com/Servletfaq/when-do-i-use-httpsessionlistener/7
>>
>> Eelco
>>
>> On Sat, Feb 13, 2010 at 8:38 AM, Andreas Lüdtke
>>  wrote:
>> > I would like to detect the termination of the session to set the
>> > "lastAccesTime" in the user profile. This should also
>> happen if the session
>> > times out.
>> >
>> > I read in archive about a HttpSessionListener that should
>> do the trick.
>> > Unfortunately I can't find a place to install it.
>> >
>> > Thanks
>> >
>> > Andreas
>> >
>> >
>> >
>> -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>> >
>>
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: best way to detect session termination

[Eelco Hillenius]

http://www.xyzws.com/Servletfaq/when-do-i-use-httpsessionlistener/7

Eelco

On Sat, Feb 13, 2010 at 8:38 AM, Andreas Lüdtke  wrote:
> I would like to detect the termination of the session to set the
> "lastAccesTime" in the user profile. This should also happen if the session
> times out.
>
> I read in archive about a HttpSessionListener that should do the trick.
> Unfortunately I can't find a place to install it.
>
> Thanks
>
> Andreas
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: wicket osgi (not Pax)

[Eelco Hillenius]

> In any case, this is getting REALLY off topic... ;-)

On the contrary; this is really helpful for OSGi n00bs like me. Thanks
for replying everyone.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Dynamically Generated Wicket UI

[Eelco Hillenius]

>The problem i have is
> adding components to the Window/tab because there is not existing markup.

Use panels as place holders. They can contain anything you like at
runtime including nothing at all. Rinse and repeat.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: wicket osgi (not Pax)

[Eelco Hillenius]

>> Is there a How-to for OSGI and wicket, not from pax
>> I managed to install jetty servlet api in equinox...now I have to install
>> wicket somehow
>
> Good luck!
>
> Due to serialization issues, it's not an easy problem to solve.
>
> I don't know of any "how-to". All I can say is that you have a long road 
> ahead of you.

Really? That's disappointing. I thought introducing IClassResolver way
back when and asking OSGi people to work with that did the trick? How
come it doesn't?

Cheers,

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Tag Oriented Development

[Eelco Hillenius]

On Tue, Dec 22, 2009 at 7:59 PM, Altuğ B. Altıntaş  wrote:
> In business, decision makers choose standards

Maybe obig conservative corporations. On the other hand, there are
plenty of examples of companies that were able to have an edge over
competition by choosing languages and frameworks that deliver. From
massive, like Google, Yahoo and Amazon to medium players like Redfin
and Teachscape to the gazillion smaller companies who rather put their
effort in stuff that will get them to the next round.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Tag Oriented Development

[Eelco Hillenius]

> I love Wicket and the natural approach it offers to do web-development...
> and I have been pushing hard to use it whenever possible...  but on the
> "real world" it is not enough to be an excellent product to gain
> wide acceptance...  Does last sentence ring a bell?

I think we've gained pretty wide acceptance actually. Wicket In Action
has been a best seller for Manning in the months right after it came
out, and Wicket is by many considered as one of the leading web
frameworks for Java. We've also had one of the most active email lists
for years now. I'm sure Wicket lags behind JSF and Struts considerably
when it comes to number of users, but hey, why would we care. You only
need a bunch of serious users to maintain a framework, and Wicket has
many thousands of them :-)

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Spring/Wicket/Hibernate testing driving me banana nuts

[Eelco Hillenius]

So in typical web applications, people would install a session filter
(like https://www.hibernate.org/43.html), which would open a session
at the start of a request, and close it afterwards. You probably need
to find an alternative for that filter in your test code.

Eelco

On Tue, Nov 17, 2009 at 4:26 PM, Loritsch, Berin C.
 wrote:
> Hmm, OK attachments are stripped here.  Having gone back up through the stack 
> trace, WicketTester extends BaseWicketTester which then extends 
> MockWebApplication.  Essentially MockWebApplication has the base 
> implementations for setting up the WebRequestCycle.
>
> The @SpringBean is having an effect, because my exception is a 
> HibernateException and not a NullPointerException.  I think it has something 
> to do with how the      /> interacts with the WicketTester that is unclear to me.  The thing that has 
> changed is that while I had that declaration, I introduced using the 
> @Transactional attributes on some of my Hibernate objects.  Spring is giving 
> me a proxied class that is supposed to take care of the hibernate sessions 
> and transactions for me.  It's having a hard time in the JUnit environment.  
> I'm using the following TransactionManager:
>
>            class="org.springframework.orm.hibernate3.HibernateTransactionManager">
>        
>    
>
>
> -Original Message-
> From: Loritsch, Berin C. [mailto:berin.lorit...@gd-ais.com]
> Sent: Tuesday, November 17, 2009 4:15 PM
> To: users@wicket.apache.org
> Subject: RE: Spring/Wicket/Hibernate testing driving me banana nuts
>
> I've got the part that injects a Spring WebApplicationContext into the 
> WicketTester already (Source attached).  I should be using the application 
> class, if I'm not then something has changed unbeknownst to me.  Is there any 
> place it would swap out what I told it to use for what it decided on its own 
> to use?
>
> -Original Message-
> From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
> Sent: Tuesday, November 17, 2009 4:05 PM
> To: users@wicket.apache.org
> Subject: Re: Spring/Wicket/Hibernate testing driving me banana nuts
>
> i see you are using MockWebApplication in your tests. this application does 
> not install the SpringComponentInjector and so @SpringBean has no effect.
>
> you should either give wickettester an instance of your actual application 
> class, or create a mock one that installs springcomponentinjector.
>
> -igor
>
> On Tue, Nov 17, 2009 at 1:00 PM, Loritsch, Berin C.
>  wrote:
>>  <> I initially had a setup that worked with both a
>> Web context and a JUnit context.  The problem was the amount of hand
>> coding and adjusting of the Spring context the approach needed.  I
>> finally got the Spring's transaction interceptor working with the
>> auto-wiring (the key is using an interface).  So now my problem is
>> that while I've saved myself the headache of making changes to a bunch
>> of files every time I add a new service, my unit tests are now failing.
>>
>> I've traced the failure to a specific class that is decorated with the
>> InjectorHolder--although I believe that is merely because it is the
>> first component that does any Hibernate requests.  I'll include the
>> stacktrace at the bottom of the message.
>>
>> I had to remove the line that specified that sessions would be thread
>> bound in Hibernate to take advantage of the Spring managed
>> transactions, and adding that configuration item back in makes no
>> difference for the tests.  I'm hoping I'm just missing something
>> simple, but all my Googling is turning up dead ends.  Any help out there?
>>
>>
>>
>>
>>
>>
>>
>>
>> org.apache.wicket.WicketRuntimeException: Error attaching this
>> container for rendering: [MarkupContainer [Component id = content]]
>>        at
>> org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContain
>> er
>> .java:1739)
>>        at
>> org.apache.wicket.Component.onBeforeRender(Component.java:3854)
>>        at
>> org.apache.wicket.Component.internalBeforeRender(Component.java:1061)
>>        at
>> org.apache.wicket.Component.beforeRender(Component.java:1095)
>>        at
>> org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContain
>> er
>> .java:1727)
>>        at
>> org.apache.wicket.Component.onBeforeRender(Component.java:3854)
>>        at org.apache.wicket.Page.onBeforeRender(Page.java:1501)
>>        at
>> com.gdais.incidents.view.SiteTemplate.onBeforeRender(SiteTemplate.java
>> :3
>> 3)
>>        at
>> org.apache.wicket.Component.internalBeforeRender(Component.java:1061)
>>        at
>> org.apache.wicket.Component.beforeRender(Component.java:1095)
>>        at
>> org.apache.wicket.Component.prepareForRender(Component.java:2223)
>>        at
>> org.apache.wicket.Component.prepareForRender(Component.java:2260)
>>        at org.apache.wicket.Page.renderPage(Page.java:893)
>>        at
>> org.apache.wicket.request.target.component.BookmarkablePageRequestTarg
>> et
>> .respond(BookmarkablePageRequestTarget.java:262)
>>    

Re: migrating to 1.5

[Eelco Hillenius]

> Do you guys have any early indication of what the migration impact
> will be like?

I don't know if it is up-to-date, but:
http://cwiki.apache.org/WICKET/migration-to-wicket-15.html

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Any issues using @SpringBean in WebApplication

[Eelco Hillenius]

> Hi Eelco -- My colleague and I were thinking that putting them all in the
> WebApplication
> would make it easier to mock services for unit testing with WicketTester.

Alternatively, you could use e.g. InjectorHolder.setInjector(new
MockSpringInjector()); like is documented in
org.apache.wicket.injection.web.InjectorHolder (at least it is in
Wicket 1.3 which I am using). That's a bit more flexible and you don't
have to worry about cases where someone (colleague?) uses @SpringBean
directly and thus compromises your test strategy).

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Any issues using @SpringBean in WebApplication

[Eelco Hillenius]

> Is there an impact on performance if Spring beans are injected in a
> WebApplication and then shared for use in WebSession and WebPages (as
> opposed to injecting directly in WebSession and WebPages)?

Sharing them (just don't keep references in your components) should be
slightly more efficient. Not the kind of gain you should base your
decisions on imho though.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Replacing a panel with another panel

[Eelco Hillenius]

> I am trying to replace a panel with another panel.  The replacement
> works the first time.  The next time I click on the replacement link, I
> get an exception.
>
> "java.lang.IllegalStateException: This method can only be called on a
> component that has already been added to its parent."

My guess is that you are referencing the the first panel again. When
you replace panel A with panel B, panel A loses it's reference to the
parent (which goes to B obviously), so if you were to replace on A
again, you get an exception like that. The solution is to reference B
rather than A.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Open Source projects using Wicket

[Eelco Hillenius]

push:

new Model(myObject), which will keep a reference to the object for the
entire life span of the component

pull:

new LoadableDetachableModel() {
  protected Object load() {
return someService.getItFromSomewhereElse();
  }
}

The difference is that with pull, you need to know the model object
when creating the model, and pass it to that model right then, while
with pull models you rather store the calculation to get a model
object. Examples of the latter are LoadableDetachableModel and
PropertyModel.

Eelco


On Fri, Oct 16, 2009 at 5:23 AM, Swanthe Lindgren
 wrote:
> I dont really get what you mean by pushing and pulling models. Could you
> please give me an example? Is creating a component without providing a
> model, relying in the parent page/panel/component's default model pushing
> data?
>
> //Swanthe
>
> Jeremy Thomerson wrote:
>>
>> Sorry, that was an overly terse statement.  Peter Thomas has put a lot of
>> work into JTrac, and has done a lot of things that I admire (for instance,
>> some of his performance testing blog entries, etc).  He is also very
>> helpful
>> on the mailing list.
>>
>> The reason I said not to look at it is that when I was using it, I found
>> that nearly all of the components were created without the use of models -
>> "pushing" data into the component rather than making it pull from a model.
>> While that works fine for a small bug tracker, it would not work well in
>> most enterprise applications - leading to performance and potentially
>> memory
>> issues.
>>
>> It's not that it's bad software - but I've taught enough training classes
>> to
>> see that one of the most common pitfalls to those new to Wicket is to
>> always
>> push data into the models.  This works fine in some instances, but is not
>> a
>> best practice and can lead to a lot of problems later if you don't know
>> what
>> you're doing.  That's why I said what I did.
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>> On Thu, Oct 15, 2009 at 7:29 PM, Dave B  wrote:
>>
>>
>>>
>>> Any particular reason?  Form a (very) cursory ten minute look, the
>>> lack of tests was glaring, though not an indictment of the actual
>>> Wicket usage.
>>>
>>> Thanks,
>>> Dave
>>>
>>> On Fri, Oct 16, 2009 at 11:04 AM, Jeremy Thomerson
>>>  wrote:
>>>

 Don't look at jtrac.

 --
 Jeremy Thomerson
 http://www.wickettraining.com



 On Thu, Oct 15, 2009 at 6:42 PM, Igor Vaynberg >>> wrote:


>
> keeping that in mind,
>
> i wouldnt look at brix, most wicket-related code there has to do with
> plumbing and implementing a development model that is unlike wicket
> but works better for cmses.
>
> maybe look at http://www.jtrac.info/ , i think that uses wicket...
>
> -igor
>
> On Thu, Oct 15, 2009 at 4:40 PM, Jeremy Thomerson
>  wrote:
>
>>
>> Beware - just like any other app, OS or not, you will find OS projects
>>
>
> out
>
>>
>> there that will teach you all kind of wrong ways to use Wicket.  I
>>
>>>
>>> know
>>>
>
> of a
>
>>
>> couple because I tried to use them, thinking they would be easier to
>>
>
> build
>
>>
>> on because they used Wicket.  But they were so poorly written that it
>>
>
> would
>
>>
>> be a bad place for someone new to the framework to start.
>>
>> http://code.google.com/p/brix-cms/ was written by some of the core
>> committers, so the Wicket code in it will be good.  Not sure how much
>>
>>>
>>> of
>>>
>
> the
>
>>
>> code is actually Wicket specific, though.
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>> On Thu, Oct 15, 2009 at 6:35 PM, Dave B  wrote:
>>
>>
>>>
>>> Hi,
>>>
>>> I'm in the process of evaluating Wicket (after an arduous JSF
>>>
>>>
>>> project,
>>>
>>>
>>> that has made us re-evaluate our web platform.)
>>>
>>> I've read Wicket in Action and whole bunch of blog and mailing list
>>> posts, done some proof-of-concept work and am now interested in
>>> reading source code from a project using Wicket, since I want to see
>>> Wicket in the wild. I know Artifactory uses Wicket, but their
>>> Subversion access instructions seem to be out of date.
>>>
>>> Does anyone know of an open source project using Wicket, so that I
>>>
>>>
>>> can
>>>
>>>
>>> peruse the source code?
>>>
>>> Many thanks,
>>> Dave
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apa

Re: Open Source projects using Wicket

[Eelco Hillenius]

> Pushing definitely is more performance efficient - you know exactly
> when and where you push it and it's easy (happy-day-scenario) to
> optimize. Partly the ease of optimization results from "difficulty of
> making complex relations".

I would expect push to put more load on your servers due to
serializing to second level cache, and getting a page back from that
cache might also be more expensive. Of course, it depends where you
pull from. And then when you're within one request, you probably have
that data you'd push already in memory (e.g. Hibernate's session cache
if you use that), so it might not be more expensive in that sense
either. I do agree that pull models can lead to more complex
structures, but that also depends on what kind of models you use (e.g.
reflection based models actually can save code, but obviously using
lots of anonymous classes won't). :-)

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Don't forget about ApacheCon US 2009!

[Eelco Hillenius]

> Will you be there?  Reply here if you're planning on going.  We should all
> get together to do something!

I'll be going, hope to see you there :-)

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: SerializableChecker$WicketNotSerializableException:

[Eelco Hillenius]

Btw, this whole serialization problem is exactly why we have
detachable models (though they obviously don't solve every problem out
there. Be sure to read up on those while you're at it.

Eelco

On Fri, Oct 9, 2009 at 3:12 PM, Eelco Hillenius
 wrote:
> I've looked at it briefly. The main thing you need to keep in mind is
> that it unfortunately is a limitation of Wicket that you can't have
> references in Components that aren't serializable (unless you don't
> care about back button support and turn of the second level session
> cache, OR you plug in your own serialization support that doesn't need
> classes to be serializable).
>
> In this case though, you don't really need those members, right? All
> the members are used in methods that are called during construction of
> the panel, so why not just pass them through those methods (or if you
> don't like that, make the members transient)?
>
> Eelco
>
> On Fri, Oct 9, 2009 at 2:16 PM, Ceki Gulcu  wrote:
>>
>>
>> Eelco Hillenius wrote:
>>>
>>> Hi,
>>>
>>> It looks like GenericBaseModel has a reference to a JUnit Description?
>>> Maybe you can paste your GenericBaseModel class here?
>>
>> Fortunately, my application is open source. You can find its source code at
>>
>>  http://github.com/ceki/mistletoe
>>
>> If you look at the DescriptionPanel class [1] you'll see that it essentially
>> presents a junit.Description and a junit.Failure instance both of which are
>> non-serializable.
>>
>> [1] http://tinyurl.com/yha75x8
>>
>>
>>> If that's something you'll have a runtime you shouldn't ignore it if
>>> you want to support history (the backbutton). If it's just during
>>> testing, you can ignore it if you like.
>>
>> My application is a testing platform so I can't ignore junit nor testing.
>> :-)
>>
>> The backbutton, doh! Thanks.
>>
>>> Eelco
>>
>> --
>> Ceki Gülcü
>> Logback: The reliable, generic, fast and flexible logging framework for
>> Java.
>> http://logback.qos.ch
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: SerializableChecker$WicketNotSerializableException:

[Eelco Hillenius]

I've looked at it briefly. The main thing you need to keep in mind is
that it unfortunately is a limitation of Wicket that you can't have
references in Components that aren't serializable (unless you don't
care about back button support and turn of the second level session
cache, OR you plug in your own serialization support that doesn't need
classes to be serializable).

In this case though, you don't really need those members, right? All
the members are used in methods that are called during construction of
the panel, so why not just pass them through those methods (or if you
don't like that, make the members transient)?

Eelco

On Fri, Oct 9, 2009 at 2:16 PM, Ceki Gulcu  wrote:
>
>
> Eelco Hillenius wrote:
>>
>> Hi,
>>
>> It looks like GenericBaseModel has a reference to a JUnit Description?
>> Maybe you can paste your GenericBaseModel class here?
>
> Fortunately, my application is open source. You can find its source code at
>
>  http://github.com/ceki/mistletoe
>
> If you look at the DescriptionPanel class [1] you'll see that it essentially
> presents a junit.Description and a junit.Failure instance both of which are
> non-serializable.
>
> [1] http://tinyurl.com/yha75x8
>
>
>> If that's something you'll have a runtime you shouldn't ignore it if
>> you want to support history (the backbutton). If it's just during
>> testing, you can ignore it if you like.
>
> My application is a testing platform so I can't ignore junit nor testing.
> :-)
>
> The backbutton, doh! Thanks.
>
>> Eelco
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: SerializableChecker$WicketNotSerializableException:

[Eelco Hillenius]

Hi,

It looks like GenericBaseModel has a reference to a JUnit Description?
Maybe you can paste your GenericBaseModel class here?

If that's something you'll have a runtime you shouldn't ignore it if
you want to support history (the backbutton). If it's just during
testing, you can ignore it if you like.

Eelco

>  ch.qos.mistletoe.wicket.Tree
>     [object=[Page class = ch.qos.mistletoe.wicket.Tree, id = 4 version = 0]]
> org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
> \
>  Unable to serialize class: org.junit.runner.Description
> Field hierarchy is:
>  4 [class=ch.qos.mistletoe.wicket.Tree, path=4]
>    private java.lang.Object org.apache.wicket.MarkupContainer.children
> [class=ch.qos.mistletoe.wicket.DescriptionPanel, path=4:node]
>      private java.lang.Object org.apache.wicket.MarkupContainer.children
> [class=[Ljava.lang.Object;]
>        java.lang.Object org.apache.wicket.Component.data[3]
> [class=ch.qos.mistletoe.wicket.DescriptionPanel$1, path=4:node:payload]
>          java.lang.Object org.apache.wicket.Component.data
> [class=org.apache.wicket.model.util.WildcardListModel]
>            private java.lang.Object
> org.apache.wicket.model.util.GenericBaseModel.object
> [class=java.util.ArrayList]
>              private java.lang.Object
> org.apache.wicket.model.util.GenericBaseModel.object[write:1]
> [class=org.junit.runner.Description] <- field that is not serializable
>        at
> org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:346)
> [wicket-1.4.2.jar:1.4.2]
>        at
> org.apache.wicket.util.io.SerializableChecker.access$500(SerializableChecker.java:63)
> [wicket-1.4.2.jar:1.4.2]
>        at
> org.apache.wicket.util.io.SerializableChecker$1InterceptingObjectOutputStream.replaceObject(SerializableChecker.java:494)
> [wicket-1.4.2.jar:1.4.2]
>        at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1116)
> [na:1.6.0_05]
>
> By the way, if you are wondering where the [wicket-1.4.2.jar:1.4.2]
> suffix comes from, it is automatically generated by logback, log4j's
> successor..
>
> Anyway, my application handles a complex tree-like structure, with
> almost all of the contents non-serializable and outside my control. I
> don't think I can use a Loadable Detachable Model, because loading the
> tree may take several minutes.
>
> Can I just ignore the serializable exception? If I don't what are the
> risks?
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: self-recursive panel

[Eelco Hillenius]

> http://wicketstuff.org/wicket13/nested/
>
> Ryan Gravener
> http://bit.ly/no_word_docs

Oh, right. Or http://wicketstuff.org/wicket14/nested/ (and notice the
fancy toolbar in the upper right corner).

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: self-recursive panel

[Eelco Hillenius]

> I was not aware of the "nested" example in wicket-examples.
>
> Unfortunately, http://www.wicket-library.com/wicket-examples/nested/ barfs
> when I try to access it.

Hmmm, don't know what's going on there. But you can check out the
source and look at it if you're interested. You won't learn much from
it, since it basically does what you do here :-)

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: self-recursive panel

[Eelco Hillenius]

Yeah, that's like Wicket's "nested" example in wicket-examples.

Eelco

On Thu, Oct 8, 2009 at 12:27 PM, Ceki Gulcu  wrote:
> Hello,
>
> I just succeeded to create a self-recursive panel displaying a
> tree-like structure with less than 40 lines of java code and 10 lines
> of HTML. I am including the code here in case someone is interested.
>
>
> ==
> public class Node implements Serializable {
>
>  String name;
>  List childrenList = new ArrayList();
>
>  Node(String name) {
>    this.name = name;
>  }
>
>  public void add(Node child) {
>    childrenList.add(child);
>  }
>
>  public String getName() {
>    return name;
>  }
>
>  public List getChildrenList() {
>    return childrenList;
>  }
>
>  static Node getSampleNode() {
>    Node nodeA = new Node("A");
>    Node nodeA0 = new Node("A0");
>    Node nodeA00 = new Node("A00");
>    Node nodeA01 = new Node("A01");
>    Node nodeA1 = new Node("A1");
>
>    nodeA.add(nodeA0);
>    nodeA.add(nodeA1);
>
>    nodeA0.add(nodeA00);
>    nodeA0.add(nodeA01);
>    return nodeA;
>  }
> }
>
> === Tree.java and Tree.html 
> public class Tree extends WebPage {
>
>  public Tree() {
>    Node node = Node.getSampleNode();
>    NodePanel nodePanel = new NodePanel("", "node", node);
>    add(nodePanel);
>  }
> }
>
> http://www.w3.org/1999/xhtml";>
>  
>    Tree
>    
>  
> 
>  
> 
> 
> 
>
>
> = NodePanel.hava and html ==
> public class NodePanel extends Panel {
>
>  public NodePanel(final String indent, String id, Node node) {
>    super(id);
>
>    add(new Label("name", indent+node.getName()));
>
>    if (node.getChildrenList().size() == 0) {
>      final WebMarkupContainer parent = new WebMarkupContainer("children");
>      add(parent);
>      parent.add(new EmptyPanel("node"));
>    } else {
>      add(new ListView("children", node.getChildrenList()) {
>       �...@override
>        protected void populateItem(ListItem item) {
>          Node childNode = (Node) item.getModelObject();
>          item.add(new NodePanel(indent+"", "node", childNode));
>        }
>      });
>    }
>  }
> }
>
> 
>
>  
>    name
>
>    
>      
>      
>    
>  
>
> 
> 
>
> HTH,
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: google-sitebricks

[Eelco Hillenius]

> I think it's a very nicely designed minimal framework,

Maybe I shouldn't say minimal, but rather that Dhanji didn't need a
lot of code to create a powerful framework. :-)

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: google-sitebricks

[Eelco Hillenius]

I think it's a very nicely designed minimal framework, and I think
it's great that it has a focus on failing as early as possible. I'm
considering using it for a site that is halfway the transition of
going from Struts 2 to mostly Ajax (extjs). That site currently uses
JSPs for templating, which should be pretty minimal since Ajax takes
over after the first render, but unfortunately isn't. Sitebricks would
be a great replacement for those JSPs, especially because we're also
refactoring that site to use Guice for DI (which totally rocks btw).

As for yet-another-framework-vs-framework discussion... I would just
use it for different purposes. Wicket is great for complex projects
that aren't Ajax-mostly, where you want to create many abstractions
and reusable components, etc. I would consider (do consider in fact)
Sitebricks when you go all ajax-y, e.g. together with YUI or ExtJs
directly. It would compete with GWT in that case, since I haven't made
up my mind whether I like that approach (great tooling support, static
typing and being able to have programmers of various levels of
competence working on it), or whether I prefer the approach to use
something like Sitebricks and/ or JAX-RS with a good JS/ Ajax lib
directly (small, elegant, flexible and no magic to fight, but needs
disciplined coders and project standards to avoid ending up in
maintenance hell). In my experience, It'll be hard to beat Wicket's
productivity though. :-)

Eelco

On Sat, Sep 26, 2009 at 2:20 PM, Objelean Alex  wrote:
> It seems that google created a yet-another-web-framework (as it used to be
> called). It is called google-sitebricks. Below is a link on infoq.
> http://www.infoq.com/news/2009/09/google-sitebricks
> What do you think about it?
>
> Regards,
> Alex Objelean
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: rpc question

[Eelco Hillenius]

While you could use Wicket for this, personally I think you're getting
close to viewing Wicket as the golden hammer :-)

Why not use Jersey for instance. I just used that myself (in a project
where the UI is in Wicket), and especially together with Jackson for
JSON <--> Pojo serialization this seems to work pretty well. It's also
part of a standard (JaxRS), which imho should never be the main reason
to choose something, but is a nice little extra.

Eelco


2009/9/18 Petr Kobalíček :
> Thanks guys,
>
> the solution from Pedro
> (http://blog.brunoborges.com.br/2008/11/restful-web-services-with-wicket.html)
> is very close I talked about. I think that wicket supports to send
> JSON instead of XML, so I'm going to play with this.
>
> I have another question, maybe very OT, can I connect this solution
> with standard RPC server to check for types, etc? For example with
> http://jabsorb.org/ ? I'd like to use wicket sessions and request
> cycle with RPC services, or is my demand stupid (I mean that there are
> better solutions)?
>
> My problem is that I have quite big application in qooxdoo that
> communicates only through JSON (not strictly RPC). This is used for
> administration part. And second part of application is pure wicket
> solution. I'd like to stay with qooxdoo for administration, i like it.
>
> Cheers and thanks
> - Petr
>
> 2009/9/18 Marc Ende :
>> Hi Petr,
>>
>> sorry, I've misunderstood your mail... :)
>>
>> you've meant the other way round. May be you should try to
>> build a restful webservice. It's also possible with wicket if you
>> decide xml as a resultpage.
>>
>> For example:
>> http://java.dzone.com/news/wicket-creating-restful-urls
>>
>> Am Fri, 18 Sep 2009 17:48:01 +0200
>> schrieb Marc Ende :
>>
>>> Hi Petr,
>>>
>>> I think you should use a LoadableDetachableModel. Within the method
>>> load() you can execute your call to the webservice or other
>>> remote-service.
>>>
>>> http://cwiki.apache.org/WICKET/working-with-wicket-models.html#WorkingwithWicketmodels-DetachableModels
>>>
>>> yours
>>> marc
>>>
>>> Am Fri, 18 Sep 2009 14:20:27 +
>>> schrieb Petr Kobalíček :
>>>
>>> > Hi list,
>>> >
>>> > is there a simple tutorial about making RPC services in wicket? I
>>> > mean all integrated with wicket RequestCycle and Sessions, ideally
>>> > that I can expose web services through some Wicket page like class.
>>> > I'm porting one application and we have admin interface in qooxdoo
>>> > toolkit (it communicates through json requests).
>>> >
>>> > I'd like to hear about "wicket" solution to this problem.
>>> >
>>> > Thanks for possibilities
>>> > - Petr
>>> >
>>> > -
>>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> > For additional commands, e-mail: users-h...@wicket.apache.org
>>> >
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Is it possible to let messages in a FeedbackPanel contain links?

[Eelco Hillenius]

Do you have to link to components, or can you link to e.g. a
bookmarkable page with a message/ topic id in the URL? If that's the
case, you can achieve that through the feedback panel.

Eelco

On Wed, Sep 2, 2009 at 6:19 AM, Pieter
Degraeuwe wrote:
> Indeed,
> The messages are removed on detach. So when clicking on the link, the actual
> message is already removed, this the component is not visible anymore.
>
> I will now -as you suggest- use another panel to show my links. (The
> feedback mechanism is not ideal for that.
>
> Thanks anyway
>
> On Wed, Sep 2, 2009 at 3:15 PM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
>> Sorry but I do not understand well what you want to achieve?
>>
>> I think messages are removed after page has been rendered... (see
>> references
>> to WebSession.cleanupFeedbackMessages() at RequestCycle.detach()).
>>
>> What kind of links are you using? Why not cache yourself the "values" you
>> are interested at? And then have some kind of panel which you display, lets
>> say, via AJAX, where you show the information you want?
>>
>> Best,
>>
>> Ernesto
>>
>> On Wed, Sep 2, 2009 at 2:16 PM, Pieter Degraeuwe <
>> pieter.degrae...@systemworks.be> wrote:
>>
>> > Hmm,
>> > this approach (overriding the method newMessageDisplayComponent(...)
>> seems
>> > to work almost;
>> >
>> > I can show links in the feedbackpanel, but when I click on them, wicket
>> > does
>> > not find the component anymore (maybe because it was removed (since
>> > messages
>> > are removed too?
>> >
>> > Any tips?
>> >
>> >
>> >
>> > On Wed, Sep 2, 2009 at 12:59 PM, Pieter Degraeuwe <
>> > pieter.degrae...@systemworks.be> wrote:
>> >
>> > > Perfect !.
>> > > I'll give it a try.
>> > >
>> > > Thanks
>> > >
>> > > On Wed, Sep 2, 2009 at 11:55 AM, Ernesto Reinaldo Barreiro <
>> > > reier...@gmail.com> wrote:
>> > >
>> > >> Individual messages are created via the factory method
>> > >> protected Component newMessageDisplayComponent(String id,
>> > FeedbackMessage
>> > >> {
>> > >> Serializable serializable = message.getMessage();
>> > >> Label label = new Label(id, (serializable == null) ? "" :
>> > >> serializable.toString());
>> > >>
>> label.setEscapeModelStrings(FeedbackPanel.this.getEscapeModelStrings());
>> > >> return label;
>> > >> }
>> > >>
>> > >> So, maybe you could override it to return a Panel with the
>> functionality
>> > >> you
>> > >> want (instead of a simple label). Otherwise, rolling out your own
>> > >> implementation of FeedBackPanel should not be very difficult in case
>> you
>> > >> find out doing this is not enough to achieve what you want.
>> > >>
>> > >> Best,
>> > >>
>> > >> Ernesto
>> > >>
>> > >> On Wed, Sep 2, 2009 at 10:59 AM, Pieter Degraeuwe <
>> > >> pieter.degrae...@systemworks.be> wrote:
>> > >>
>> > >> > Hi,
>> > >> > After some actions the user did trigger in my webapp, I give the
>> user
>> > >> some
>> > >> > messages like 'The order was successfully created.'
>> > >> >
>> > >> > However, sometimes I want to give a message like. 'The order was
>> > >> > successfully created, but some warnings were created. Click *here*
>> to
>> > >> view
>> > >> > these warnings'
>> > >> >
>> > >> > Is this possible in using the standard FeedbackPanel? If so, is
>> there
>> > >> > somewhere documentation how to do so?, If not, what is the best
>> > approach
>> > >> to
>> > >> > achieve this.
>> > >> >
>> > >> > Thanks
>> > >> >
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Pieter Degraeuwe
>> > > Systemworks bvba
>> > > Belgiëlaan 61
>> > > 9070 Destelbergen
>> > > GSM: +32 (0)485/68.60.85
>> > > Email: pieter.degrae...@systemworks.be
>> > > visit us at http://www.systemworks.be
>> > >
>> >
>> >
>> >
>> > --
>> > Pieter Degraeuwe
>> > Systemworks bvba
>> > Belgiëlaan 61
>> > 9070 Destelbergen
>> > GSM: +32 (0)485/68.60.85
>> > Email: pieter.degrae...@systemworks.be
>> > visit us at http://www.systemworks.be
>> >
>>
>
>
>
> --
> Pieter Degraeuwe
> Systemworks bvba
> Belgiëlaan 61
> 9070 Destelbergen
> GSM: +32 (0)485/68.60.85
> Email: pieter.degrae...@systemworks.be
> visit us at http://www.systemworks.be
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: UTF-8

[Eelco Hillenius]

> The result is in the attachment file (sorry but I don't have a quick
> way to do a patch file against SVN trunk at the moment).

The mailing list daemon thinks attachments are delicious. The way to
submit patches is to attach it to a JIRA issue. Did anyone already
open a feature request for this? If not, please open an issue here:
http://issues.apache.org/jira/browse/WICKET. Further discussion and
patches can go there.

Cheers,

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: UTF-8

[Eelco Hillenius]

>> But I'm sure you can write a properties implementation that reads from
>> UTF-8 in a few hours max, especially now that you have an example in
>> Tapestry's code. Patch is welcome :-)
>
> Why not just "borrow" the code from Tapestry?  It's Apache licensed of
> course, so no issues there.

Sure, if it makes sense. But it needs to fit in Wicket's framework,
and I don't know how Tapestry specific that code for handling those
UTF-8 properties files in Tapestry is.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: UTF-8

[Eelco Hillenius]

On Tue, Sep 1, 2009 at 1:19 AM, Olivier
Bourgeois wrote:
> That's exactly what I said : I had to use XML properties files to have
> UTF-8 localized properties.
>
> You can't use simple properties format because Java can't handle
> natively anything else than ISO. We use also Tapestry here, and you
> can use UTF-8 properties files (thanks to the wrapper around native
> Java properties).

Ah, right. Well reading is an art :-)

It's been a while, but I think I considered 'fixing' or otherwise
supporting loading in regular properties files through UTF-8, but
decided against it because it would be non-standard even in newer JDK
versions, and the newer JDKs already had a solution for reading
properties in UTF-8 with xml files.

But I'm sure you can write a properties implementation that reads from
UTF-8 in a few hours max, especially now that you have an example in
Tapestry's code. Patch is welcome :-)

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: UTF-8

[Eelco Hillenius]

> Erm 
> http://chillenious.wordpress.com/2006/11/13/wicket-now-supports-resource-bundles-in-xml-format/

Which says Wicket 2.0 (yes, it's that old), but it was also one of the
first things backported. Loading is automatic, and .xml takes
precedence over .properties.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: UTF-8

[Eelco Hillenius]

> Because Wicket uses Java Properties objects and it can't handle UTF-8.
> In Tapestry they made a wapper around Java Properties so that you can
> use the good old properties format (ie "key=value") with UTF8 encoding
> and IMO it's a nice feature missing in Wicket.

Erm 
http://chillenious.wordpress.com/2006/11/13/wicket-now-supports-resource-bundles-in-xml-format/

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Session gc

[Eelco Hillenius]

> see httpsessionlistener
> http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpSessionListener.html

Yep. You can use the session store hooks that Wicket provides, but I
found HttpSessionListener to be the most reliable.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: How to detect model "leakage" into session

[Eelco Hillenius]

One 'hack' of a way to check whether you have stuff in your session
that shouldn't be, is to make sure that the objects you don't want
sticking around are not serializable, and you'll see stacktraces soon
enough. If that's an options, it's a useful hack...

Eelco

On Wed, Aug 26, 2009 at 12:29 PM, Bas Gooren wrote:
> Hi all,
>
> My problem is as follows: I use LoadableDetachableModels throughout my 
> application, and have made sure I never use a model without it being attached 
> to a component to prevent models which never get their detach() method called.
> Nonetheless, after hitting two fairly simple pages which list some database 
> data in my application, I get a 100kb session which is filled with literal 
> strings from model objects.
>
> I've fired up my (Eclipse) debugger and have stepped through all models on 
> one of the pages after setting a breakpoint on the pages onDetach() method. I 
> see all LoadableDetachableModels are detached, so I have no idea what's 
> causing this.
>
> What would be a good strategy for finding the source of this problem?
>
> Bas

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Need Wicket Book

[Eelco Hillenius]

On Mon, Aug 17, 2009 at 11:45 PM, Ernesto Reinaldo
Barreiro wrote:
> Well, expensive is a relative term: in the country I come from $27.50 is
> almost twice the money a developer will receive as payment for a month of
> hard work;-)

Insane, isn't it. Yet in other countries one wouldn't even accept that
as an hourly wage.

> Besides that, IMHO, the book is an excellent reading and buying it is a good
> way to support those who expend so much energy and time maintaining the
> framework.

Glad to hear people are still liking the book. I wish prices would be
distributed more to relative income, but that's out of my control :-)

Anyway, I still feel that the examples project are an excellent source
for learning about Wicket. Most important things are covered, and
going through the examples is very hands-on. Also, you can download
the first chapter of Wicket In Action for free, which will at least
inform you what kind of problems the framework tries to solve.

Good luck,

Eelco

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Model question ?

[Eelco Hillenius]

> Is there any issues you need to be concerned with when using the page
> itself as the model object?

I don't think so.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket-Scala extensions

[Eelco Hillenius]

Sweet!

Eelco

On Fri, Aug 14, 2009 at 9:56 AM, Antony Stubbs wrote:
> Ok for those following this thread - Wicket-Scala Extensions is out!
> Announcement here:
> http://www.nabble.com/Announcing:-Scala-Wicket-Extensions-Project-ts24975011.html
>
> Cheers,
> Antony Stubbs,
>
> sharca.com
>
> On 14/07/2009, at 11:34 AM, Antony Stubbs wrote:
>
>> omgosh - http://www.footprint.de/fcc/2009/02/london-wicket-presentation/
>> I've met you! haha. h... Isn't the internet nutty?!
>>
>> On 14/07/2009, at 7:14 PM, Jan Kriesten wrote:
>>
>>>
>>> Hi Antony,
>>>
>>> great to see Scala and Wicket getting more popular. :-)
>>>
>>> I've been using them together quite a while now and am convinced that
>>> there are
>>> lots of benefits in it!
>>>
>>> I created a dynamic component (like wicket:component which isn't
>>> officially
>>> supported) which also works with Ajax. There's also a 'VarModel' which is
>>> similar to your Fodel. You'll find the sources here:
>>> http://www.footprint.de/fcc/2008/11/some-wicket-scala/
>>>
>>> I also use Scala's mixin capabilities to abstract layout information out
>>> of the
>>> pages/components. E.g. to define cell styles of datatable columns or to
>>> format
>>> cell output, I have something like:
>>>
>>> trait Centered[T] extends IStyledColumn[T] {
>>>  abstract override def getCssClass: String = {
>>>    val style = super.getCssClass
>>>
>>>    if( style==null ) "columnCentered"
>>>    else style + " " + "columnCentered"
>>>  }
>>> }
>>>
>>> trait DateFormat[T] extends PropertyColumn[T] {
>>>  override protected def createLabelModel( embeddedModel: IModel[T] ):
>>> IModel[_] = {
>>>    val m = super.createLabelModel( embeddedModel )
>>>    m.getObject match {
>>>      case dt: DateTime => VarModel( dt.toString(
>>> dateFormatter.withLocale(
>>> getLocale ) ) )
>>>      case _ => m
>>>    }
>>>  }
>>> }
>>>
>>> To create/apply a cell to use this style I just have to apply this trait:
>>>
>>> val col1 = new PropertyColumn[M]( new Model( "Date" ), COL_DATE,
>>> "reg_date" )
>>> with Centered[M] with DateFormat[M]
>>>
>>>
>>> Scala's just great to abstract more between logic and layout.
>>>
>>> Best regards, --- Jan.
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: How To Kill Previous Page

[Eelco Hillenius]

If you never want to support back button behavior, that's easy, just
implement a dummy ISessionStore, or probably better (because you still
need to the current page to be in memory for call backs, implement a
dummy IPageStore. Basically like NonPageCachingDummyWebApplication in
WicketTester.

> what happens when you try to access a page that was taken away from the page
> map?

That'll be when a user presses the back button: that user will get an
error (not sure exactly which one from the top of my head). Best to
just implement and test when happens what yourself to make sure
everything is like you wanted.

Eelco

On Fri, Aug 7, 2009 at 1:54 PM, Carlo Camerino wrote:
> i'm still looking at though, and probably would need to implement it soon.
>
> thanks for the reply
>
> On Fri, Aug 7, 2009 at 7:41 PM, Alex Objelean wrote:
>
>>
>> getPage().getPageMap().remove(); ?
>>
>> Alex Objelean
>>
>>
>> carlo c wrote:
>> >
>> > Hi,
>> >
>> > I would like to ask if it's possible to kill the previous page out of the
>> > pagestore.
>> > I have this requirement in which i have a view screen which can be able
>> to
>> > delete or edit an entity.
>> >
>> > My problem is that when the client copies the url and pastes it back the
>> > client can go back to the previous page since the client can retrieve it
>> > from the session store.
>> >
>> > Is there  a way in which wicket can actually destroy the previous page?
>> >
>> > the problem is the users can copy for exampler
>> >
>> > View Page
>> > wicket:interface=1
>> >
>> > Acknowledgement Page
>> > wicket:interface=2
>> >
>> > The user can actually paste the url
>> >
>> > wicket:interface=1 to the browser and still be able to view the record.
>> >
>> > Is there any way for me to kill the page with id = 1?
>> >
>> > Thanks A Lot
>> > Carlo
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/How-To-Kill-Previous-Page-tp24863148p24863291.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Twenty Six Wicket Tricks

[Eelco Hillenius]

On Tue, Jul 28, 2009 at 12:08 PM, Matej Knopp wrote:

> I would like to have some clarification on this. What is so difficult
> about the Wicket Tree API? (apart from the fact that it uses swing
> TreeModel which seem to be too confusing for some people).

Confusing for some, easy for others (who maybe already have worked
with it in Swing) :-) Components like that get complex pretty quickly.
Look at what other frameworks deliver and see if you can use that
without a lot of hacking (if they provide a tree widget backed by a
model to start with, most probably just don't). But hey, the more
alternatives the merrier; in the end API design (and thus Wicket
widget design) involves a lot of subjective choices.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: will there be a performance gain to use singleton to remove references to the service object in models?

[Eelco Hillenius]

Actually, thinking about it, if you're very tight on memory, it will
save you a reference, particularly when the page gets serialized. So
if you are worrying about efficiency *and* are ok with this code
style, it's an option. :-)

Eelco

On Tue, Jul 28, 2009 at 12:47 AM, Eelco
Hillenius wrote:
> It might give you a very slight edge to use a singleton as you (or the
> annotation processor in this case) don't have to introspect and work
> through a proxy. If you're not bothered by singletons (I, for one
> typically are): go for it. However, keep that famous 'premature
> optimization is the root of all evil' in mind; 99.9% chance you're
> optimizing something that will never ever become a bottleneck.
>
> Eelco
>
> 2009/7/27 Murat Yücel :
>> Hi Jason
>>
>> I dont have a performance comparison, but i cannot see why you should
>> gain better performance.
>> All spring beans are as default singleton, so you will just forward a
>> singleton using a singleton.
>>
>> /Murat
>>
>> 2009/7/28 Jason Wang :
>>> Hi all,
>>>
>>> Although I am using spring-wicket to prevent the whole spring being
>>> serialized, It still brothers me to  see the  references in the model
>>> object, for example:
>>>
>>> Instead of using this:
>>>
>>> public class MyViewObjectProvider extends SortableDataProvider{
>>>   �...@springbean("daoService")
>>>    private  DAOServices daoService;
>>>
>>>    private String objectID;
>>>
>>>    public Iterator iterator(final int first, final int count){
>>>         .
>>>      return daoService.load(objectId).subList(first,
>>> first+count).iterator();
>>>   }
>>>
>>> }
>>>
>>>
>>>
>>> I always write a singleton helper class for the service to be used, so I can
>>> have the model this way:
>>>
>>> public class MyViewObjectProvider extends SortableDataProvider{
>>>    //so no reference to the dao service object
>>>
>>>    private String objectID;
>>>     public Iterator iterator(final int first, final int count){
>>>         .
>>>   //here the DAOServiceHelper.get() returns a instance that managed by
>>> spring(with the actual service object injected.)
>>>      return DAOServiceHelper.get().load(objectId).subList(first,
>>> first+count).iterator();
>>>   }
>>>
>>>  }
>>>
>>> So my question is, will there be a noticeable  performance gain to do it the
>>> 2nd way?
>>> The reason to ask is that the static kind of singleton usage is indeed
>>> anti-spring, and makes
>>> my eyes bleed
>>>
>>> If no one has done a performance comparison, I might have to do one myself.
>>> Just being lazy...
>>>
>>>
>>> Thanks,
>>>
>>> Jason Wang
>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: will there be a performance gain to use singleton to remove references to the service object in models?

[Eelco Hillenius]

It might give you a very slight edge to use a singleton as you (or the
annotation processor in this case) don't have to introspect and work
through a proxy. If you're not bothered by singletons (I, for one
typically are): go for it. However, keep that famous 'premature
optimization is the root of all evil' in mind; 99.9% chance you're
optimizing something that will never ever become a bottleneck.

Eelco

2009/7/27 Murat Yücel :
> Hi Jason
>
> I dont have a performance comparison, but i cannot see why you should
> gain better performance.
> All spring beans are as default singleton, so you will just forward a
> singleton using a singleton.
>
> /Murat
>
> 2009/7/28 Jason Wang :
>> Hi all,
>>
>> Although I am using spring-wicket to prevent the whole spring being
>> serialized, It still brothers me to  see the  references in the model
>> object, for example:
>>
>> Instead of using this:
>>
>> public class MyViewObjectProvider extends SortableDataProvider{
>>   �...@springbean("daoService")
>>    private  DAOServices daoService;
>>
>>    private String objectID;
>>
>>    public Iterator iterator(final int first, final int count){
>>         .
>>      return daoService.load(objectId).subList(first,
>> first+count).iterator();
>>   }
>>
>> }
>>
>>
>>
>> I always write a singleton helper class for the service to be used, so I can
>> have the model this way:
>>
>> public class MyViewObjectProvider extends SortableDataProvider{
>>    //so no reference to the dao service object
>>
>>    private String objectID;
>>     public Iterator iterator(final int first, final int count){
>>         .
>>   //here the DAOServiceHelper.get() returns a instance that managed by
>> spring(with the actual service object injected.)
>>      return DAOServiceHelper.get().load(objectId).subList(first,
>> first+count).iterator();
>>   }
>>
>>  }
>>
>> So my question is, will there be a noticeable  performance gain to do it the
>> 2nd way?
>> The reason to ask is that the static kind of singleton usage is indeed
>> anti-spring, and makes
>> my eyes bleed
>>
>> If no one has done a performance comparison, I might have to do one myself.
>> Just being lazy...
>>
>>
>> Thanks,
>>
>> Jason Wang
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [OT] Continue to support Wicket 1.2 in WicketForge

[Eelco Hillenius]

I think we even 'officially' recommend upgrading from 1.2 (or before)
to 1.3 or higher because of the performance and scaling improvements
between the two releases.

Eelco

On Mon, Jul 27, 2009 at 10:51 PM, Nick Heudecker wrote:
> Thanks for the feedback.  Looks like I can safely remove Wicket 1.2
> support.
>
> On Mon, Jul 27, 2009 at 3:33 AM, Linda van der Pal <
> lvd...@heritageagenturen.nl> wrote:
>
>> I've only ever seen questions on this list about 1.3 and 1.4 (in the few
>> months I've been on it, that is), so I'm guessing that if there are users of
>> 1.2 they are either knowledgable enough not to have questions, or they're
>> simply not on this list.
>>
>> Regards,
>> Linda
>>
>> Maarten Bosteels wrote:
>>
>>> We only use wicket 1.4.*
>>>
>>> Regards,
>>> Maarten
>>>
>>>
>>> On Sat, Jul 25, 2009 at 2:16 PM, Erik van Oosten >> >wrote:
>>>
>>>
>>>
 Mostly Wicket 1.4 at my company, just 1 Wicket 1.3 project left.

 Regards,
  Erik.


 Nick Heudecker wrote:



> Hi,
>
> For those of you that don't know, I maintain WicketForge, the Wicket
> plugin
> for IDEA (http://plugins.intellij.net/plugin/?id=1545 or
> http://code.google.com/p/wicketforge).  Currently, WicketForge supports
> Wicket 1.2 in addition to 1.3 and 1.4, but I'd like to remove support
> for
> 1.2 to clean a few things up.  First, I want to see if people are still
> using 1.2 with WF.
>
> My question to you is: are you still using WicketForge with Wicket 1.2?
>
> Thanks for your time and feedback.
>
>
>
>
 --
 Erik van Oosten
 http://www.day-to-day-stuff.blogspot.com/


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




>>>
>>>  
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database:
>>> 270.13.32/2266 - Release Date: 07/27/09 05:58:00
>>>
>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
> --
> Nick Heudecker
> Professional Wicket Training & Consulting
> http://www.systemmobile.com
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: A packaged resource that has a variable image based on component value

[Eelco Hillenius]

I would vary the packaged resource rather than having a resource vary
what it points to. That way, you can let browsers cache the image, and
you could potentially move it out of a packaged resource to a static
image some day if you'd want it e.g. to get maximum performance.

Eelco

On Thu, Jul 9, 2009 at 11:56 PM, Steve Tarlton wrote:
> I know this is probably very simple to do, but I haven't been able to get my
> head wrapped around it. I want to create a component within the column of a
> table that has 6 different images associated to it. Each image is tied to a
> number as the component is actually an integer representing a state. I
> believe I would simply create a packaged resource vary the image it selects
> based on the value of the component. I figured maybe someone here on the
> list might give me a nudge in the right direction.
>
> BTW: The inmethod datagrid ROCKS!
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: model detached many times

[Eelco Hillenius]

It's fine if a model if detached multiple times in a request, but
hundreds for a single model sounds suspicious. Try to trace what
components fire the detach method and see if there's anything weird
with that.

Eelco

On Thu, Jul 9, 2009 at 11:21 PM, Ian MacLarty wrote:
> Hi,
>
> I noticed that my IDetachable model is being detached many times
> (hundreds) for each request.  Is that something to worry about, or is
> it just because the detach method is called for each component that
> points to this model?
>
> Ian.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Google App Engine and Wicket

[Eelco Hillenius]

> Both articles avoid the DiskPageStore problem by using the HttpSessionStore,
> however if you do a search through the mailing list archives for
> HttpSessionStore you'll find numerous references to problems in using it in
> the long term and especially in a real, production application, so I don't
> think that's a good long term solution, so my original question still
> stands. Is there an alternative or is Wicket perhaps not well suited for use
> in the App Engine.

It's probably a good idea to have a specialized implementation of
ISessionStore for App Engine that uses whatever makes sense with App
Engine for medium term storage ('cause that's what it is... short term
storage is the current page, which is typically local memory, and
older pages are used for the duration of the session, and typically
just keeping the last few in memory suffices.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: serialVersionUID

[Eelco Hillenius]

> The purpose of the *public* static final long serialVersionUID is for long

Why do you stress *public*? private is the norm for serialVersionUID.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: GWT vs. Wicket?

[Eelco Hillenius]

I really like the idea behind GWT. And striving for a statically typed
'true' OO programming model is what GWT and Wicket have in common.

I haven't build anything with GWT, so my opinions in this respect are
what I infer from how I think GWT works. I expect GWT to scale more
easily if you plan well for it. Meaning that you probably don't want
to end up with a very crowded pages that's very chatty with the
server.. in that case Wicket might actually be more efficient
(probably a surprise for many) because often times it'll do everything
in one request (locality). A few other things I like about Wicket when
compared with GWT:
- It's just the Java code you work with, nothing complicating like an
extra compile step (in GWT's case to JavaScript) or even byte code
engineering like many other frameworks do. This makes Wicket easier to
debug - though admitted Wicket doesn't have the easiest to follow
bowels around due to the magic we have to do to give users a stateful
programing experience.
- Wicket is very flexible. I've read comments a while back of someone
saying Wicket doesn't very well support integrating with other
libraries... well, that's just bullocks. Some things will be harder
than other things, but you can pretty much take the framework apart at
any level and replace with your own ideas, including tags that
dynamically create components and stuff.
- Wicket is completely dynamic. I've worked on several projects now
where we had panels contributed by e.g. domain objects. Maybe not
something that appeals to people who take separation of layers ultra
serious, but I think it is awesome. I currently use this for
functionality that is about surveys. Surveys have questions, and these
questions can be anything... free text, multiple choice, but
potentially location or color. Questions can contribute their own
panels for editing and viewing. So we can decide at some point to e.g.
develop a location question, that displays a map, and we could jar the
question with the UI with it, plug it in, and no-one ever had to touch
other parts of the UI. I love that kind of flexiblity, and it's hard
to find frameworks that support stuff like that (though I expect that
you can achieve something like this with GWT, I don't expect it to be
as straightforward as with Wicket).
- It's safe by default. I don't mean hacker-safe, but rather that you
never by default communicate sensitive info like IDs (or as with GWT
whole objects) with clients. My experience with using other frameworks
than Wicket is that we always spent quite a bit of time making sure
users couldn't do things they weren't supposed to do (like deleting an
object they have no right for), whereas with Wicket based projects the
amount of time doing this is zero.

I do expect a few things to be nicer with GWT though. Mainly, no
worries about scaling (Wicket *is* scalable, but beyond a few servers
you'll have to do work for it, while with GWT it's mainly a question
of scaling your services and avoid too much chatty-ness), and no
worries about detaching models! And these two advantages can be large
enough for someone to prefer GWT.

I can easily make this email 3 times longer with my perceived pros and
cons, but these are the things that spontaneously came up. :-)

Eelco

On Wed, Apr 8, 2009 at 6:11 AM, Casper Bang  wrote:
> I was just wondering about the Wicket community's opinion of GWT. It seems
> to share many of the positive characteristics as Wicket (focus on code, not
> markup) with the major difference/benefit as I see, that is does not
> maintain any state on the server. Also, with GWT you seem to get more
> readily available components (i.e. http://extjs.com/explorer/). The bennefit
> of Wicket as I can see, is that applications potentially degrade nicer and
> the programming model hides the Ajax RPC better. Any thoughts?
>
> /Casper
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: delete onSubmit

[Eelco Hillenius]

> Is there a way to correctly/formally "remove" the object from Hibernate's
> immediate memory?

yes, Session#evict. It may be your first step in a swamp of cascading
hacks, but every now it then it solves a hard-to-track down Hibernate
problem for me.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: need source code for [AutoCompleteTextField]

[Eelco Hillenius]

Look at those examples, see how data is passed in, copy to your
application and replace the example data with yours. Along those
lines. The examples will help you on your way, and the rest has to
come from your own inventiveness.

Eelco


On Wed, Apr 1, 2009 at 11:14 PM, FaRHaN  wrote:
> I want to implement AutoCompleteTextField that ships with Wicket but not the 
> built-in functionality that ships with wicket.
> For Example: various Countries & ISO languages have been shiped with wicket 
> as default (as implemented in the wicket library examples)
>
> So, i want to introduce my own values(choices) stored in an array through 
> java code. those will be populate when i press any of those choices' prefixes.
>
> thanx...
>
> --- On Thu, 4/2/09, Jeremy Thomerson  wrote:
>
> From: Jeremy Thomerson 
> Subject: Re: need source code for [AutoCompleteTextField]
> To: users@wicket.apache.org
> Date: Thursday, April 2, 2009, 5:51 AM
>
> So, let me see if I understand this
>
> You want the source code to implement an AutoCompleteTextField.
>
> BUT - You don't want the source to the AutoCompleteTextField that ships as a
> DEFAULT PART OF WICKET?
>
> Why?
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Thu, Apr 2, 2009 at 12:45 AM, FaRHaN  wrote:
>
>> Anybody who loves to develop applications with Ajax will certainly know the
>> Autocomplete behaviour of Ajax and most probably he developed this feature
>> in his application also.
>> I want to introduce that feature in my application, that will take input
>> (choices) stored in an array of strings or in database. Please provide me
>> some source code example to accomplish this behaviour.
>> (Please dont refer me to Wicket library examples because built-in
>> functionality has been implemented in those Ajax examples)
>>
>> Thanx...
>>
>>
>>
>>
>
>
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: How NOT TO Cache Markup - Markup Dynamically created

[Eelco Hillenius]

> it said that if I returned null from getCacheKey that the markup would not
> be cached.
>
> When I do this I get into a loop and it keeps trying to get the markup over
> and over again.

Did you check the markup can be loaded at all?

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: IMarkupCacheKeyProvider - getCacheKey Problem

[Eelco Hillenius]

I don't remember the details from the top of my head, but there should
be an example at Wicket examples that shows you how to effectively
disable caching.

Eelco

On Sun, Mar 15, 2009 at 4:00 PM, Karen Schaper  wrote:
> Hi All,
>
> I have a wicket class that extends from WebPage and implements
>       IMarkupResourceStreamProvider,
>       IMarkupCacheKeyProvider
>
> I am now using wicket 1.4rc2.
>
>
> I DO NOT want the markup cached.  The page actually creates a variety of
> markup so it can be different each time.
>
> From what I've read if the I return null in the method getCacheKey, the
> markup will not be cached.
>
> However when I do this I get into a never ending loop of calls to get the
> markup.
>
> Is this a bug?  Is there any way to not have the markup be cached?
>
> Any thoughts or hints on this would be greatly appreciated.
>
> Thanks
>
> Karen
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: What IDE best fits with Wicket?

[Eelco Hillenius]

I'm using Jetty directly (without Maven, though we do use maven for
project management), and hotswap works great then.

Eelco


On Tue, Mar 10, 2009 at 4:47 AM, francisco treacy
 wrote:
> i would like to add an ingredient here: scala.
>
> is there anyone successfully using an IDE with wicket/maven/scala
> *and* jetty hotswap?
>
> i have always developed wicket/java in eclipse (dead easy to set up -
> create quickstart archetype, right click debug Start.java and off you
> go). but scala plugin for eclipse was a PIA to work with (stable or
> nightly) and i decided to try with netbeans 6.5, where scala plugin is
> quite decent. i managed to set up the quickstart with maven, added
> some config for scala and all is great... but i really can't figure
> out how to have jetty hotswap support.  apparently i should add some
> configuration to tell netbeans i want the "process-resources" goal to
> execute each time i save an html file, or compile a scala file.
>
> it is not very convenient to restart the app every time i make a
> change.  does anybody have experience with a similar setup?
>
> thanks,
>
> francisco
>
>
> On Sat, Feb 28, 2009 at 5:45 AM, Brill Pappin  wrote:
>> It's been a year or two since I tried it... but I couldn't stand it
>> unfortunately (m4eclipse was going through some serious issues at the time).
>>
>> Glad to see that its improved enough to use!
>>
>> - Brill
>>
>> On 27-Feb-09, at 6:14 AM, Sergio García wrote:
>>
>>>
>>> I'm using Q4E, and although it has some flaws, it works very good with
>>> maven
>>>
>>> Brill Pappin wrote:

 What are you using instead?

 - Brill

 On 24-Feb-09, at 12:45 PM, James Carman wrote:

> +1!  We had an awful lot of trouble getting it to work for us.
>
> On Tue, Feb 24, 2009 at 12:38 PM, Martijn Dashorst
>  wrote:
>>
>> m2eclipse is absolutely worthless for anything beyond a quickstart.
>> It
>> is constantly reparsing poms, grinding eclipse to a halt. It failed
>> to
>> generate the right project dependencies for our multimodule project
>> that consists of 2 multimodule child projects. It failed miserably to
>> uninstall, needing me to axe my eclipse installation.
>>
>> In short: my experience (and that of my co-workers) with m2eclipse is
>> that it is far from ready for prime time.
>>
>> Martijn
>>
>> On Tue, Feb 24, 2009 at 5:55 PM, Brill Pappin 
>> wrote:
>>>
>>> I should add something about the Eclipse maven plugins... don't go
>>> for the
>>> official eclipse Q4 plugin... use the "Maven Integration 4
>>> Eclipse" plugin
>>> (and actually the development version if your jiggy with it, it
>>> works and
>>> gets updated/fixed way more often).
>>>
>>> If your on Netbeans, I think Maven will generate Netbeans project
>>> files for
>>> you as well (it will do so for eclipse), so you could actually
>>> flip back and
>>> forth if you wanted.
>>>
>>> - Brill Pappin
>>>
>>> On 23-Feb-09, at 5:19 PM, Pierre Goupil wrote:
>>>
 +1, I like Wicket Bench. And with M2Eclipse, you have the full
 sources &
 JavaDoc just by adding Wicket as a dependency, which is very
 convenient.
 But
 don't expect Wicket Bench to do too much, it's just a small,
 useful tool.

 Pierre


> Hi, I use Eclipse with Wicket Bench plugin and it works very fine.

 --
 Sans amis était le grand maître des mondes,
 Eprouvait manque, ce pour quoi il créa les esprits,
 Miroirs bienveillants de sa béatitude.
 Mais au vrai, il ne trouva aucun égal,
 Du calice du royaume total des âmes
 Ecume jusqu'à lui l'infinité.

 (Schiller, "l'amitié")

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: memcached session store

[Eelco Hillenius]

> Just to be complete, even if this is not really an option for us: with
> ONE_PASS_RENDER clustering with wicket would be fine, no further state
> management issues, right?

Right. And there is back button support (access to older pages/
previous renderings) to consider, which without session affinity
you'll have to distribute throughout your cluster (though you might
want to do that anyway to support fall over).

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: How to donate to Wicket Project

[Eelco Hillenius]

As for the Wicket team, nothing is more welcome than being part of the
community and contributing patches and on the mailing list etc.

Cheers,

Eelco

On Sat, Dec 13, 2008 at 3:47 PM, Ayodeji Aladejebi  wrote:
> Thank you..I think the book is the way to go. I will probably buy it for all
> all the java developers in my office
> Maybe i should order like 10 copies
>
> Hmm..sounds good
>
> thanks
>
> On Sat, Dec 13, 2008 at 2:16 PM, James Carman
> wrote:
>
>> Of course, the ASF would always love donations:
>>
>> http://www.apache.org/foundation/contributing.html
>>
>> Also, you can buy from the Wicket store and part of the proceeds will
>> help the ASF (I believe that's how it's set up):
>>
>> http://www.cafepress.com/apachewicket
>>
>> The coffee mug is very nice and I also have the golf shirt!  Wish I
>> had a chance to play golf.
>>
>> On Sat, Dec 13, 2008 at 8:23 AM, Bruno Borges 
>> wrote:
>> > I don't think the project would accept money that way. If you really
>> wanna
>> > do that, just buy the book Wicket in Action and Eelco and Martijn will be
>> > more than happy. =D
>> >
>> > But, the best way to really contribute to the project is
>> > - submitting bugs
>> > - fixing them
>> > - helping writing documentation
>> > - spreading the word (blogging)
>> >
>> > =) Good luck with that! And thanks for showing us your willing to
>> > contribute.
>> >
>> > Best regards,
>> > Bruno Borges
>> > blog.brunoborges.com.br
>> > +55 21 76727099
>> >
>> > "The glory of great men should always be
>> > measured by the means they have used to
>> > acquire it."
>> > - Francois de La Rochefoucauld
>> >
>> >
>> > On Sat, Dec 13, 2008 at 8:14 AM, Ayodeji Aladejebi > >wrote:
>> >
>> >> Hi,
>> >> I am really grateful for the Wicket Project and really feel like buying
>> >> beer
>> >> for the wicket team but when i checked sponsorship under the Wicket
>> Site,
>> >>
>> >> it saw too much information except paying methods
>> >>
>> >> I don't use PayPal as I am not transferring money from US or europe, i
>> >> rather require an international Wire transfer account.
>> >>
>> >> Thank you for the Wicket Project
>> >>
>> >>
>> >> --
>> >> Aladejebi Ayodeji A.,
>> >> DabarObjects Solutions
>> >> Phone: +234 9 481 7 156
>> >> Mobile: +234 803 589 1780
>> >> Email: d...@dabarobjects.com
>> >> Web: www.dabarobjects.com
>> >> Blog: blog.dabarobjects.com
>> >>
>> >> Participate, Collaborate, Innovate
>> >> Join Community:
>> >> http://www.cowblock.net/
>> >>
>> >> Get A Free Blog:
>> >> http://blogs.cowblock.net/
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
> --
> Aladejebi Ayodeji A.,
> DabarObjects Solutions
> Phone: +234 9 481 7 156
> Mobile: +234 803 589 1780
> Email: d...@dabarobjects.com
> Web: www.dabarobjects.com
> Blog: blog.dabarobjects.com
>
> Participate, Collaborate, Innovate
> Join Community:
> http://www.cowblock.net/
>
> Get A Free Blog:
> http://blogs.cowblock.net/
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket Session grows too big real fast

[Eelco Hillenius]

> With Wicket 1.3 only one page should be stored in session. You should
> check if you don't keep references between pages -> that would result
> in 1+N pages (with N being the number of pages you reference in your
> page).

That's optimized though, so shouldn't typically be a problem. See the
custom read/ write serialization methods in Component and Page and
PageSerializer in AbstractPageStore.

I think the main concern you should have is with serialized domain
objects, especially if you use ORMs like Hibernate and such, since
that makes it all too easy to just read in half of your database with
very little programming effort.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ics-wicket-examples: beginner wicket examples available

[Eelco Hillenius]

Hi Philip,

Really great to see our work being put to good use!

Thanks!

Eelco

On Sun, Nov 23, 2008 at 10:03 AM, PhilipJohnson <[EMAIL PROTECTED]> wrote:
>
> Greetings all,
>
> I teach software engineering and I've assigned a simple webapp using Wicket
> to my students this semester. To help them bootstrap, I created a Google
> Project with an initial set of simple examples for them to look at.  I
> thought I would post a link here in case others might find it of use:
>
> http://code.google.com/p/ics-wicket-examples/
> http://code.google.com/p/ics-wicket-examples/
>
> These examples conform to the conventions for my class, including:
>  * Ant-based, no use of Maven.
>  * Test cases (using WicketTester) with 100% coverage
>  * Conforms to class coding standards checked by Checkstyle, PMD, and
> FindBugs.
>
> The book Wicket In Action is required for the class, and so one of the
> examples is the Cheesr application from that book re-worked slightly to
> conform to the above coding standards.
>
> If you see a way to improve an example, or have a self-contained, short
> example code that you think might be useful to the class, I would love to
> learn about it.   I don't read this list regularly, so please contact me at
> [EMAIL PROTECTED], or simply post an Issue to the ics-wicket-examples
> project. I teach this class every year and intend to maintain and add to
> this set of examples for quite a while.
>
> If you would like to read about the students' initial reactions to using
> wicket, they are required to post a blog entry by tomorrow.  Here's one
> student's summary:
>
> http://ronnreeves.blogspot.com/2008/11/mystackcom-sic-wicket-webapp.html
> http://ronnreeves.blogspot.com/2008/11/mystackcom-sic-wicket-webapp.html
>
> A directory to all of their blogs (some have not posted their entry for this
> assignment yet) is available here:
>
> http://groups.google.com/group/ics-software-engineering-fall-2008/web/00-engineering-log
> http://groups.google.com/group/ics-software-engineering-fall-2008/web/00-engineering-log
>
> I have found the Wicket community to be very helpful and responsive as I've
> learned about the framework, and I hope this can partially return the favor
> by helping others get started easily.
>
> Philip Johnson
>
> --
> View this message in context: 
> http://www.nabble.com/ics-wicket-examples%3A--beginner-wicket-examples-available-tp20648922p20648922.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]

Re: How to use TextTemplateHeaderContributor.forCss method?

[Eelco Hillenius]

The substitution doesn't happen at all? Any errors you see in the logs?

Eelco

On Sun, Nov 9, 2008 at 2:16 PM, shetc <[EMAIL PROTECTED]> wrote:
>
> Hi All,
>
> I've had success using the TextTemplateHeaderContributor.forJavaScript
> method but can't get the equivalent TextTemplateHeaderContributor.forCss
> method to work. Here are some snippets:
>
> From CSS:
> .someClass {
>background: #fff url('${brand}/someImage.jpg') 100% 100% no-repeat;
> }
>
> From Java:
> IModel skinModel = new AbstractReadOnlyModel() {
>private static final long serialVersionUID = 1L;
>@Override
>public Map getObject() {
>Map variables =
>new HashMap(1);
>variables.put("brand", getStyle());
>return variables;
>}
> };
> add(TextTemplateHeaderContributor.forCss(
>MyApplication.class, "skins/style.css", skinModel));
>
> The problem is that the substitution seems to fail and the someImage.jpg
> file is not drawn. Any ideas on what I am doing wrong?
>
> Thanks,
> Steve
> --
> View this message in context: 
> http://www.nabble.com/How-to-use-TextTemplateHeaderContributor.forCss-method--tp20411565p20411565.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]

Re: Moving from Tapestry to Wicket?

[Eelco Hillenius]

> Honestly in our application (we have a roadmap for scalability) we are
> likely to get several hundred concurrent sessions per server with a few kb
> of state stored in the HTTPSession. Its not that much.

That's definitively no problem for even a very modest setup.

> What I was more
> concerned about was Page storage and storage that I can't control (for
> example, if I couldn't control IModel storage I would be concerned).

Well, when using any framework that abstracts stuff for you, you'll
trade convenience for transparency. I believe Wicket's architecture is
very open and it is easy enough to customize how it works for what you
want, but the more you want to deviate from the default, the more work
it'll be. I think you should just build the darn thing and optimize
when you have proof (through load testing for instance) that you are
hitting a bottle neck. :-)

Do try to work with detachable models (LoadableDetachableModel is my
favorite) where you can, because that will save considerably
especially with complex domain models and avoid lazy loading problems
with frameworks like Hibernate.

> We are unlikely to have spikes of traffic, but we are more likely to have
> dribs and drabs of users who potentially keep sessions open for perhaps
> minutes to hours.

Not a problem at all.

> For our initial scaling the client will have an affinity to a specific
> server. We can control the number of users that we have on a server. We can
> then scale our servers horizontally if we hit a scaling issue on one of the
> servers. I'm starting not to worry about it too much.

Yeah, with just a few hundred users clustering won't be much of a
problem either. Once you start to hit tens of thousands of concurrent
sessions you have to take this stuff more seriously, but until then in
my experience you'll be tweaking your database and business logic etc
way before Wicket gets to be in the way :-)

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Background processing

[Eelco Hillenius]

> there is no point streaming huge amounts of data through wicket,
> servlets do a much better job.

Imho it's nice to have code in the same place, and I typically prefer
using e.g. shared resources over servlets. Both will do the job just
fine.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Moving from Tapestry to Wicket?

[Eelco Hillenius]

>> I have a complex table and many links on the page that are not
>> book-markable. Will that be a problem in terms of too much session
>> information?

The default session store in Wicket saves history in some temp files
and only holds the current page in memory (well, the current page of
any page map in case you use more). Say that's a very heavy page,
taking up to 100K. And say you run a VM with 1 GB of dedicated memory.
You can support close to 10,000 concurrent sessions (close, because
obviously, you'll use memory for other things than just sessions).
Changes are that you run into bottlenecks with processors and database
utilization long before you run out of memory for one box.

The only kind of web sites I probably wouldn't recommend Wicket as
used by default for are sites like Google, Yahoo and CNN etc, where
you can have enormous spikes in traffic that are very short lived.
But... the good news with Wicket then again is that you can build your
app entirely using bookmarkable pages (even stateless if you want, so
that you can avoid *any* memory usage) so that clustering will be easy
and cheap. On top of that, you can plug in your own implementations of
things like session store so that you can decide when/ how/ where
state should be kept.

You have to weigh the benefits of the stateful programming model
against your technical requirements. But you can use Wicket for most
use cases if you give it a bit of thought.

>> Would it be conceptually easy for me to write Javascript/AJAX and hook them 
>> into Wicket in a simple way?

Yeah, that's fairly simple. You can either write snippets that are
used by components/ behaviors that integrate with our regular AJAX
engine, or you can even plugin your own engine if you'd prefer that.

>> Its all about cost.

The funny thing is that in most discussions out there people focus on
the cost of servers/ memory/ etc. While probably for most people -
basically for anything that doesn't have the size of Google -
development and maintenance cost is often the highest component. So a
good development model makes sense.

>> we have absolute faith that it will have a lot of users according to our 
>> business plan.

May I ask what you think is a lot (say hits per second and concurrent
sessions)? Thousands? Tens of thousands? Hundred of thousands? Even
millions? If you're talking about really large numbers, you need to be
aware of the choices you make in your app, not only for Wicket
obviously, and test for scalability from the start. Though if you're
talking about thousands up to maybe a few thousands, Wicket should be
able to handle it fine without you having to worry about using
stateful components.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AbstractPageStore memory implementation instead of disk

[Eelco Hillenius]

> Ok, I think I get it :-) One more questionL if I would have sticky
> sessions, and no page back functionality, would I still need wicket to
> serialize?

Technically not, if you really don't need page back functionality (are
you sure you can enforce that?), than it would suffice to just have
the current page of any page maps you use in RAM. And you don't need a
background saving thread in that case either, so I think if you go
about it smart, you can store that page in your session, so that it
gets send over the cluster if you want with not a lot of
configuration. Anyway, make sure that your assumptions about not
having to support the back button are correct.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Wicket critique

[Eelco Hillenius]

The author of the question actually did a project in Wicket (thoof),
so he must be for even more improvements :-)

Eelco

On Tue, Sep 23, 2008 at 1:44 AM, Yiannis Mavroukakis
<[EMAIL PROTECTED]> wrote:
> http://stackoverflow.com/questions/116978/can-anyone-recommend-a-simple-java-web-app-framework
>
> Anyone interested in replying to this?
>
> -
> 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]

Re: job postings

[Eelco Hillenius]

> Speaking of which, we're looking for a colleague... New Yorkers, look
> here: http://newyork.craigslist.org/mnh/sof/846161277.html

And while we are looking for people who live in/ near New York, we
*might* be interested in other US people, particularly from Seattle.
Feel free to drop me a line :-)

Cheers,

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: job postings

[Eelco Hillenius]

> we encourage wicket related job postings on this list and i think that's
> great.

Speaking of which, we're looking for a colleague... New Yorkers, look
here: http://newyork.craigslist.org/mnh/sof/846161277.html

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Java BlackBelt Wicket exam

[Eelco Hillenius]

:-)

On Sun, Sep 21, 2008 at 6:08 AM, Leon Nieuwoudt
<[EMAIL PROTECTED]> wrote:
> For black belt, one of the questions must be to identify Martin, Eelco, Nino
> and Igor from a police line-up.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]