...
create
...
interface
...
generation
...
for
...
.html
...
markup
...
files
...
in
...
order
...
to
...
ensure
...
validity
...
of
...
wicket:ids.
| Code Block |
|---|
public HelloWorld() { add(new Label("message", "Hello World!")); } |
The
...
wicket:id
...
list
...
is
...
known
...
at
...
compile
...
time
...
for
...
every
...
.html.
...
The
...
java
...
code
...
could
...
have
...
been
...
safer:
| Code Block |
|---|
public HelloWorld() implements HelloWorldHtml { add(new Label(MESSAGE, "Hello World!")); } |
Constant
...
MESSAGE
...
might
...
have
...
been
...
defined
...
in
...
the
...
interface
...
extracted
...
from
...
HelloWorld.html.
...
create
...
abstraction
...
for
...
content
...
types
...
currently,
...
wicket
...
has
...
a
...
concept
...
of
...
"markup
...
type"
...
that
...
is
...
actually
...
the
...
markup
...
extension.
...
in
...
doing
...
work
...
on
...
wml
...
support
...
for
...
"mobile
...
wicket",
...
i'm
...
discovering
...
a
...
need
...
for
...
full
...
mime
...
type
...
support.
...
if
...
it
...
doesn't
...
break
...
too
...
many
...
people,
...
it
...
would
...
ideally
...
be
...
best
...
to
...
introduce
...
a
...
formal
...
MarkupType
...
class
...
with
...
a
...
getExtension()
...
and
...
getContentType(),
...
where
...
ContentType
...
includes
...
mime
...
type
...
information.
...
there
...
quite
...
a
...
bit
...
to
...
think
...
through
...
here
...
in
...
terms
...
of
...
request/response
...
markup
...
type
...
mappings,
...
but
...
i'd
...
be
...
up
...
for
...
working
...
on
...
this.
...
this
...
problem
...
is
...
definitely
...
generic
...
to
...
problems
...
outside
...
mobile
...
wicket.
...
– jonathan
multiply child/extend
...
inheritance
...
https://issues.apache.org/jira/browse/WICKET-1134
improve ajax support of javascript
i still think we should be doing something more object oriented in terms of composing javascript for ajax purposes. i'd like to see us adopt something like that JavaScript class i was promoting a while back. one thing that occurs to me today is that not only could you easily compose javascript this way, but there might be a whole host of reusable javascript behaviors we could all leverage. for example, instead of having bits of javascript code hacked into strings all over projects to accomplish deletion confirmation on link/button clicks, we could have ConfirmJavaScript extends JavaScript and take care of the gory details in there (string resources for localization, whatever). as hunks of javascript get more complex and prevalent, creating this abstraction could really serve us nicely as a community. i personally would have loved to reuse things like FadeComponentJavaScript or DisableComponentJavaScript. the subclasses will all take a lot of work to create, but let's make an abstraction for JS code so we can do this work at all. – jonathan
A few advantages to making our javascript more OO:
- conform to Yahoo recommendations on page rendering performance by putting javascript just before </body>
- more component oriented development through object literals (JSON)
- separate javascript from markup
| Code Block |
|---|
] h5. improve ajax support of javascript i still think we should be doing something more object oriented in terms of composing javascript for ajax purposes. i'd like to see us adopt something like that JavaScript class i was promoting a while back. one thing that occurs to me today is that not only could you easily compose javascript this way, but there might be a whole host of reusable javascript behaviors we could all leverage. for example, instead of having bits of javascript code hacked into strings all over projects to accomplish deletion confirmation on link/button clicks, we could have ConfirmJavaScript extends JavaScript and take care of the gory details in there (string resources for localization, whatever). as hunks of javascript get more complex and prevalent, creating this abstraction could really serve us nicely as a community. i personally would have loved to reuse things like FadeComponentJavaScript or DisableComponentJavaScript. the subclasses will all take a lot of work to create, but let's make an abstraction for JS code so we can do this work at all. -- jonathan A few advantages to making our javascript more OO: * conform to Yahoo recommendations on page rendering performance by putting javascript just before </body> * more component oriented development through object literals (JSON) * separate javascript from markup {code} ListView users = new ListView("users", usersModel); users.setOutputMarkupId(true); Event e = new ClickEvent("a[class=deleteLink]"); // DomQuery-esque selector (http://extjs.com/learn/Tutorial:DomQuery_v1.1_Basics)... selector could be turned into a Builder object instead of string e.addHandler(new ConfirmDialog("Are you sure you want to delete?")); users.addEvent(e); // can be shortened to new ClickEvent("...", new ConfirmDialog("...")) {code} |
serializes
...
to:
| Code Block |
|---|
} { element: "{usersMarkupId}:", // generated by Component events: [ { event: "click", [ // generated by ClickEvent { selector: "a[class=deleteLink]", handlers: [ function() { // generated by ConfirmDialog if(confirm("Are you sure you want to delete?") { // Wicket.ajax... } } ] } ] } ] } {code} |
Wrap
...
the
...
above
...
in
...
an
...
'ondomready'
...
event
...
and
...
we
...
have
...
unobtrusive
...
javascript
...
that
...
should
...
be
...
easier
...
to
...
abstract
...
going
...
forward.
...
– brian
New Inspectors
Add inspector to look for empty src=""
...
attrs
...
which
...
cause
...
extra
...
requests
...
to
...
the
...
server
...
Remove
...
Change
...
and
...
possibly
...
VersionManager
...
no
...
longer
...
needed
...
since
...
we
...
serialize
...
the
...
entire
...
page.
...
Downside
...
-
...
makes
...
HttpSessionStore
...
not
...
as
...
space
...
efficient
...
(possibly
...
move
...
these
...
implementation
...
details
...
down
...
into
...
the
...
session
...
store
...
package?
...
-
...
jonathan)
...
(this
...
is
...
already
...
pushed
...
to
...
the
...
store
...
package
...
i
...
guess,
...
version
...
manager
...
and
...
pagemap
...
are
...
created
...
by
...
the
...
httpsession
...
store
...
already,
...
the
...
problem
...
with
...
removing
...
this
...
is
...
that
...
it
...
will
...
break
...
all
...
stuff
...
that
...
cant
...
depend
...
on
...
the
...
file
...
based
...
store
...
are
...
really
...
need
...
to
...
be
...
in
...
mem,
...
the
...
disk
...
based
...
store
...
already
...
doesn't
...
do
...
anything
...
with
...
Change
...
and
...
also
...
the
...
version
...
manager,
...
it
...
only
...
uses
...
the
...
version
...
number
...
from
...
the
...
vm,
...
johan)
...
Cleanup
...
component
...
visibility
...
Currently
...
we
...
have
...
Component.set/isVisible,
...
Component.isRenderAllowed,
...
Component.set/isVisibilityAllowed
...
The
...
reason
...
for
...
Component.set/isVisible
...
is
...
simply
...
-
...
allow
...
users
...
to
...
control
...
visibility
...
of
...
their
...
component
...
The
...
reason
...
for
...
Component.isRenderAllowed
...
is
...
for
...
security
...
strategy
...
to
...
be
...
able
...
to
...
force
...
component
...
to
...
be
...
invisible
...
Now
...
if
...
i
...
am
...
a
...
user
...
and
...
want
...
to
...
test
...
if
...
the
...
component
...
will
...
be
...
rendered
...
or
...
not
...
I
...
need
...
to
...
do
| Code Block |
|---|
} boolean visible=component.isVisible()&&component.isRenderAllowed() {code} |
This
...
is
...
ugly
...
as
...
I
...
have
...
to
...
remember
...
both
...
checks
...
all
...
the
...
time.
...
Because
...
of
...
this
...
I
...
have
...
introduced
...
Component.determineVisibility()
...
in
...
1.3.3
...
which
...
encapsulates
...
all
...
necessary
...
checks.
...
Now,
...
what
...
if
...
I
...
want
...
to
...
write
...
a
...
component
...
that
...
controls
...
visibility
...
of
...
its
...
children
...
or
...
other
...
components.
...
It
...
can
...
call
...
child.setVisible(false),
...
but
...
that
...
is
...
not
...
guaranteed
...
to
...
work
...
because
...
the
...
child
...
might
...
have
...
its
...
isVisible()
...
overridden
...
and
...
thus
...
any
...
call
...
to
...
setVisible()
...
will
...
be
...
ignored.
...
For
...
this
...
reason
...
I
...
have
...
introduced
...
Component.set/isVisibilityAllowed()
...
in
...
1.3.3.
...
Both
...
setter
...
and
...
getter
...
are
...
final
...
so
...
it
...
is
...
impossible
...
for
...
the
...
user
...
to
...
break
...
the
...
contract.
...
So
...
now
...
to
...
check
...
for
...
visibility
...
I
...
need
...
to
...
call
...
component.determineVisibility()
...
which
...
is
...
very
...
kludgy.
...
I
...
also
...
have
...
two
...
sets
...
of
...
getters
...
and
...
setters
...
that
...
seemingly
...
control
...
visibility.
...
Bad.
...
I
...
think
...
we
...
should
...
rename/refactor
...
some
...
of
...
this
...
to
...
make
...
it
...
cleaner.
...
The
...
best
...
solution
...
would
...
be
...
to
...
have
...
isVisible()
...
be
...
final
...
and
...
equivalent
...
of
...
what
...
determineVisibility()
...
does
...
now
...
because
...
that
...
is
...
the
...
most
...
natural
...
way
...
to
...
query
...
a
...
component
...
for
...
its
...
visibility.
...
Also
...
whatever
...
the
...
equivalent
...
of
...
current
...
isVisible
...
ends
...
up
...
being
...
(
...
an
...
overridable
...
getter)
...
it
...
should
...
not
...
have
...
a
...
setter.
...
Remove
...
PageMap
...
PageMap
...
is
...
a
...
misnomer
...
and
...
isnt
...
really
...
needed
...
anymore
...
-
...
not
...
with
...
second
...
level
...
session
...
store
...
around.
...
(again,
...
move
...
into
...
httpsessionstore
...
package
...
for
...
backwards
...
compat?)
...
(see
...
above
...
points,
...
johan)
...
Transparent clustering support out of the box and enabled by default
Coming in Wicket 1.3.1
...
...
Window scope
this will basically replace PageMap and allow users to store per browser tab/window attributes
JDK-1.5
...
support
...
- Generify
...
- models
...
- Annotation
...
- for
...
- mounting
...
- a
...
- bookmarkable
...
- page
...
- -
...
- done
...
- in
...
...
- Use varargs, for instance (a bad example) MarkupContainer#add(Component)
...
- ->
...
- MarkupContainer#add(Component...)
...
- Take
...
- advantage
...
- of
...
- new
...
- classes
...
- (java.util.concurrent,
...
- LinkedHashMap
...
- that
...
- can
...
- be
...
- used
...
- as
...
- an
...
- LRUMap,
...
- etc)
...
- to
...
- remove
...
- some
...
- of
...
- the
...
- wicket.util
...
- classes
...
Make
...
WicketTester
...
a
...
first
...
class
...
citizen
...
Currently
...
WicketTester
...
is
...
one
...
of
...
the
...
less
...
mature
...
parts
...
of
...
the
...
core
...
project.
...
It
...
really
...
is
...
useful
...
and
...
great,
...
but
...
the
...
API
...
is
...
not
...
thought
...
through
...
and
...
there
...
are
...
lots
...
of
...
areas
...
you
...
still
...
can't
...
test.
...
Migrating
...
the
...
API
...
to
...
a
...
Junit
...
4.4
...
+
...
...
style
...
of
...
programming
...
would
...
be
...
a
...
very
...
nice
...
addition.
...
IDataProvider#size()
...
should
...
return
...
long
...
The
...
JPA
...
spec
...
has
...
count
...
queries
...
return
...
long
...
instead
...
of
...
int.
...
This
...
change
...
has
...
been
...
attempted
...
earlier,
...
and
...
it
...
was
...
not
...
found
...
to
...
be
...
trivial.
...
It
...
is
...
also
...
a
...
major
...
break
...
in
...
API
...
so
...
we
...
need
...
to
...
consider
...
this
...
carefully.
...
Rewrite
...
repeaters
...
to
...
make
...
it
...
easier
...
to
...
work
...
with
...
- boundless
...
- datasets
...
- unknown
...
- size
...
- or
...
- too
...
- expensive
...
- to
...
- calculate
...
- every
...
- request
...
- provide
...
- pager
...
- with
...
- first/pref/next
...
- only?
...
- data
...
- stores
...
- that
...
- return
...
- count
...
- and
...
- window
...
- at
...
- the
...
- same
...
- time
...
- need
...
- to
...
- know
...
- the
...
- window
...
- boundaries
...
- without
...
- querying
...
- the
...
- size
...
- first
...
- (no
...
- culling? fallback?)
(see WICKET-1784
...
)
...
Take
...
a
...
good
...
look
...
at
...
PagingNavigator
...
and
...
AjaxPagingNavigator
...
The
...
PagingNavigator
...
has
...
been
...
with
...
us
...
since
...
1.0
...
and
...
might
...
need
...
some
...
cleaning
...
up.
...
Replace
...
ImageMap
...
with
...
a
...
better
...
one
...
The
...
ImageMap
...
has
...
been
...
with
...
us
...
since
...
1.0
...
and
...
might
...
need
...
some
...
cleaning
...
up.
...
...
:
...
rewrite
...
existing
...
ImageMap
...
or
...
create
...
a
...
new
...
one?
...
Establish
...
Wicket
...
Security
...
strategies
...
sub
...
project
...
- Make
...
- Swarm
...
- part
...
- of
...
- wicket
...
- core
...
- -
...
- Giving
...
- users
...
- easier
...
- access
...
- to
...
- a
...
- security
...
- framework.
...
- Move
...
- auth-roles
...
- into
...
- sub
...
- project
...
Improve
...
Tree
...
model
...
the
...
tree
...
can
...
use
...
a
...
more
...
web-friendly
...
model
...
then
...
swing's
...
tree
...
model
Add Rapid Prototyping Forms
The Idea of Alistair Maw and Jonathan Locke (ROR? No. Wicket on Wheels.) should be included in next Wicket. A set of nice looking Defaultformcomponents and a Beanresolver to automatically let create forms from just the plain bean but still allow to customize it later by overiding parts of it. Beside nice looking (to show/ even may go live with it in first place) and fast it should have enabled possibility to integrate security on a Form as well as Field-level.
See Wicket Web Beans.
Clean up/ Have a look at Models
With now having a CompoundPropertyModel that has the same abilities as BoundCompundPropertyModel it might be nice to have someone overwork all models and decide if we really need all. Stiping out/ Migrating ino one e.g.: BoundCompoundProperty and CompoundProperty model as well as others (if possible) would really ease wicket for beginners as well as save experienced users some thoughts about what model to use.
Already done in 1.3, there is not much that needs to be improved other than apply generics.
Postprocessing Response
Can be interesting for me have a feature (configurable in application) that apply a xsl postprocessig for each response. Now i can use a Border o XslBehaivor to have same feature but is not transparent for page.
see IResponseFilter
Package Level Properties / resources
done in 1.4, looks for package.properties, see PackageStringResourceLoader
Add support for SSL pages/components out-of-the-box
The wiki describes a nice way (though still diamond in the rough) to switch from/to SSL connections using an annotation. This could/should go into core.
Add possibility to use interface implementation instead of extending Panel
Allow components (for example formComponents) have their own markup without the need to extend Panel. The change should not change/brake any existing stuff, only add additional possibility how to solve some problems easier then currently. For example instead of wrapping TextField in Panel just subclass the TextField and implement the given interface.
Mounting with "nicer URLs"
Ability to mount page so it will have one instance per session which will be always accessable by mounted URL.
Normalize page URLs
so when user hits a page /my/page/a/b/c////
...
redirect
...
immediately
...
to
...
/my/page/a/b/c
...
Improve
...
url
...
generation
...
Instead
...
of
...
urlFor
...
returning
...
a
...
CharSequence
...
it
...
should
...
return
...
a
...
UrlBuilder
...
that
...
contains
...
methods
...
to
...
append
...
parameters
...
and
...
would
...
encode
...
them
...
automatically.
...
The
...
problem
...
currently
...
this:
...
suppose
...
you
...
want
...
to
...
generate
...
a
...
callback,
...
it
...
should
...
be
...
pretty
...
simple:
| Code Block |
|---|
} String url=urlfor(ilinklistener.interface)+"&myparam="+value; {code} |
However,
...
if
...
the
...
page
...
is
...
bookmarkable+stateless
...
the
...
encoding
...
is
...
different
...
-
...
/param/value/
...
by
...
default
...
or
...
whatever
...
the
...
coding
...
strategy
...
is,
...
so
...
simply
...
doing
...
+"&myparam="+value
...
will
...
not
...
work.
...
Investigate
...
JDK-7
...
properties
...
support/libraries
...
Java
...
properties
...
are
...
probably
...
something
...
we
...
will
...
have
...
to
...
deal
...
with
...
sooner
...
or
...
later.
...
We
...
should
...
try
...
to
...
look
...
at
...
what
...
is
...
proposed,
...
and
...
what
...
is
...
readily
...
available.
...
The
...
following
...
blogs
...
have
...
links
...
to
...
sources:
...
...
...
Portlet 2.0
...
(jsr
...
286)
...
Support
...
jsr
...
286
...
portlet
...
specification:
...
...
Previous page / Back button support
Using the pagemap isn't
...
very
...
elegant
...
and
...
passing
...
in
...
the
...
current
...
page
...
isn't
...
always
...
convenient.
...
Make Validators more flexible
- let validators be a behavior to contribute to the markup (eg. maxlength attribute for <input>)
- let validators use IModel instead/in addition to fixed values
Make JavascriptStripper more flexible
Currently, stripping of comments and whitespaces is implemented as static method. Therefore, the default implementation cannot be extended (e.g. with an implementation that strips Firebug's logging, i.e. console.log(),
...
consoloe.debug(),
...
...)
...
or
...
replaced
...
(e.g.
...
by
...
a
...
JS
...
compressor
...
like
...
http://developer.yahoo.com/yui/compressor/
).
...