I have no personal experience with retrowaever. However, there are many
success stories on the internet. I have at least one colleague that used
it without problems.
If I understand correctly, there is one slight drawback: you can not use
the new java 5 APIs (like StringBuilder and java.util.c
All,
I am for 1.5. I am in the happy situation where I have complete control
over deployment of my apps. Not everyone is. I would rather have it
sooner than later, but if it's best for the community as a whole, I am
glad to wait until after the Constructor refactoring. Just not too much
after.
I am sorry,i forget the time for 2.0 release. But I still have doubt about one year is enough. I never used Retrotranslator and other retroweaver tools.I am not sure it can run in different jdk with problems.So i avoid it. Stick with the old version is not bad, we seldom change the version for c
Yes, you are correct, that is exactly what I meant. The pace of development seems to be quite nice. :)-- JessOn 2/14/06, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
I think you mean pace of releasing. The pace of development isactually very high, and is - unfortunately - the main reason why wedidn
I think you mean pace of releasing. The pace of development is
actually very high, and is - unfortunately - the main reason why we
didn't bring out a release yet :)
Eelco
> Based on the current pace of development, a 2.0 release would probably not
> land until late this year at the earliest, I wo
On 2/13/06, wang lei <[EMAIL PROTECTED]> wrote:
Here is my opinions:>> - should the post 1.2 version of Wicket involve both changes?Absolutely not.I support the constructor change ,because it force the programmer to do in a right way.
I don't want wicket support JDK1.5 soon.I know generics can brin
As Jesse referenced, once we move to Java 1.5 we can still release Java
1.4 versions via tools such as Retroweaver... assuming that the tool
works as advertised. Has anyone had more experience in these types of
tools?
- Jason B.
Jesse Sightler wrote:
I'm completely in favor of jumping to
may i humbly suggest you do not post off topic.-IgorOn 2/13/06, Gili <[EMAIL PROTECTED]
> wrote:Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?On a related note, I believe RFE #1167649 can be closed as
We /will/ evaluate all bugs, issues and patches before we bring out
any final release. We can't make any guarantees on fixes and schedules
however.
On 2/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Say what? Running out of things to work on? That's a joke, right? May
> I remind you that we
Say what? Running out of things to work on? That's a joke, right? May
I remind you that we are doing this largely in our spare time, and
have been doing that for a long time already?
Eelco
On 2/13/06, Gili <[EMAIL PROTECTED]> wrote:
>
> Seems to me you guys are quickly running out of thi
Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?
On a related note, I believe RFE #1167649 can be closed as fixed.
Thanks,
Gili
Martijn Dashorst wrote:
All,
We are of course very busy finalizing Wicke
Here is my opinions:>> - should the post 1.2 version of Wicket involve both changes?Absolutely not.I support the constructor change ,because it force the programmer to do in a right way.I don't want wicket support JDK1.5 soon.I know generics can bring many benefits.But there is a long time before m
I'm completely in favor of jumping to Wicket 2.0 and implementing both
of these changes with it. Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
I'm sure that won't be perfect for some people, but I think it is
reasonable to cut ove
Here are mine:
> The questions I'm seeking answers to are the following:
>
> - should the post 1.2 version of Wicket involve both changes?
No. The constructor changes first, we can call it 1.3, and that
version should be primarily just that change and some minor ones
around it.
> - should we m
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refa
Yeah. Another problem with having an application level signin page
setting is that there might be multiple instead of just one (e.g
depending of the level of authentication, think of how how many
banking apps work), and that authentication might be done outside of
Wicket, in which case you'd rather
Eelco tells me that a couple people are complaining about this change and I wanted to explain why it happened and also reassure everyone that the big bunch of changes that just went through is the last of what I wanted to get done for
1.2. From here on out, I'd like to see us just fix bugs and im
hm... a little out of topic, but I am just getting confuse recentlyWhy a simple, common task like setSignInPage() becomes so complex ? I need to learn 4 class to accomplish :IUnauthorizedComponentInstantiationListener
RestartResponseAtInterceptPageExceptionUnauthorizedInstantiationExceptionSimplePa
Ok, totally understandable. I'll go with the scriptaculous-example.
Thanks for your input.
Btw, have you thought about using JCI compiling classloader or
something similar to speedup the compile - reload cycle when
developing?
/Mats
On 2/13/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> I thi
I think such a component would be very implementation dependend, and
the dojo/scriptaculous components are probably a better way to go.
They have the backing power of useful javascript libraries and don't
suffer from a not invented here syndrome.
I think such a component would distract too much fr
yes it is removed and the replacement is: setUnauthorizedComponentInstantiationListener()see the library examplegetSecuritySettings().setUnauthorizedComponentInstantiationListener(new IUnauthorizedComponentInstantiationListener()
{ public void onUnauthorizedInstantiation(final Co
I understand simple wicket forms at least a little now...but I'm
really starting to struggle w/ things beyond the trivial when it comes
to forms. I'm also having some trouble locating some real solid
examples or documentation...the API reference stops being helpful
really quick. The wicket-exampl
it is not part of the core, so "preferred" way does not apply to it. it is just an implementation. if you like it go ahead and use it.i dont know if we will be providing an implementation as part of the core. depends on how complex the _javascript_ needs to be to draw the drop down part and how cro
you should put index.html in your context root and have a metaredirect to /foo insidesomething like this: -IgorOn 2/13/06, Tom S. <[EMAIL PROTECTED]> wrote:
OK, I now can read my html files from a different location. But I still havea serious problem with resources (
e.g. graphics). The servlet
Hey all,Where abouts has ApplicationSettings.setSigninPage moved to/changed to? Just pulled out a new HEAD build and its no longer there, and no sign of it on any other class.
http://papernapkin.org/pastebin/app/view/236 shows using IUnauthorizedComponentInstantiationListener which I havn't seen b
I saw that there is an autocompleting TextField in the scriptaculous
examples at wicket-stuff. Is this the prefered way of doing it in
1.2? Or is it a behaviour one should use somehow?
/Mats
---
This SF.net email is sponsored by: Splunk Inc. D
I once read that it is more secure to store passwords as char arrays. In PasswordTextField, does the model binds automatically to a char array? or what way can a user make use of a char array to store thier passwords or its not a compelling security issue?
OK, I now can read my html files from a different location. But I still have
a serious problem with resources (e.g. graphics). The servlet mapping in the
web.xml looks like this:
MyWebApplication
/foo/*
When I open the URL http://localhost:8080/foo/graphics/logo.png, the graphic
is
that is possible but then you have to writer youre own ResourceFinder or ResourceLocator.On 2/13/06, Thomas Singer <
[EMAIL PROTECTED]> wrote:OK, for styles, this works, but how to do that with images?
What about moving the html-files to the resources directory? Maybe there isan easy way to tell Wi
OK, for styles, this works, but how to do that with images?
What about moving the html-files to the resources directory? Maybe there is
an easy way to tell Wicket where it should search for them.
Cheers,
Tom
Martijn Dashorst schrieb:
>From within style.css the references to images is always
>From within style.css the references to images is always local to the style.So when I need to add a style.css to a wicket markup file, and I want previewability, I usually do something like this:
some ideasMake those resources also PackageResources so inside the src dir.Or set a hard path ../../../ in Index.html to style.css and logo.pngAnd then fix that path at runtime johan
On 2/13/06, Tom S. <[EMAIL PROTECTED]> wrote:
Hi,At the moment I have following project structure:[root]+ [resources
nice but i do it already a little bid different.Because what we want is that person A alters field X and person B field Y then it may pass.(ok it can be that those 2 fields are related to each other but then a validator must handle that)
The big trick we needed to fix was that a form input that is
Great, thank you.
2006/2/13, Martijn Dashorst <[EMAIL PROTECTED]>:
Someone asked about how I did my optimistic locking form, so I took 15 minutes and wrote a short entry on my blog.
http://www.jroller.com/page/dashorst?entry=wicket_goodie_hibernate_versioned_form
Martijn-- Living a wicket life...M
Someone asked about how I did my optimistic locking form, so I took 15 minutes and wrote a short entry on my blog.http://www.jroller.com/page/dashorst?entry=wicket_goodie_hibernate_versioned_form
Martijn-- Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorstWicket 1.1.1 is
Regarding this issue yes, but I don't know about the rest of your page ;-)MartijnOn 2/13/06, Thomas Singer <
[EMAIL PROTECTED]> wrote:> You are aware that in valid HTML the ID of an element should be
> unique?No, I was not aware of this issue, but already wondered, why IDEAcomplained. I've changed
Hi,
At the moment I have following project structure:
[root]
+ [resources]
| + style.css
| + graphic/logo.png
+ [src]
+ [com.blabla.pages]
+ Index.java
+ Index.html
Index.html references style.css and graphic/logo.png relative to [resources]
(which is in the classpath) to ensure the
You are aware that in valid HTML the ID of an element should be
unique?
No, I was not aware of this issue, but already wondered, why IDEA
complained. I've changed all id's to class'es and now it should be HTML
conform, right?
--
Cheers,
Tom
Martijn Dashorst schrieb:
Tom,
You are aware th
38 matches
Mail list logo
