igor.vaynb...@gmail.com
wrote:
On Thu, May 30, 2013 at 12:37 PM, tetsuo <ronald.tet...@gmail.com>
wrote:
-1000!
This will be horrible! Even with the current API, most generics I
have
to
declare in my code don't add anything to type safety. For example:
while i am also not a fan of having component generified i do believe
the example below is a bit contrived.
first, i hope most people do not use PropertyModels because they are
not compile-time-safe. there are plenty of project that implement
compile-time-safe models, personally i prefer
https://github.com/42Lines/****metagen<https://github.com/42Lines/**metagen>
<https://github.com/**42Lines/metagen<https://github.com/42Lines/metagen>>to
using proxy-based solutions.
further, i hope even less people use compound property models. they
are even more unsafe then property models and make your code even
more
fragile. i would hate to refactor code that uses CPMs.
add(new Form<Person>("form", new CompoundPropertyModel<Person>(
****
new
PropertyModel<Person>(this, "person")))
.add(new TextField<String>("name"))
.add(new TextField<Integer>("age"))
.add(new TextField<Double>("salary"))
.add(new Button("save", new
PropertyModel<Person>(this,"****person")){
public void onSubmit() {
repository.save((Person)****getForm().****
getDefaultModelObject());
}
});
In my experience, this kind of code is fairly common in Wicket
applications. Every form component must be declared with a type, but
none
has *any* kind of type safety gain.
but how often do you declare a form component without adding any
validators to it? the generic type of component also makes sure you
add the correct validator. for example it wont let you add a
validator
that expects strings to a component that produces integers.
also, not sure why you are replicating the model in Button. first,
the
Button uses its model to fill its label; secondly, in real code the
model would be in a final var or field that things like onsubmit can
access easily.
-igor
- The property model uses reflection, so its type can't be verified
by
the
compiler (this.person could be anything, not just a Person).
- Generics will guarantee that the form model will be of type
Person,
but
since it's all declared inline, and the real model isn't verifiable,
it
just adds lots of verbosity without any real gain.
- Most form components use the implicit model, that also uses
reflection,
and also can't verify the actual type of the underlying property, at
compilation time. Even in runtime, *the type information is lost due
erasure
*, so it can't use it to do any additional verification.
*- Worse, you can even declare the "name" TextField as <Integer> or
<Double> (while maintaining the 'text' attribute as String), and
since
there is no type information at runtime, it doesn't matter. It won't
even
throw an exception (it will just work normally).* In this case, the
type
declaration is simply a lie.
Just pain, no gain. In my code, I sometimes just add a
@SuppressWarnings(
"rawtypes") to the class, and remove all useless generic type
declarations.
If everything will be required to declare them, I will have do it
more
frequently.
That said, repeater components benefit greatly from generics. So do
custom
models, validators, and converters. Or the rare cases that we
explicitly
declare the form component model. But forcing everything to be
generic-typed will just make Wicket extremely verbose to use, with
very
little benefit.
On Thu, May 30, 2013 at 4:00 AM, Martin Grigorov <
mgrigo...@apache.org
wrote:
Hi,
I just pushed some initial work for [1] and [2] in
branch generified-component-4930.
So far it doesn't look nice.
The added generics break somehow setMetaData/getMetaData methods -
you
can
see compilation errors in Component and Page classes. I think it is
caused
by the anonymous instance of MetaDataKey ( new MetaDataKey<T>(type)
{}
).
Also the visit*** methods do not compile at the moment, but even if
we
find
a way to fix their signature I think writing a visitor will become
quite
cumbersome.
At the moment we have IVisitor
and org.apache.wicket.util.****iterator.****
AbstractHierarchyIterator
which
do
the
same job. The Iterator API is supposed to be simpler to write for
the
users. Maybe we can drop IVisitor ... ?!
I'd like to ask for help with this task. It is supposed to be the
biggest
API break for Wicket 7.0. My current feeling is that the end result
won't
be very pleasant for the user-land code.
For example the application code will have to do something like:
WebMarkupContainer<Void> wmc = new WebMarkupContainer<>("id")
It is not that much but we have to decide whether we want it.
But first let's try to fix the compilation problems.
1.
https://issues.apache.org/****jira/browse/WICKET-4930<https://issues.apache.org/**jira/browse/WICKET-4930>
<https:**//issues.apache.org/jira/**browse/WICKET-4930<https://issues.apache.org/jira/browse/WICKET-4930>>(Add
generics
to
o.a.w.Component)
2.
https://cwiki.apache.org/****confluence/display/WICKET/**<https://cwiki.apache.org/**confluence/display/WICKET/**>
Wicket+7.0+Roadmap#Wicket7.****0Roadmap-Genericsfororg.**
