Either way, you have to put logic somewhere that tries to figure out
what the heck you want to borrow and then figure out where the heck to
get it.
If it is done at compile time you don't need messaging logic. It
would be uniquely defined what you can get.
Please explain.
Think about
i really like this. lets commit it. a couple of notes below:
assocatedmarkupsourcingstrategy.oncomponenttag() may have a problem.
looks like its assuming external markup files begin with wicket:xxx
tag, but they may begin with
html xmlns:wicket
wicket:panel
is the html tag stripped before this
Since we provide AbstractRequestWrapperFactory shouldnt it be plugged
into wicketfilter somewhere? right now it seems a bit strange that it
and its friends are so isolated.
-igor
2 - If you want to use Wicket *in Scala*, work on a transparent layer that
sits on top of stock Wicket and adds nice features that would be useful to
the Scala crowd.
I'm already writing all my personal Wicket in Scala. Works well.
On Sun, Jan 9, 2011 at 2:16 PM, Jeremy Thomerson
Biggest thing I miss in IntelliJ when coding Scala (I write Wicket in Java
for my dayjob) is my autocompletion of types. In Java you can type in
IModelString foo = new and hit Ctrl + shift + space and it'll provide a
list of all types that subclass IModel, but for the time being (IntelliJ
10,
I had that idea as well. My initial commit actually included such a
hook. But I removed it again. Though wrappers are registered with
filters/servlets in the servlet world, wicket already provides a very
very easy way by subclassung Application.newRequestxx().
IMO the problem is, and here I agree
what bothers me is that there are isenabled(), supports() methods but
nothing that really makes use of them. We can provide a
FilterFactoryManager class where users can add filters and it can have
a simple Request wrap(Request) method that takes care of isenabled()
and supports(). or, we simply
