What existing classes could be substituted by guava classes?
I don't think it would be sensible to replace 3 or 4 classes with a
2-million-byte library :)
“The truth is rarely pure and never simple.” ― Oscar Wilde
On Sun, Jul 13, 2014 at 2:13 PM, Garret Wilson gar...@globalmentor.com wrote:
much fun it would be to do the same with JSF's
render kits or Swing`s LaFs :)
Tetsuo
“The truth is rarely pure and never simple.” ― Oscar Wilde
On Thu, Jul 10, 2014 at 9:49 PM, John Sarman johnsar...@gmail.com wrote:
Garrett,
Since Wicket is open source, why not create the desired patch
of the bug at Oracle ? Just for reference
Martin Grigorov
Wicket Training and Consulting
On Fri, May 23, 2014 at 11:48 PM, tetsuo ronald.tet...@gmail.com wrote:
Never mind, Eclipse bug (sigh)
“The truth is rarely pure and never simple.” ― Oscar Wilde
On Fri, May 23, 2014 at 4:38 PM, tetsuo
I'm using Java 8 lambdas with Wicket, and they make it really simple
to have almost 100% type-safe code, without the verbosity of anonymous
inner classes. With a few adapter classes and interfaces, it was
relatively easy to integrate them.
But I'm having some non-trivial problems with
Never mind, Eclipse bug (sigh)
“The truth is rarely pure and never simple.” ― Oscar Wilde
On Fri, May 23, 2014 at 4:38 PM, tetsuo ronald.tet...@gmail.com wrote:
I'm using Java 8 lambdas with Wicket, and they make it really simple
to have almost 100% type-safe code, without the verbosity
Since it's the same request, isn't (or couldn't be) the db connection the
same in size() and iterator() calls? If you created the temporary table in
one, isn't it still available to the other (so you could avoid recreating
it)?
“The truth is rarely pure and never simple.” ― Oscar Wilde
On Tue,
the list
twice.
On Tue, May 6, 2014 at 8:06 PM, tetsuo ronald.tet...@gmail.com wrote:
Since it's the same request, isn't (or couldn't be) the db connection the
same in size() and iterator() calls? If you created the temporary table
in
one, isn't it still available to the other (so you could avoid
But I guess most of the time you have an empty list you want to hide not
only the list, but also some markup around it (thus the use of an
enclosure), so just changing the HTML generated by the empty list would not
be enough.
I think the ListView should be invisible when empty. Besides that, the
+1 for keeping IChoiceRenderer.
I often create Enums with a single value when I want a singleton (the JVM
guarantees the single instance, and it takes less space in memory and when
serialized), and many of my custom choice renderers are like this. I can't
do this if it is not an interface.
value.
Martin Grigorov
Wicket Training and Consulting
On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet guillaume.s...@gmail.com
wrote:
On Wed, Feb 26, 2014 at 4:33 PM, tetsuo ronald.tet...@gmail.com wrote:
Because... it's an unnecessary breaking change?
From what I understand of your
at 6:21 PM, tetsuo ronald.tet...@gmail.com wrote:
Guillaume, you're right.
Martin, sorry for the misunderstanding.
Enums can't extend any classes besides Enum. But can implement
interfaces.
Thanks! Now it is clear to me.
I use Enums in lots of places, not as enums
Making 'void' methods return 'this' doesn't prevent you to write each call
in a new line. But gives others the choice to call it inline.
It could be a problem if Wicket's internal code used chaining extensively,
but I find it very convenient to chain calls, specially when building the
component
I think it isn't even an Wicket issue. I don't think the servlet spec
guarantees the thread-safety of the http session (
http://stackoverflow.com/a/616723/176897). Even if it does, it will be
between request threads. It would be very, very, unlikely that it would
mandate that the session should
no magic (or the option of no magic) +1
On Mon, Aug 26, 2013 at 3:41 AM, Michael Mosmann mich...@mosmann.de wrote:
Am 23.08.13 00:16, schrieb Martijn Dashorst:
On Thu, Aug 22, 2013 at 11:42 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
On Thu, Aug 22, 2013 at 2:04 PM, Martijn
About changing parameters on stateful pages, one comment: one thing that
makes Wicket secure by default is exactly the fact that you get the
parameters when you create a page, and everything after is made by
interacting with components (which don't process values if disabled,
invisible, or
I use JRebel (I've bought it when a perpetual license was still available),
and it works great. If you use Scala, or do non-commercial development,
it's free.
But just using Jetty already saves you lots of time, since restarting the
whole server takes milliseconds. Wicket and Spring are pretty
What about moving this functionality directly into MarkupContainer, so that
there's no need for an additional 'magic' component? Would it be feasible?
On Tue, Jun 18, 2013 at 9:37 AM, Nick Pratt nbpr...@gmail.com wrote:
-1 to deprecate. Same reasons as Igor stated.
On Mon, Jun 17, 2013 at
... :)
Could Generics.getClass(type) be changed to not throw
IllegalArgumentException when it can't resolve the class? Maybe return null
and let callers deal with it?
On Fri, Jun 14, 2013 at 2:52 AM, Sven Meier s...@meiers.net wrote:
Hi Tetsuo,
I stand corrected:
For #getObjectClass
I can make the change and send a pull request, but will it have a chance to
be accepted? :)
On Fri, Jun 14, 2013 at 4:18 PM, tetsuo ronald.tet...@gmail.com wrote:
This change kind of works (I had to change getPath() too), but then for
every component I use LazyModel this way (every textfield
On 06/13/2013 09:35 PM, tetsuo wrote:
wait, wait, do you actually do something like
new TextFieldString(name, new IModelString(){
public String getObject() {
return entity.getName();
}
public void setObject(String value) {
entity.setName(value
() {
LazyModelB model = model(from(A.class).getB());
final A a = new A();
a.b = new B();
assertEquals(a.b, model.bind(Model.of(a)).**getObject());
}
Sven
On 06/13/2013 10:23 PM, tetsuo wrote:
Thanks for the response!
If I use an object instance
I made the changes to make it work, added a test case, and sent a pull
request on github.
Now it works when you create an unbound model from a class, and then bind
it to a plain model.
On Thu, Jun 13, 2013 at 6:39 PM, tetsuo ronald.tet...@gmail.com wrote:
Well, you were the one who said
-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:
add(new FormPerson(form, new CompoundPropertyModelPerson(new
PropertyModelPerson(this, person)))
.add(new TextFieldString(name))
Just not by default, please.
On Mon, May 27, 2013 at 6:32 PM, Sebastien seb...@gmail.com wrote:
Hi Martin,
About the dynamic calculation, can't it be made according to an
IApplicationSettings or an IJavaScriptLibrarySettings flag? Maybe could
this flag be false by default and the user may
No, parleys is not free. Some talks are, but most aren't.
On Thu, Apr 4, 2013 at 8:11 AM, Martin Grigorov mgrigo...@apache.orgwrote:
Am I using parleys.com wrongly or it is not exactly free ?
It allows me to watch the first N minutes and then asks me to pay an annual
fee to be able to watch
Well, it was the last time I looked into it. Now, the 'pricing' page says
it's free for viewers...
On Thu, Apr 4, 2013 at 8:53 AM, tetsuo ronald.tet...@gmail.com wrote:
No, parleys is not free. Some talks are, but most aren't.
On Thu, Apr 4, 2013 at 8:11 AM, Martin Grigorov mgrigo
You don't have a servlet-mapping?
On Mon, Feb 25, 2013 at 9:30 AM, David Torres david.tor...@renuda.com wrote:
Hello list.
My name is David, and I started recently to develop tools for Sakai. We
decided to use Wicket and we are happy with that.
The problem is that we started from a existent
Portlet support was dropped in 1.5...
On Mon, Feb 25, 2013 at 1:11 PM, David Torres david.tor...@renuda.com wrote:
I would like to try that, but then I would need to use url-pattern, and
the URL of my tool is this
Isolating Servlet dependencies could potentially ease portlet support, too.
It won't be an easy task, though. Some of the main classes of the
framework, like WicketFilter, are deeply coupled to the Servlet API.
But I'm not sure if the benefits out-weight the cost of doing the changes
and
for at the beginning of a project-lifecycle
just my 2 cents
Am 13.12.2012 20:33, schrieb tetsuo:
What about home-baking or incorporating (if donated, obviously) a
library that integrates jquery-ui components into an official
wicket-jqueryui or wicket-widgets project?
When I'm trying to sell
Wicket already uses jquery for its ajax support. A jquery-ui module
(thus the dependency to jquery-ui.js) would be completely optional, as
is the embedded yui library currently used by wicket-extensions.
On Thu, Dec 13, 2012 at 8:29 PM, Michael Haitz michael.ha...@1und1.de wrote:
I think
() instanceof
XXX)' will break (since it will return the wrapper), but this edge
case will work.
On Thu, Sep 27, 2012 at 7:18 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
On Thu, Sep 27, 2012 at 3:33 PM, tetsuo ronald.tet...@gmail.com wrote:
What about calling APanel.setDefaultModelObject
If the code doesn't require it, why add it artificially?
Is there any planned feature that may potentially require it?
On Wed, Aug 22, 2012 at 5:35 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
http://s.apache.org/wicket-servlet3-discuss
It has been proposed a couple of times for
-1 RCx should only be used if you are pretty sure it could be released,
since it means *Release* Candidate.
On Fri, May 4, 2012 at 9:53 AM, Martijn Dashorst martijn.dasho...@gmail.com
wrote:
I would opt for a beta2. IMO we should not make release candidates
available for wider use, but
The new annotations don't add much for framework developers, they just
replace the web.xml file, in a hard-to-maintain fashion.
Asynchronous servlets, in the other hand, are a nice addition to the
platform, but unless the atmosphere module absolutely requires special
support from wicket-core, and
Using 3.0 in a module might prove to be quite difficult. The main problem is
that they changed the artifactId from servlet-api to javax.servlet-api. This
makes it impossible to simple set a dependency management, you need to exclude
the dependencies on servlet 2.5.
I think you need to do this
I think it should be an optional add-on (if included in the library at
all), so that core/extensions components won't rely on it, and
application developers may use it if they want the convenience. It is
just a convenience, after all.
If it is enabled by default, it may cause really weird,
What about one (or more) separate apache-hosted repository for
experimental projects? Maybe completely separate, maybe a clone just
to host the experimental branches. This would
- keep the main repository cleaner
- ease experimentation, since there will be no subconscious fear of
committing junk
Apache has policies that try to keep legal issues (IP ownership,
copyright, licensing, patents) in check. I don't know the specifics,
but I think any 'big' chunk of contributed code must be checked before
accepted. But, if the incremental development is all done on Apache
infrastructure, by
Well, I still don't see a good reason to require anything beyond Java 5 :)
On Thu, Feb 16, 2012 at 2:12 PM, Johan Compagner jcompag...@gmail.com wrote:
Stick for now to Java 6
or does somebody really has good reason (api or feature that he wants to
use) to go to Java 7?
I think java 7
, it won't be consistent with the 'ISomething' convention, but
this change probably won't break almost any application code besides
internal hooks someone dares to override in the WebApplication class.
My 2 cents.
Tetsuo
On Tue, Jan 10, 2012 at 7:55 AM, Martin Grigorov mgrigo...@apache.org wrote
Oh, or just remove the 'final' from the methods! (I can suggest a
number of other cases it could also be done)
On Wed, Jan 11, 2012 at 8:32 PM, tetsuo ronald.tet...@gmail.com wrote:
No, please not another breaking change just for the sake of it.
It's cheap to rename things that exist in your
(unless enhance the panel to display it properly, of
course).
Tetsuo
On Tue, Jan 10, 2012 at 1:47 PM, Bertrand Guay-Paquet
ber...@step.polymtl.ca wrote:
I don't fully understand the blog post about the security problems. From
what
I can see, you need to be able to render a mallicious script
I don't think JSON would bring any benefit, and it could cause a
number of security issues.
http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html
On Mon, Jan 9, 2012 at 12:22 PM, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
Are we interested in
This (nested first) is the behavior for 1.5.
In 1.4, you could override the 'Form.delegateSubmit()' method,
rewriting its logic to execute forms in reverse order, **IF**
'Form.onSubmit()' wasn't protected (thus, you can't call it on nested
forms from your form subclass).
You can, however, use
), but it has always worked brilliantly for me.
But it's definitely not broken.
Am 19.09.11 19:20, schrieb tetsuo:
What is so broken about the current ajax in Wicket, that requires such
rewrite?
What is so broken about the current ajax in Wicket, that requires such
rewrite?
On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
staged approach is fine, however its step 2 only that will cause
migration headaches, so this is just delaying the inevitable...
AM, tetsuo ronald.tet...@gmail.com wrote:
What is so broken about the current ajax in Wicket, that requires such
rewrite?
On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
staged approach is fine, however its step 2 only that will cause
migration
In short term removing final from method signatures would allow to
mock it for tests and return customized impl from
org.apache.wicket.protocol.http.WebApplication.getAjaxRequestTargetProvider().
setAjaxRequestTargetProvider()?
write(byte[],int,int) has a concrete implementation even in OutputStream. I
don't think it would be necessary to make it abstract, even in Wicket.next.
Well, the ideal would be to make this method abstract, and write(byte[])
concrete, since it would avoid the arraycopy overhead, but I think it
- I echo the .setOutput*() thing. There should be some global setting for
these.
- some preparation for Java 8/closures support (Single-Method Interfaces)
- more/refined debug tools
- revive portlet support
On Wed, Aug 31, 2011 at 9:26 AM, Korbinian Bachl - privat
, it is a big blob of code with lots of private/final methods,
impossible to customize.
On Wed, Aug 31, 2011 at 10:33 AM, tetsuo ronald.tet...@gmail.com wrote:
- I echo the .setOutput*() thing. There should be some global setting for
these.
- some preparation for Java 8/closures support
, they are
still in their 2.x or 3.x versions, even with almost, or more than, a decade
of history (Apache HTTPD, Linux, Spring, Apache Commons). Tomcat only is at
version 7 because it increments every time the specs versions change. But
which quality Java framework has such a high version number?
Tetsuo
an ecosystem is important for the project, this stability is
essential, or else third-party projects won't even have time to mature
before the next (incompatible) release.
On Mon, Aug 29, 2011 at 11:09 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
On Mon, Aug 29, 2011 at 6:28 PM, tetsuo
I've used this technique in some projects (internal APIs), with some degree
of success, but I don't think it fits well in this case.
Java's generics doesn't support this very well. It makes the code too
verbose, and in some inheritance cases, it just doesn't work.
One feature I would love to
Why does it require java 6?
On Mon, Aug 22, 2011 at 7:38 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
+1 for including it in rc6. we are tweaking poms anyways.
the release of this is pending on jboss guys getting weld and seam
artifacts into central, something im working with them on.
for the sake of it is not being 'bleeding
edge', it's just begging to lose users.
Tetsuo
On Tue, Jul 5, 2011 at 10:20 AM, Martin Grigorov mgrigo...@apache.org wrote:
:-)
The diamond notation is just about the declaration at the right side
of equals sign. This part is automatically typed for me
), not while generating HTML.
Besides, this kind of fork/join processing has its own overhead, both
in CPU cycles and in code complexity. Not worth it.
Tetsuo
On Tue, Jul 5, 2011 at 12:52 PM, Andrea Del Bene adelb...@ciseonweb.it wrote:
My fault Martin, I have not explained well myself. I try
I don't like the builder pattern in this case (specially with that
verbose syntax), but I kind of like the idea of method chaining for
additional (optional) configurations, with sensible defaults:
add(new AttributeModifier(class, selected)); // to overwrite the
current value
add(new
I'd prefer calling the constructor instead of static methods. It makes
it clear that you are creating a new instance, and how you could
extend the class if you needed to.
Oh, and 'for' is a reserved keyword :)
Tetsuo
On Wed, Jun 8, 2011 at 9:02 AM, Martijn Dashorst
martijn.dasho...@gmail.com
Well, I was trying to understand the problem before posting random thoghts :)
SegFault commented the issue with this question:
the only problem I see is that there is no one to clean the static
org.apache.wicket.page.PersistentPageManager.managers = maybe a stupid
question,
but how does
that does not change page instances
into SerializedPage...kind of like HttpSessionStore works in 1.4
compared to a store that uses DiskPageStore.
-igor
On Fri, Mar 18, 2011 at 9:35 AM, Martin Grigorov mgrigo...@apache.org
wrote:
On Fri, Mar 18, 2011 at 5:04 PM, tetsuo ronald.tet...@gmail.com
, tetsuo ronald.tet...@gmail.com wrote:
Why would it (Igor's proposal) be not correct?
On Fri, Mar 18, 2011 at 2:28 PM, Peter Ertl pe...@gmx.org wrote:
in general I prefer correctness over convenience ... so if we need a
context listener to do everything right so should it be (remember having
Since Spring 3.0, scoped proxies are Serializable. So, it's perfectly
possible to use @Configurable, @Autowired, and lots of AspectJ magic,
for Pages and Components, instead of wicket-spring/@SpringBean.
Provided, of course, that all beans you inject into Components are
scope-proxied
Yes, it is. Just use @SpringBean.
On Wed, Feb 23, 2011 at 4:25 PM, James Carman
ja...@carmanconsulting.com wrote:
On Wed, Feb 23, 2011 at 8:56 AM, tetsuo ronald.tet...@gmail.com wrote:
Since Spring 3.0, scoped proxies are Serializable. So, it's perfectly
possible to use @Configurable
you did with
servlet-api, even if all the tests pass with 2.3), but my preference
is to always minimize requirements on dependencies.
Tetsuo
On Wed, Feb 16, 2011 at 1:11 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
Currently wicket-spring 1.5 depends on spring 2.5 (specifically
is that in 1.5 the method is final on Pages. Is there
any workaround? Would you consider reverting this change? Or will I
have to stay with 1.4 forever?
Tetsuo
What about having the aggregated jar only for the bundle (zip)
download, not to be available in maven central?
On Tue, Jan 25, 2011 at 7:17 AM, Martin Grigorov mgrigo...@apache.org wrote:
[x] - Just forget about the aggregated wicket.jar and modify the wicket
module a pom-only module. This
+spring-hibernate3.jar+aopalliance.jar
With maven this is a non-issue, since you'd simply declare
spring-hibernate3 and spring-webmvc, and everything else would come as
transitive dependencies, but to do it by hand is pretty daunting,
especially for beginners trying out the library.
Tetsuo
On Tue
... :)
Tetsuo
On Tue, Jan 25, 2011 at 11:27 AM, Pedro Santos pedros...@gmail.com wrote:
Spring distribution hasn't the spring.jar anymore:
https://fisheye.springsource.org/browse/spring-framework/trunk/build-spring-framework/resources/readme.txt?r=2858r=2854r=2940r=3872
On Tue, Jan 25, 2011
Er... why was servlet API dependency version upgraded to 2.5? I can't
remember the discussion. Searched for it, but only found a pre-1.4
discussion, which was settled on 2.4.
On Sat, Jan 22, 2011 at 7:02 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
The Wicket Team is proud to introduce the
.
On Saturday, January 22, 2011, tetsuo ronald.tet...@gmail.com wrote:
Er... why was servlet API dependency version upgraded to 2.5? I can't
remember the discussion. Searched for it, but only found a pre-1.4
discussion, which was settled on 2.4.
On Sat, Jan 22, 2011 at 7:02 PM, Igor Vaynberg
dependencies?
Tetsuo
On Wed, Dec 22, 2010 at 9:09 AM, Juergen Donnerstag
juergen.donners...@gmail.com wrote:
+1
Juergen
On Wed, Dec 22, 2010 at 11:59 AM, Martin Grigorov mgrigo...@apache.org
wrote:
+1 to rename current wicket to wicket-core
On Tue, Dec 21, 2010 at 5:58 PM, Igor Vaynberg
Unless you can think of a spectacularly better name, I think you
should just keep IHeaderResponse.
Tetsuo
On Sat, Dec 18, 2010 at 12:25 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
On Sat, Dec 18, 2010 at 2:27 AM, Juergen Donnerstag
juergen.donners...@gmail.com wrote:
I understand
+1 Apache Extras
http://www.apache-extras.org/
https://blogs.apache.org/foundation/entry/the_apache_software_foundation_launches
On Tue, Dec 14, 2010 at 3:22 PM, Stefan Lindner lind...@visionet.de wrote:
+1 for Apache.
Let's keep Wicketstuff as close as possible to wicket.
Stefan
GitHub may be a little better for developers, but I think it's quite
intimidating to users (people who just want to easily download the
binaries and read the documentation).
Google Code (thus, Apache extras) is much more friendly to non-committer-users.
But well, if one is fine with that
Grigorov mgrigo...@apache.org wrote:
On Tue, Dec 14, 2010 at 7:37 PM, tetsuo ronald.tet...@gmail.com wrote:
GitHub may be a little better for developers, but I think it's quite
intimidating to users (people who just want to easily download the
binaries and read the documentation).
Google Code (thus
Use DCEVM instead:
http://ssw.jku.at/dcevm/
Won't rerun constructors, though (which would be a horrible idea, BTW)
On Fri, Nov 19, 2010 at 9:25 AM, Peter Ertl pe...@gmx.org wrote:
The most annoying thing is when you suddenly decide to anonymously
subclass a component - then you have to
Drop Java 5 support just because of one single annotation?
On Fri, Nov 5, 2010 at 3:45 PM, Jeremy Thomerson
jer...@wickettraining.comwrote:
Since Wicket 1.5 its not yet released, should we make it dependent on Java
1.6? I don't see that being a big problem.
Jeremy Thomerson
dependencies (from the Tree component), but I think nothing one
could do would change the classification from semi-compatible to compatible
in that listing. Unless, of course, GAE turns to be the main target for
Wicket (which I don't think is the case).
my 2c,
Tetsuo
On Mon, Sep 20, 2010 at 9:52 AM
the classification from
semi-compatible to compatible...
Sure you can, the defaults could change automatically by detecting that GAE
is the container.
Regards,
Erik.
Op 20-09-10 15:05, tetsuo wrote:
I think Wicket is listed as semi-compatible because it requires some
customization (override some
in the page, where is
it?
Thanks a lot!
Tetsuo
On Tue, Sep 7, 2010 at 9:36 PM, melom me...@intelliware.ca wrote:
Hi everyone,
I've posted this on the Liferay forums as well and would like to share it
here as well:
Our development team has put together a step-by-step document on how to
build
It seems that this memory leak happens only once. I guess the first deploy
(the one which will force the creation of the background Java2D thread) will
hang around forever, but subsequent redeploys will be correctly cleaned-up.
Also, what leaks is the classloader. Only static variables and class
You could use Spring 3's @Async:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/scheduling.html#scheduling-annotation-support-async
If you can upgrade to 3.0, that is..
On Thu, May 20, 2010 at 5:17 PM, Alex Objelean alex.objel...@gmail.comwrote:
I do not
You can return a Future from the @Async-annotated method.
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/scheduling.html#scheduling-annotation-support-async
On Thu, May 20, 2010 at 5:52 PM, Alex Objelean alex.objel...@gmail.comwrote:
Thanks for the hint. It
JRebel is intended to be used in development, not in production. In
production, you want to undeploy and redeploy your application and,
hopefully, leave no old ClassLoader reference behind.
I'm not sure if InheritableThreadLocal will create memory leaks, but I know
it is something to be very
to think of some problematic case (since I was worried about
this, too), but couldn't. Do you have any case with potential to trigger the
leak?
Tetsuo
On Wed, May 19, 2010 at 1:15 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
On 19/05/2010 13:06, Alex Objelean wrote:
Please, correct
On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
I can't, however, do it now. But I would have no reason to do it knowing
some folks just consider a normal thing restart the container to update the
application. So if Wicket devs are in this way, I could
On Wed, May 19, 2010 at 4:30 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
I do not think the application object is general enough to be passed
implicitly to threads.
Now, this is a valid argument!
I agree wholeheartedly that Application.get() shouldn't be accessible to
child
onClickOrSomethingSimilar() {
final Application app = Application.get();
new Thread(new Runnable() {
void run() {
doSomethingWith(app);
}
}).start();
}
On Wed, May 19, 2010 at 10:29 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
It solves this problem,
Taking specifically your example, 'foo == false' is too similar to 'foo =
false', which also compiles, and is probably an error (not just checking the
value, but changing it. '!foo' or 'false == foo' ('false = foo' doesn't
compile) may be better choices.
But yes, most of these warnings are just
2 - here I have an simple consideration: framework should respect my
component design.
My view is different: we should respect the framework design. Don't fight
your tools, learn how to use them properly.
That said, I think that the model is the place where lazy instantiations
should occur. I
I agree, names like IThing and ThingImpl can be a sign of not thinking too
hard about naming things (and even a rush to get coding without enough
thought put into design - but that's a long story).
I* is just a convention, which some like, others dislike, and *Impl are
perfectly fine when
What if I have
a class for the iPlayer (a BBC service for watching already broadcast TV
programs online). If I call my class IPlayer do I need to worry that half
the world is going to think it's an interface.
Oh, Apple will have a lot of trouble if they try to use Wicket :)
Again,
-1
It breaks compatibility for absolutely no reason.
On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom seij...@gmail.com wrote:
+1
On Oct 2, 2009, at 17:28, Igor Vaynberg igor.vaynb...@gmail.com wrote:
is it perhaps time to take the I out of our interface names? wicket
has been the only
gain anything for adding the angle
brackets, since the models in general use reflection (PropertyModel,
CompoundPropertyModel, etc.), and don't make any use of the build-time
validation at all.
sigh...
Tetsuo
On Mon, Jul 6, 2009 at 3:35 PM, tetsuo ronald.tet...@gmail.com wrote:
I understand
fine.
Tetsuo
On Mon, Jul 6, 2009 at 3:48 PM, tetsuo ronald.tet...@gmail.com wrote:
I've just read the explanation in a Tim's blog post comment. Oh, well,
generics definitely isn't easy to grasp...
I myself have observed that my (wicket) code is so much readable without
most generics
'IModel? getModel()' instead of 'Object getModel()', and 'IModelT
getModel()' instead of 'T getModel()', sorry.
And sorry for flooding the mailing list, this is the last one, I promise :)
On Mon, Jul 6, 2009 at 3:54 PM, tetsuo ronald.tet...@gmail.com wrote:
What if Component
Now I get it, thanks.
Indeed, it's hard to think in a better solution (without ditching generics
altogether).
Tetsuo
On Mon, Jul 6, 2009 at 4:19 PM, Matej Knopp matej.kn...@gmail.com wrote:
Problem is setDefaultModelObject().
If you have setModelObject(Object o) you can not override
99 matches
Mail list logo
