Re: [Announce] wicketstuff-push ported to use wicket 1.4 jetty 6.1.14
concerning the proper javascript client for comet... is there anything reasonable except dojo-cometd-client to use? The dojo stuff feels really bloated for me Am 11.12.2008 um 15:00 schrieb Michael Sparer: Alright, I'll keep an eye on changes of your project. Maybe we can merge some useful stuff in the future, but for now I'm of the same opinion as you. Let's keep them seperate for now. greetings from ice-cold austria, Michael Rodolfo Hansen-2 wrote: Yeah, I think we might just want to separate them, the goals will start becoming a bit different as well.. Especially since push has other options other than cometd / dojo for the general notion of getting push to web clients... So its better to separate those concerns and have push with its own mindset, no? On Tue, Dec 9, 2008 at 9:40 AM, Michael Sparer wrote: Rodolfo, so you finally decided to stick with your initial idea ;-) did you at least have a look at the cometd stuff in the new wicketstuff-dojo-1.1. project? I'm still against the idea to split up wicketstuff-push completely from the dojo project, but we had the discussion before without result ... regards, Michael Rodolfo Hansen-2 wrote: Hi, a new version of wicketstuff-push was moved to the wicketstuff-core group of projects, as push-parent (as was specified in the wiki) A couple of new things were done: It is no longer compatible with java 1.4, is built for wicket 1.4 and requires jetty 6.1.14. The dependencies on dojo have been reduced even further, so this package is basically just a cometd client/server project for wicket. The RemoveListener is now working and is extended with a new type of WicketRemoveListener that allows access to the Wicket Application Singleton and the session that registered the singleton (i thought of a couple of ways to register them, and decided to choose the one present in the code for it) Please let me know of any suggestions, ideas for the proj. - Michael Sparer http://talk-on-tech.blogspot.com -- View this message in context: http://www.nabble.com/-Announce--wicketstuff-push-ported-to-use-wicket-1.4-jetty-6.1.14-tp20914051p20914877.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - Michael Sparer http://talk-on-tech.blogspot.com -- View this message in context: http://www.nabble.com/-Announce--wicketstuff-push-ported-to-use-wicket-1.4-jetty-6.1.14-tp20914051p20955950.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Modify textfield input before validation
I really wonder why converters are not the right thing to do?
Trimming crap off the input is a one-way conversion *imho*
Am 11.12.2008 um 20:45 schrieb pixologe:
Please note that these were just examples, not actual use cases of
mine
(apart from the URL stuff).
Anyway, I think there are quite some use cases where fixing/
optimizing user
input makes sense. I've always thought converters would be the way
to go,
but just recently read that they aren't.
Having stuff like this done in the domain object's setter is far to
backend
for my taste. As this feature addresses user interaction, I think it
is
rather a matter of presentation, and I would not think that my
domain object
should have to care. Worse, using this scenario it would not be
possible to
use wicket's validation behavior _after_ doing the modification. One
could
use a model as well, then.
kan-4 wrote:
As I remember, wicket trims spaces already, so you don't need do
anything special about it.
For DB, if you use hibernate (or if not, anyway you should have data
objects for your business entities), you can have something like
that:
public class MyEntity
{
// This is mapped to database, but not for public, only database
will use
it.
private String siteUrlStr;
// this is your public interface:
public SiteUrl getSiteUrl(){return new SiteUrl(getSiteUrlStr());}
public void setSiteUrl(SiteUrl url){siteUrlStr = url.getStr();}
}
And in code the lists should be treated as List, Collection or so,
not
as comma-separated strings (only in some particular places like
persisting in database or in user interface).
2008/12/11 pixologe :
Thanks for your ideas...
But huh... is there really no "wicket way" to achieve this?
After all I would not think that it is uncommon to fix simple
things in
user
input before validation, e.g. trim strings, discard empty items in
comma
separated lists etc.
Your solutions would work both I think, I just do not like the
idea of
doing
things like these with javascript.
Also, retrieving a String value from DB and wrapping it into an
object
just
in order to be able to convert it back does not seem right to me...
I'll probably stick to the js solution (reluctantly ;-), but if
there is
really no elegant way, I would love to see one in future wicket
versions.
Thanks for inspiration!
best regards
--
View this message in context:
http://www.nabble.com/Modify-textfield-input-before-validation-tp20952903p20956050.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
WBR, kan.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Modify-textfield-input-before-validation-tp20952903p20963023.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Create custom UrlCodingStrategy
maybe this would be the time to apply my patch? :-) https://issues.apache.org/jira/browse/WICKET-1666 Am 03.12.2008 um 16:18 schrieb Mathias P.W Nilsson: Yes, thanks! This is what I have been trying to do but with no luck. -- View this message in context: http://www.nabble.com/Create-custom-UrlCodingStrategy-tp20660813p20814900.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature idea: sealed flag on MarkupContainer
for SubPanel the ctor is called that order
-
- Panel
- BasePanel
- SubPanel
so the fields will be initialized, eh?!
Am 20.11.2008 um 16:32 schrieb John Krasnay:
Here's the problem (also with sketchy pseudo code :)
public class BasePanel extends Panel {
public BasePanel(String id) {
super(id);
add(new Label("foo", ...));
}
}
public class SubPanel extends BasePanel {
@Override
public void onComponentAdd(Component child) {
// oops, called from BasePanel ctor
// my fields aren't initialized yet
}
}
jk
On Thu, Nov 20, 2008 at 12:38:39PM +0100, Peter Ertl wrote:
I was thinking about something like this:
[warning, sketchy pseudo code will follow]
method org.apache.wicket.MarkupContainer.add(Component... children) :
-> call empty overridable method onComponentAdd(Component child)
for each component
-> add component
protected void onComponentAdd(Component child) { /* overridable
*/ }
Am 20.11.2008 um 12:30 schrieb John Krasnay:
Yeah, I thought about that. The problem is add() is usually called
from
a component's constructor, so you would have a case of a constructor
(indirectly) calling a non-final method,
jk
On Thu, Nov 20, 2008 at 11:27:39AM +0100, Peter Ertl wrote:
Wouldn't it be more powerful to override / hook into the process of
adding a component of a container?
Something like that ...
new WebMarkupContainer(id)
{
@Override
public void onComponentAdd(Component child)
{
// check the sealed flag, decorate the child, throw exception, or
do [whatever]
}
}
Am 20.11.2008 um 05:25 schrieb John Krasnay:
Hi folks,
In my current Wicket app I have a panel that contains a vertically
stacked list of sub-panels. Because the precise list of sub-panels
is
not known until runtime, I've implemented this with a
RepeatingView.
My
parent panel has the following methods that I use to build the
list of
sub-panels ("rv" is my RepeatingView instance):
public void addSubPanel(Panel subPanel) { rv.add(subPanel); }
public String newSubPanelId() { return rv.newChildId(); }
I use this same pattern in a number of other instances such as
menus
and
button bars.
The problem is that I often mistakenly call add instead of
addSubPanel,
which of course fails at render time with an exception that I
always
find hard to decipher.
It would be nice if there was a way to "seal" a MarkupContainer
once I
had populated it such that any subsequent call to add, remove, or
replace would fail immediately with an exception. This would
make it
much easier to find out where I had made the mistake.
Does anyone else think this would be a worthwhile feature?
jk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature idea: sealed flag on MarkupContainer
I was thinking about something like this:
[warning, sketchy pseudo code will follow]
method org.apache.wicket.MarkupContainer.add(Component... children) :
-> call empty overridable method onComponentAdd(Component child)
for each component
-> add component
protected void onComponentAdd(Component child) { /* overridable */ }
Am 20.11.2008 um 12:30 schrieb John Krasnay:
Yeah, I thought about that. The problem is add() is usually called
from
a component's constructor, so you would have a case of a constructor
(indirectly) calling a non-final method,
jk
On Thu, Nov 20, 2008 at 11:27:39AM +0100, Peter Ertl wrote:
Wouldn't it be more powerful to override / hook into the process of
adding a component of a container?
Something like that ...
new WebMarkupContainer(id)
{
@Override
public void onComponentAdd(Component child)
{
// check the sealed flag, decorate the child, throw exception, or
do [whatever]
}
}
Am 20.11.2008 um 05:25 schrieb John Krasnay:
Hi folks,
In my current Wicket app I have a panel that contains a vertically
stacked list of sub-panels. Because the precise list of sub-panels
is
not known until runtime, I've implemented this with a RepeatingView.
My
parent panel has the following methods that I use to build the
list of
sub-panels ("rv" is my RepeatingView instance):
public void addSubPanel(Panel subPanel) { rv.add(subPanel); }
public String newSubPanelId() { return rv.newChildId(); }
I use this same pattern in a number of other instances such as menus
and
button bars.
The problem is that I often mistakenly call add instead of
addSubPanel,
which of course fails at render time with an exception that I always
find hard to decipher.
It would be nice if there was a way to "seal" a MarkupContainer
once I
had populated it such that any subsequent call to add, remove, or
replace would fail immediately with an exception. This would make it
much easier to find out where I had made the mistake.
Does anyone else think this would be a worthwhile feature?
jk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature idea: sealed flag on MarkupContainer
Wouldn't it be more powerful to override / hook into the process of
adding a component of a container?
Something like that ...
new WebMarkupContainer(id)
{
@Override
public void onComponentAdd(Component child)
{
// check the sealed flag, decorate the child, throw exception, or
do [whatever]
}
}
Am 20.11.2008 um 05:25 schrieb John Krasnay:
Hi folks,
In my current Wicket app I have a panel that contains a vertically
stacked list of sub-panels. Because the precise list of sub-panels is
not known until runtime, I've implemented this with a RepeatingView.
My
parent panel has the following methods that I use to build the list of
sub-panels ("rv" is my RepeatingView instance):
public void addSubPanel(Panel subPanel) { rv.add(subPanel); }
public String newSubPanelId() { return rv.newChildId(); }
I use this same pattern in a number of other instances such as menus
and
button bars.
The problem is that I often mistakenly call add instead of
addSubPanel,
which of course fails at render time with an exception that I always
find hard to decipher.
It would be nice if there was a way to "seal" a MarkupContainer once I
had populated it such that any subsequent call to add, remove, or
replace would fail immediately with an exception. This would make it
much easier to find out where I had made the mistake.
Does anyone else think this would be a worthwhile feature?
jk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Render a Wicket page to a string for HTML email
> final WebApplication app = (WebApplication)WebApplication.get();
this will not work reliably unless you created a new WicketTester
before in your tests or are running inside a current request handled
by WicketFilter
(needed to initialize the ThreadLocal Application instance in
Application)
Am 06.11.2008 um 23:01 schrieb cjlyth:
getBinaryContent was not returning anything for me. When i simply
changed it
to return tester.getServletResponse().getDocument() everything
seemed to
work.
Here is the sample that works in a jUnit test, I have not yet
integrated
this into any real applications.
public String renderPageToString(final Class
pageClass,
final PageParameters pageParameters) {
try {
final WebApplication app =
(WebApplication)WebApplication.get();
return Executors.newSingleThreadExecutor().submit(
new Callable() {
public String call() throws
Exception {
final WicketTester
tester = new WicketTester(app);
tester.startPage(pageClass, pageParameters);
tester.assertNoErrorMessage();
return
tester.getServletResponse().getDocument();
}
}).get();
} catch (InterruptedException e) {
throw new WicketRuntimeException(e.getMessage(), e);
} catch (ExecutionException e) {
throw new WicketRuntimeException(e.getMessage(), e);
}
}
Peter Ertl wrote:
...
return new
String(tester.getServletResponse().getBinaryContent(),
tester.getServletResponse().getCharacterEncoding());
...
--
View this message in context:
http://www.nabble.com/Render-a-Wicket-page-to-a-string-for-HTML-email-tp20325702p20370600.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Render a Wicket page to a string for HTML email
cool. let's put this to the wiki (or maybe org.apache.util.* ???) and
help some people out there :-)
Am 06.11.2008 um 23:01 schrieb cjlyth:
getBinaryContent was not returning anything for me. When i simply
changed it
to return tester.getServletResponse().getDocument() everything
seemed to
work.
Here is the sample that works in a jUnit test, I have not yet
integrated
this into any real applications.
public String renderPageToString(final Class
pageClass,
final PageParameters pageParameters) {
try {
final WebApplication app =
(WebApplication)WebApplication.get();
return Executors.newSingleThreadExecutor().submit(
new Callable() {
public String call() throws
Exception {
final WicketTester
tester = new WicketTester(app);
tester.startPage(pageClass, pageParameters);
tester.assertNoErrorMessage();
return
tester.getServletResponse().getDocument();
}
}).get();
} catch (InterruptedException e) {
throw new WicketRuntimeException(e.getMessage(), e);
} catch (ExecutionException e) {
throw new WicketRuntimeException(e.getMessage(), e);
}
}
Peter Ertl wrote:
...
return new
String(tester.getServletResponse().getBinaryContent(),
tester.getServletResponse().getCharacterEncoding());
...
--
View this message in context:
http://www.nabble.com/Render-a-Wicket-page-to-a-string-for-HTML-email-tp20325702p20370600.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Render a Wicket page to a string for HTML email
public String renderPageToString(final WebApplication application,
final Page page)
{
try
{
return Executors.newSingleThreadExecutor().submit(new
Callable()
{
public String call() throws Exception
{
final WicketTester tester = new WicketTester(application);
tester.startPage(page);
tester.assertNoErrorMessage();
return new
String(tester.getServletResponse().getBinaryContent(),
tester.getServletResponse().getCharacterEncoding());
}
}).get();
}
catch (InterruptedException e)
{
throw new WicketRuntimeException(e.getMessage(), e);
}
catch (ExecutionException e)
{
throw new WicketRuntimeException(e.getMessage(), e);
}
}
Am 05.11.2008 um 18:31 schrieb Igor Vaynberg:
that should do it for most cases. you might want to give wickettester
the actual application object also.
-igor
On Wed, Nov 5, 2008 at 9:26 AM, Peter Ertl <[EMAIL PROTECTED]> wrote:
So would this be ok ?!
(caution! untested!)
try
{
final String html =
Executors.newSingleThreadExecutor().submit(new
Callable()
{
public String call() throws Exception
{
final WicketTester tester = new WicketTester();
tester.startPage(MyPage.class);
return new
String(tester.getServletResponse().getBinaryContent(),
tester.getServletResponse().getCharacterEncoding());
}
}).get();
}
catch (InterruptedException e)
{
e.printStackTrace();
}
catch (ExecutionException e)
{
e.printStackTrace();
}
Am 05.11.2008 um 18:18 schrieb Igor Vaynberg:
you still have to do it in a separate thread :)
-igor
On Wed, Nov 5, 2008 at 9:14 AM, Peter Ertl <[EMAIL PROTECTED]>
wrote:
Won't it be easier / will it work to use WicketTester for this?
Am 05.11.2008 um 17:26 schrieb Igor Vaynberg:
make sure you do this in a thread other then the request thread
so you
dont mess up any threadlocals.
-igor
On Wed, Nov 5, 2008 at 2:22 AM, Jörn Zaefferer
<[EMAIL PROTECTED]> wrote:
No voodoo neccessary, got it working:
protected String renderPage(Class pageClass,
PageParameters pageParameters) {
//get the servlet context
WebApplication application = (WebApplication)
WebApplication.get();
ServletContext context =
application.getServletContext();
//fake a request/response cycle
MockHttpSession servletSession = new
MockHttpSession(context);
servletSession.setTemporary(true);
MockHttpServletRequest servletRequest = new
MockHttpServletRequest(
application, servletSession, context);
MockHttpServletResponse servletResponse = new
MockHttpServletResponse(
servletRequest);
//initialize request and response
servletRequest.initialize();
servletResponse.initialize();
WebRequest webRequest = new
ServletWebRequest(servletRequest);
BufferedWebResponse webResponse = new
BufferedWebResponse(servletResponse);
webResponse.setAjax(true);
WebRequestCycle requestCycle = new WebRequestCycle(
application, webRequest, webResponse);
requestCycle.setRequestTarget(new
BookmarkablePageRequestTarget(pageClass, pageParameters));
try {
requestCycle.getProcessor().respond(requestCycle);
log.warn("Response after request:
"+webResponse.toString());
if (requestCycle.wasHandled() == false) {
requestCycle.setRequestTarget(new
WebErrorCodeResponseTarget(
HttpServletResponse.SC_NOT_FOUND));
}
requestCycle.detach();
} finally {
requestCycle.getResponse().close();
}
return webResponse.toString();
}
Does it make sense to put this in a ticket to request it for
Wicket
1.5?
Jörn
On Tue, Nov 4, 2008 at 5:55 PM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
Are you in New Orleans in some voodoo bar? Why not join us at
ApacheCon? :)
Martijn
On Tue, Nov 4, 2008 at 10:43 AM, Igor Vaynberg
<[EMAIL PROTECTED]>
wrote:
without seeing your code we have to resort to waving a dead
chicken
in
front of our screens or making swags.
-igor
On Tue, Nov 4, 2008 at 9:19 AM, Jörn Zaefferer
<[EMAIL PROTECTED]> wrote:
Hi,
I've found this article on how to render a page to a String:
http://www.danwalmsley.com/2008/10/21/render-a-wicket-page-to-a-string-for-html-email/
It seemed to be exactly what I was looking for. Copying the
code
into
my app, I got a compiler error on the line where the
WebRequest is
created. Using the constructor to ServletWebRequest helped.
Nonetheless, I get only an empty string back, no clue whats
going
wrong.
I'm using Wicket 1.3.5.
Any ideas?
Jörn
---
Re: Render a Wicket page to a string for HTML email
So would this be ok ?!
(caution! untested!)
try
{
final String html =
Executors.newSingleThreadExecutor().submit(new Callable()
{
public String call() throws Exception
{
final WicketTester tester = new WicketTester();
tester.startPage(MyPage.class);
return new
String(tester.getServletResponse().getBinaryContent(),
tester.getServletResponse().getCharacterEncoding());
}
}).get();
}
catch (InterruptedException e)
{
e.printStackTrace();
}
catch (ExecutionException e)
{
e.printStackTrace();
}
Am 05.11.2008 um 18:18 schrieb Igor Vaynberg:
you still have to do it in a separate thread :)
-igor
On Wed, Nov 5, 2008 at 9:14 AM, Peter Ertl <[EMAIL PROTECTED]> wrote:
Won't it be easier / will it work to use WicketTester for this?
Am 05.11.2008 um 17:26 schrieb Igor Vaynberg:
make sure you do this in a thread other then the request thread so
you
dont mess up any threadlocals.
-igor
On Wed, Nov 5, 2008 at 2:22 AM, Jörn Zaefferer
<[EMAIL PROTECTED]> wrote:
No voodoo neccessary, got it working:
protected String renderPage(Class pageClass,
PageParameters pageParameters) {
//get the servlet context
WebApplication application = (WebApplication)
WebApplication.get();
ServletContext context =
application.getServletContext();
//fake a request/response cycle
MockHttpSession servletSession = new
MockHttpSession(context);
servletSession.setTemporary(true);
MockHttpServletRequest servletRequest = new
MockHttpServletRequest(
application, servletSession, context);
MockHttpServletResponse servletResponse = new
MockHttpServletResponse(
servletRequest);
//initialize request and response
servletRequest.initialize();
servletResponse.initialize();
WebRequest webRequest = new
ServletWebRequest(servletRequest);
BufferedWebResponse webResponse = new
BufferedWebResponse(servletResponse);
webResponse.setAjax(true);
WebRequestCycle requestCycle = new WebRequestCycle(
application, webRequest, webResponse);
requestCycle.setRequestTarget(new
BookmarkablePageRequestTarget(pageClass, pageParameters));
try {
requestCycle.getProcessor().respond(requestCycle);
log.warn("Response after request:
"+webResponse.toString());
if (requestCycle.wasHandled() == false) {
requestCycle.setRequestTarget(new
WebErrorCodeResponseTarget(
HttpServletResponse.SC_NOT_FOUND));
}
requestCycle.detach();
} finally {
requestCycle.getResponse().close();
}
return webResponse.toString();
}
Does it make sense to put this in a ticket to request it for
Wicket 1.5?
Jörn
On Tue, Nov 4, 2008 at 5:55 PM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
Are you in New Orleans in some voodoo bar? Why not join us at
ApacheCon? :)
Martijn
On Tue, Nov 4, 2008 at 10:43 AM, Igor Vaynberg <[EMAIL PROTECTED]
>
wrote:
without seeing your code we have to resort to waving a dead
chicken in
front of our screens or making swags.
-igor
On Tue, Nov 4, 2008 at 9:19 AM, Jörn Zaefferer
<[EMAIL PROTECTED]> wrote:
Hi,
I've found this article on how to render a page to a String:
http://www.danwalmsley.com/2008/10/21/render-a-wicket-page-to-a-string-for-html-email/
It seemed to be exactly what I was looking for. Copying the
code into
my app, I got a compiler error on the line where the
WebRequest is
created. Using the constructor to ServletWebRequest helped.
Nonetheless, I get only an empty string back, no clue whats
going
wrong.
I'm using Wicket 1.3.5.
Any ideas?
Jörn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-
Re: Render a Wicket page to a string for HTML email
Won't it be easier / will it work to use WicketTester for this?
Am 05.11.2008 um 17:26 schrieb Igor Vaynberg:
make sure you do this in a thread other then the request thread so you
dont mess up any threadlocals.
-igor
On Wed, Nov 5, 2008 at 2:22 AM, Jörn Zaefferer
<[EMAIL PROTECTED]> wrote:
No voodoo neccessary, got it working:
protected String renderPage(Class pageClass,
PageParameters pageParameters) {
//get the servlet context
WebApplication application = (WebApplication)
WebApplication.get();
ServletContext context =
application.getServletContext();
//fake a request/response cycle
MockHttpSession servletSession = new
MockHttpSession(context);
servletSession.setTemporary(true);
MockHttpServletRequest servletRequest = new
MockHttpServletRequest(
application, servletSession, context);
MockHttpServletResponse servletResponse = new
MockHttpServletResponse(
servletRequest);
//initialize request and response
servletRequest.initialize();
servletResponse.initialize();
WebRequest webRequest = new
ServletWebRequest(servletRequest);
BufferedWebResponse webResponse = new
BufferedWebResponse(servletResponse);
webResponse.setAjax(true);
WebRequestCycle requestCycle = new WebRequestCycle(
application, webRequest, webResponse);
requestCycle.setRequestTarget(new
BookmarkablePageRequestTarget(pageClass, pageParameters));
try {
requestCycle.getProcessor().respond(requestCycle);
log.warn("Response after request:
"+webResponse.toString());
if (requestCycle.wasHandled() == false) {
requestCycle.setRequestTarget(new
WebErrorCodeResponseTarget(
HttpServletResponse.SC_NOT_FOUND));
}
requestCycle.detach();
} finally {
requestCycle.getResponse().close();
}
return webResponse.toString();
}
Does it make sense to put this in a ticket to request it for Wicket
1.5?
Jörn
On Tue, Nov 4, 2008 at 5:55 PM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
Are you in New Orleans in some voodoo bar? Why not join us at
ApacheCon? :)
Martijn
On Tue, Nov 4, 2008 at 10:43 AM, Igor Vaynberg <[EMAIL PROTECTED]
> wrote:
without seeing your code we have to resort to waving a dead
chicken in
front of our screens or making swags.
-igor
On Tue, Nov 4, 2008 at 9:19 AM, Jörn Zaefferer
<[EMAIL PROTECTED]> wrote:
Hi,
I've found this article on how to render a page to a String:
http://www.danwalmsley.com/2008/10/21/render-a-wicket-page-to-a-string-for-html-email/
It seemed to be exactly what I was looking for. Copying the code
into
my app, I got a compiler error on the line where the WebRequest is
created. Using the constructor to ServletWebRequest helped.
Nonetheless, I get only an empty string back, no clue whats
going wrong.
I'm using Wicket 1.3.5.
Any ideas?
Jörn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Render a Wicket page to a string for HTML email
Great work!
You should put this on the Wiki :-)
Am 05.11.2008 um 11:22 schrieb Jörn Zaefferer:
No voodoo neccessary, got it working:
protected String renderPage(Class pageClass,
PageParameters pageParameters) {
//get the servlet context
WebApplication application = (WebApplication)
WebApplication.get();
ServletContext context = application.getServletContext();
//fake a request/response cycle
MockHttpSession servletSession = new MockHttpSession(context);
servletSession.setTemporary(true);
MockHttpServletRequest servletRequest = new
MockHttpServletRequest(
application, servletSession, context);
MockHttpServletResponse servletResponse = new
MockHttpServletResponse(
servletRequest);
//initialize request and response
servletRequest.initialize();
servletResponse.initialize();
WebRequest webRequest = new ServletWebRequest(servletRequest);
BufferedWebResponse webResponse = new
BufferedWebResponse(servletResponse);
webResponse.setAjax(true);
WebRequestCycle requestCycle = new WebRequestCycle(
application, webRequest, webResponse);
requestCycle.setRequestTarget(new
BookmarkablePageRequestTarget(pageClass, pageParameters));
try {
requestCycle.getProcessor().respond(requestCycle);
log.warn("Response after request:
"+webResponse.toString());
if (requestCycle.wasHandled() == false) {
requestCycle.setRequestTarget(new
WebErrorCodeResponseTarget(
HttpServletResponse.SC_NOT_FOUND));
}
requestCycle.detach();
} finally {
requestCycle.getResponse().close();
}
return webResponse.toString();
}
Does it make sense to put this in a ticket to request it for Wicket
1.5?
Jörn
On Tue, Nov 4, 2008 at 5:55 PM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
Are you in New Orleans in some voodoo bar? Why not join us at
ApacheCon? :)
Martijn
On Tue, Nov 4, 2008 at 10:43 AM, Igor Vaynberg <[EMAIL PROTECTED]
> wrote:
without seeing your code we have to resort to waving a dead
chicken in
front of our screens or making swags.
-igor
On Tue, Nov 4, 2008 at 9:19 AM, Jörn Zaefferer
<[EMAIL PROTECTED]> wrote:
Hi,
I've found this article on how to render a page to a String:
http://www.danwalmsley.com/2008/10/21/render-a-wicket-page-to-a-string-for-html-email/
It seemed to be exactly what I was looking for. Copying the code
into
my app, I got a compiler error on the line where the WebRequest is
created. Using the constructor to ServletWebRequest helped.
Nonetheless, I get only an empty string back, no clue whats going
wrong.
I'm using Wicket 1.3.5.
Any ideas?
Jörn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best: http://
wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket modals are not working in IE8 and Google chrome browsers
If people started using IE8 - which is still beta - it's their problem *imho* Same for chrome (we gathers your private data and only runs on Windows so far) Just because it's from Google or Microsoft doesn't mean we have to bootlick them :-) Am 25.10.2008 um 07:20 schrieb Anirban Basak: My query was can anybody help me out to make the wicket modals work in IE8? Personally I don't like IE but people already started using IE8. Warm Regards, Anirban Basak Ph : 91 33 2357 7177 Extn: 277 -Original Message- From: Matej Knopp [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2008 11:22 PM To: users@wicket.apache.org Subject: Re: Wicket modals are not working in IE8 and Google chrome browsers With IE8? That's a bad joke. The browser is nowhere near being usable even in beta2. -Matej 2008/10/24 Anirban Basak <[EMAIL PROTECTED]>: Hi, I'm using wicket for last 5+ months in my current project. We are planning to go live by mid Nov with a beta version. Yesterday our client came up with a strange complain, wicket modals, we are currently using for pop- ups, are not at all working in IE8 and Google chrome browsers. So, I verified it and yes, modals are not really opening up! I know both are still in beta stage, but is there any patch/work around ? Google chrome we can ignore right now but probably can't bypass IE8 as new Vista Laptops ship with IE8 (as client told us. Not verified yet though) Warm Regards, Anirban Basak Ph : 91 33 2357 7177 Extn: 277 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.3/1744 - Release Date: 10/24/2008 6:08 PM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returning XML to JS
have a look at XStream :-) Am 21.10.2008 um 11:25 schrieb [EMAIL PROTECTED]: Hi, What's the nice / correct way to do this in Wicket: I have a client side bit of JS that looks something like getData(URL); It expects to get back an XML document like foo bar On the wicket side, I want the Java object that spits back the XML to be part of a component. This parent component will have supplied the URL in question. Any ideas how I should do this? Thanks, Ambrose Wheatcroft Analyst / Programmer, JHC PLC +44 (0)20 7367 6500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: html code in component class
If it's just a line use Label
Am 09.10.2008 um 21:01 schrieb miro:
Using panel I have to write a .html file which I dont want to do
becasue my
html code is very little just a line ,
next option is Fragment but this is not clear, neither the api doc
nor the
wicket examples please can you give me small example using
fragment ?
jwcarman wrote:
What's wrong with using a panel? If this is to be done in only one
class, have you thought about using a Fragment?
On Thu, Oct 9, 2008 at 2:28 PM, miro <[EMAIL PROTECTED]> wrote:
the label appears complex i looking for a simple solution
My custom componentuses wicket components internally here is an
example
protected class CustomLinkComponent extends
WebMarkupContainer {
String displayName;
Class clazz;
public CustomLinkComponent(String displayName, Class
clazz) {
super("customlink");
this.displayName=displayName;
this.clazz=clazz;
add(getBookmarkablePageLink());
add(getDisplayNameLabel());
}
protected BookmarkablePageLink
getBookmarkablePageLink(){
return new BookmarkablePageLink("link",
clazz);
}
protected Label getDisplayNameLabel(){
return new Label("lbl",displayName);
}
}
the html for this is
#
so instead of writing a html page i want my component to render
this
html
and further wicket should replace the child components link and
lbl with
actual values , can I do this ?
jwcarman wrote:
Sure. Look at what the Label class does. It doesn't have an HTML
template.
On Thu, Oct 9, 2008 at 1:49 PM, miro <[EMAIL PROTECTED]> wrote:
like I have very little html and I dont want a write a new .html
file
and
just in my component i want to override some method which
returns html
as
string for the component .Is this possible ?
--
View this message in context:
http://www.nabble.com/html-code-in-component-class-tp19903944p19903944.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/html-code-in-component-class-tp19903944p19904618.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/html-code-in-component-class-tp19903944p19905223.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
why don't you open up an issue in JIRA?
Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer:
Here is a first patch for the RevisionVersionProvider:
Index: src/main/java/org/wicketstuff/mergedresources/versioning/
RevisionVersionProvider.java
===
--- src/main/java/org/wicketstuff/mergedresources/versioning/
RevisionVersionProvider.java (revision
4147)
+++ src/main/java/org/wicketstuff/mergedresources/versioning/
RevisionVersionProvider.java (working
copy)
@@ -15,7 +15,7 @@
public int getVersion(final Class scope, final String fileName)
throws VersionException {
final String file = getResourcePath(scope, fileName);
- final InputStream in =
ClassLoader.getSystemResourceAsStream(file);
+ final InputStream in =
RevisionVersionProvider
.class.getClassLoader().getResourceAsStream(file);
if (in == null) {
throw new VersionException(scope, fileName, "can't find
" + file);
}
ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
always returned null for classpath resources. Using the
RevisionVersionProvider classloader works fine.
Let me know where I should post further patches etc.
Jörn
On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
<[EMAIL PROTECTED]> wrote:
Code is now available through wicketsuff:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
wicketstuff-merged-resources and
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
wicketstuff-merged-resources-examples
Now I want to make it available through
http://wicketstuff.org/maven/repository/. I therefore registered at
wicketstuff.org/teamcity (sfussenegger). What's next?
Stefan Fußenegger wrote:
I just finished the 4th and last entry of my series "Wicket
Interface
Speed-Up" on my blog. To give a short summary: I investigated one
of my
apps with YSlow and started optimizing it's interface rendering
speed [1].
Especially Wicket's way of handling resources, i.e. JS and CSS
files,
causes interfaces to load rather slowly. In my articles, I explain
how to
modify the cache interval [2], how to mount resources with a
version (e.g.
/css/all-1234.css) in order to use aggressive client-side caching
(e.g.
resources expire after a year) [3]. Finally, I show how to merge
resources
at application startup (using a class classed
MergedResourceStream) to
reduce the number of resources a client has to download [4],
including
code). I was able to increase interface loading times
considerably, so
it's surely worth a look.
I feel that it would also be worth to discuss, whether this work
could be
part of upcoming Wicket versions. For the time being I'd like to
make the
code attached to [4] a wicketstuff project - sfussenegger needs
commit
access ;) - and wait for your feedback.
The links:
[1]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
Wicket Interface Speed-Up
[2]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
Wicket Interface Speed-Up: Modifying Expires and Cache-Control
Headers
[3]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
Wicket Interface Speed-Up: Caching Resources Forever
[4]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket,tomcat and UTF-8
It's a standard tomcat problem that everybody sooner or later encounters... This will work for you: http://cagan327.blogspot.com/2006/05/utf-8-encoding-fix-tomcat-jsp-etc.html Just use the EncodingFilter and I bet my [EMAIL PROTECTED]@#$ it will work :-) Am 29.08.2008 um 11:04 schrieb Ray trace: i dont think u actually read my post but thx anyways. as stated in the initial post i tried that allready. Emanuele Gesuato-2 wrote: Ray trace wrote: ino its wierd yes my browser says utf-8 . the mysql database is in utf-8. hibernate is utf-8. basically all is utf-8 except the incoming post data.arg. true UTF-8property> database schema is created with utf-8 ...so that hibernate tools generate the correct tables. all though i dont think its hibernate causing the problems. Have you tried using URIEncoding="UTF-8" in the connector tag of your tomcat server.xml ? It should be similar to the following: enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="2" disableUploadTimeout="true" URIEncoding="UTF-8"/> HTH, Emanuele - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket%2Ctomcat--and-UTF-8-tp19215411p19216327.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
I totally agree that having the version in the filename and not in the query string will be a-lot-better. Just wanted to point you to that option so you can include it in your excellent analysis on caching *thanks* :-) People can use that option right now and get a more decent version later (e.g. your versioned resource filenames, which is the *correct* way) Resources need some more love in wicket 1.5 - full ack! Cheers Peter Am 29.08.2008 um 09:24 schrieb Stefan Fußenegger: Okay, sorry, you're right. Too bad, I didn't ever stumble upon this option. However, changing filename instead of using query string has certain advantages, see http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ Furthermore, setting this option does not effect expires or cache- control headers. still only one hour, which is far from being aggressive. If you want to change that, you'll still have to explicitly mount all resources with your desired cache duration. Johan suggested (comment on http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html my second article ) "what i can do is make it a setting: IResourceSettings.getResourceCacheDuration()". If such a setting is available, using IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) would make more sense. I still think though that this isn't enough and resources should get a focus in upcoming wicket versions. Some might argue, that resources shouldn't be served by Wicket at all, but I really don't like to use proxies, CDNs or whatever voodoo for low traffic web sites: server-side performance isn't an issue there while client-side performance is. regards Peter Ertl wrote: That's not true. this settings will generate urls like: /resources/[package+class]/javascript.js?lm=[lastmodified] read it again : "add Last Modified Time To Resource Reference Url" getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? It will not sent the "LastModified" header as you think. So whenever the resource changes the url changes, too. Try it out and see :-) I did test it in Firefox. There will be no "IfModified" requests from the browser. Everything will be completely cached in the browser until the resource has changed. Cheers Peter Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: honestly, no, I didn't. however, using last modified times still results in an HTTP request and a "304 Not Modified" reply. better than nothing, but client-side caching is still preferable. regards Peter Ertl wrote: @stefan: did you take into account getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? Cheers Peter Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: sfussenegger now has access to wicketstuff... i dont know which parts should go into wicket itself, i can tell you that the part where you merge the files by listing them out upfront is probably not going to make it in because it breaks encapsulation... -igor On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: I just finished the 4th and last entry of my series "Wicket Interface Speed-Up" on my blog. To give a short summary: I investigated one of my apps with YSlow and started optimizing it's interface rendering speed [1]. Especially Wicket's way of handling resources, i.e. JS and CSS files, causes interfaces to load rather slowly. In my articles, I explain how to modify the cache interval [2], how to mount resources with a version (e.g. /css/all-1234.css) in order to use aggressive client-side caching (e.g. resources expire after a year) [3]. Finally, I show how to merge resources at application startup (using a class classed MergedResourceStream) to reduce the number of resources a client has to download [4], including code). I was able to increase interface loading times considerably, so it's surely worth a look. I feel that it would also be worth to discuss, whether this work could be part of upcoming Wicket versions. For the time being I'd like to make the code attached to [4] a wicketstuff project - sfussenegger needs commit access ;) - and wait for your feedback. The links: [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html Wicket Interface Speed-Up [2] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers [3] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html Wicket Interface Speed-Up: Caching Resources Forever [4] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests - --- Stefan Fußenegger
Re: Discussion on "Wicket Interface Speed-Up"
That's not true. this settings will generate urls like: /resources/[package+class]/javascript.js?lm=[lastmodified] read it again : "add Last Modified Time To Resource Reference Url" getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? It will not sent the "LastModified" header as you think. So whenever the resource changes the url changes, too. Try it out and see :-) I did test it in Firefox. There will be no "IfModified" requests from the browser. Everything will be completely cached in the browser until the resource has changed. Cheers Peter Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: honestly, no, I didn't. however, using last modified times still results in an HTTP request and a "304 Not Modified" reply. better than nothing, but client-side caching is still preferable. regards Peter Ertl wrote: @stefan: did you take into account getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? Cheers Peter Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: sfussenegger now has access to wicketstuff... i dont know which parts should go into wicket itself, i can tell you that the part where you merge the files by listing them out upfront is probably not going to make it in because it breaks encapsulation... -igor On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: I just finished the 4th and last entry of my series "Wicket Interface Speed-Up" on my blog. To give a short summary: I investigated one of my apps with YSlow and started optimizing it's interface rendering speed [1]. Especially Wicket's way of handling resources, i.e. JS and CSS files, causes interfaces to load rather slowly. In my articles, I explain how to modify the cache interval [2], how to mount resources with a version (e.g. /css/all-1234.css) in order to use aggressive client-side caching (e.g. resources expire after a year) [3]. Finally, I show how to merge resources at application startup (using a class classed MergedResourceStream) to reduce the number of resources a client has to download [4], including code). I was able to increase interface loading times considerably, so it's surely worth a look. I feel that it would also be worth to discuss, whether this work could be part of upcoming Wicket versions. For the time being I'd like to make the code attached to [4] a wicketstuff project - sfussenegger needs commit access ;) - and wait for your feedback. The links: [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html Wicket Interface Speed-Up [2] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers [3] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html Wicket Interface Speed-Up: Caching Resources Forever [4] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
@stefan: did you take into account getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? Cheers Peter Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: sfussenegger now has access to wicketstuff... i dont know which parts should go into wicket itself, i can tell you that the part where you merge the files by listing them out upfront is probably not going to make it in because it breaks encapsulation... -igor On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: I just finished the 4th and last entry of my series "Wicket Interface Speed-Up" on my blog. To give a short summary: I investigated one of my apps with YSlow and started optimizing it's interface rendering speed [1]. Especially Wicket's way of handling resources, i.e. JS and CSS files, causes interfaces to load rather slowly. In my articles, I explain how to modify the cache interval [2], how to mount resources with a version (e.g. /css/all-1234.css) in order to use aggressive client-side caching (e.g. resources expire after a year) [3]. Finally, I show how to merge resources at application startup (using a class classed MergedResourceStream) to reduce the number of resources a client has to download [4], including code). I was able to increase interface loading times considerably, so it's surely worth a look. I feel that it would also be worth to discuss, whether this work could be part of upcoming Wicket versions. For the time being I'd like to make the code attached to [4] a wicketstuff project - sfussenegger needs commit access ;) - and wait for your feedback. The links: [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html Wicket Interface Speed-Up [2] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers [3] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html Wicket Interface Speed-Up: Caching Resources Forever [4] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "WANG–Wicket Ajax Next Generation–bei ng based on YUI" (MD)
cool :-) this will be quite a big challenge ... thinking of concurrency issues and multiple server implementations (jetty, tomcat, ??) and the upcoming servlet api which will probably include 'Async and Cometd Support' http://dist.codehaus.org/jetty/misc/AsyncServlet3.0-draft0.html I will try to come up with some initial suggestion :-) Am 26.08.2008 um 23:25 schrieb Matej Knopp: I'm generally not against having push in core, so any suggestion about how the api should look like is appreciated. -Matej On Tue, Aug 26, 2008 at 11:12 PM, Peter Ertl <[EMAIL PROTECTED]> wrote: +1 for including support for cometd in wicket core I expect server side push the next great thing in web development :) my 2 pct Am 26.08.2008 um 22:19 schrieb Matej Knopp: Hi, On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <[EMAIL PROTECTED] > wrote: Matej, What are the implications of the decision to "base Wicket Ajax Next Generation on YUI" in terms of choosing a Javascript library for future Wicket based web front ends? actually, there really are none. The use of YUI will be more or less internal to Wicket, so you can continue using jQuery, YUI2 or whatever else you are using. Everything in Wicket (and YUI) is namespaced so there are no conflicts. We too were tending towards jQuery, mainly because + code based on jQuery can be quite terse yet still easy to read and elegant. I think same goes for YUI, especially with YUI3 Node class. + it doesn't require any great Javascript expertise (in particular, no obvious cross-browser issues to worry about so far). I don't see how this is different than what YUI does + it's got a small footprint and seems to be fast enough, even using the (really useful) CSS selectors. CSS selectors are of no use for Wicket Ajax, of course they might be useful for the actual application or other components. However YUI also have CSS selectors, even though i haven't profiled them. Anyway, in general i don't think that CSS selector speed matters too much. For anything really have you would have to cache the results somehow (like i did for grid). + there's huge number and variety of jQuery plugins for those special occasions. Unfortunately the quality of plugins varies. For actual wicket ajax implementation i prefer to stick with the core thing, and that's where YUI definitely beats jquery. I don't say that there are no plugins for jQuery that covers YUI functionality. Question is how well are those plugins supported and maintained. + there's a big developer community/interest with plenty of reference material, blogs etc... + the lack of any licensing concerns. + it's really easy to use and it just works. Again, I don't see why this wouldn't apply to YUI as well. Since you have no doubt carefully looked at the options and chosen YUI as the most appropriate for Wicket 1.5 (or, shall we just call it Wicket 5), and having seen the magic you have performed with your inmethod grids, I imagine that most of the above can be said for YUI too, and then some. Could be :) So ... would it make more sense to start preferring YUI for use in new Wicket applications or will it not make any real difference which Javascript library is used by the application developer? Really it won't. I used YUI because i liked it more. I went through the jQuery source code when I was evaluating it and I found YUI to be much more readable. This is a personal opinion though. It's more about the approach. I like YUI approach to things. I like the way the YUI API is designed. It like the things that are in YUI core and that only are available as plugin to jquery. Anyway, as I say, this doesn't make any implication to Wicket users or 3rd party components. The reason why wicket ajax is based on another framework is to get rid of most of the low level browser specific code we have currently so that I wouldn't have to maintain it :) -Matej Matej Knopp-2 wrote: Hi, I haven't announced yet publicly but for some time I was working on Ajax implementation for 1.5. The work is available in /repos/asf/wicket/sandbox/knopp/experimental/wicket I will put together a wiki page when I have some free time. I have of course considered jquery. I gave it a proper look but I decided to go with YUI instead because I like it's approach more. Also some functionality that YUI provides in core (dom manipulations) is only available as plugin to Jquery. New Wicket Ajax the is based on YUI3 which provides new node module that allows method chaining and kinda feels like jquery. Also personally I consider YUI source code much more readable than jquery -Matej On Tue, Aug 26, 2008 at 6:10 PM, Scott Swank <[EMAIL PROTECTED] > wrote: Has jquery been considered for WANG, or am I coming into this conversation late? Scott
Re: "WANG–Wicket Ajax Next Generation–bei ng based on YUI" (MD)
+1 for including support for cometd in wicket core I expect server side push the next great thing in web development :) my 2 pct Am 26.08.2008 um 22:19 schrieb Matej Knopp: Hi, On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <[EMAIL PROTECTED]> wrote: Matej, What are the implications of the decision to "base Wicket Ajax Next Generation on YUI" in terms of choosing a Javascript library for future Wicket based web front ends? actually, there really are none. The use of YUI will be more or less internal to Wicket, so you can continue using jQuery, YUI2 or whatever else you are using. Everything in Wicket (and YUI) is namespaced so there are no conflicts. We too were tending towards jQuery, mainly because + code based on jQuery can be quite terse yet still easy to read and elegant. I think same goes for YUI, especially with YUI3 Node class. + it doesn't require any great Javascript expertise (in particular, no obvious cross-browser issues to worry about so far). I don't see how this is different than what YUI does + it's got a small footprint and seems to be fast enough, even using the (really useful) CSS selectors. CSS selectors are of no use for Wicket Ajax, of course they might be useful for the actual application or other components. However YUI also have CSS selectors, even though i haven't profiled them. Anyway, in general i don't think that CSS selector speed matters too much. For anything really have you would have to cache the results somehow (like i did for grid). + there's huge number and variety of jQuery plugins for those special occasions. Unfortunately the quality of plugins varies. For actual wicket ajax implementation i prefer to stick with the core thing, and that's where YUI definitely beats jquery. I don't say that there are no plugins for jQuery that covers YUI functionality. Question is how well are those plugins supported and maintained. + there's a big developer community/interest with plenty of reference material, blogs etc... + the lack of any licensing concerns. + it's really easy to use and it just works. Again, I don't see why this wouldn't apply to YUI as well. Since you have no doubt carefully looked at the options and chosen YUI as the most appropriate for Wicket 1.5 (or, shall we just call it Wicket 5), and having seen the magic you have performed with your inmethod grids, I imagine that most of the above can be said for YUI too, and then some. Could be :) So ... would it make more sense to start preferring YUI for use in new Wicket applications or will it not make any real difference which Javascript library is used by the application developer? Really it won't. I used YUI because i liked it more. I went through the jQuery source code when I was evaluating it and I found YUI to be much more readable. This is a personal opinion though. It's more about the approach. I like YUI approach to things. I like the way the YUI API is designed. It like the things that are in YUI core and that only are available as plugin to jquery. Anyway, as I say, this doesn't make any implication to Wicket users or 3rd party components. The reason why wicket ajax is based on another framework is to get rid of most of the low level browser specific code we have currently so that I wouldn't have to maintain it :) -Matej Matej Knopp-2 wrote: Hi, I haven't announced yet publicly but for some time I was working on Ajax implementation for 1.5. The work is available in /repos/asf/wicket/sandbox/knopp/experimental/wicket I will put together a wiki page when I have some free time. I have of course considered jquery. I gave it a proper look but I decided to go with YUI instead because I like it's approach more. Also some functionality that YUI provides in core (dom manipulations) is only available as plugin to Jquery. New Wicket Ajax the is based on YUI3 which provides new node module that allows method chaining and kinda feels like jquery. Also personally I consider YUI source code much more readable than jquery -Matej On Tue, Aug 26, 2008 at 6:10 PM, Scott Swank <[EMAIL PROTECTED]> wrote: Has jquery been considered for WANG, or am I coming into this conversation late? Scott On Tue, Aug 26, 2008 at 5:51 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Probably something for 1.5 (with WANG–Wicket Ajax Next Generation–being based on YUI) Martijn On Tue, Aug 26, 2008 at 2:25 PM, Nino Saturnino Martinez Vazquez Wael <[EMAIL PROTECTED]> wrote: I've been hearing some rants on how merging resources can up the performance, should wicket be able todo this? I mean merging several css's into one etc.. I know it wont work for dynamic css/js/images. But on static it could, even yslow recommends you merge your resources into one... Images might be stretching it too far? WDYT? http://workingwithrails.com/railsplugin/5317-asset-packager http://www.kaboomerang.com/blog/2007/11/29/getting-to-10-actiontastic-actionatr-gwt-and-automagic-rest/
Re: Wicket merchandise take 2
Just having the logo would look even more magical *g* "Less is more" Loads of people would ask what this 'wicked' logo means and you have all the attraction you possibly want :-) This would make it easier to proselytize alien web developers because you don't have to hunt them down first but they come to you voluntarily +1 for just the logo +1 for having some well-contrasting shirt color besides white (maybe dark blue which is on the opposite side of the color circle) Keep on rocking Peter Am 26.08.2008 um 00:18 schrieb Ryan Gravener: I like the idea of a professional shirt, something you can wear in the office to show your support for wicket. However, I don't know about you Europeans but http://images.cafepress.com/product/297944696v9_240x240_Back.jpg would repel the girls in the states. Would it be possible to only have the front logo on the golf shirt? On Mon, Aug 25, 2008 at 5:54 PM, Eelco Hillenius <[EMAIL PROTECTED]>wrote: Neato. Hey, would it be possible to have 'fitted' T-shirts as well besides 'standard' fit? I like to show off my beer belly when I can. Same here, except I want the 6pack protruding through Eelco On Mon, Aug 25, 2008 at 7:42 AM, Nino Saturnino Martinez Vazquez Wael <[EMAIL PROTECTED]> wrote: I guess we should link to the merchandise page from the wiki also? James Carman wrote: The proceeds should benefit the ASF, not a random charity. On Mon, Aug 25, 2008 at 5:48 AM, Nino Saturnino Martinez Vazquez Wael <[EMAIL PROTECTED]> wrote: I haven't heard anything from prc @ apache that we could not do this, so im gonna take this as silent approval. So any profit from merchandise could be donated following these rules, if 1's full then 2 etc (providing the people want it): 1. Provide the core team with merchandise (might be the ordinary stuff with a comitter stamp on) 2. Provide the wicket stuffers with merchandise (might be the ordinary with a stuffer comitter stamp on) 3. Merchandise for critical patchers 4. Random Charity So without further restraints, I now declare the shop open: http://www.cafepress.com/apachewicket You can now surprise your loved one with a teddy bear, and later with the wonderful Apache Wicket boxer shorts. Btw: if you find any problems with some of the merchandise please write me. Input are welcome. -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ryan Gravener http://twitter.com/ryangravener - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I'm adding a new item to a ListView via ajax - how to get reference to the new item?
use AjaxRequestTarget.get()
Am 17.08.2008 um 15:36 schrieb Martin Grigorov:
On Sun, 2008-08-17 at 13:36 +0200, Wayne Pope wrote:
Hi,
But how do I get that target?
As the items are being rendered using a ListView - the only time I
can get
access is during the populateItem - but thats a ListItem, I need a
AjexRequestTarget to append the javascript?
You could append Javascript at render time (in
populateItem(ListItem())
by adding AjaxCallDecorator to your AjaxButton.
Or with AttributePrepender/Appender for the 'onclick' AjaxButton
attribute
On Sun, Aug 17, 2008 at 1:28 PM, Vitaly Tsaplin <[EMAIL PROTECTED]
>wrote:
Hi,
The item is already on your page so just use its html id in the
javascript script you use to highlight it.
Vitaly
On Sun, Aug 17, 2008 at 1:22 PM, Wayne Pope
<[EMAIL PROTECTED]> wrote:
Hi everyone,
I have a ListView that displays a list of cars (say).
I have a small form on the page whereby they can add a new car
using a
AjaxFallbackButton.
I can enter a new car and it updates the ListView
However I want to highlight the newly added item, and I just
can't seemt
to
figure out how I can 'target' the item.
I'd like to do something like
protected void onSubmit(AjaxRequestTarget target, Form arg1) {
// add new car...
if (target!=null) {
target.addComponent(carList);
target.addCompoent(.addJavascript(new
Effect.Highlight(this).toJavascript()));
}
- the question is how do I get the target reference to the new item
added?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
I don't need nearly as much extensions for wicket because it's such a no-brainer to write my own custom components... I think JSF is a big joke with nobody laughing :) my 2 % Cheers Peter Am 07.08.2008 um 17:59 schrieb Timm Helbig: Sorry, not really. *) JSF doesn't consume less Memory over Wicket. But this is not really an Argument since Hardware isn't that expensive today. *) Maybe the availability of Millions of extension Libraries for JSF. *) EL Tags are quite useful, but IMHO just another way to do the same thing. Regards, Timm Am Donnerstag, 7. August 2008 08:44:22 schrieb nlif: Thanks Timm. This is valuable feedback. Nevertheless - can you point to any advantage JSF has over Wicket? Anything at all? Thanks Timm Helbig wrote: Hi, I did one Project with JSF and two with Wicket. By far Wicket is much easier to handle, (nearly) everything works as supposed, which is not true for JSF, especially when it comes to external Libraries like Trinidad or other UI Extension Libraries. One other thing which is important for me is the Productivity. And this is much higher with Wicket than with JSF. The Community support is suberb with Wicket, and somewhat difficult when you check the JSF Forums, but this depends on the Manufactor of the Library you use. I don't want to slash JSF here, but I find it is miles away from a usable Product. For me it looks more like a prototype of what could be possible. Just check what happened from 1.1 to 1.2, and you see, that even Sun seemed to face this. Regards, Timm Am Mittwoch, 6. August 2008 11:13:53 schrieb nlif: Hi all, We are in the process of selecting a web-framework, and although I am in favor of Wicket, I was asked to provide an objective comparison of Wicket with JSF. I have developed a few small apps in Wicket, but I admit I am not very familiar with JSF. Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. Although this is the Wicket forum, I expect there are people here who also used (or at least evaluated) JSF at some point, so I'd be happy if folks here could share their experience. If anyone can point me to useful links that would be great too. I really am not trying to provoke a flame war, just to gather information. In your opinion, what are Wicket strengths? What are JSF's ? (even if you're a Wicket fan, surely there's something ;) I would be interested to hear people thoughts regarding the fact the JSF is a standard, while Wicket is not. How important is that to you? In what ways do you think this matters (if at all)? Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). Many thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
Even Mac guys agree that development by Sun would be much better :-)
They still lag behind with java 1.6 (no current 1.6.0_07), do not
support powerpc for 1.6 anymore, can't run 32bit on 1.6 and can't run
64bit on 1.5 etc.
Yeah, java by apple suckzz !
Am 17.07.2008 um 16:08 schrieb Johan Compagner:
the mac jvm is really horrible
We really develop eclipse/swing applications for 8 years now and
throughout
all those years if there is a jvm specific problem
Its the mac, its always the mac, For me it is already so far that i
really
hate everything that is a mac.
When they released leopard i think we have to do stuff like this in
our
swing code base:
// MAC FIX
@Override
public Insets getMargin()
{
Insets insets = super.getMargin();
if (insets == null)
{
insets = new Insets(0, 0, 0, 0);
}
return insets;
}
Else we would get null pointers deep in there look and feel.
And that is just a small example. we have in our code base all over
the
place things like // mac fix
There is only one other company that also kind of does that but on a
smaller
level because it just touches a smaller part of java (jdbc) and thats
oracle.
if (oracle) do this
else do that..
But oracle just do that because the can and they are big and they
just want
everybody tied to there implementation of jdbc and there way of doing
With the mac it is just apple cant do the job
I look forward to the day that apple just drops the jvm development
and let
sun do it.. Then we finally are liberated of that apple crap
johan
On Thu, Jul 17, 2008 at 3:50 PM, Brill Pappin <[EMAIL PROTECTED]> wrote:
Actually, I use a Mac now (vista prompted the purchase) and the Mac
JVM is
actually not much different... in fact I don't notice anything at
all when
working with java unless I'm doing something low lever like trying
to load a
YourKit agent... but even then its not so different.
If your using swing and want to use the Mac LAF then you have to
consider
the way the UI works, but even then its pretty portable.
I don't know if anyone is truly concerned about how well it works,
but
there is the result of my recent experience.
- Brill
On 17-Jul-08, at 5:34 AM, Johan Compagner wrote:
if you target Java 5 by using webstart
then there isnt to much of a problem just with that
But yes you do have especially with the mac the different jvm
problems as
you have with browsers :(
But happily not that many problems (there are way more different
browsers
and platforms) and if i have to say only one really bugs me (mac)
johan
On Thu, Jul 17, 2008 at 10:50 AM, Martijn Dashorst <
[EMAIL PROTECTED]> wrote:
This only holds true if you have the full deployment environment
under
control: Java for OS X is much different than Java for Windows, as
Johan can attest for. Just as with browsers you have to consider
folks
that don't update their JDK's, and many corporate IT guys don't
want
to update anything (including browsers!). So probably the easiest
deployment platform still remains the browser, since most shops do
have at least IE6 (while a shitty product in itself, it is
manageable
to get it to work).
Deployment of anything, even web apps is an exciting thing in
Corporations.
Martijn
On Thu, Jul 17, 2008 at 10:18 AM, Michael Allan <[EMAIL PROTECTED]>
wrote:
Zappaterrini, Larry wrote:
Your reason is a special instance of a much more general
reason. Web
applications are much easier to deal with from a deployment
perspective than desktop applications.
I don't know, it's not difficult to set up an RMI server, or to
deploy
a Swing client with Web Start (gives the user a single-click
launch
from the browser). I've done it, and frankly it's easier than
messing
with Tomcat and Web frameworks (no offense to Wicket).
And any developer who's coded a GUI using a proper toolkit, such
as
Swing, will never willingly trade it for a Web framework. (A
big part
of the attraction of Wicket is its Swing-like, component
design. But
it can't approach the real thing.)
Also, there are firewall and security issues surrounding access to
central data repositories that web applications handle nicely.
That security coddling is a mixed blessing. The browser's
sandbox,
for instance, makes it a complicated business to provide the
user with
normal access to resources on the desktop. With Swing, your app
is a
full peer on the desktop.
True, there are firewall and NAT hurdles for RMI clients. I
googled
for "RMI over HTTP" and "HTTP tunneling", and I didn't get a
comfortable, reassuring response. Why is that? It's a
mystery... It
should be a well beaten path.
--
Michael Allan
Toronto, 647-436-4521
http://zelea.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
However this will not be true if you change the render strategy *imho* getRequestCycleSettings ().setRenderStrategy(IRequestCycleSettings.ONE_PASS_RENDER) +1 for applying the patch as it's not only a matter of correctness but also of taste Am 02.07.2008 um 16:06 schrieb Johan Compagner: what does it matter how the urls that are inside the html look like? Its all about how the urls look like in the browsers url bar right? On Wed, Jul 2, 2008 at 6:59 AM, David Leangen <[EMAIL PROTECTED]> wrote: once again, i dont see what this offers over the hybrid strategy. Maybe you can correct me if I'm wrong here... The hybrid stategy is only applied when the target is an IBookmarkablePageRequestTarget. So, for normal bookmarkable pages, there is no problem, like you say. The issue only arises when a page is mounted, but is used in a stateful way (for example it has a form or something). In that case, the target becomes an IListenerInterfaceRequestTarget. When this is the case, the hybrid strategy is not used. This is the case that the patch is intended for. -dml- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
+1 -- sounds reasonable, doesn't break anything (hopefully :-), easier path-based security on apache front end proxy, Good work, David :-) Am 30.06.2008 um 07:33 schrieb David Leangen: Wouldn't this be useless except from the fact of been "pretty" ? Yes, it would indeed be "useless" in that functionally, it contributes nothing. It also takes nothing away. So by definition I guess that's a refactoring. The purpose of this refactoring, just like any other for that matter, is to better communicate intent. Cheers, David On Mon, Jun 30, 2008 at 2:12 AM, David Leangen <[EMAIL PROTECTED]> wrote: Currently, when a target is an instance of IListenerInterfaceRequestTarget, the URL gets "mounted" (so to speak) on the root of where the wicket application is located. So, if the servlet context path for the wicket application is set to /home/, then all targets (whether bookmarkable or not), are written as something like /home/?wicket:interface=:0. This works, but I think it somewhat defeats the purpose of having mounted pages. Rather, I think it would be better that when the target is an instance of BookmarkablePageRequestTarget, since we can get the target path easily, we should therefore write the URL to that target path, and not the application's root path. So, if I have a form on a page mounted at /home/myform, the above link gets rendered as /home/myform/?wicket:interface=:0 instead. Now, I perfectly understand that this type page has state, so is no longer bookmarkable. However, at least we can preserve the "pretty URL" aspect of the page, which IMO is the original intent. [On that topic, I notice that people often confuse the two related-but-different topics of "pretty urls" and "bookmarkable pages". I wonder if there isn't a better way of formalising the two concepts so people get less confused... no ideas, just thinking out loud.] Anyway, I tried this out by modifying WebRequestCodingStrategy. The fix is quite simple and it appears to work without any problems. If you think this is a reasonable proposal, I will create an issue and submit my patch. Thank you! David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Home page accepting IndexedParamUrlCodingStrategy
pseudo code example:
mount("/", ... indexed HomePage.class)
mount("/foo", FooPage.class)
What should happen with this path:
url = /foo
-> call HomePage with indexed parameter 'foo' ?
-> call page FooPage.class ?
not having indexed urls for '/' makes sense for me
Am 27.06.2008 um 19:59 schrieb Tauren Mills:
Does anyone have suggestions on how to do this? Or is it just not
possible to use IndexedParamUrlCodingStrategy without a mount point
(from the root of the site)?
Thanks!
Tauren
On Thu, Jun 26, 2008 at 3:53 PM, Tauren Mills <[EMAIL PROTECTED]>
wrote:
Thanks for the suggestion, but I'm unclear on how to mount the home
page on "/". I guess that is the main problem I'm having. Before
adding PageParameters to the page, I used this:
mountBookmarkablePage("/home", HomePage.class);
With that, going to localhost:8080/ would redirect to
localhost:8080/home. Then I changed it to the following:
mount(new IndexedParamUrlCodingStrategy("/home",
HomePage.class));
//mountBookmarkablePage("/home", HomePage.class);
Everything still worked the same (going to site root would redirect
to
/home), but it would also accept parameters. Functions perfectly,
but
I need to get rid of the /home mount point. So I tried this:
mount(new IndexedParamUrlCodingStrategy("/", HomePage.class));
//mount(new IndexedParamUrlCodingStrategy("/home",
HomePage.class));
//mountBookmarkablePage("/home", HomePage.class);
Doing so gives a 404 error when I go to the root of the site. So how
do I mount the home page on "/"? I tried both "" and "/".
MyWebApplication:
public Class getHomePage() {
return HomePage.class;
}
protected void init() {
super.init();
mount(new IndexedParamUrlCodingStrategy("/", HomePage.class));
//mount(new IndexedParamUrlCodingStrategy("/home",
HomePage.class));
//mountBookmarkablePage("/home", HomePage.class);
}
Jetty launcher code (for testing):
WebAppContext context = new WebAppContext();
context.setServer(server);
context.setContextPath("/");
context.setWar("src/webapp");
web.xml:
wicketsite
org.apache.wicket.protocol.http.WicketServletservlet-class>
applicationFactoryClassName
value>org.apache.wicket.spring.SpringWebApplicationFactoryvalue>
1
wicketsite
/*
Thanks for the help!
Tauren
On Thu, Jun 26, 2008 at 3:38 PM, David Leangen <[EMAIL PROTECTED]>
wrote:
IIUC, the home page is automatically mounted on the path where you
wicket
app is located.
So, if you put your wicket on "/home", then the home page will be
mounted on
/home.
Guess you'll need to put your home page on "/" to make this work.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Tauren Mills
Sent: 27 June 2008 07:30
To: users@wicket.apache.org
Subject: Home page accepting IndexedParamUrlCodingStrategy
How do I go about making my HomePage accept index parameters? I
want
a home page that will accept URLs like:
localhost:8080/us/ca/sacramento
Instead of having a mount point first, for example /home:
localhost:8080/home/us/ca/sacramento
I've tried this in my app:
getHomePage() {
return HomePage.class;
}
init() {
mount(new IndexedParamUrlCodingStrategy("/", HomePage.class));
}
This returns in a 404 error for the home page (localhost:8080/). I
also tried with "" instead of "/" as the mount point, but the same
problem.
If I use this with the /home mount point, everything works
perfectly:
mount(new IndexedParamUrlCodingStrategy("/home", HomePage.class));
FYI... I get the PageParameters in HomePage like this (which is
working fine);
setCountry(pageParams.getString("0",null));
setState(pageParams.getString("1",null));
setCity(pageParams.getString("2",null));
Any suggestions?
Thanks,
Tauren
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to send response without HTML code
I think this is what AbortWithWebErrorCodeException is for Am 11.06.2008 um 13:24 schrieb Erik van Oosten: Hi Milan, I think you should throw the exception AbortWithHttpStatusException. If you change your mind and want to set the HTTP status code, but provide content as well, then call something like ((WebResponse )getResponse ).getHttpServletResponse().setStatus(HttpServletResponse.SC_...) in the constructor of your page. Regards, Erik. Milan Křápek schreef: Thanks for response but this is not th exact thing I want. I need to know the name of wicket component, where can I get access to request from user and fill the response for him. All I need is some parent class of WebPage. But this object must return just http code without any HTML. (I was not able to send response from WebPage without having any addititonal HTML file ). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Strong typing is my friend. Refactoring is my friend. The stronger and clearer we make typing throughout Wicket the happier I'll be. Code is written once and maintained a hundred thousand times. I'd always trade verbosity for maintainability. +1 for that --- very nice said! I totally agree :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket generics
+1 for do it right, no matter if the api breaks or not
Am 07.06.2008 um 09:20 schrieb Igor Vaynberg:
so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design
class component {
public void setmodel(imodel model) {...}
public imodel getmodel();
}
that is all good until you want to have a generified subclass eg a
listitem:
class listitem extends component {
public imodel getmodel() { return (imodel)super.getmodel(); }
<== works like a charm
public void setmodel(imodel model) {..} <== woops, compilation
error
Name clash: The method setModel(IModel) of type ListItem has the
same erasure as
setModel(IModel) of type MarkupContainer but does not override it
unfortunately the error makes sense and there is no way around it.
same goes for setmodelobject(). i think this makes this design variant
pretty useless. as long as we have the model coupled to component i
dont see a clean way of doing this :(
class listitem extends component {
public imodel getmodel(..);
public void setmodel(imodel model);
}
looks half baked and broken by design
i would almost reconsider 1.4 and its scope and opt to include a model
decoupling (however and if that is possible) refactor in it. otherwise
i fear we will break the whole generics model again in 1.5 and users
will have to relearn how to use them with wicket.
so as far as i can see, and this is only my opinion, our options are:
continue 1.4 as it is now with fully typed components
remove component type but make the api ugly ( i will let matej
explain )
attempt to fix 1.4 by decoupling model from component - 1.4 takes a
lot longer and is not a simple "drop-in/upgrade/whatever"
thoughts and ideas?
-igor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
I remember that having more than one wildcard in an type expression seems to be inherently broken. Usually you can rewrite something like void foo(Class> pageClass) into something like > void foo(Class pageClass) I would bet this solves your problem :-) However, nobody can explain why... :-( Probably some lack of the generics specification, broken compiler, or whatever... I would suggest to avoid more than one wildcard in one type expression in general and use above workaround. Cheers Peter Am 04.06.2008 um 10:10 schrieb Johan Compagner: Yeah it is very strange that you get different errors in eclipse and javac. I wonder which one is correcct.. But you have to generify the Page then it should work fine (like ) I think we just need to drop the in that example What do you exactly call? johan On Wed, Jun 4, 2008 at 9:39 AM, Rod Good <[EMAIL PROTECTED]> wrote: Hi, I'm getting inconvertible type errors when I compile from Maven on the command line with Java 6. Does anyone know if this issue was resolved ? I am building against 1.4-m2 - downloaded today (04-06-2008). The issue is the same as noted by Ryan Mckinley on 05/21/2008 : strangely, things work fine for me in eclipse, but from the command line, I still get: $ mvn clean install: /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/ website/ wicket/page/DownloadingPage.java:[18,97] inconvertible types found : java.lang.Class required: java.lang.Class> I ran: mvn clean install in the wicket directory... Not sure if the java version is helpful: ryan$ mvn -version Maven version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp Thanks, Rod. NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Group Limited or third parties. If you are not the intended recipient of this email you should not read, print, re- transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Group Limited does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Group Limited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: decode() in WebRequestCodingStrategy
Eventually you might be interested in https://issues.apache.org/jira/browse/WICKET-1666 Am 02.06.2008 um 09:02 schrieb reikje: why do you want to add extra params in the RequestParameters? The use case is this. The request comes in with a URL like "/press/article/headline.html". I will take the URL and look up which Content node this "path" maps to in our CMS. Then I would like to add the id of this Content node into the RequestParameters for later processing. reikje wrote: I am trying to implement a custom WebRequestCodingStrategy. In the decode methode, I would like to add some custom parameters in the RequestParameters object that is returned. I can add whatever I want in addBookmarkablePageParameters(..) - perfect. However, all of my parameters are completly ignored as WebRequestCodingStrategy.decode will only return the parameters that were previously in the Request. Is that supposed to be like this? I was expecting that I could add individual parameters in a method called addBookmarkablePageParameters. I choosed to do that in WebRequestCodingStrategy because I don't want to mount anything. -- View this message in context: http://www.nabble.com/decode%28%29-in-WebRequestCodingStrategy-tp17460040p17595176.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. 2) How strongly do you feel about your choice above? [X ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. Cheers Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AutoCompleteTextField - autocomplete multiple fields
I filed an issue in April 2007 (the patch probably unusable right now)
to support autocompleting multiple fields
https://issues.apache.org/jira/browse/WICKET-488
An example would be to select an address from the autocompleter which
will fill in the fields for street, zip code, city, etc.
The basic idea was to change this line in the wicket-autocompleter.js:
obj.value=getSelectedValue();
which can only replace the value of one dom object with something like
if(handleSelection(value)) // execute optional
'onselect' handler
obj.value = value;
function handleSelection(input) {
var menu = getAutocompleteMenu();
var attr =
menu.firstChild.childNodes[selected].attributes['onselect'];
if(attr)
return eval(attr.value)(input);
else
return true;
}
all the generated list items of the autocompleter html could
optionally have an onselect attribute to execute arbitrary javascript
autocompleter item #1
autocompleter item #2
Maybe this almost dead issue could be revived if you like the idea ...
(In that case I wouldn't mind update the patch for current 1.3.x and
1.4.x)
Cheers
Peter
Am 30.05.2008 um 09:23 schrieb Roland Huss:
Hi Daniel,
Daniel Stoch-2 wrote:
The main
problem is that the AutoCompleteTextField and related classes
(behavior, renderer) are not easily to extend (eg. it is necessary to
make a few modifications in wicket-autocomplete.js but in
AbstractAutoCompleteBehavior the standard js is added in renderHead
method, so there is no way to replace it, etc.). So I must made a
copy
of these standard classes and then made modifications in them.
I had the same problem with extending AbstractAutoCompleteBehavior
while
working on wicketstuff-objectautocomplete and I already
opened a Jira issue for that. You might want to vote for
https://issues.apache.org/jira/browse/WICKET-1651 which provides a
patch for
putting AACB's renderHead() logic into a protected initHead()
method, which
then
can be overwritten by a subclass and AACB.super.renderHead() is still
called.
...roland
--
View this message in context:
http://www.nabble.com/AutoCompleteTextField---autocomplete-multiple-fields-tp17500271p17553097.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: hi everyone, does anyone know how can we use RESTFUL in wicket?
Yeah, I know... the patch I committed is about having "indexed urls" like "/blog/2008/06/13/hello.html" with "/blog" being the resource mount path so "/2008/06/13/hello.html" are the actual parameters having "/blog?year=2008&month=06&day=13&item=hello.html" doesn't look so nice and is not so much of REST *imho* Am 29.05.2008 um 17:05 schrieb Johan Compagner: we already can mount shared resources and you can give them parameters so that you dont have to have session but can create the same resource depending on the params johan On Thu, May 29, 2008 at 5:01 PM, Peter Ertl <[EMAIL PROTECTED]> wrote: I just uploaded a patch a few days ago to support indexed resource urls. Hopefully the wicket devs will apply it to the codebase. I guess it would be a good base for RESTful resources without explicit session state. It's like Martijn describes, but for shared resources. Cheers Peter Am 29.05.2008 um 16:24 schrieb Martijn Lindhout: Where do you want to use REST for in your app? I use some REST url's in mij application using the IndexedParamUrlCodingStrategy (of course REST is far more than URL's only...). Sample URL's are: /activate/ - Activates a profile after initial signup /profile/scott - shows Scott's profile /reset/scott - Resets Scott's password 2008/5/27 Brill Pappin <[EMAIL PROTECTED]>: There's that word I keep hearing... "should" :) Actually I keep saying it too, and give myself a slap. IMO, REST is great for services, but it's pretty strict in terms of what is "RESTful". I think something *like* wicket could work in a RESTful way, but Wicket does not and I doubt ever will (if it ever does, it won't be wicket code your using today). - Brill Pappin -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Monday, May 26, 2008 12:02 PM To: users@wicket.apache.org Subject: Re: hi everyone, does anyone know how can we use RESTFUL in wicket? But REST is how http/internet should work! On Mon, May 26, 2008 at 5:59 PM, Igor Vaynberg <[EMAIL PROTECTED] > wrote: rest is for services, wicket is for ui. why does anything need to be integrated? -igor On Mon, May 26, 2008 at 7:47 AM, shrimpywu <[EMAIL PROTECTED]> wrote: hi everyone, does anyone know how can we use RESTFUL in wicket? now the RestFul framework is quite popular.. doest anyone know how can we put it into wicket?? do we need to integrate some other framework with wicket? or wicket already support that? -- View this message in context: http://www.nabble.com/hi-everyone%2C-does-anyone-know-how-can-we-use-R ESTFUL-in-wicket--tp17473242p17473242.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hi everyone, does anyone know how can we use RESTFUL in wicket?
Damn it, forgot to mention the jira issue: https://issues.apache.org/jira/browse/WICKET-1666 I don't think there already something in wicket like this... Am 29.05.2008 um 17:01 schrieb Peter Ertl: I just uploaded a patch a few days ago to support indexed resource urls. Hopefully the wicket devs will apply it to the codebase. I guess it would be a good base for RESTful resources without explicit session state. It's like Martijn describes, but for shared resources. Cheers Peter Am 29.05.2008 um 16:24 schrieb Martijn Lindhout: Where do you want to use REST for in your app? I use some REST url's in mij application using the IndexedParamUrlCodingStrategy (of course REST is far more than URL's only...). Sample URL's are: /activate/ - Activates a profile after initial signup /profile/scott - shows Scott's profile /reset/scott - Resets Scott's password 2008/5/27 Brill Pappin <[EMAIL PROTECTED]>: There's that word I keep hearing... "should" :) Actually I keep saying it too, and give myself a slap. IMO, REST is great for services, but it's pretty strict in terms of what is "RESTful". I think something *like* wicket could work in a RESTful way, but Wicket does not and I doubt ever will (if it ever does, it won't be wicket code your using today). - Brill Pappin -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Monday, May 26, 2008 12:02 PM To: users@wicket.apache.org Subject: Re: hi everyone, does anyone know how can we use RESTFUL in wicket? But REST is how http/internet should work! On Mon, May 26, 2008 at 5:59 PM, Igor Vaynberg <[EMAIL PROTECTED] > wrote: rest is for services, wicket is for ui. why does anything need to be integrated? -igor On Mon, May 26, 2008 at 7:47 AM, shrimpywu <[EMAIL PROTECTED]> wrote: hi everyone, does anyone know how can we use RESTFUL in wicket? now the RestFul framework is quite popular.. doest anyone know how can we put it into wicket?? do we need to integrate some other framework with wicket? or wicket already support that? -- View this message in context: http://www.nabble.com/hi-everyone%2C-does-anyone-know-how-can-we-use-R ESTFUL-in-wicket--tp17473242p17473242.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hi everyone, does anyone know how can we use RESTFUL in wicket?
I just uploaded a patch a few days ago to support indexed resource urls. Hopefully the wicket devs will apply it to the codebase. I guess it would be a good base for RESTful resources without explicit session state. It's like Martijn describes, but for shared resources. Cheers Peter Am 29.05.2008 um 16:24 schrieb Martijn Lindhout: Where do you want to use REST for in your app? I use some REST url's in mij application using the IndexedParamUrlCodingStrategy (of course REST is far more than URL's only...). Sample URL's are: /activate/ - Activates a profile after initial signup /profile/scott - shows Scott's profile /reset/scott - Resets Scott's password 2008/5/27 Brill Pappin <[EMAIL PROTECTED]>: There's that word I keep hearing... "should" :) Actually I keep saying it too, and give myself a slap. IMO, REST is great for services, but it's pretty strict in terms of what is "RESTful". I think something *like* wicket could work in a RESTful way, but Wicket does not and I doubt ever will (if it ever does, it won't be wicket code your using today). - Brill Pappin -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Monday, May 26, 2008 12:02 PM To: users@wicket.apache.org Subject: Re: hi everyone, does anyone know how can we use RESTFUL in wicket? But REST is how http/internet should work! On Mon, May 26, 2008 at 5:59 PM, Igor Vaynberg <[EMAIL PROTECTED] > wrote: rest is for services, wicket is for ui. why does anything need to be integrated? -igor On Mon, May 26, 2008 at 7:47 AM, shrimpywu <[EMAIL PROTECTED]> wrote: hi everyone, does anyone know how can we use RESTFUL in wicket? now the RestFul framework is quite popular.. doest anyone know how can we put it into wicket?? do we need to integrate some other framework with wicket? or wicket already support that? -- View this message in context: http://www.nabble.com/hi-everyone%2C-does-anyone-know-how-can-we-use-R ESTFUL-in-wicket--tp17473242p17473242.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
+1 for finishing generics (no matter how ugly it gets), then
refactoring / removing the things that suck
Am 22.05.2008 um 11:37 schrieb Johan Compagner:
exactly Repeaters is very nice that the populateItem is generified..
I think
that is really handy..
And if the EditPage now wanted a specific type then you need now to
cast at
that place..
I thing that the example below is exactly the thing that generics
are pretty
good:
populateItem(ListItem item) {
add(new Link("edit", item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
(and EditPage is by itself already generified to )
This is just a perfect thing that i say yes very nice you see
exactly what
the code should do
and cant say that this is really verbose..
johan
On Thu, May 22, 2008 at 11:28 AM, Martijn Dashorst <
[EMAIL PROTECTED]> wrote:
I often do the following:
populateItem(ListItem item) {
add(new Link("edit", item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
}
So both are used often, but mostly to pass things around.
Martijn
On Thu, May 22, 2008 at 11:25 AM, Johan Compagner <[EMAIL PROTECTED]
>
wrote:
getModel() i agree, but getModelObject() is something that is used
the
most
if i have to guess.
Because in an onSubmit() of a form or a onClick of a Link what do
most of
you do?
onSubmit()
{
dao.save(getModelObject())
}
onClick()
{
dao.delete(getModelObject())
}
johan
On Thu, May 22, 2008 at 10:05 AM, Matej Knopp
<[EMAIL PROTECTED]>
wrote:
Although I'm not sure how many people call getModel/getModelObject
anyway. I think it's mostly about ListItems etc an i doubt anyone
would subclass it just because of getModel/getModelObject...
-Matej
On Thu, May 22, 2008 at 10:04 AM, Matej Knopp <[EMAIL PROTECTED]
>
wrote:
I would all be easier if getModel() and getModelObject() weren't
final. (I know there's a reason why they are, I'm not
questioning it).
Then in your component subclass you coud do IModel
getModel()
{ return (IModel)super.getModel() }, similiar with
getmodelobject so you wouldn't have casts all over places and it
would
be safer too).
-Matej
On Thu, May 22, 2008 at 9:39 AM, Johan Compagner <
[EMAIL PROTECTED]>
wrote:
It isnt all or nothing.. i never said that
I just say if you dont want Component but you do want IModel
then you will get a warning at getModel()
we as a framework shouldnt hide the warning at that call.
But i am also curious how many people get really the model back
from
a
component (not counting specific places like
repeaters.onpopuplate)
because i think most people do component.getModelObject() which
then
needs a
cast
But i like that extra helper method way more then having an extra
getUnsafeModel() method..
because thats explicit a developer has to really choose for it.
i think there are 3 options
1> keep it what we have now, tweak it with the feedback we get
from
1.4M2
2> drop it on Component only and have a class like you described
above
to do
this: IModel model =
Unsafe.cast(component.getModel()); (its
still
a hack and a sense of false security but ok. if people really
want
this..)
3> drop it on Component and Model
i am +1 on 1
and -0 on 2 and 3
I still think it is not bad. and you can come around it really
easy
by
just
creating a few extra classes like
StringLabel
NumberLabel
StringTextField
NumberTextField
if you only have a few of those extra all your code is cleanup
johan
On Thu, May 22, 2008 at 9:12 AM, Joni Freeman
<[EMAIL PROTECTED]>
wrote:
Yeah, it could even be in its separate utility class:
interface IModel {}
class Component {
private IModel model;
public IModel getModel() {
return model;
}
}
public class Unsafe {
public static IModel cast(IModel model) {
return (IModel) model;
}
}
class MyComp extends Component {
public MyComp() {
IModel model = Unsafe.cast(getModel());
}
}
I'm merely pointing out that there exists a solution to do
unsafe
cast
without getting compiler warning. Just like normal casts are
handled.
I don't think Johan's all or nothing proposition is very
pragmatic
one.
Without generic IModel we do not get any API discoverability
and our
APIs continue to suck. For instance, how can API user know
what kind
of
model this needs: MyJuicyComponent(String id, IModel model).
At one
point we did this: MyJuicyComponent(String id, IModel/
**/
model) but this convention is far from optimal. To be sure, one
needs
to
browse the sources...
Joni
On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
Well, maybe it really is a hack that's too ugly. We might
have two
methods,
default getModel() that doesn't cast it and alternative
convenience
one that does.
-Matej
On Wed, May 21, 2008 at 10:10 PM, Matej Knopp <
[EMAIL PROTECTED]
wrote:
class Component {
private IModel model;
Re: (Class>) casting troubles
Maybe this can help a little: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6384510 (verified with java 1.5 on mac os x leopard) Am 21.05.2008 um 11:13 schrieb Martijn Dashorst: On Wed, May 21, 2008 at 11:03 AM, Johan Compagner <[EMAIL PROTECTED] > wrote: if we drop that then we can pretty much drop also model Not sure. I think having Component(String id, IModel model) is a good thing. However, generifying Component further to get rid of the cast when doing getModelObject() or getModel() turns out not to be great. Because the model goes into the Component and gone is the generified model. I don't have a direct problem with that. The generics of Component are really hard on the eye and the brain. We are trying to make things simpler and clearer. Having Component(String id, IModel model) makes things clearer. For example the DropDownChoice that is generified now makes sure that i have a lot less explaining to on this list.. Yes, I am not in favor of dropping DDC(String, IModel, IModel>). I am in favor of dropping the generics from the Component class definition. Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
Also if you use CompoundPropertyModels (widely used) then generics are completely not used anymore at all.. Speaking for me, I never use expression based property models in any mid- to large-sized project to have complete(!) refactoring support in my IDE. String expression are a lot less verbose than static bindings, that true. But once I rename a bean property that get's accessed in a component or page the change will not affect the string expression of PropertyModels and friends. So there will be nice runtime errors. Static binding is your friend here. So I favor for keeping generics (even though it hurts sometimes). Cheers Peter Am 21.05.2008 um 11:03 schrieb Johan Compagner: if we drop that then we can pretty much drop also model Because the model goes into the Component and gone is the generified model. Also if you use CompoundPropertyModels (widely used) then generics are completely not used anymore at all.. So what do we gain then? For example the DropDownChoice that is generified now makes sure that i have a lot less explaining to on this list.. On Wed, May 21, 2008 at 10:54 AM, Martijn Dashorst < [EMAIL PROTECTED]> wrote: Am I the only one who gets confused with all those <>? Can't we just drop the component generification? I see a lot of problems and type duplication for little gain. I think having IModel generified is a good thing because it allows you to specify types on your component constructors. Martijn On Wed, May 21, 2008 at 10:38 AM, Gerolf Seitz <[EMAIL PROTECTED] > wrote: On Wed, May 21, 2008 at 10:30 AM, Johan Compagner <[EMAIL PROTECTED] > wrote: always strange that that works If you just look at it then it seems to be the same thing :) tbh, i would still like to get an explanation _why_ it works with > and not directly with Component>. Gerolf -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
I suspect the multiple wildcards (?) in one type expression causing
all that trouble.
probably an issue of the compiler and not of the language spec.
public class Test
{
public static void main(String[] args)
{
bad(Derived.class); // ok
bad(Base.class); // compile error
good(Derived.class); // ok
good(Base.class); // ok
}
public static void bad(Class> clazz)
{ // ^^ two wildcards in one expression:
// uh oh, calling for trouble!
}
public static > void good(Class clazz)
{
//
}
public static class Base
{
}
public static class Derived extends Base
{
}
}
Am 21.05.2008 um 10:38 schrieb Gerolf Seitz:
On Wed, May 21, 2008 at 10:30 AM, Johan Compagner <[EMAIL PROTECTED]
>
wrote:
always strange that that works
If you just look at it then it seems to be the same thing :)
tbh, i would still like to get an explanation _why_ it works with
> and not directly with >>.
Gerolf
Re: Spring?
at this point because of the convenience and flexibility it offers. Guice looks nice, but the tool support isn't there yet. That's why I use guice. Because you don't even need tools :-) Am 21.05.2008 um 03:32 schrieb Nick Heudecker: I have to agree with James. I wouldn't build an application without Spring at this point because of the convenience and flexibility it offers. Guice looks nice, but the tool support isn't there yet. On Tue, May 20, 2008 at 7:22 PM, James Carman <[EMAIL PROTECTED] > wrote: A resounding YES to Spring! On Tue, May 20, 2008 at 8:04 PM, Bruce McGuire <[EMAIL PROTECTED]> wrote: Hello All. We are just starting a new version of an existing app, moving toward open source technologies. We have decided on using Wicket based on some prototypes we have done, and are using Hibernate for the models. Our question is this: do you recommend also adding Spring into the mix? There are aspects (no pun intended) of Spring that we like, but are unsure if the benefits (AOP, IOC) are worth the added effort. I appreciate your thoughts on this. Thanks, Bruce. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nick Heudecker Professional Wicket Training & Consulting http://www.systemmobile.com Eventful - Intelligent Event Management http://www.eventfulhq.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forum?
guice DOES support @Transactional (and any other AOP Alliance interceptor) it's called AbstractModule.bindInterceptor() Am 20.05.2008 um 22:33 schrieb James Carman: I'm interested. I just don't know about making it ORM and container agnostic. There are too many things you can do with Spring that I can't live without (like @Transactional annotations). On Tue, May 20, 2008 at 4:29 PM, Cristi Manole <[EMAIL PROTECTED]> wrote: I am interested in helping out. And I am sure others are too. I hope you keep going with this idea. Cristi Manole On Tue, May 20, 2008 at 11:26 PM, Peter Ertl <[EMAIL PROTECTED]> wrote: Don't forget to make it language independent so it runs on C#, Scala, Fortran or Algol 68 as well :-) Am 20.05.2008 um 22:15 schrieb James Carman: If you are creating a "product", why do you need to be able to plugin a different IoC container (Guice vs. Spring for example)? Do you think a site admin will honestly care which container you use (or ORM API for that matter)? 2008/5/20 Uwe Schäfer <[EMAIL PROTECTED]>: hi i remember someone asking for a wicket based forum few weeks ago. i plan to build one within the next few months. is there anyone interested in contributing code, ideas, reviews, tests or criticism? it is going to be as modular as i can get it, and should play nicely with guice as well as spring, jpa as well as hibernate or ibatis, etc... anyone interested in helping out? cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 Registrieren Sie sich unter http://morningnews.thomas-daily.de für die kostenfreien TD Morning News, eine Auswahl aktueller Themen des Tages morgens um 9:00 in Ihrer Mailbox. Hinweis: Der Redaktionsschluss für unsere TD Morning News ist täglich um 8:30 Uhr. Es werden vorrangig Informationen berücksichtigt, die nach 16:00 Uhr des Vortages eingegangen sind. Die Email-Adresse unserer Redaktion lautet [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forum?
Don't forget to make it language independent so it runs on C#, Scala, Fortran or Algol 68 as well :-) Am 20.05.2008 um 22:15 schrieb James Carman: If you are creating a "product", why do you need to be able to plugin a different IoC container (Guice vs. Spring for example)? Do you think a site admin will honestly care which container you use (or ORM API for that matter)? 2008/5/20 Uwe Schäfer <[EMAIL PROTECTED]>: hi i remember someone asking for a wicket based forum few weeks ago. i plan to build one within the next few months. is there anyone interested in contributing code, ideas, reviews, tests or criticism? it is going to be as modular as i can get it, and should play nicely with guice as well as spring, jpa as well as hibernate or ibatis, etc... anyone interested in helping out? cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 Registrieren Sie sich unter http://morningnews.thomas-daily.de für die kostenfreien TD Morning News, eine Auswahl aktueller Themen des Tages morgens um 9:00 in Ihrer Mailbox. Hinweis: Der Redaktionsschluss für unsere TD Morning News ist täglich um 8:30 Uhr. Es werden vorrangig Informationen berücksichtigt, die nach 16:00 Uhr des Vortages eingegangen sind. Die Email-Adresse unserer Redaktion lautet [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using generics with some non-generic classes in Wicket
taken from SUN's generic tutorial:
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
end of page 8
snip :::
interface Collection
{
public boolean containsAll(Collection c);
public boolean addAll(Collection c);
}
We could have used generic methods here instead:
interface Collection
{
public boolean containsAll(Collection c);
public boolean addAll(Collection c);
// hey, type variables can have bounds too!
}
snip :::
isn't addAll() that the same as
public void foo(Class< ? extends Component< ? >> clazz);
and
public > void foo(Class clazz);
???
seems like this is our first generic bug :-)
Am 15.05.2008 um 16:41 schrieb Peter Ertl:
this one will do:
public > void foo(Class clazz);
however, the subtle differences between this and igors version are
really hard to get.
Am 15.05.2008 um 16:31 schrieb Igor Vaynberg:
this is the usecase we are talking about. i get a compile error,
which sucks.
public class Test
{
public static void main(String[] args)
{
Foo foo = new FooImpl();
foo.foo(IntegerComponent.class); // ok
foo.foo(Component.class); // compile error
}
public static class Component {}
public static class IntegerComponent extends Component {}
public static interface Foo
{
public void foo(Class< ? extends Component< ? >> clazz);
}
public static class FooImpl implements Foo
{
public void foo(Class< ? extends Component< ? >> clazz) {}
}
}
-igor
On Wed, May 14, 2008 at 11:56 PM, Sebastiaan van Erk
<[EMAIL PROTECTED]> wrote:
Igor Vaynberg wrote:
well, apparently johan ran into a situation where component is
too
restrictive...
As I understand it, Johan ran into a situation where Component
causes
*warnings* for users who use raw types. Which I've been arguing
all along
that they SHOULD get: they should use Component or
Component
instead of raw types, or live-with/suppress the warning.
To make it clear, I made the following test class:
public class Test {
public void doTest(Test> test) {
System.out.println("test");
}
public static void main(String[] args) {
Test> test1 = newInstance(); // fine - no
warnings.
Test test2 = newInstance(); // not fine, use of
raw
type, warning
Test test3 = newInstance(); // not fine, use of raw
type,
warning
test1.doTest(test1); // fine - no warnings.
test1.doTest(test2); // error - generic types don't
match,
can be "fixed" by line below
test1.doTest((Test) test2); // warning - unchecked
conversion
test1.doTest(test3); // warning - unchecked conversion
}
public static Test newInstance() {
return new Test();
}
}
As you can see, there is only one case when you get a compile
error when
using the > generic type, and that is a case
where there
is on the user side an incorrect generic type: Test. The
user here
declares he's using generics, but then inserts a raw type of a
known generic
type - a situation that should not happen.
Regards,
Sebastiaan
-igor
On Wed, May 14, 2008 at 2:37 PM, Sebastiaan van Erk <[EMAIL PROTECTED]
>
wrote:
Igor Vaynberg wrote:
since then the thread has evolved into whether or not we should
use
extends Component> or >
-igor
I don't understand how that changes any of my points. The first is
incorrect
(from a generics point of view) since you're referencing an
unparameterized
generic type.
So the second gives warnings only in code that is not properly
generified...
Regards,
Sebastiaan
On Wed, May 14, 2008 at 1:54 PM, Sebastiaan van Erk
<[EMAIL PROTECTED]>
wrote:
Igor Vaynberg wrote:
i do like generics. did i ever say otherwise? the problem
here is that
if we scope something as Class then even
though
you ARE using generics in your code you will still get a
warning
because we did not scope the class as ClassComponent>.
on the other hand if we do scope it as ClassComponent>
then you can no longer pass a raw reference when calling the
function.
But that's exactly the point isn't it? If you're using
generics then
you
shouldn't be using raw Components anymore...
so we are screwed if we do and we are screwed if we dont, i
expected
generics to be better.
Well they definitely could have been better (erasure is
terrible if you
ask
me), but I don't see what's wrong in this case. It warns you
if you
should
be using a parameterized type but you don't.
And especially if you look at the vote result, I think the
majority
wants
the generics...
that vote was before we uncovered this issue. we voted on the
idea of
generics, not on the implementation.
That's true, but I wonder if this issue would change the vote
much. I
don't
really understand why it'
Re: Using generics with some non-generic classes in Wicket
this one will do:
public > void foo(Class clazz);
however, the subtle differences between this and igors version are
really hard to get.
Am 15.05.2008 um 16:31 schrieb Igor Vaynberg:
this is the usecase we are talking about. i get a compile error,
which sucks.
public class Test
{
public static void main(String[] args)
{
Foo foo = new FooImpl();
foo.foo(IntegerComponent.class); // ok
foo.foo(Component.class); // compile error
}
public static class Component {}
public static class IntegerComponent extends Component {}
public static interface Foo
{
public void foo(Class< ? extends Component< ? >> clazz);
}
public static class FooImpl implements Foo
{
public void foo(Class< ? extends Component< ? >> clazz) {}
}
}
-igor
On Wed, May 14, 2008 at 11:56 PM, Sebastiaan van Erk
<[EMAIL PROTECTED]> wrote:
Igor Vaynberg wrote:
well, apparently johan ran into a situation where component is
too
restrictive...
As I understand it, Johan ran into a situation where Component
causes
*warnings* for users who use raw types. Which I've been arguing all
along
that they SHOULD get: they should use Component or
Component
instead of raw types, or live-with/suppress the warning.
To make it clear, I made the following test class:
public class Test {
public void doTest(Test> test) {
System.out.println("test");
}
public static void main(String[] args) {
Test> test1 = newInstance(); // fine - no
warnings.
Test test2 = newInstance(); // not fine, use of
raw
type, warning
Test test3 = newInstance(); // not fine, use of raw
type,
warning
test1.doTest(test1); // fine - no warnings.
test1.doTest(test2); // error - generic types don't
match,
can be "fixed" by line below
test1.doTest((Test) test2); // warning - unchecked
conversion
test1.doTest(test3); // warning - unchecked conversion
}
public static Test newInstance() {
return new Test();
}
}
As you can see, there is only one case when you get a compile error
when
using the > generic type, and that is a case
where there
is on the user side an incorrect generic type: Test. The user
here
declares he's using generics, but then inserts a raw type of a
known generic
type - a situation that should not happen.
Regards,
Sebastiaan
-igor
On Wed, May 14, 2008 at 2:37 PM, Sebastiaan van Erk <[EMAIL PROTECTED]
>
wrote:
Igor Vaynberg wrote:
since then the thread has evolved into whether or not we should
use
extends Component> or >
-igor
I don't understand how that changes any of my points. The first is
incorrect
(from a generics point of view) since you're referencing an
unparameterized
generic type.
So the second gives warnings only in code that is not properly
generified...
Regards,
Sebastiaan
On Wed, May 14, 2008 at 1:54 PM, Sebastiaan van Erk
<[EMAIL PROTECTED]>
wrote:
Igor Vaynberg wrote:
i do like generics. did i ever say otherwise? the problem here
is that
if we scope something as Class then even
though
you ARE using generics in your code you will still get a warning
because we did not scope the class as ClassComponent>.
on the other hand if we do scope it as ClassComponent>
then you can no longer pass a raw reference when calling the
function.
But that's exactly the point isn't it? If you're using generics
then
you
shouldn't be using raw Components anymore...
so we are screwed if we do and we are screwed if we dont, i
expected
generics to be better.
Well they definitely could have been better (erasure is
terrible if you
ask
me), but I don't see what's wrong in this case. It warns you if
you
should
be using a parameterized type but you don't.
And especially if you look at the vote result, I think the
majority
wants
the generics...
that vote was before we uncovered this issue. we voted on the
idea of
generics, not on the implementation.
That's true, but I wonder if this issue would change the vote
much. I
don't
really understand why it's an issue, because you can use
generified
Components always: Component if you don't want to
constrain the
model object, and Component if you don't need a model.
The question that started the thread was about
StringResourceModel
which
was
not yet generified, and in that case, the warning seems to me
to be
perfectly ok: it just says StringResourceModel should be
generified.
It's
not a release yet, so that some users who use the current
snapshot run
into
these kind of warnings which cannot be removed seems to be fine
to
me...
Regards,
Sebastiaan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe
Re: Using generics with some non-generic classes in Wicket
wicket 1.6 = scala-based ? *lol* Am 14.05.2008 um 23:28 schrieb Eelco Hillenius: On Wed, May 14, 2008 at 2:25 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: the whole generics thing turned out to be quiet a lot crappier then i thought it would. :-) Generics for models: great. Generics for components: awful. Too bad that stuff is contagious. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using generics with some non-generic classes in Wicket
that's exactly what I am saying... It always pisses me off to see developers checking in code that delivers like 50-100 warnings and they don't care. warnings are a good thing. not so sure about generics (just kidding :-) Am 14.05.2008 um 22:41 schrieb Igor Vaynberg: well, maybe you get used to warnings, i tend to do something about them and clean up my code. i do not want to turn this warning off, because as you said yourself it is a very useful warning, if i turn it off i might as well not be using generics... -igor On Wed, May 14, 2008 at 1:38 PM, Peter Ertl <[EMAIL PROTECTED]> wrote: In IDEA it is annoying when you enable inspection 'Raw use of parametrized class' which is generally quite useful it will complain on protected boolean isPageAuthorized(final Class pageClass) so, no, you don't get a warning but a potentially useful inspection is more or less useless (warnings have no effect once you get used to them) Am 14.05.2008 um 22:29 schrieb Johan Compagner: how do users get in this situation a warning? if we as a framework say method(RawType type) then why would that give a warning in the caller method? We just say we accept raw type there johan On Wed, May 14, 2008 at 9:53 PM, Igor Vaynberg <[EMAIL PROTECTED] > wrote: then our users have to suppress warnings in their code, which is unacceptable at least to me. the whole generics thing turned out to be quiet a lot crappier then i thought it would. -igor On Wed, May 14, 2008 at 12:48 PM, Johan Compagner <[EMAIL PROTECTED] > wrote: yes then all the call to that method must be of a generic type. cant be raw i dont know what are we going to do in wicket i think we should decide it should we just where we dont care about generic delete/not use the and then supresswarning? johan On Wed, May 14, 2008 at 9:45 PM, Igor Vaynberg <[EMAIL PROTECTED] > wrote: so i just implemented IAuthorizationStrategy and on this line in my class: public boolean isInstantiationAuthorized(Class< ? extends Component> componentClass) i get: Component is a raw type. References to generic type Component should be parameterized so that means we have to change our sig to Component> but then we are back to the problem described in this thread. generics suck. -igor On Wed, May 14, 2008 at 12:12 AM, Johan Compagner <[EMAIL PROTECTED] wrote: I dont think that user gets a warning if a param is of raw type. But we have a warning there. The problem is that for example MarkupContainer.add(Component) or IVisitor.visit(Component) i dont care what component is put in generified or not. In add it really doesnt matter because we dont do anything with it. With visitor it is different because the user could use it inside the method. But it should be useable without warnings for generified and none generfied components.. On 5/14/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote: if we have a signature that accepts a raw type, will that also cause a warning in user's code? also having those suppress annotations practically _everywhere_ will be annoying -igor On Tue, May 13, 2008 at 11:56 PM, Johan Compagner < [EMAIL PROTECTED] wrote: I dont care, because i cant do any thing with the ? The only thing it enforces is that it must now be a generic class which is annoying. Not to mention that in that area eclipse and javac accept different things So or we in wicket dont use any where and have supress warning everywhere for that or we do use it and then suddenly it is in my eyes restricted to much. On 5/14/08, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: Johan Compagner wrote: yes thats the reason you are calling the method add with a generified component but that container itself is not generified i dont like this about generics expecially the onces like this: add(MarkupContainer container) then suddenly a none generified component cant be added... thats really stupid should mean anything.. including none generics No, that's not correct. For example, List is much more restrictive than a raw List (which is a List). To a raw list you can add an instance of any type whatever, i.e., list.add(new Object()). But in List the ? is a wildcard which says it could be any type there, i.e., it could be a List. But you can't add a new Object() to a List! Thus MarkupContainer means "MarkupContainer parameterized by some unknown type", and *not* MarkupContainer parameterized by Object, which is what the raw type means. Regards, Sebastiaan johan On Tue, May 13, 2008 at 5:55 PM, Stefan Simik <[EMAIL PROTECTED]> wrote: I have one idea, the reason of the warnigs is, that parent of AjaxPagingNavigator is PagingNavigator, which has parent Panel ---> that is not parameterized. The same p
Re: Using generics with some non-generic classes in Wicket
In IDEA it is annoying when you enable inspection 'Raw use of
parametrized class' which is generally quite useful
it will complain on
protected boolean isPageAuthorized(final Class
pageClass)
so, no, you don't get a warning but a potentially useful inspection is
more or less useless
(warnings have no effect once you get used to them)
Am 14.05.2008 um 22:29 schrieb Johan Compagner:
how do users get in this situation a warning?
if we as a framework say method(RawType type)
then why would that give a warning in the caller method?
We just say we accept raw type there
johan
On Wed, May 14, 2008 at 9:53 PM, Igor Vaynberg <[EMAIL PROTECTED]
>
wrote:
then our users have to suppress warnings in their code, which is
unacceptable at least to me. the whole generics thing turned out to
be
quiet a lot crappier then i thought it would.
-igor
On Wed, May 14, 2008 at 12:48 PM, Johan Compagner <[EMAIL PROTECTED]
>
wrote:
yes then all the call to that method must be of a generic type.
cant be raw
i dont know what are we going to do in wicket i think we should
decide it
should we just where we dont care about generic delete/not use the
and
then
supresswarning?
johan
On Wed, May 14, 2008 at 9:45 PM, Igor Vaynberg <[EMAIL PROTECTED]
>
wrote:
so i just implemented IAuthorizationStrategy and on this line in my
class:
public boolean isInstantiationAuthorized(Class< ? extends
Component>
componentClass)
i get: Component is a raw type. References to generic type
Component should be parameterized
so that means we have to change our sig to >
but then we are back to the problem described in this thread.
generics suck.
-igor
On Wed, May 14, 2008 at 12:12 AM, Johan Compagner <[EMAIL PROTECTED]
wrote:
I dont think that user gets a warning if a param is of raw type.
But
we have a warning there.
The problem is that for example MarkupContainer.add(Component) or
IVisitor.visit(Component) i dont care what component is put in
generified or not.
In add it really doesnt matter because we dont do anything with
it.
With visitor it is different because the user could use it
inside the
method. But it should be useable without warnings for generified
and
none generfied components..
On 5/14/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
if we have a signature that accepts a raw type, will that also
cause
a
warning in user's code?
also having those suppress annotations practically _everywhere_
will
be
annoying
-igor
On Tue, May 13, 2008 at 11:56 PM, Johan Compagner <
[EMAIL PROTECTED]
wrote:
I dont care, because i cant do any thing with the ? The only
thing
it
enforces is that it must now be a generic class which is
annoying.
Not
to mention that in that area eclipse and javac accept different
things
So or we in wicket dont use any where and have supress
warning
everywhere for that or we do use it and then suddenly it is in
my
eyes
restricted to much.
On 5/14/08, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
Johan Compagner wrote:
yes thats the reason
you are calling the method add with a generified component but
that
container itself is not generified
i dont like this about generics expecially the onces like
this:
add(MarkupContainer container)
then suddenly a none generified component cant be added...
thats really stupid should mean anything.. including none
generics
No, that's not correct. For example, List is much more
restrictive
than a raw List (which is a List). To a raw list you
can
add an
instance of any type whatever, i.e., list.add(new Object()).
But
in
List the ? is a wildcard which says it could be any type
there,
i.e.,
it could be a List. But you can't add a new Object()
to
a
List!
Thus MarkupContainer means "MarkupContainer parameterized by
some
unknown type", and *not* MarkupContainer parameterized by
Object,
which
is what the raw type means.
Regards,
Sebastiaan
johan
On Tue, May 13, 2008 at 5:55 PM, Stefan Simik
<[EMAIL PROTECTED]>
wrote:
I have one idea,
the reason of the warnigs is, that parent of
AjaxPagingNavigator
is
PagingNavigator,
which has parent Panel ---> that is not parameterized.
The same problem is with LoopItem, which extends the
WebMarkupContainer ---> that is not parameterized.
? could this be the reason ?
Stefan Simik wrote:
Mhmm, it is meaningful ;) I will know in future, thx
One of the last occuring warning is, when working with
MarkupContainer#add(...) or #addOrReplace(...) method.
Example: I have a simple AjaxPagingNavigator, to which I
add a
simple
ListView
---
ListView menu = new ListView("id",
numbers){
//populate metods
}
add(menu);//warning here
The warning says:
"Type safety: The method add(Component...) belongs to the
raw
type
MarkupContainer.
References to generic type MarkupContainer should be
parameterized"
I cannot find out, what's the w
Re: Using generics with some non-generic classes in Wicket
StringModel looks ambigious to me, will it extend
- LoadableDetachableModel
- IModel
- Model
- AbstractReadOnlyModel
-
???
Am 14.05.2008 um 15:47 schrieb Doug Donohoe:
Let me outline what I believe the benefits are. For example:
add(new Label("tournamentName", tournament.getName()));
add(new Label("hostName", game.getHostPlayer()));
row.add(new AttributeModifier("class", true, new
Model(row.getIndex() % 2 == 0 ? "odd" : "even")));
add(new StringLabel("tournamentName", tournament.getName()));
add(new StringLabel("hostName", game.getHostPlayer()));
row.add(new AttributeModifier("class", true, new
StringModel(row.getIndex()
% 2 == 0 ? "odd" : "even")));
Sure, it seems like a small difference and a saving of two
characters, but
here is what I believe are the benefits of doing this:
1) I can more easily use the features of my IDE such as auto-
completion
2) Find Usages is more accurate (at least in IntelliJ, where I'm not
aware
of a find-usages that scopes to a particular generic type)
3) Let's face it, Generics clutters up your code and makes it harder
to
read. This simplifies things a bit.
In answer to Martijn's assumption (in a separate post) that I was
going to
iterate over all java types and all wicket types: that is an
incorrect
assumption. Obviously, I would want to pick the most common use
cases and
seek feedback from the community. Let us not dismiss it outright. I
believe this is a valid topic of conversation. Generics are new to
Wicket
and still unused by many Java APIs and likely new to many
programmers. I
can tell you that using classes such as this made it much quicker
and easier
to remove all the warnings that showed up in my code when I migrated
to 1.4.
It seems easier to replace common usage from before (new Label(...))
with
new StringLabel(...) rather than new Label (even typing
that now
was more difficult). In any case, there may be some complaining
about the
extensive use of Generics in 1.4 once it is released. This may make
it
easier to transition. Maybe not. At least let's be open to
discussing it.
Finally, in answer to the point about "negating the point of
generics", I
respectfully disagree. One major point of generics is to avoid code
duplication of boilerplate code. It it weren't for the need to
create
constructors, there wouldn't be any duplicated code. I agree that
it is a
fine balance to strike, but there are competing needs of readability
and
maintainability.
-Doug
Hoover, William wrote:
imho, that seems like that adds a lot of unnecessary code. One of the
nice things about Wicket is that it keeps the bloat to a minimum.
-Original Message-
From: Doug Donohoe [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 14, 2008 8:21 AM
To: users@wicket.apache.org
Subject: Re: Using generics with some non-generic classes in Wicket
Somewhat related to this thread, when I moved to generics win Wicket
1.4, I created some utility classes such as:
public class VoidContainer extends WebMarkupContainer public
class VoidPanel extends Panel public class StringLabel
extends
Label
public class IntegerModel extends Model public class
StringModel extends Model public class DateModel extends
Model public class DoubleModel extends Model
And so on. This made my wicket code cleaner and easier to use. I
think
the Wicket 1.4 generics implementation is headed in the right
direction.
It was a pain at first because I had to parameterize everything, but
creating convenience classes like this made it easier.
I'm thinking about creating a patch with a suite of these types of
classes because I think users will want something like this.
-Doug
Johan Compagner wrote:
The problem is that wicket needs an annotation
so that all the warnings about raw types are gone.
A component only has to be generic if you use the IModel constructor
or call getModel(), getModelObject() methods..
for the rest it is not really needed
johan
On Wed, May 14, 2008 at 9:28 AM, Sebastiaan van Erk
<[EMAIL PROTECTED]>
wrote:
My post kind of missed the point, I shouldn't post when I'm already
half asleep. :-)
Obviously MarkupContainer satisfies the MarkupContainer in a
method argument, so it accepts the raw type. However, it
generates a
warning because the method says it's generified, so you should be
using the generic type.
Johan Compagner wrote:
I dont care, because i cant do any thing with the ? The only thing
it enforces is that it must now be a generic class which is
annoying. Not to mention that in that area eclipse and javac
accept
different things
The reason it warns you to use generics when generics are wanted is
because Sun wants to be able to make it *required* (in a future
release) to use generics where generics are wanted; at least, so I
read... I think in the real world they wouldn't dare to do this
because it would piss off so many users a
Re: Javascript error in wicket
Of course it's there... The script seems to be broken (Firefox issue,
not Wicket)
Am 30.04.2008 um 16:44 schrieb Vitaly Tsaplin:
This file exists. I can open it...
On Wed, Apr 30, 2008 at 2:52 PM, Peter Ertl <[EMAIL PROTECTED]>
wrote:
that's not wicket but firefox...
try reading the filename:
file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSessionStore.js
Am 30.04.2008 um 12:17 schrieb Vitaly Tsaplin:
Hi everyone,
Firebug is complaining as follows:
[Exception... "Component is not available" nsresult: "0x80040111
(NS_ERROR_NOT_AVAILABLE)" location: "JS frame ::
file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSessionStore.js
:: sss_saveState :: line 1753" data: no]
[Break on this error] oState.session = { state: ((this._loadState ==
STATE_RUNNING) ? STATE_RUNNIN...
Any ideas?
Vitaly
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javascript error in wicket
that's not wicket but firefox...
try reading the filename:
file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSessionStore.js
Am 30.04.2008 um 12:17 schrieb Vitaly Tsaplin:
Hi everyone,
Firebug is complaining as follows:
[Exception... "Component is not available" nsresult: "0x80040111
(NS_ERROR_NOT_AVAILABLE)" location: "JS frame ::
file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSessionStore.js
:: sss_saveState :: line 1753" data: no]
[Break on this error] oState.session = { state: ((this._loadState ==
STATE_RUNNING) ? STATE_RUNNIN...
Any ideas?
Vitaly
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to hide /?wicket:.. from the URLs
A "poor man's solution" could be: You could rewrite your URL through e.g. a front-end apache and mod_rewrite. response: convert any occurrence of '?wicket' to '?foobar' in url request: convert '?foobar' to '?wicket' Am 30.04.2008 um 03:57 schrieb Johan Compagner: Currently it is not easy to get wicket out of all the urls. This prefix is a static final that is used on many places, i want to make that configurable in a next release. By default wicket will generate relative paths. You can get a absolute one with i believe RequestUtils. But this is still without host/port i think, why do you want that? For generating emails or something like that? On 4/30/08, Ritz123 <[EMAIL PROTECTED]> wrote: Hi, Was wondering if its possible to hide "wicket" name from the URLs (stateless and stateful). One might not want to show their end users that wicket is being used behind the scenes. Also I noticed even if page has bookmarkable links - the links show relative ../../../../mount/params!! Is there anyway to have complete(absolute urls) with the hostname? -- View this message in context: http://www.nabble.com/Is-it-possible-to-hide---wicket%3A..-from-the-URLs-tp16972147p16972147.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jquery Attached Behaviors Disappearing During Ajax Calls
Have you tried putting that javascript behavior into an wicket
behavior attached to the component?
something like...
textbox.add(new MyJQueryCustomBehavior())
Am 30.04.2008 um 09:41 schrieb carloc:
Hi,
I'm using JQuery together with Wicket. I have this problem that
whenever I
update a component through ajax, the behaviors I attached using jquery
disappear already.
For example I have a textbox which has this
$('textbox').click(function() {
alert('hello')
})
This would work while the textbox has not yet been updated.
But whenever the component has been replaced by Wicket
target.addComponent(textbox)
It will be replaced by a new component and the behavior that was
binded is
no longer there.
Is there a workaround to this?
Thanks
Carlo
--
View this message in context:
http://www.nabble.com/Jquery-Attached-Behaviors-Disappearing-During-Ajax-Calls-tp16977307p16977307.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
make source jars part of wicket distribution
Dear wicket developers, could you make the wicket source jars part of the distribution (even when this means more megabytes)? Or maybe an additional apache-wicket-1.x-sources.tar.gz (.zip) ? This would be very helpful for debugging and ensure that wicket-jar and wicket-source-jars do match exactly. Regards, Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems and Questions about MultiFileUploadField, UploadProgressBar
Great! So could you share your experience? Am 02.04.2008 um 11:58 schrieb Fabien D.: My problem is fixed! :) I search response for my question : is it possible to use MultiFileUploadField, UploadProgressBar together?or UploadProgressBar is only for simpleUpload? -- View this message in context: http://www.nabble.com/Problems-and-Questions-about-MultiFileUploadField%2C-UploadProgressBar-tp16445359p16446351.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: export excel file via an OutputStream
use AbstractResourceStreamWriter
> Wicket got to have a more structured api for this common task.
usually it's not wicket but you when something is not working the way
you expect it
Am 01.04.2008 um 09:31 schrieb [EMAIL PROTECTED]:
Hello:
I am trying to export dynamically generated excel file.
The generator would send the file.xls to an OutputStream.
In wicket, I am trying to use example as below but
how can I connect the OutputStream to the inputstream
ins. Pipedoutputstream would block. Using a separate thread
is not desirable.
public void onClick() {
IResourceStream stream = new AbstractResourceStream() {
public InputStream getInputStream() throws
ResourceStreamNotFoundException {
return ins;
}
public void close() throws IOException {
ins.close();
}
};
getRequestCycle().setRequestTarget(
new
ResourceStreamRequestTarget(stream).setFileName("file.xls"));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 1.4 with only generics and stop support for 1.3
+1 Am 18.03.2008 um 10:50 schrieb Gabor Szokoli: +1 On 3/17/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Everybody is invited to vote! Please use [ ] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3 [ ] -1, I need a supported version running on Java 1.4 Let your voices be heard! Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.2 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket, Hibernate and Models
whew - glad to hear :-)
[having probably hundreds of anonymous models in his projects]
Am 13.03.2008 um 17:46 schrieb Igor Vaynberg:
actually not in 1.3. our serialization is smart enough to take this
into account if i remember correctly.
-igor
On Thu, Mar 13, 2008 at 8:47 AM, Leszek Gawron
<[EMAIL PROTECTED]> wrote:
Maurice Marrink wrote:
I believe refreshingview has better support for reusing items but in
our apps we hardly ever use refreshingview. both are suitable for
use
with hibernate.
Maurice
On Thu, Mar 13, 2008 at 4:35 PM, carloc <[EMAIL PROTECTED]>
wrote:
What should I use when I am accessing hibernate?
Should I use a ListView or should I use a refreshing view?\
In the api it says to use refreshingview instead of using
listview when
using database collections
what is better to use?
carloc wrote:
Hi everyone,
I have been reading wicket in action recently and I have seen
pitfalls of
hibernate section.
I was wondering about the stuff about hibernate and memory leaks
due to
hibernate proxy objects maintaining a reference to the session
with
them
Am I doing this wrong then?
@SpringBean
private UserService userService;
add(new ListView("user", userService.findUsers() {
})
is this wrong? I'm using it directly meaning it will be stored
in the page
store right?
should i be doing this instead?
LoadableDetachableModel model = new LoadableDetachablemodel() {
Object load() {
return usrService.findUsers()
}
}
please mind that you shouldn't create anonymous model classes as they
keep the reference to the page/panel and you will fall into other
memory
issues.
--
Leszek Gawron http://www.mobilebox.pl/
krs.html
CTO at MobileBox Ltd.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket, Hibernate and Models
> please mind that you shouldn't create anonymous model classes as
they keep the reference to the page/panel and you will fall into other
memory issues.
could you elaborate on that?
Am 13.03.2008 um 16:47 schrieb Leszek Gawron:
Maurice Marrink wrote:
I believe refreshingview has better support for reusing items but in
our apps we hardly ever use refreshingview. both are suitable for use
with hibernate.
Maurice
On Thu, Mar 13, 2008 at 4:35 PM, carloc <[EMAIL PROTECTED]>
wrote:
What should I use when I am accessing hibernate?
Should I use a ListView or should I use a refreshing view?\
In the api it says to use refreshingview instead of using listview
when
using database collections
what is better to use?
carloc wrote:
>
> Hi everyone,
>
> I have been reading wicket in action recently and I have seen
pitfalls of
> hibernate section.
> I was wondering about the stuff about hibernate and memory leaks
due to
> hibernate proxy objects maintaining a reference to the session
with
> them
>
>
> Am I doing this wrong then?
> @SpringBean
> private UserService userService;
>
> add(new ListView("user", userService.findUsers() {
> })
>
> is this wrong? I'm using it directly meaning it will be stored
in the page
> store right?
>
> should i be doing this instead?
>
> LoadableDetachableModel model = new LoadableDetachablemodel() {
> Object load() {
>return usrService.findUsers()
>}
>
> }
please mind that you shouldn't create anonymous model classes as
they keep the reference to the page/panel and you will fall into
other memory issues.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default Focus Behavior?
-1 for letting components handle focus. There's only _one_ focus that
can set on a page at a time. What if several components demand focus?
Who will be the winner?
Also, not every WebComponent can receive focus (Label, Image, ...) but
only FormComponents (input, select, button, ...)
I vote for a method like:
WebPage#setFocus(FormComponent component)
class WebPage
{
private FormComponent focus;
public final void setFocus(FormComponent component)
{
focus = component;
focus.setOutputMarkupId(true);
}
public void renderHead(IHeaderResponse response)
{
if (focus != null)
{
final String item = String.format("document.getElementById('%s')",
focus.getMarkupId());
final String js = String.format("%s.focus(); try
{ %s.select() } catch( /* ignore */ )", item);
response.renderOnDomReadyJavascript(js);
}
}
}
Regards
Peter
Am 09.03.2008 um 20:04 schrieb djo.mos:
jwcarman wrote:
How about something like:
public class DefaultFocusBehavior extends AbstractBehavior
{
private Component component;
public void bind( Component component )
{
this.component = component;
component.setOutputMarkupId(true);
}
public void renderHead( IHeaderResponse iHeaderResponse )
{
super.renderHead(iHeaderResponse);
iHeaderResponse.renderOnLoadJavascript("document.getElementById('"
+ component.getMarkupId() + "').focus();");
}
}
This simply looks great ! I think this should make it into the core
Wicket
behaviors as the componenet focus is quite useful.
Cheers.
--
View this message in context:
http://www.nabble.com/Default-Focus-Behavior--tp15934889p15945036.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: need to sanitize uploaded file names before saving?
Why not simply use new java.io.File(client_file_name).getName() ? > Returns the name of the file or directory denoted by this abstract pathname. > This is just the last name in the pathname's name sequence. > If the pathname's name sequence is empty, then the empty string is returned. Am 20.02.2008 um 22:03 schrieb Alex Jacoby: Good points -- I was munging the filename a bit, but basically leaving it unchanged so that it would be simpler to debug. I'm still curious about the directory traversal thing... I've tried using tamper data to change the filename, but I get a MalformedStreamException each time I try [1]. Side note: I think spaces are allowed in filenames in unix file systems. Just quoted or escaped. (Regardless, your point is still taken.) Alex [1] org.apache.wicket.util.upload.MultipartFormInputStream $MalformedStreamException: Stream ended unexpectedly at org .apache .wicket .util .upload .MultipartFormInputStream.readBodyData(MultipartFormInputStream.java: 568) On Feb 20, 2008, at 3:24 PM, Abdul Habra wrote: When I save uploaded files, I never use the client's name of the file. That could cause problems, and could be a security risk. For example, a windows client may have a file name which contains spaces, however on a unix system this will not be a valid file name. Another example if u r running on a windows server, somebody may upload a file named dir.bat and put in it whatever commands they like, then ... I leave it to your imagination :) Alex Jacoby <[EMAIL PROTECTED]> wrote: I'm saving uploaded files to a directory on the local file system. I was just wondering: would it be possible for someone to give their uploaded file a name like "../../secretdir/passwd" so that they could theoretically clobber another file (if permissions weren't somehow blocking it)? If so, is this something that wicket does or could check for? The javadocs for FileItem.getName say that while most browsers provide only a basename (no path), Opera does include a full path, so it would seem that a malicious user could do some directory traversal trickery... It's not hard to check for "../" or a leading "/" (or just "/" ANYWHERE I suppose), but I'd skip it if it weren't necessary. Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding in Jetty without web.xml
Also you should do this instead: Context context = new Context(server, "/", Context.SESSIONS); you write: Context context = new Context(server, "/");
Re: Embedding in Jetty without web.xml
Dont change wicket, it's fine :-)
Actually I got this working without any web.xml or WEB-INF/ and it's
possible!
The things is: When you use the wicket filter you also need to add the
DefaultServlet (or any servlet that is mapped to your wicket filter
path)
it looks like that in my AppLauncherJetty.class
context.addServlet(DefaultServlet.class, "/*") // or whatever you
wicket filter path is
in jetty a filter is just _decorating_ a request. but the request
needs a _target_ which the DefaultServlet in that case is.
otherwise you get a 404!
even though wicket filter eventually does not call chain.doFilter(..)
jetty still needs the servlet.
Try and see.
Regards
Peter
Am 30.01.2008 um 01:27 schrieb Eelco Hillenius:
Actually, WicketFilter does try to read web.xml. See
WicketFilter#init.
You could file a feature request to let the framework be more lenient
so that it doesn't fail when web.xml is not available. We can at least
think about that. To solve your problem now, I suggest you make a copy
of WicketFilter for your own purposes and rip the web.xml reading code
out and get your filter path somewhere else.
Eelco
On Jan 29, 2008 4:21 PM, Philip Healy <[EMAIL PROTECTED]> wrote:
Hello,
I am trying to set up a Wicket application to execute in an
embedded Jetty
instance. The Wicket application is not deployed as a webapp (so
there so
web.xml), as I am trying to avoid using unnecessary directory
structure and
config files). The Wicket application classes are available on the
classpath. I am using the following to configure the Wicket filter
and
start the Jetty server:
// Create server and root context
Server server = new Server();
Connector connector = new SocketConnector();
connector.setPort(8080);
server.addConnector(connector);
Context context = new Context(server, "/");
// Add wicket filter
FilterHolder filterHolder = new FilterHolder(WicketFilter.class);
filterHolder.setInitParameter("applicationClassName",
TestWebApplication.class.getCanonicalName());
context.addFilter(filterHolder, "/*",
org.mortbay.jetty.Handler.DEFAULT);
// Start server
server.start();
server.join();
I added the following to the init() method of the WebApplication
subclass:
mount("/test", PackageName.forPackage(this.getClass().getPackage()));
Although the server starts, the Wicket application is not available
at
http://localhost:8080/test/, I get a Jetty-generated 404 message.
Any
ideas?
Regards,
Philip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajax History Back support on Stateless pages
As far as I understand your page will not be stateless anymore once you use ajax. Am 31.12.2007 um 12:59 schrieb based: Hi I have a stateless page which holds product datas. And it has a tab component which uses Ajax. I know a way to do it with Page Bookmarks (#tabName). But i wonder is there any other solution or any pattern to implement this issue better? Thanks fatih -- View this message in context: http://www.nabble.com/Ajax-History-Back-support-on-Stateless-pages-tp14556855p14556855.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two wicket applications in one spring context
I wouldn't separate that but put admin and user into one application. - same code base (easy sharing) - no two web sessions that need to be linked - easy deployment you my 2ct Am 22.12.2007 um 11:12 schrieb Per Newgro: Hi * i try to adapt the phonebook example to my needs. What i try to achieve is to develop an admin part and an user part of my application. I would like to connect to my applications by two urls (localhost:8080 and localhost:8080/admin). So i think i have to develop two applications. They share much code. So i would like to develop them both in same maven project. But. If i try it my way it seems to conflict with spring conditions. How could i solve this? Maybe i use the wrong example? Thanks for your help Per web.xml http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; version="2.4"> accommodationOffice contextConfigLocation classpath:applicationContext.xml class>org.springframework.web.context.ContextLoaderListenerlistener-class> wicket.accommodationOffice org.apache.wicket.protocol.http.WicketFilterclass> applicationFactoryClassName org.apache.wicket.spring.SpringWebApplicationFactoryparam-value> beanName officeApplication 1 wicket.accommodationOffice.admin org.apache.wicket.protocol.http.WicketFilterclass> applicationFactoryClassName org.apache.wicket.spring.SpringWebApplicationFactoryparam-value> beanName adminApplication 1 wicket.accommodationOffice /officeApplication/* wicket.accommodationOffice.admin /adminApplication/* Exception in jetty start ERROR - log- Failed startup of context [EMAIL PROTECTED]/,src/main/webapp} java.lang.IllegalStateException: more then one bean of type [org.apache.wicket.protocol.http.WebApplication] found, must have only one at org .apache .wicket .spring .SpringWebApplicationFactory .createApplication(SpringWebApplicationFactory.java:112) at org .apache .wicket .spring .SpringWebApplicationFactory .createApplication(SpringWebApplicationFactory.java:86) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java: 496) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java: 99) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java: 40) at org .mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java: 594) at org.mortbay.jetty.servlet.Context.startContext(Context.java:139) at org .mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java: 1218) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java: 500) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java: 40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java: 117) at org.mortbay.jetty.Server.doStart(Server.java:220) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java: 40) at my.accommodationoffice.Start.main(Start.java:35) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get session from panel ?
Looks interesting...
MySession.get()
Will this reliably work in WicketTester or are there implication you
should be aware of?
Regards
Peter
Am 20.12.2007 um 10:27 schrieb Sebastiaan van Erk:
Or Session.get(), or better yet use MySession.get() where in
MySession you define the static method:
public static MySession get() {
return (MySession) Session.get();
}
which avoids casts. (Use can use the same trick to get the
application).
Regards,
Sebastiaan
Suad AlShamsi wrote:
Did you try to get it from the application.
getApplicaion().getSession();
tsuresh wrote:
Hello,
I have Panel called MenuPanel and a page WelcomePage. When the
user is
authenticated through Login page the user is forwarded to
WelcomePage. This
WelcomePage consists of MenuPanel. How do I get the user session
from the
MenuPanel. I simply added the MenuPanel in WelcomePage as
add(new MenuPanel("menuBar"));
and in MenuPanel I tried to get Session as
LoginSession sess = (LoginSession) getSession();
But this sess returned null;
I have made the LoginSession class. I have set user session in
Login page as ..
session.setUser(user);
Am i missing something?
thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom styles for trees
You could submit a suggestion on jira... After all this is open source :-) Am 12.12.2007 um 23:39 schrieb Loren Cole: Ah! thank you. I apologize if I'm resurrecting a dead horse, but why isn't this done with css? I saw some discussion about it from last summer, but the last comment in the thread suggested that the status quo was "easy enough." My unasked for two cents is any thing you can do to isolate look and feel from code is a good thing, and overriding a css class to get this effect is more intuitive than overriding a method in the super class. Are there any plans to change this? - Loren On Dec 12, 2007 3:28 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: You need to override the getImageResourceReference method of LabelIconPanel (or LinkIconPanel). Look at the default implementation in LabelIconPanel. -Matej On Dec 12, 2007 9:27 PM, Loren Cole <[EMAIL PROTECTED]> wrote: I'd like to remove the folder and page icons from a LinkTree and I'm not entirely sure how to go about it. As far as I can tell I need to create a LinkIconPanel instead and then add a blank image component to it... Or is there some way I can reference the image and set it's visible flag? Why isn't this all done in css? or is it and I'm just missing something... Many thanks for any help, - Loren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
