from:"Stefan Fußenegger"


Thanks, I'll go for the suggested JS.Is there any documentation of the Wicket
JavaScript library available somewhere?

However, wouldn't be replacing borders (i.e. keeping parts of the hierarchy)
be a nice feature? I'd add a ticket if you agree.

Regards, Stefan


igor.vaynberg wrote:
 
 the way to do this is to have the div be output there without
 class=error and to append the class to it via
 ajaxrequesttarget.appendjavascript($(divid).addclass('error'););
 
 that way you do not need to repaint the input tag which is the
 problematic part for your usecase.
 
 -igor
 
 On Tue, Jan 13, 2009 at 4:49 AM, Stefan Fußenegger
 stefan_fusseneg...@gmx.at wrote:

 Hi,

 My HTML looks similar to this:

 divlabelFoo/labelinput type=text //div

 I want to validate the contents of the field as soon as the user starts
 typing. If there is an error, the html should become:

 div class=errorThere was an errorlabelFoo/labelinput type=text
 //div

 However, if I add the whole hierarchy to the AjaxRequestTarget, the
 changes
 in the text field get lost (Which results in quite weired typing
 behavior).

 Is it possible to skip components from being updated within another
 component? Might storing the value (prependJavascript), updating the
 whole
 hierarchy and writing back the stored value (appendJavascript) give
 satisfying results.

 What do you think? Any other ideas?

 Thanks, Stefan

 -
 ---
 Stefan Fußenegger
 http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
 --
 View this message in context:
 http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21435127.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
 
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21473620.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

Re: Ajax-Update MarkupContaining containing FormComponent without loosing user changes


I knew it was pseudo code. With JS library I meant the stuff contained in
wicket-ajax.js, wicket-event.js, wicket-ajax-debug.js.

with replacing border, you meant the server-side concept of a Border, right?
I was talking more of a html related concept (bad description, sorry), where
a border is some markup surrounding some other markup. The later should be
kept untouched by the update. I think it shouldn't be to difficult to get a
DOM node by id, remove it or move it somewhere else temporarily, insert the
ajax-retrieve stuff, move the DOM node back to where it was. If the
implementation is as simple as this, it would be a feature worth adding,
wouldn't it?

Regards 


igor.vaynberg wrote:
 
 On Thu, Jan 15, 2009 at 12:53 AM, Stefan Fußenegger
 stefan_fusseneg...@gmx.at wrote:

 Thanks, I'll go for the suggested JS.Is there any documentation of the
 Wicket
 JavaScript library available somewhere?
 
 there is no wicket js library, what i gave you was pseudocode.
 
 However, wouldn't be replacing borders (i.e. keeping parts of the
 hierarchy)
 be a nice feature? I'd add a ticket if you agree.
 
 you can replace borders already, the problem here relates to the
 timing of client-server interaction. because you are validating while
 the user is typing the serverside often gets the value that is out of
 date since the user types faster then you can send requests to the
 server. this means that when repainting the component on the
 serverside there is a good chance you will repaint it with the wrong
 value.
 
 currently there is no way to tell a form component to repaint but not
 update its value attribute, and this is not always possible anyways.
 
 -igor
 

 Regards, Stefan


 igor.vaynberg wrote:

 the way to do this is to have the div be output there without
 class=error and to append the class to it via
 ajaxrequesttarget.appendjavascript($(divid).addclass('error'););

 that way you do not need to repaint the input tag which is the
 problematic part for your usecase.

 -igor

 On Tue, Jan 13, 2009 at 4:49 AM, Stefan Fußenegger
 stefan_fusseneg...@gmx.at wrote:

 Hi,

 My HTML looks similar to this:

 divlabelFoo/labelinput type=text //div

 I want to validate the contents of the field as soon as the user starts
 typing. If there is an error, the html should become:

 div class=errorThere was an errorlabelFoo/labelinput
 type=text
 //div

 However, if I add the whole hierarchy to the AjaxRequestTarget, the
 changes
 in the text field get lost (Which results in quite weired typing
 behavior).

 Is it possible to skip components from being updated within another
 component? Might storing the value (prependJavascript), updating the
 whole
 hierarchy and writing back the stored value (appendJavascript) give
 satisfying results.

 What do you think? Any other ideas?

 Thanks, Stefan

 -
 ---
 Stefan Fußenegger
 http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
 --
 View this message in context:
 http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21435127.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





 -
 ---
 Stefan Fußenegger
 http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
 --
 View this message in context:
 http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21473620.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
 
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21482168.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

Re: Ajax-Update MarkupContaining containing FormComponent without loosing user changes

Even if they are for wicket's internal use, documentation might be
valuable, especially for (wicketstuff) developers who go deeper then regular
users. Furthermore, having some basic JS utilities (with documented public
API) coming with Wicket would make using Wicket even more fun. I'd bet that
a lot of Wicket users implemented Wicket.$('id') or something similar on
their own. And I'm not talking about a fully fledged JS framework or
library, just some basic stuff to handle common tasks like the whole event
stuff or some DOM manipulations. Basically just what's in place already but
kept secret for internal use only.

Maybe that's a candidate for the Wicket 1.5 wishlist ...

igor.vaynberg wrote:

On Thu, Jan 15, 2009 at 9:11 AM, Stefan Fußenegger
stefan_fusseneg...@gmx.at wrote:

I knew it was pseudo code. With JS library I meant the stuff contained
in
wicket-ajax.js, wicket-event.js, wicket-ajax-debug.js.

those are for wicket's internal use. dont touch :)

with replacing border, you meant the server-side concept of a Border,
right?
I was talking more of a html related concept (bad description, sorry),
where
a border is some markup surrounding some other markup. The later should
be
kept untouched by the update. I think it shouldn't be to difficult to get
a
DOM node by id, remove it or move it somewhere else temporarily, insert
the
ajax-retrieve stuff, move the DOM node back to where it was. If the
implementation is as simple as this, it would be a feature worth adding,
wouldn't it?

javascript implementation is easy, it is the serverside declaration
and invocation that would be confusing. you are welcome to prototype
it if you want to pursue it further.

-igor

Regards

igor.vaynberg wrote:

On Thu, Jan 15, 2009 at 12:53 AM, Stefan Fußenegger
stefan_fusseneg...@gmx.at wrote:

Thanks, I'll go for the suggested JS.Is there any documentation of the
Wicket
JavaScript library available somewhere?

there is no wicket js library, what i gave you was pseudocode.

However, wouldn't be replacing borders (i.e. keeping parts of the
hierarchy)
be a nice feature? I'd add a ticket if you agree.

you can replace borders already, the problem here relates to the
timing of client-server interaction. because you are validating while
the user is typing the serverside often gets the value that is out of
date since the user types faster then you can send requests to the
server. this means that when repainting the component on the
serverside there is a good chance you will repaint it with the wrong
value.

currently there is no way to tell a form component to repaint but not
update its value attribute, and this is not always possible anyways.

-igor

Regards, Stefan

igor.vaynberg wrote:

the way to do this is to have the div be output there without
class=error and to append the class to it via
ajaxrequesttarget.appendjavascript($(divid).addclass('error'););

that way you do not need to repaint the input tag which is the
problematic part for your usecase.

-igor

On Tue, Jan 13, 2009 at 4:49 AM, Stefan Fußenegger
stefan_fusseneg...@gmx.at wrote:

Hi,

My HTML looks similar to this:

divlabelFoo/labelinput type=text //div

I want to validate the contents of the field as soon as the user
starts
typing. If there is an error, the html should become:

div class=errorThere was an errorlabelFoo/labelinput
type=text
//div

However, if I add the whole hierarchy to the AjaxRequestTarget, the
changes
in the text field get lost (Which results in quite weired typing
behavior).

Is it possible to skip components from being updated within another
component? Might storing the value (prependJavascript), updating the
whole
hierarchy and writing back the stored value (appendJavascript) give
satisfying results.

What do you think? Any other ideas?

Thanks, Stefan

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21435127.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

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21473620.html
Sent from the Wicket - User mailing list archive at Nabble.com

Re: Ajax-Update MarkupContaining containing FormComponent without loosing user changes

My suggestions was to actually maintain a minimal JS api in the future. I
don't believe that the very basic utility functions are going to change
between minor versions. So it might be worth thinking about making this API
official. The users would definitely benefit from it - and nobody would have
to write a single line of code. It's just a suggestion, as I think it's at
least worth considering.

igor.vaynberg wrote:

thats exactly the point. we do not maintain api compatibility of the
js code, not even between minor versions, so you should not use them
or depend on them.

-igor

On Thu, Jan 15, 2009 at 10:05 AM, Stefan Fußenegger
stefan_fusseneg...@gmx.at wrote:

Even if they are for wicket's internal use, documentation might be
valuable, especially for (wicketstuff) developers who go deeper then
regular
users. Furthermore, having some basic JS utilities (with documented
public
API) coming with Wicket would make using Wicket even more fun. I'd bet
that
a lot of Wicket users implemented Wicket.$('id') or something similar on
their own. And I'm not talking about a fully fledged JS framework or
library, just some basic stuff to handle common tasks like the whole
event
stuff or some DOM manipulations. Basically just what's in place already
but
kept secret for internal use only.

Maybe that's a candidate for the Wicket 1.5 wishlist ...

igor.vaynberg wrote:

On Thu, Jan 15, 2009 at 9:11 AM, Stefan Fußenegger
stefan_fusseneg...@gmx.at wrote:

I knew it was pseudo code. With JS library I meant the stuff
contained
in
wicket-ajax.js, wicket-event.js, wicket-ajax-debug.js.

those are for wicket's internal use. dont touch :)

with replacing border, you meant the server-side concept of a Border,
right?
I was talking more of a html related concept (bad description, sorry),
where
a border is some markup surrounding some other markup. The later should
be
kept untouched by the update. I think it shouldn't be to difficult to
get
a
DOM node by id, remove it or move it somewhere else temporarily, insert
the
ajax-retrieve stuff, move the DOM node back to where it was. If the
implementation is as simple as this, it would be a feature worth
adding,
wouldn't it?

javascript implementation is easy, it is the serverside declaration
and invocation that would be confusing. you are welcome to prototype
it if you want to pursue it further.

-igor

Regards

igor.vaynberg wrote:

On Thu, Jan 15, 2009 at 12:53 AM, Stefan Fußenegger
stefan_fusseneg...@gmx.at wrote:

Thanks, I'll go for the suggested JS.Is there any documentation of
the
Wicket
JavaScript library available somewhere?

there is no wicket js library, what i gave you was pseudocode.

However, wouldn't be replacing borders (i.e. keeping parts of the
hierarchy)
be a nice feature? I'd add a ticket if you agree.

currently there is no way to tell a form component to repaint but not
update its value attribute, and this is not always possible anyways.

-igor

Regards, Stefan

igor.vaynberg wrote:

the way to do this is to have the div be output there without
class=error and to append the class to it via
ajaxrequesttarget.appendjavascript($(divid).addclass('error'););

that way you do not need to repaint the input tag which is the
problematic part for your usecase.

-igor

On Tue, Jan 13, 2009 at 4:49 AM, Stefan Fußenegger
stefan_fusseneg...@gmx.at wrote:

Hi,

My HTML looks similar to this:

divlabelFoo/labelinput type=text //div

I want to validate the contents of the field as soon as the user
starts
typing. If there is an error, the html should become:

div class=errorThere was an errorlabelFoo/labelinput
type=text
//div

However, if I add the whole hierarchy to the AjaxRequestTarget, the
changes
in the text field get lost (Which results in quite weired typing
behavior).

Is it possible to skip components from being updated within another
component? Might storing the value (prependJavascript), updating
the
whole
hierarchy and writing back the stored value (appendJavascript) give
satisfying results.

What do you think? Any other ideas?

Thanks, Stefan

-
To unsubscribe, e

Ajax-Update MarkupContaining containing FormComponent without loosing user changes

2009-01-13 Thread Stefan Fußenegger


Hi,

My HTML looks similar to this:

divlabelFoo/labelinput type=text //div

I want to validate the contents of the field as soon as the user starts
typing. If there is an error, the html should become:

div class=errorThere was an errorlabelFoo/labelinput type=text
//div

However, if I add the whole hierarchy to the AjaxRequestTarget, the changes
in the text field get lost (Which results in quite weired typing behavior).

Is it possible to skip components from being updated within another
component? Might storing the value (prependJavascript), updating the whole
hierarchy and writing back the stored value (appendJavascript) give
satisfying results.

What do you think? Any other ideas?

Thanks, Stefan

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21435127.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

Re: Dojo 1.1 integration available from wicketstuff

2008-12-23 Thread Stefan Fußenegger

Hi Emanuele,

I don't plan to support additional components myself - especially not
problems that seem to be caused by Dojo only. wicketstuff-dojo-1.1 is mainly
meant to ease the integration of Dojo into Wicket (i.e. to provide the
infrastructure like custom builds, packaging as jar files, configuration of
Dojo as part of a Wicket application, mounting resources and the like). In
the future, there might be more and more components available out of the
box. However, at the moment I don't have plans - or time - to add more
components than those already included (animations, toaster widget, drag and
drop and cometd support)

If you've built a Wicket component based on wicketstuff-dojo-1.1, you're
welcome to contribute your code. If you want to contribute but don't know
how, I'd be happy to get you started.

Merry Christmas, Stefan

Emanuele Gesuato-2 wrote:

Stefan Fußenegger wrote:
There's now a little bit of documentation online:
http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-dojo-1.1

Cheers, Stefan

Hi,

First of all, good job.

Is there any plan to support the dojo context menu ? :-)

We are using it but we've got several warnings with some deprecation
calls on the html document in development that are quite annoying.
Also if i have different context menu in the same page and if these
context menu has submenus, the submenus are sharing the same instance of
the content component.

Example:
If i have menuA and menuB in two tables, tableA and tableB. If i right
click on menuA or menuB in the java code i see that the referenced
component is always on tableB. This only happens in the voices of the
menu that are in a submenu.

Thanks for any help,
Emanuele

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-tp20625220p21144111.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

Re: code for DataGrid with vertical scrolling

2008-12-23 Thread Stefan Fußenegger


I once started working on a component that used vertical scrolling. It was
based on a GrowableListView (based on
http://wicketinaction.com/2008/10/repainting-only-newly-created-repeater-items-via-ajax/),

GrowableListView.java: http://pastie.org/345504 
GrowableListView.html: http://pastie.org/345507

Might not be the cleanest or best code ever, but it used to work - if I
remember correctly. This could be used to add columns to a single-row-table,
where each table cell contains a ListView of items

To use a table with the above code, call 

setItemTagName(td);
setContainerTagName(tr);

This table could than be scrolled with JS, e.g. with Dojo's
dojox.fx.smoothScroll(). That's the part I didn't finish so far, though :)
You'd probably be able to adapt the JS code found here:
http://www.songtexte.com/songtext/johnny-cash/folsom-prison-blues-3d41577.html
(see the Videos box in the right column) 




miro wrote:
 
 please point me for the code with data grid vertical scrolling component.
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/code-for-DataGrid-with-vertical-scrolling-tp21112343p21144910.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

Re: Dojo 1.1 integration available from wicketstuff

2008-12-18 Thread Stefan Fußenegger


There's now a little bit of documentation online:
http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-dojo-1.1

Cheers, Stefan


Stefan Fußenegger wrote:
 
 Hi folks,
 
 I just shared a new project called wicketstuff-dojo-1.1 [1], an
 integration of the Dojo JavaScript toolkit [2] into Wicket. This project
 is based on wicketstuff-dojo [3] and wicketstuff-push [4] (both based on
 dojo 0.4). However, not all of the components from wicketstuff-dojo have
 been ported to the new dojo version (but feel free to do so). 
 
 Currently, there is no documentation available. I'll add some info to the
 wicketstuff wiki next week. In the meantime, (really) early adopters can
 check it out for review. To build the project, check it out and run `mvn
 clean install`. To build a custom dojo distribution, place your
 profile.profile.js (e.g. foobar.profile.js) in buildDojo/custom-profile/
 and run `mvn -Ddojo.profile=profile clean install`. In your project pom,
 add 
 
 dependency
 groupIdorg.wicketstuff/groupId
 artifactIdwicketstuff-dojo-1.1/artifactId
 version1.3.5-standard-SNAPSHOT/version
 /dependency
 
 or, for the custom profile
 
 dependency
 groupIdorg.wicketstuff/groupId
 artifactIdwicketstuff-dojo-1.1/artifactId
 version1.3.5-profile-SNAPSHOT/version
 /dependency
 
 (Not sure if this versioning strategy is the best choice, but it makes it
 quite easy to use different custom profiles for different projects)
 
 Looking forward to your feedback!
 
 Regards, Stefan
 
 [1]
 https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-dojo-1.1/
 [2] http://dojotoolkit.org/
 [3] http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Dojo
 [4]
 https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-tp20625220p21069750.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

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-27 Thread Stefan Fußenegger

 on the internet that have a pager
  above the pageable view that shows you the number of the last
  available page...you know how those work without doing a select
  count()?
 
  -igor
 
 
 
 
 
 
  
   On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer 
 [EMAIL PROTECTED]
  wrote:
  
  
   have a look at https://issues.apache.org/jira/browse/WICKET-1784
  
  
   Wayne Pope-2 wrote:
   
Ok,
   
I was just having a bit of code clean up and I realized that in
 our
IDataProviders we are loading all rows for a given dataset.
So looking at the iterator method I see we can limit the result
 (and
  the
offset). Great I thought - however I see that that the size()
 method
  is
called as part of the getViewSize() in the AbstractPageableView.
 Thus
  I
need
to call the database here to figure out the size.
   
Am I doing sonething wrong or have I got to hit the database
 twice
 for
each
DataProvider render.
   
Obvously I don't want to hard code a size. Is there any other
 way ?
   
Thanks
Wayne
   
   
  
  
   -
   Michael Sparer
   http://talk-on-tech.blogspot.com
   --
   View this message in context:
  
 
 http://www.nabble.com/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20702476.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]



 
 -
 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/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20715382.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]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-27 Thread Stefan Fußenegger


Hi Igor,

thanks for implementing this minimal version. i totally agree with your
reasoning. Is there any chance though that this goes into 1.3 branch as
well? I'd really appreciate that.

you mentioned that you implemented such a repeater yourself. didn't you use
any navigation or did you write that yourself? just wondering.

shall i open a ticket against 1.5 to track this issue/enhancement?

best regards, stefan



igor.vaynberg wrote:
 
 On Thu, Nov 27, 2008 at 12:46 AM, Stefan Fußenegger
 [EMAIL PROTECTED] wrote:

 I don't think IDataProvider is only about databases.
 
 you started off with your core assumption being wrong. idataprovider
 was written exclusively for accessing databases. my thinking, at the
 time, was that 99% of people use wicket to build applications that
 access databases, and i dare say it was a good guess because in its ~3
 years of existence only a handful of people had a problem with the way
 it works.
 
 There are other data
 sources and some return the total amount and the desired subset at the
 same
 time (Lucene as a famous example). Such data sources would really benefit
 of
 a single-query-approach.
 
 i am not disputing this fact. i am simply saying that we are not going
 to fix this right now because this is not a bug. you are trying to use
 the components for something they were not designed to be used. in 1.5
 we may address this.
 
 I faced this issue myself in a search (read Lucene)
 centered application. I successfully went down the road of implementing a
 custom repeater.
 
 i had to do the same myself.
 
 But when the repeater was working as desired, I figured out
 that PagingNavigationLink is the real showstopper, not IDataProvider (see
 my
 JIRA comment [0]). The fix would be rather trivial, as
 PagingNavigationLink
 is doing something it needn't do (checking the requested page against the
 valid range of pages).

 Let me answer 2 possible questions in advance:

 Q: Why is this check in PagingNavigationLink a problem?
 A: Obviously, you can't fetch size and data as long as the page isn't
 known.
 
 the check is there because we code defensively. we do not assume that
 every implementation of ipageable will cull the number when you call
 setcurrentpage(x).
 
 Q: How would a custom repeater that fetches data and size at the same
 tame
 handle invalid (out of range) pages?
 A: Out of range pages will return the size and an empty dataset. In this
 case, the repeater would change the page number to the last valid and do
 a
 second query. Yeah, two queries again. But this should only happen rarely
 though.
 
 this will change the existing behavior. if you are on page 5 and click
 page 10 (which happens to not exist) you would end up back on 5 with
 your suggestion where as currently you would properly end up on 9.
 
 looking at WICKET-1784, i extracted the code you want into an
 overridable int cullPageNumber(int x). so feel free to subclass the
 link and override that to return x without any extra checks.
 
 we may properly fix this in 1.5, but for right now this is too big a
 refactor because it changes the basic assumptions with which the code
 was written.
 
 -igor
 

 Best regards, Stefan

 [0]
 https://issues.apache.org/jira/browse/WICKET-1784?focusedCommentId=12651278#action_12651278


 igor.vaynberg wrote:

 On Wed, Nov 26, 2008 at 9:32 AM, Wayne Pope
 [EMAIL PROTECTED] wrote:
so you think pushing all that extra data over the network is actually
more efficient then doing another query wtf.
 The point is I'd rather avoid 2 calls where 1 will do.
 AbstractPageableView
 will do fine I believe.

 the number of calls itself is meaningless, i dont comprehend why
 people have a hard time understanding this simple fact.

 if you have one call that takes 1000ms and ten calls that each take
 10ms you should concentrate on the one call that takes a long time
 rather then eliminating all ten 10ms calls which only saves you 100ms.
 if you can optimize the 1000ms and shave off 20% then your eleven
 calls are still faster then the one call.

 and since connection pools have been inventind many years ago there is
 no more overhead of establishing network connections, just pushing
 bits around. maybe that is still a problem in php, but in java it has
 been solved a long time ago.

 -igor



i can only assume that you have actually profiled your app and that
one select count() call was what was taking a significant chunk of
processing time in the database server? to the point where eliminating
it will actually reduce enough load on the database to increase your
throughput?

 No I haven't, as mentioned before, I just want to avoid 2 calls when
 one
 will do.  I have however seen several times in production systems
 waiting
 on
 i/o's reduces your scalability. I'd rather keep server count down as
 money
 is tight.
 I'll be mindfull not to ask 'stupid' questions again.



 On Wed, Nov 26, 2008 at 6:19 PM, Igor Vaynberg
 [EMAIL PROTECTED]wrote:

 On Wed, Nov 26, 2008 at 9:06

Dojo 1.1 integration available from wicketstuff

2008-11-21 Thread Stefan Fußenegger


Hi folks,

I just shared a new project called wicketstuff-dojo-1.1 [1], an integration
of the Dojo JavaScript toolkit [2] into Wicket. This project is based on
wicketstuff-dojo [3] and wicketstuff-push [4] (both based on dojo 0.4).
However, not all of the components from wicketstuff-dojo have been ported to
the new dojo version (but feel free to do so). 

Currently, there is no documentation available. I'll add some info to the
wicketstuff wiki next week. In the meantime, (really) early adopters can
check it out for review. To build the project, check it out and run `mvn
clean install`. To build a custom dojo distribution, place your
profile.profile.js (e.g. foobar.profile.js) in buildDojo/custom-profile/
and run `mvn -Ddojo.profile=profile clean install`. In your project pom,
add 

dependency
groupIdorg.wicketstuff/groupId
artifactIdwicketstuff-dojo-1.1/artifactId
version1.3.5-standard-SNAPSHOT/version
/dependency

or, for the custom profile

dependency
groupIdorg.wicketstuff/groupId
artifactIdwicketstuff-dojo-1.1/artifactId
version1.3.5-profile-SNAPSHOT/version
/dependency

(Not sure if this versioning strategy is the best choice, but it makes it
quite easy to use different custom profiles for different projects)

Looking forward to your feedback!

Regards, Stefan

[1]
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-dojo-1.1/
[2] http://dojotoolkit.org/
[3] http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Dojo
[4]
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-tp20625220p20625220.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]

Re: wicketstuff-push is over, wickestuff-dojo-1.1 is born ???

2008-11-21 Thread Stefan Fußenegger

see
http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-to20625220.html

Michael Sparer wrote:

Hi Julien,

we're doing our last tests today and tomorrow and will put
wicketstuff-dojo-1.1 into production by Monday. If no issues arise, we'll
share it as a wicketstuff project next week. Please note that so far, we
only ported some components to 1.1. (includes wiper, slider, drag and drop
and cometd). We're also making extensive use of cometd, which is quite a
bit better than in dojo 0.4 by the way, and it is also included in the
wicketstuff-dojo-1.1 project then. Then it's your turn to give
recommendations, improvements and, most important, help to get the same
functionality working for 1.1.

as for the corrupted push project: rodolfo made some changes, so I don't
know what's going on there. A version of wicketstuff-push before rodolfo
started with the makeover is available as a branch. Just check out
wicketstuff's branches, if you can't wait till next week.

regards,
Michael

julien Graglia wrote:

Hi,
I have read some posts (1) that seems to say that wicketstuff-push will
be replaced by a new wicketstuff-dojo-1.1 artifact.

The post says that this artifact is in a private SVN repo, but will be
available shortly..

Do you have any informations about that?

I need to do reverse ajax with wicket (cometd...) ie. push event from a
server thread at the server initiative. It works with an old (rev 4245)
version of wicketstuff-push. The trunk seems corrupted : a dojo
folder is missing..

1 : http://www.nabble.com/New-wicketstuff-dojo-project-td19070145.html
--
Julien Graglia
NetCeler

-
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/wicketstuff-push-is-over%2C-wickestuff-dojo-1.1-is-born-tp20356751p20625246.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]

AjaxFallbackButton: inconsistend submit order

2008-10-23 Thread Stefan Fußenegger


Hi folks,

I just stumbled upon a problem with a Form containing a nested Form and two
AjaxFallbackButtons (submit and preview). I need to implement different
onSubmit() behavior of the nested Form depending on the clicked button.

The order of onSubmit() calls is:

without JS:
- AjaxFallbackButton.onSubmit(AjaxRequestTarget,Form)
- OuterForm.onSubmit() // not used
- Inner Form.onSubmit()

with JS:
- Inner Form.onSubmit()
- OuterForm.onSubmit() // not used
- AjaxFallbackButton.onSubmit(AjaxRequestTarget,Form)

With JS, it is therefore not possible to determine which button was clicked
from inside a form's onSubmit() method.

Is this a (known) bug?

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/AjaxFallbackButton%3A-inconsistend-submit-order-tp20131329p20131329.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]

Re: Discussion on Wicket Interface Speed-Up

2008-09-02 Thread Stefan Fußenegger


wicketstuff-merged-resources is now available in JIRA:

http://wicketstuff.org/jira/browse/WMR

and from wicketstuff maven repo:
repositories
repository
idwicket-snaps/id
urlhttp://wicketstuff.org/maven/repository/url
snapshots
enabledtrue/enabled
/snapshots
releases
enabledtrue/enabled
/releases
/repository
/repositories

dependency
  groupIdorg.wicketstuff/groupId
  artifactIdwicketstuff-merged-resources/artifactId
  version1.3.4-SNAPSHOT/version
/dependency

i am also going to add a short wiki page at wicketstuff.org

regards, Stefan



Jörn Zaefferer-2 wrote:
 
 Good point, I forgot that wicketstuff has its own JIRA installation.
 Though the entry for the project is missing. Let me know once its
 there, and I'll create the report.
 
 Jörn
 
 On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl [EMAIL PROTECTED] wrote:
 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

Re: Discussion on Wicket Interface Speed-Up


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]

Re: Discussion on Wicket Interface Speed-Up


you're right with the encapsulation, but i feel that resource versioning (and
aggressive client side caching) could be a nice addition to wicket. but
maybe sombody can think of another way to reduce (merge) resources without
breaking encapsulation ...

btw, resource versioning also works with wicket-ajax.js and wicket-event.js:

protected void init() {
  final String version = getFrameworkSettings().getVersion();
  final String suffix = (n/a.equals(version) ?  : - + version) +
.js;

  getSharedResources().add(WicketAjaxReference.INSTANCE.getName(),
getResourceReference(WicketAjaxReference.class,
wicket-ajax.js).getResource());
  mountSharedResourceWithCaching(/scripts/wicket-ajax + suffix,
WicketAjaxReference.INSTANCE.getSharedResourceKey());

  getSharedResources().add(WicketEventReference.INSTANCE.getName(),
getResourceReference(WicketEventReference.class,
wicket-event.js).getResource());
  mountSharedResourceWithCaching(/scripts/wicket-event + suffix,
WicketEventReference.INSTANCE.getSharedResourceKey());
}

// it's getting dirty ...
protected void mountSharedResourceWithCaching(final String path, final
String resourceKey) {
  mount(new SharedResourceRequestTargetUrlCodingStrategy(path, resourceKey)
{
public IRequestTarget decode(final RequestParameters requestParameters)
{
  final SharedResourceRequestTarget t = (SharedResourceRequestTarget)
super.decode(requestParameters);
  if (t != null) {
  // wrap target
return new IRequestTarget() {
  public void detach(final RequestCycle requestCycle)
{t.detach(requestCycle);}

  public void respond(final RequestCycle requestCycle) {
t.respond(requestCycle);
final WebResponse response = (WebResponse)
requestCycle.getResponse();
response.setDateHeader(Expires, System.currentTimeMillis() +
CACHE_DURATION * 1000L);
response.setHeader(Cache-Control, max-age= +
CACHE_DURATION);
  }
};
  } else {
return null;
  }
}
  });
}

regards


igor.vaynberg wrote:
 
 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]
 
 
 


-
---
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-tp19197540p19214462.html
Sent from the Wicket - User mailing list archive

Re: Discussion on Wicket Interface Speed-Up

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
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

Re: Discussion on Wicket Interface Speed-Up


Sounds promising ... and little mysterious ;) Any concrete plans/ideas so
far?


Matej Knopp-2 wrote:
 
 On Fri, Aug 29, 2008 at 9:41 AM, Peter Ertl [EMAIL PROTECTED] wrote:
 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!

 And they are going to get it :) Resources are going to be much simpler
 in 1.5 - current code is too tangled and ambiguous.
 
 -Matej
 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

Re: Discussion on Wicket Interface Speed-Up

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]

Re: Discussion on Wicket Interface Speed-Up


just applied your patch

could somebody please create wicketstuff-merged-resources in JIRA and
teamcity?


Jörn Zaefferer-2 wrote:
 
 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]


 
 


-
---
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-tp19197540p19218353.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]

Discussion on Wicket Interface Speed-Up

2008-08-28 Thread Stefan Fußenegger


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]

Re: Escaping of strings containing in attributes

2008-08-05 Thread Stefan Fußenegger


no comments here?


Stefan Fußenegger wrote:
 
 While validating some of my pages, I found out that some pages do not
 validate due to  in attributes, e.g. 
 
  
 
 W3 validator complains with: character  is the first character of a
 delimiter but occurred as data.
 
 I'm doing the following in code:
 
 class Image { String path; String alt; }
 
 // for StaticImage see
 http://cwiki.apache.org/WICKET/how-to-load-an-external-image.html
 final StaticImage img = new StaticImage(image, new PropertyModel(img,
 path)));
 img.add(new AttributeModifier(alt, true, new PropertyModel(img,
 alt)));
 
 if alt contains foo  bar, the page won't validate. I think using
 PropertyModel together with AttributeModifier is quite common. however,
 the beans won't contain escaped markup ... hopefully ;)
 
 Should this be considered a bug? For the time beeing I use:
 
 new AttributeModifier(alt, true, new Model(album.getName())) {
   protected String newValue(final String currentValue, final String
 replacementValue) {
 return Strings.escapeMarkup(replacementValue).toString();
   }
 }
 
 
 
 btw: While looking for answers, I also found this (quite old) thread:
 
 http://www.nabble.com/Escaping-quotes-in-attributes-td11487305.html#a11487344
 
 Al Maw mentions a comment in code: attributes without values are
 possible, e.g. 'disabled' inside ComponentTag.writeOutput(...). As
 mentioned and suggested in this thread, this is not true for XHTML and
 should probably be fixed. However, the comment (and corresponding code) is
 still there (at least in wicket 1.3.4).
 
 best regards and nice weekend!
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Escaping-of-strings-containing---in-attributes-tp18779532p18832765.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]

Escaping of strings containing in attributes

2008-08-01 Thread Stefan Fußenegger


While validating some of my pages, I found out that some pages do not
validate due to  in attributes, e.g. 



W3 validator complains with: character  is the first character of a
delimiter but occurred as data.

I'm doing the following in code:

class Image { String path; String alt; }

// for StaticImage see
http://cwiki.apache.org/WICKET/how-to-load-an-external-image.html
final StaticImage img = new StaticImage(image, new PropertyModel(img,
path)));
img.add(new AttributeModifier(alt, true, new PropertyModel(img, alt)));

if alt contains foo  bar, the page won't validate. I think using
PropertyModel together with AttributeModifier is quite common. however, the
beans won't contain escaped markup ... hopefully ;)

Should this be considered a bug? For the time beeing I use:

new AttributeModifier(alt, true, new Model(album.getName())) {
  protected String newValue(final String currentValue, final String
replacementValue) {
return Strings.escapeMarkup(replacementValue).toString();
  }
}



btw: While looking for answers, I also found this (quite old) thread:

http://www.nabble.com/Escaping-quotes-in-attributes-td11487305.html#a11487344

Al Maw mentions a comment in code: attributes without values are possible,
e.g. 'disabled' inside ComponentTag.writeOutput(...). As mentioned and
suggested in this thread, this is not true for XHTML and should probably be
fixed. However, the comment (and corresponding code) is still there (at
least in wicket 1.3.4).

best regards and nice weekend!

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Escaping-of-strings-containing---in-attributes-tp18779532p18779532.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]

Re: Localizer cache with 150.000+ entries causing OutOfMemory

2008-06-19 Thread Stefan Fußenegger


Hi,

According to https://issues.apache.org/jira/browse/WICKET-1667 this issue
will be fixed in Wicket 1.3.4 and 1.4-M3 respectively. I already put the
patch into production and it works. Thanks to Igor!

Regards, Stefan


Heart wrote:
 
 I've met the same problem several days away and resovled it by override a
 method of Localizer
 
 see:
 http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--to17142582.html#a17182935
 
 that may help you a little.
 
 
 2008/6/9 Stefan Fußenegger [EMAIL PROTECTED]:
 

 I am just analysing a heap dump (god bless the
 -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due
 to
 an OutOfMemoryError (GC overhead limit exceeded to be precise). Using
 jhat, the 175456 instances of class
 org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry immediately
 got
 my attention. While looking through the 107 instance of
 ConcurrentHashMap,
 I
 found one *really* big one: Localizer.cache has a hash table length of
 262144, each of its 32 segments with about 5300 entries, where a hash key
 is
 a string, sometimes longer than 500 charactes, similar to (see
 Localizer.getCacheKey(String,Component)):


 fooTitle.bar-org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-org.apache.wicket.markup.html.panel.Fragment:track-org.apache.wicket.markup.html.list.ListItem:14-my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-org.apache.wicket.markup.html.list.ListItem:0-my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-my.company.boxes.BodyBox:2-org.apache.wicket.markup.repeater.RepeatingView:body-my.company.layout.Border:border-my.company.pages.music.FoobarPage:43-de-null

 Those numbers pretty much convinced me: The localizer cache has blown
 away
 my application.

 Looking at this hash keys, I suspect the following problem: those strings
 are constructed from the position of a localized String on a page,
 which
 is quite a bad thing if you use nested list views or repeating views to
 construct your page. For instance, I have a panel with a long (pageable)
 list of entries, might be  5000 entries which might appear on various
 positions in a repeating view I use as a container for most of my pages.
 Let's say there are 5 possible positions, this would cause 2500 thousand
 cached entries, each with a key of 300+ characters plus some more
 characters
 for the cached message - feel free to do the maths. From a quick estimate
 I'd say: No wonder, this has blown away my app.

 As a quick fix, I'd suggest to regularly clear the localizer cache, use a
 more sophisticated cache (that expires old entries once in a while!!) or
 to
 disable the cache completely. However, don't try to overwrite
 Localizer.newCache() and clear the cache regularly: clearCache() will
 replace your cache with a ConcurrentHashMap (not using
 Localizer.newCache()). However, quite unlikely, that this will happen as
 newCache() is private anyway ;) I am going to add some code to clear the
 cache regularly.

 Best regards, Stefan

 PS: I'll also create a JIRA issue, but I am really short on time right
 now.

 -
 ---
 Stefan Fußenegger
 http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
 --
 View this message in context:
 http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.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]


 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p18000380.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]

Re: Localizer cache with 150.000+ entries causing OutOfMemory

2008-06-10 Thread Stefan Fußenegger


Hi Igor,

Thanks for your quick reply and the patch, sorry for not searching the
mailinglist only but not JIRA.

Your patch was for 1.4, I applied it to 1.3.3, created a quickstart
including JUnit test and attached it to the JIRA issue. Hope this fix gets
into the next maintenance release. I am to lazy to create a properly patched
jar and a MVN repo for my team right now ;)

Regards, Stefan



igor.vaynberg wrote:
 
 try applying this patch and see if it helps
 
 https://issues.apache.org/jira/browse/WICKET-1667
 
 -igor
 
 On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger
 [EMAIL PROTECTED] wrote:

 I am just analysing a heap dump (god bless the
 -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due
 to
 an OutOfMemoryError (GC overhead limit exceeded to be precise). Using
 jhat, the 175456 instances of class
 org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry immediately
 got
 my attention. While looking through the 107 instance of
 ConcurrentHashMap, I
 found one *really* big one: Localizer.cache has a hash table length of
 262144, each of its 32 segments with about 5300 entries, where a hash key
 is
 a string, sometimes longer than 500 charactes, similar to (see
 Localizer.getCacheKey(String,Component)):

 fooTitle.bar-org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-org.apache.wicket.markup.html.panel.Fragment:track-org.apache.wicket.markup.html.list.ListItem:14-my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-org.apache.wicket.markup.html.list.ListItem:0-my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-my.company.boxes.BodyBox:2-org.apache.wicket.markup.repeater.RepeatingView:body-my.company.layout.Border:border-my.company.pages.music.FoobarPage:43-de-null

 Those numbers pretty much convinced me: The localizer cache has blown
 away
 my application.

 Looking at this hash keys, I suspect the following problem: those strings
 are constructed from the position of a localized String on a page,
 which
 is quite a bad thing if you use nested list views or repeating views to
 construct your page. For instance, I have a panel with a long (pageable)
 list of entries, might be  5000 entries which might appear on various
 positions in a repeating view I use as a container for most of my pages.
 Let's say there are 5 possible positions, this would cause 2500 thousand
 cached entries, each with a key of 300+ characters plus some more
 characters
 for the cached message - feel free to do the maths. From a quick estimate
 I'd say: No wonder, this has blown away my app.

 As a quick fix, I'd suggest to regularly clear the localizer cache, use a
 more sophisticated cache (that expires old entries once in a while!!) or
 to
 disable the cache completely. However, don't try to overwrite
 Localizer.newCache() and clear the cache regularly: clearCache() will
 replace your cache with a ConcurrentHashMap (not using
 Localizer.newCache()). However, quite unlikely, that this will happen as
 newCache() is private anyway ;) I am going to add some code to clear the
 cache regularly.

 Best regards, Stefan

 PS: I'll also create a JIRA issue, but I am really short on time right
 now.

 -
 ---
 Stefan Fußenegger
 http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
 --
 View this message in context:
 http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.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]
 
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17751273.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]

Re: Localizer cache with 150.000+ entries causing OutOfMemory

2008-06-10 Thread Stefan Fußenegger


Hi Daniel,

I didn't put the patch into production yet, but I am quite confident, that
it will help. As you can see in the example I attached to the JIRA issue
(just attached a new version), the unpatched Localizer had 200 entries in
his cache, the patched Localizer only four - which is a Good Thing (tm), as
there are only 4 different cached values!

Regards, Stefan



Daniel Frisk wrote:
 
 So the patch did help?
 
 I too have observed this problem but it was at the moment less of a  
 problem than other heap eaters, now this is next in line. We have  
 added a script which automatically restarts the server when repeated  
 OOME occurs and are down to a couple of times per week without the  
 patch. But still, who wouldn't want to see months of uptime...
 
 // Daniel
 jalbum.net
 
 
 On 2008-06-10, at 11:29, Stefan Fußenegger wrote:
 

 Hi Igor,

 Thanks for your quick reply and the patch, sorry for not searching the
 mailinglist only but not JIRA.

 Your patch was for 1.4, I applied it to 1.3.3, created a quickstart
 including JUnit test and attached it to the JIRA issue. Hope this  
 fix gets
 into the next maintenance release. I am to lazy to create a properly  
 patched
 jar and a MVN repo for my team right now ;)

 Regards, Stefan



 igor.vaynberg wrote:

 try applying this patch and see if it helps

 https://issues.apache.org/jira/browse/WICKET-1667

 -igor

 On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger
 [EMAIL PROTECTED] wrote:

 I am just analysing a heap dump (god bless the
 -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application  
 cache due
 to
 an OutOfMemoryError (GC overhead limit exceeded to be precise).  
 Using
 jhat, the 175456 instances of class
 org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry  
 immediately
 got
 my attention. While looking through the 107 instance of
 ConcurrentHashMap, I
 found one *really* big one: Localizer.cache has a hash table  
 length of
 262144, each of its 32 segments with about 5300 entries, where a  
 hash key
 is
 a string, sometimes longer than 500 charactes, similar to (see
 Localizer.getCacheKey(String,Component)):

 fooTitle.bar- 
 org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink- 
 org.apache.wicket.markup.html.panel.Fragment:track- 
 org.apache.wicket.markup.html.list.ListItem:14- 
 my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos- 
 org.apache.wicket.markup.html.list.ListItem:0- 
 my.company.BarListPanel$1:bars-my.company.FooListPanel:panel- 
 my.company.boxes.BodyBox:2- 
 org.apache.wicket.markup.repeater.RepeatingView:body- 
 my.company.layout.Border:border-my.company.pages.music.FoobarPage: 
 43-de-null

 Those numbers pretty much convinced me: The localizer cache has  
 blown
 away
 my application.

 Looking at this hash keys, I suspect the following problem: those  
 strings
 are constructed from the position of a localized String on a page,
 which
 is quite a bad thing if you use nested list views or repeating  
 views to
 construct your page. For instance, I have a panel with a long  
 (pageable)
 list of entries, might be  5000 entries which might appear on  
 various
 positions in a repeating view I use as a container for most of my  
 pages.
 Let's say there are 5 possible positions, this would cause 2500  
 thousand
 cached entries, each with a key of 300+ characters plus some more
 characters
 for the cached message - feel free to do the maths. From a quick  
 estimate
 I'd say: No wonder, this has blown away my app.

 As a quick fix, I'd suggest to regularly clear the localizer  
 cache, use a
 more sophisticated cache (that expires old entries once in a  
 while!!) or
 to
 disable the cache completely. However, don't try to overwrite
 Localizer.newCache() and clear the cache regularly: clearCache()  
 will
 replace your cache with a ConcurrentHashMap (not using
 Localizer.newCache()). However, quite unlikely, that this will  
 happen as
 newCache() is private anyway ;) I am going to add some code to  
 clear the
 cache regularly.

 Best regards, Stefan

 PS: I'll also create a JIRA issue, but I am really short on time  
 right
 now.

 -
 ---
 Stefan Fußenegger
 http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
 --
 View this message in context:
 http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.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]





 -
 ---
 Stefan Fußenegger
 http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
 -- 
 View this message in context:
 http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing

Localizer cache with 150.000+ entries causing OutOfMemory

2008-06-09 Thread Stefan Fußenegger


I am just analysing a heap dump (god bless the
-XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due to
an OutOfMemoryError (GC overhead limit exceeded to be precise). Using
jhat, the 175456 instances of class
org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry immediately got
my attention. While looking through the 107 instance of ConcurrentHashMap, I
found one *really* big one: Localizer.cache has a hash table length of
262144, each of its 32 segments with about 5300 entries, where a hash key is
a string, sometimes longer than 500 charactes, similar to (see
Localizer.getCacheKey(String,Component)):

fooTitle.bar-org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-org.apache.wicket.markup.html.panel.Fragment:track-org.apache.wicket.markup.html.list.ListItem:14-my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-org.apache.wicket.markup.html.list.ListItem:0-my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-my.company.boxes.BodyBox:2-org.apache.wicket.markup.repeater.RepeatingView:body-my.company.layout.Border:border-my.company.pages.music.FoobarPage:43-de-null

Those numbers pretty much convinced me: The localizer cache has blown away
my application. 

Looking at this hash keys, I suspect the following problem: those strings
are constructed from the position of a localized String on a page, which
is quite a bad thing if you use nested list views or repeating views to
construct your page. For instance, I have a panel with a long (pageable)
list of entries, might be  5000 entries which might appear on various
positions in a repeating view I use as a container for most of my pages.
Let's say there are 5 possible positions, this would cause 2500 thousand
cached entries, each with a key of 300+ characters plus some more characters
for the cached message - feel free to do the maths. From a quick estimate
I'd say: No wonder, this has blown away my app.

As a quick fix, I'd suggest to regularly clear the localizer cache, use a
more sophisticated cache (that expires old entries once in a while!!) or to
disable the cache completely. However, don't try to overwrite
Localizer.newCache() and clear the cache regularly: clearCache() will
replace your cache with a ConcurrentHashMap (not using
Localizer.newCache()). However, quite unlikely, that this will happen as
newCache() is private anyway ;) I am going to add some code to clear the
cache regularly.

Best regards, Stefan

PS: I'll also create a JIRA issue, but I am really short on time right now.

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.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]

Re: users, please give us your opinion: what is your take on generics with Wicket

2008-06-03 Thread Stefan Fußenegger


1) Generifying* Wicket
   [X] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.

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.

I didn't read all of the posts here, but I would suggest to go for Component
or even @SuppressWarnings(unchecked). This way, you don't have to use
generified components but are still able to do so. Currently, I am always
passing models as parameter to the constructor of my custom components.
Those parameters are always named according to the expected type they
contain (e.g. fooModel if i expect an object of type Foo in there).
Therefore, generics could jump in quite easily and I am looking forward to
use them!

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17618096.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]

Re: Use Spring with Wicket

2008-06-03 Thread Stefan Fußenegger


Martijn Dashorst compiled a nice list of books (3 for beginners, another 3 on
advanced topics) that will certainly help you to get started:

http://martijndashorst.com/blog/2008/05/25/wicket-starter-kit/

Regards


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Use-Spring-with-Wicket-tp17600138p17619622.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]

Memory leak in DiskPageStore

2008-06-02 Thread Stefan Fußenegger


Recently, I had 2 memory related crashes of my Wicket app. Thanks to the
priceless -XX:+HeapDumpOnOutOfMemoryError option, I had a heap dump to look
at (one crash was due to a GC overhead exception, so no dump there). One
thing that immediately attracted my attention was that there were 116.917
instances of
org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry. As
objects of this class represent a session (javadoc), it seems that I had
116.917 sessions mapped in DiskPageStore.sessionIdToEntryMap.

In my app, i spotted two reasons for this;
1. search engine bots (e.g. googlebot) receive a new session for each page
they access, as we cut of the ;jsessionid= from the URL in our app in order
not to have those ugly IDs on the search engine result pages. As a result,
when google tried to index 100.000+ pages 100.000+ sessions had been
created. I am certainly going to work on this issue, however, it helped me
to spot reason number 2:

2. No entries are removed from DiskPageStore.sessionIdToEntryMap. I guess,
this should be added to the DiskPageStore.unbind(String sessionId) method:

public void unbind(String sessionId)
{
// FIX: replace get() with remove()
SessionEntry entry = 
(SessionEntry)sessionIdToEntryMap.get(sessionId);
if (entry != null)
{
if (isSynchronous())
{
entry.unbind();
}
else
{
List pages = getPagesToSaveList(sessionId);
synchronized (pages)
{
flushPagesToSaveList(sessionId, pages);
entry.unbind();
}
pagesToSaveAll.remove(sessionId);
}
}
}

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597466.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]

Re: Memory leak in DiskPageStore

2008-06-02 Thread Stefan Fußenegger


https://issues.apache.org/jira/browse/WICKET-1679


Matej Knopp-2 wrote:
 
 Hi,
 
 about not removing the entries, can you please create jira issue? I
 will try to look into it ASAP.
 
 -Matej
 
 On Mon, Jun 2, 2008 at 11:38 AM, Stefan Fußenegger
 [EMAIL PROTECTED] wrote:

 Recently, I had 2 memory related crashes of my Wicket app. Thanks to the
 priceless -XX:+HeapDumpOnOutOfMemoryError option, I had a heap dump to
 look
 at (one crash was due to a GC overhead exception, so no dump there). One
 thing that immediately attracted my attention was that there were 116.917
 instances of
 org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry. As
 objects of this class represent a session (javadoc), it seems that I
 had
 116.917 sessions mapped in DiskPageStore.sessionIdToEntryMap.

 In my app, i spotted two reasons for this;
 1. search engine bots (e.g. googlebot) receive a new session for each
 page
 they access, as we cut of the ;jsessionid= from the URL in our app in
 order
 not to have those ugly IDs on the search engine result pages. As a
 result,
 when google tried to index 100.000+ pages 100.000+ sessions had been
 created. I am certainly going to work on this issue, however, it helped
 me
 to spot reason number 2:

 2. No entries are removed from DiskPageStore.sessionIdToEntryMap. I
 guess,
 this should be added to the DiskPageStore.unbind(String sessionId)
 method:

public void unbind(String sessionId)
{
// FIX: replace get() with remove()
SessionEntry entry =
 (SessionEntry)sessionIdToEntryMap.get(sessionId);
if (entry != null)
{
if (isSynchronous())
{
entry.unbind();
}
else
{
List pages =
 getPagesToSaveList(sessionId);
synchronized (pages)
{
flushPagesToSaveList(sessionId,
 pages);
entry.unbind();
}
pagesToSaveAll.remove(sessionId);
}
}
}

 -
 ---
 Stefan Fußenegger
 http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
 --
 View this message in context:
 http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597466.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]
 
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597859.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]

Re: How to avoid Lazy loading exception

2008-05-04 Thread Stefan Fußenegger


Do you have OpenSessionInViewFilter in your web.xml? If no, you will get this
exception whenever you try to do lazy loading outside your DAOs.

add to web.xml:
  filter
filter-nameOpenSessionFilter/filter-name
filter-class
  org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
/filter-class
init-param
  param-namesessionFactoryBeanName/param-name
  param-valuehibernateSessionFactory/param-value
/init-param
  /filter

  filter-mapping
filter-nameOpenSessionFilter/filter-name
url-pattern/*/url-pattern
  /filter-mapping

I always use a self-written class called PersistentObjectModel (a
LoadableDetachableModel) and let all my Persisent classes implement an
interface called IPersistentObject with a single method: Serializable
getId()

public class PersistentObjectModelT extends IPersistentObject extends
LoadableDetachableModel {

private static final long serialVersionUID = 1L;

private final ClassT _clazz;

private final int _id;

@SpringBean(name = myDao)
private IMyDao _myDao;

@SuppressWarnings(unchecked)
public PersistentObjectModel(final T object) {
super(object);

if (object instanceof HibernateProxy) {
_clazz = (ClassT) ((HibernateProxy)
object).getHibernateLazyInitializer()
.getImplementation().getClass();
} else {
_clazz = (ClassT) object.getClass();
}
_id = object.getId();
// inject the bean
InjectorHolder.getInjector().inject(this);
}

public PersistentObjectModel(final ClassT clazz, final int id) {
_clazz = clazz;
_id = id;
// inject the bean
InjectorHolder.getInjector().inject(this);
}

@Override
protected T load() {
return _myDao.getById(_clazz, _id);
}

@SuppressWarnings(unchecked)
@Override
public T getObject() {
return (T) super.getObject();
}

}


This makes working with hibernate objects really easy:

setModel(new PersistentObjectModel(Foo.class, 1)); // option 1: class and id
setModel(new PersistentObjectModel(foo)); // option 2: persistent object

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/How-to-avoid-Lazy-loading-exception-tp17040941p17045620.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]

Wicket fail-over with Terracotta - sticky or non-sticky sessions?

2008-04-03 Thread Stefan Fußenegger


Hi all,

I am currently evaluating a Wicket fail-over solution (two equal nodes with
a floating IP, probably using Linux Heartbeat) with Terracotta. Of course,
it would be desirable to switch between nodes without any impact on a user's
session. In order to provide this, the cluster must be able to handle
non-sticky sessions. Session clustering works like a breeze with Wicket and
Terracotta

I already spotted a problem with buffered redirects, that could be avoided
with a different rendering strategy
(IRequestCycleSettings.REDIRECT_TO_RENDER). However, this problem would only
occur if a node goes down just when the client is redirecting - not very
likely and probably acceptable as switching over might take a few seconds
anyway.

Now my question: What other problems could appear when I only use session
clustering for fail-over purposes? Can I stay with the default rendering
strategy (IRequestCycleSettings.REDIRECT_TO_BUFFER) without clustering the
buffer if I accept missing feedback messages in the above scenario?

Any further comments on my setup will be appreciated as well!

(If answers are woth it, I'll create a wiki page out of this thread)

Best Regards, Stefan


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Wicket-fail-over-with-Terracotta---sticky-or-non-sticky-sessions--tp16467830p16467830.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]

Re: Accessing prototype scoped panel beans using @SpringBean annotation

)
 at org.apache.wicket.Page.renderPage(Page.java:870)
 at
 org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:231)
 at
 org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:103)
 at
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172)
 at org.apache.wicket.RequestCycle.step(RequestCycle.java:1241)
 at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316)
 at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
 at
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354)
 
 
 Can anyone throw some light on what I'm doing wrong.  I'm not tied to the
 idea of the Panels being prototype beans however without it, immediately
 on server startup, I get a WicketRuntimeException: There is no
 application attached to current thread main.  Making them prototype seems
 to be the only way for me to get my server to startup cleanly.
 
 Thanks,
 Tom.
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Accessing-prototype-scoped-panel-beans-using-%40SpringBean-annotation-tp15627974p15631515.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]

Re: how to create the component dynamic?


Hi Mead,

I'd say that wicket is a real cool choice to accomplish this (I know what
I'm talking about as I hacked such a tool in PHP years ago in my programming
infancy ;) )

There is no general answer though. But for different question types you
could do

if (type == DROP_DOWN_QUESTION) add(new DropDownQuestionPanel(panel,
question);
else if (type == RADIO_QUESTION) add(new RadioQuestionPanel(panel,
question);
// you got the idea

you could also create the panels dynamically by giving a type such as
com.foo.questiontype.DropDown using reflection. This way you could create
a quite flexible solution, where you could drop in just another jar to add
new question types.

If it comes to different numbers of possibilities, RepeatingView might be a
good choice.

Best regards and good luck




Mead-2 wrote:
 
  Well, I wanne build a Survey-System!
 Now there're some Questions in the Survey-System, and will default some
 answer-item for user to choice!
 following is the example of Question
 1,It's the weather good today?(A.B.C. would be radio)
   A.yes, Sunny
   B.no, Rainy
   C.so so
 I think all the component shall be created at run time! but some question
 has 5 items some has 3 items,
 some is a TextField which filled by user, some is CheckBox or Radio.
 How to do with this?
 
 Mead
 
  
  
  
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/how-to-create-the-component-dynamic--tp15630091p15631519.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]

usage of AbortWithHttpStatusException


Hi,

How is AbortWithHttpStatusException meant to be used? I expected that this
exception would result in a (e.g.) 404 error page to be shown. However, all
I get is an empty page. Any ideas on how I can get a nice, custom error page
to show up?

Cheers, Stefan

btw: i'm using jetty if this is important.

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/usage-of-AbortWithHttpStatusException-tp15631513p15631513.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]

Re: Accessing prototype scoped panel beans using @SpringBean annotation


What do you mean by directly? Do you want to inject the panels rather than
the factories? You could probably try to write your own annotation and use a
custom org.apache.wicket.injection.IFieldValueFactory



Ned Collyer wrote:
 
 
 Stefan Fußenegger wrote:
 
 Hi Tom,
 
 I'd suggest not to use Spring to manage panels. You should rather create
 a new panel for every page and request. You should use Spring to manage
 your services and inject those into your panels.
 
 Best regards, Stefan
 
 
 Hi Stephan :) (I work with Tom)
 
 We have a work around for this specific problem, and it still involves
 spring, but not using panels directly.
 
 Basically the situation is as follows.
 
 We have a main wicket project which is published as a jar.
 
 There are also other modules also published as plugin jars.
 
 We launch these with an embedded jetty instance.
 
 The problem is the Main project contains the page instances, and the other
 jars contain the panels.
 
 The Main project has no idea about which panels are available, as these
 will be determined at run time by whatever has been configured (thru
 spring).  The main jar has no knowledge of which panel classes exist - so
 we cannot really instantiate new ones using plain old java.
 
 There are a few ways to approach this, ie, having some class loader which
 resolves given string class references, and those strings are wired in
 through spring.  This works - but feels a bit hacky.
 
 Our workaround is .. somewhat similar - we basically have a panel factory
 in the plugin that instantiate a panel and return it.  We can then wire
 these panel factories thru spring to a given page.
 
 This turns out to be quite elegant - however it would be nice if we had
 the ability to wire plugin panels to the main jar directly without this
 factory.
 
 Rgds
 
 Ned
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Accessing-prototype-scoped-panel-beans-using-%40SpringBean-annotation-tp15627974p15632905.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]

RestartResponseAtInterceptPageException with Ajax

2008-02-21 Thread Stefan Fußenegger

Hi,

I'm currently trying to use RestartResponseAtInterceptPageException with
Ajax. More precisely, I show a component that refreshes itself after
executing an authorized action. It the user is not authorized to execute
this action, I'd like to redirect him to the Login-Page. After proper login,
the user should be redirected to the original page. However, using
continueToOriginalDestination() does not work (out of the box), as the User
is redirected to the URL of the Ajax request.

Workaround/Possible changes to simplify workaround:

A custom workaround would be to do a custom PageMap implementation. However,
as the method setUpRedirect(RequestCycle) is private, deriving from the
default PageMap will require some ugly copy-paste in order to do so. This
could be avoided by a) making setUpRedirect(RequestCycle) protected and/or
b) introduce a protected method that constructs the interceptContinuationURL
inside setUpRedirect(RequestCycle).

Changing default behaviour:

The workaround version is not trivial, as in requires quite a bit of
knowledge of Wicket's inner workings (What the hell is a PageMap?).
Therefore, it might be a good idea to change the default behaviour there, as
no user wants to see Ajax responses at all (well, at least no normal user -
I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour be
somewhat more intelligent by default (without hacking a custom PageMap)?
That is to redirect to the page the Ajax request belonged to? Or even
better: redirect to the Ajax call and render the complete page (well, don't
know how tricky that would be).

Or do I miss something completely? Any other possible workarounds or
suggestions?

Cheers, Stefan

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15607225.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]

Re: RestartResponseAtInterceptPageException with Ajax

2008-02-21 Thread Stefan Fußenegger

Maurice,

Thanks for your suggestions. However, these suggestions are yet 2 other
workarounds for this problem.

imho, using RestartResponseAtInterceptPageException and
continueToOriginalDestination() should work out of the box, regardless of
the type of request (Ajax and non-Ajax). Therefore I suggest adding support
to the framework - and your suggestions did not convince me not to do so,
sorry ;)

However, the strategy to choose a page for continueToOriginalDestination()
is open for discussion. The simplest approach would be to go back to the
source of the Ajax request, while allowing to complete the request and
render the entire page afterwards would be best.

-- Stefan

Mr Mean wrote:

Hmm, i'm not sure this will work at all with the restartresponse but i
have 2 alternatives that do not require changes to wicket

-append some javascript to the ajaxrequesttarget that will trigger the
browser to request your login page (you can get the wicket url for the
loginpage using urlFor)
if your login page accepts pageparams you can use those to decide
what the response for a successful login should be.

-open you login page in a ModalWindow on the same page and close it
after a successful login (you might need to refresh the origin page
after this)

Maurice

On Thu, Feb 21, 2008 at 10:30 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:

Hi,

I'm currently trying to use RestartResponseAtInterceptPageException with
Ajax. More precisely, I show a component that refreshes itself after
executing an authorized action. It the user is not authorized to execute
this action, I'd like to redirect him to the Login-Page. After proper
login,
the user should be redirected to the original page. However, using
continueToOriginalDestination() does not work (out of the box), as the
User
is redirected to the URL of the Ajax request.

Workaround/Possible changes to simplify workaround:

A custom workaround would be to do a custom PageMap implementation.
However,
as the method setUpRedirect(RequestCycle) is private, deriving from the
default PageMap will require some ugly copy-paste in order to do so.
This
could be avoided by a) making setUpRedirect(RequestCycle) protected
and/or
b) introduce a protected method that constructs the
interceptContinuationURL
inside setUpRedirect(RequestCycle).

Changing default behaviour:

The workaround version is not trivial, as in requires quite a bit of
knowledge of Wicket's inner workings (What the hell is a PageMap?).
Therefore, it might be a good idea to change the default behaviour
there, as
no user wants to see Ajax responses at all (well, at least no normal
user -
I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour be
somewhat more intelligent by default (without hacking a custom PageMap)?
That is to redirect to the page the Ajax request belonged to? Or even
better: redirect to the Ajax call and render the complete page (well,
don't
know how tricky that would be).

Or do I miss something completely? Any other possible workarounds or
suggestions?

Cheers, Stefan

-
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/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15610291.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]

Re: RestartResponseAtInterceptPageException with Ajax

2008-02-21 Thread Stefan Fußenegger


I was just waiting for green lights ;)

https://issues.apache.org/jira/browse/WICKET-1363


igor.vaynberg wrote:
 
 feel free to add a jira request for this
 
 -igor
 
 
 On Thu, Feb 21, 2008 at 4:44 AM, Stefan Fußenegger
 [EMAIL PROTECTED] wrote:

  Maurice,

  Thanks for your suggestions. However, these suggestions are yet 2 other
  workarounds for this problem.

  imho, using RestartResponseAtInterceptPageException and
  continueToOriginalDestination() should work out of the box, regardless
 of
  the type of request (Ajax and non-Ajax). Therefore I suggest adding
 support
  to the framework - and your suggestions did not convince me not to do
 so,
  sorry ;)

  However, the strategy to choose a page for
 continueToOriginalDestination()
  is open for discussion. The simplest approach would be to go back to the
  source of the Ajax request, while allowing to complete the request and
  render the entire page afterwards would be best.

  -- Stefan





  Mr Mean wrote:
  
   Hmm, i'm not sure this will work at all with the restartresponse but i
   have 2 alternatives that do not require changes to wicket
  
   -append some javascript to the ajaxrequesttarget that will trigger the
   browser to request your login page (you can get the wicket url for the
   loginpage using urlFor)
if your login page accepts pageparams you can use those to decide
   what the response for a successful login should be.
  
   -open you login page in a ModalWindow on the same page and close it
   after a successful login (you might need to refresh the origin page
   after this)
  
   Maurice
  
   On Thu, Feb 21, 2008 at 10:30 AM, Stefan Fußenegger
   [EMAIL PROTECTED] wrote:
  
Hi,
  
I'm currently trying to use RestartResponseAtInterceptPageException
 with
Ajax. More precisely, I show a component that refreshes itself after
executing an authorized action. It the user is not authorized to
 execute
this action, I'd like to redirect him to the Login-Page. After
 proper
   login,
the user should be redirected to the original page. However, using
continueToOriginalDestination() does not work (out of the box), as
 the
   User
is redirected to the URL of the Ajax request.
  
  
Workaround/Possible changes to simplify workaround:
  
A custom workaround would be to do a custom PageMap implementation.
   However,
as the method setUpRedirect(RequestCycle) is private, deriving from
 the
default PageMap will require some ugly copy-paste in order to do so.
   This
could be avoided by a) making setUpRedirect(RequestCycle) protected
   and/or
b) introduce a protected method that constructs the
   interceptContinuationURL
inside setUpRedirect(RequestCycle).
  
  
Changing default behaviour:
  
The workaround version is not trivial, as in requires quite a bit of
knowledge of Wicket's inner workings (What the hell is a
 PageMap?).
Therefore, it might be a good idea to change the default behaviour
   there, as
no user wants to see Ajax responses at all (well, at least no normal
   user -
I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour
 be
somewhat more intelligent by default (without hacking a custom
 PageMap)?
That is to redirect to the page the Ajax request belonged to? Or
 even
better: redirect to the Ajax call and render the complete page
 (well,
   don't
know how tricky that would be).
  
Or do I miss something completely? Any other possible workarounds or
suggestions?
  
Cheers, Stefan
  
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
  
 http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15607225.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]
  
  
  


  -
  ---
  Stefan Fußenegger
  http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
  --
  View this message in context:
 http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15610291.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]
 
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer

Re: (Server-independent) Comet support in Wicket?

2008-02-20 Thread Stefan Fußenegger

wicketstuff-push might be what you are looking for: wicket cometd support
with jetty. but i don't think that anybody has used it with 10k simultaneous
users yet.

see:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/

Jörn Zaefferer-2 wrote:

Hi,

I've started evaluating Wicket today for an application written from
scratch. First impressions are very well, there is just one
requirement on which I couldn't find enough useful information yet:
Comet support in Wicket or Comet with Wicket.

Before looking at Wicket I tried to use lift which has Comet support
built in (based on Scala Actors). This post
(http://blogs.webtide.com/gregw/2006/07/25/1153845234453.html)
suggests that its not possible to implement scaleable Comet support
within a web framework, instead it must be supported by the
application server, eg. Jetty 6.

Post about Comet and Wicket, eg. this one
(http://www.mail-archive.com/[EMAIL PROTECTED]/msg17308.html)
don't give me any actual information about the current state of afairs
(its from 2006, the linked sf.net issue is now private). This issue
(http://wicketstuff.org/jira/browse/DOJO-23) about integration with
cometd isn't too helpful either, I can't find any documentation on
that.

To provide some information on the actual requirements I have: The
architecture must support several both dependent and independent
components on a single page which get updated based on server-events,
be it on schedules or events triggered by other users. While the exact
number of simultaneous users isn't clear yet, up to 10k must be
possible with the appropriate hardware.

Thanks
Jörn Zaefferer

-
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/%28Server-independent%29-Comet-support-in-Wicket--tp15574656p15589149.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]

Re: Minor Announcement: wicket-googlecharts

2007-12-21 Thread Stefan Fußenegger


Hi Daniel,

Last week I did exactly the same as you did here and was also planing to
release it as wicketstuff project ... i think this could be called bad
timing ;)

Maybe we could collaborate on this in the future (I'll have a closer look
after Christmas and maybe merge my stuff with yours)

Regards, Stefan


Daniel Spiewak wrote:
 
 Just a minor sidebar, at Johan's suggestion I've released
 wicket-googlecharts into the wicket-stuff project.  I played with the
 build
 system a bit to make it work with maven and I think I did it right, but my
 maven experience is limited.  License is currently discretionary, though
 if
 I really had to pick one I'd probably go with either ASL2 or BSD.
 
 Warning: anything that isn't tested by the test page in the project is
 completely theoretical and untested.  This means things like scatter
 plots,
 color fills, etc are all up in the air.  I'll probably get around to
 stabilizing functionality eventually, but for now it can just float.
 Hopefully someone will find this useful!
 
 Daniel
 
 (original article:
 http://www.codecommit.com/blog/java/a-wicket-api-for-google-charts)
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Minor-Announcement%3A-wicket-googlecharts-tp14442165p14454946.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]

Re: Attempted summary of multiple wicket:child / thread

2007-11-11 Thread Stefan Fußenegger

 pushing my luck asking to provide two aliases
 ;)

 C) If you don't 'override' a 'default' section in a derived page wicket
 uses the 'default' section provided in the base page.

 (Comment - arrhh beautiful - 100% accurate and natural)

 At university I remember a lecturer telling a story of an interview with
 one of the creators of Unix. He was asked if he had any regrets over his
 illustrious career and he said Yes I do, I regret naming the 'create'
 function 'creat' instead of 'create' just to save one byte!. How much
 frustration does a bad name cause?

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 
 -- 
 Bruno Borges
 blog.brunoborges.com.br
 +55 1185657739
 
 The glory of great men should always be
 measured by the means they have used to
 acquire it.
 - Francois de La Rochefoucauld
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13690139
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Attempted summary of multiple wicket:child / thread

2007-11-09 Thread Stefan Fußenegger

I think it would be a nice feature to define defaults and overrides this way.
However, this wouldn't be backwards compatible anymore as the contents are
currently ignored. (Ok, you are currently forced to extend them, so you
probably wouldn't see the markup from such sections in *old* applications.)

My vote on this:
- I would love to have multiple sections.
- I would appreciate default markup for extendible sections.

Kind regards,

-- stefan

PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :)

Chris Colman wrote:

That is what I'd suggest as well, since it involves the least amount
of
change. As an added bonus, if no id's are added and 2 wicket:child
sections are used, it could throw an exception (which it currently
does
not do, it just silently ignores the second wicket:child).

That would be magic!

While we're at this epic moment after spending days thrashing this out
could we spend just 3 extra minutes to investigate implementing standard
Java method like behavior for this feature?
Ie., In the case that no override extend is provided in a derived
page, simply use the markup in the child tag in the base page.

Then it would work like methods work in Java - and it's probably how
most Java developers would naturally expect an OO framework like wicket
to work anyway.

Intuitively it seems like an easy to implement option in the framework:
the child/extend feature is already merging code from the base page
anyway - if there is no override extend tag in a derived page then it
simply pulls the markup from the base page's child tag.

Regards,
Sebastiaan

-
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/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13662915
Sent from the Wicket - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: facebook support

2007-11-09 Thread Stefan Fußenegger


I'd be interested in Facebook and Open Social support. However, I don't have
any experience with either of them.

It would be extremely cool to have a common interface for both of them -
write once run everywhere.

I would also help implementing it. I don't have much time to spend tough.
For my project, facebook and open social support won't be required within
the next 6 month. (But it would be cool to have.)

-- Stefan




Jonathan Locke wrote:
 
 I'd like to get facebook support into Wicket.  If anyone out there has
 interest and would like to cooperate(particularly anyone with Facebook
 experience), please get in touch with me.  Thanks.
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/facebook-support-tf4773546.html#a13662919
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Attempted summary of multiple wicket:child / thread

2007-11-09 Thread Stefan Fußenegger

Of course, it really is optional. Wicket only checks whether a page has a
wicket:extend tag or not to decide if markup merging is needed.
(Therefore, my patch does not have any impact on that, as there is no markup
merging triggered)

Thanks for pointing this out!

-- stefan

Sebastiaan van Erk wrote:

Hi,

Actually, Wicket already works like this. It does *NOT* require the
wicket:extend, and if it's not present it just renders the contents of
the wicket:child. (Just tested this with beta4).

Furthermore, your patch works exactly the same as far for multilple
child sections (as far as I can tell, or otherwise it should for
backwards compatibility), and does precisely what both you and Chris want.

Regards,
Sebastiaan

Stefan Fußenegger wrote:
I think it would be a nice feature to define defaults and overrides this
way.
However, this wouldn't be backwards compatible anymore as the contents
are
currently ignored. (Ok, you are currently forced to extend them, so you
probably wouldn't see the markup from such sections in *old*
applications.)

My vote on this:
- I would love to have multiple sections.
- I would appreciate default markup for extendible sections.

Kind regards,

-- stefan

PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :)

Chris Colman wrote:
That is what I'd suggest as well, since it involves the least amount
of
change. As an added bonus, if no id's are added and 2 wicket:child
sections are used, it could throw an exception (which it currently
does
not do, it just silently ignores the second wicket:child).
That would be magic!

Then it would work like methods work in Java - and it's probably how
most Java developers would naturally expect an OO framework like wicket
to work anyway.

Regards,
Sebastiaan
-
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 ;)

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13666078
Sent from the Wicket - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

2007-11-08 Thread Stefan Fußenegger


hi eelco,

Assume the tag wouldn't be renamed. Then it would only be a new and optional
(!) attribute for the child/extend tags. So isn't it unnecessary to
explicitly turn on/off a feature that you could implicitly turn on as soon
as this attribute is used?

The naming - is abstract/implement better than child/extend - is another
topic I really didn't want to argue about.

This is just an idea. I know that supporting it as wicket core feature
(docs, mailing list, code, ...) is a totally different question.

regards, stefan

100th reply - is it a Good Thing (tm) ;)




Eelco Hillenius wrote:
 
 On Nov 7, 2007 11:19 AM, Scott Swank [EMAIL PROTECTED] wrote:
 I can see how wicket:abstract and wicket:implements tags could be
 a nice enhancement to the current wicket:extend and wicket:child
 tags.  Do you have a working, or mostly working, patch?
 
 What I think we should do with this is make it an option. It would be
 turned off by default, requiring users to an extra one or two lines of
 configuration to turn this on (we've done this before), and let it
 prove itself. Sounds to me like everyone would be happy.
 
 WDYT?
 
 Eelco
 
 -
 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13643104
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Attempted summary of multiple wicket:child / thread

2007-11-08 Thread Stefan Fußenegger

Hi eelco.

Did you see what I changed in order to make this working? There is nearly no
extra complexity. So I think complexity isn't an argument here.

best regards

-- stefan

Eelco Hillenius wrote:

In conclusion, the proposed change:
- is useful
- does not have to be used if you don't like it
- is 100% backwards compatible
- it introduces no new tags (if using child/extends)

The thing is though, even though it is 100% backwards compatible, it
is something we'll have to support. It adds complexity to the
implementation, and we'll have to answer questions about it on the
list. That would be fine if everyone would have been wildly
enthusiastic about it, but that is not the case - whether you think
that is justified or not.

So, like I propose in the main thread, the best way to go is to
implement this as a separate project, using separate tags. We'll be
happy to support any internal API changes if that is needed to make
the implementation work. The advantage of having this separate project
is that such inheritance would be available for people who like it,
and hey, maybe in the longer term you have something that works so
good that you can convince people based on something that works.
Executable code works much better than simply words when it comes to
that ;-)

Do people want to work on this?

Regards,

Eelco

-
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/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13643264
Sent from the Wicket - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

Well, the tags are not new, as they do the perfectly same as extend and
child. Basically, the patch only introduces an id attribute to those tags in
order to make linking of markup more flexible. The new names were only
introduced to keep functionality of the patch separated from the existing
(and as the names child/extend are not very well chosen, as they aren't
naturally related)

I see that it was a bad idea to rename the tags for the prototype.
Obviously, everybody fears new tags and therefore dismisses the whole idea
only for that reason.

Evan Chooly wrote:

In our app we have a ListView into which we can dump panels for, in
our case, various different filtering options depending on the page.
The base page keeps a List and that's used as the model for the
ListView. If the subclass doesn't add anything, nothing shows up.
But the pages that need them can add them. These panels show up in
the base page's markup area (outside the wicket:child/ area) with no
hackery needed.

I think the proposed patch is an overly complicated solution to
problem that has many different simple solutions. I agree with the
earlier comments about the proliferation of tags in wicket. I'd
rather not see new tags added just for this. It fuglifies the markup
for no real gain.

On Nov 6, 2007 11:30 AM, Stefan Fußenegger [EMAIL PROTECTED]
wrote:

I posted a new message in Wicket - Dev:
http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html

It contains a patch that demonstrates the discussed enhancement. Please
comment!

-- stefan

Stefan Fußenegger wrote:

Hi folks,

I just stumbled on a situation where it would be useful to have two or
more wicket:child / tags in a base page. Just consider a layout that
consists of the usual footer, header, navigation, and content parts.
But
now, the content should be arranged in two columns, e.g. two different
div /s.

To give a short example, the BasePage.html cloud look like this

body

!-- some layout markup --

div class=content_left
wicket:child /
/div

!-- more layout markup --

div class=content_rigt
wicket:child /
/div

!-- even more layout markup --
/body

And the Child.html markup would look like this:

body

div class=content_left
wicket:extend
!-- content of left column (first child) goes here --
/wicket:extend
/div

div class=content_rigt
wicket:extend
!-- content of right column (second child) goes here --
/wicket:extend
/div
/body

Wouldn't that be a desirable feature? I tried to run the above example
expecting to get an exception. The second wicket:child/wicket:extend
pair
was happily ignored though.

Best regards, Stefan

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13610287

Sent from the Wicket - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Multiple wicket:child / tags on a single base page?


Hey Chris, I would need some lobbying here! ;)

-- stefan



Chris Colman wrote:
 
 Wouldn't this essentially be the same as using wicket:panel
 id=header/ and using WebMarkupContainers on the java side?
 I.e.:
 
 Base
 
 
 Structural markup goes here (see below for explanation of this)
 
 wicket:panel id=header /
 
 More structural markup goes here
 
 wicket:panel id=body /
 
 And again more structural markup goes here too
 
 
 PumpsBase
 -
 wicket:panel id=header
 A header for all pages to do with pumps
 /wicket:panel
 
 Note: no body implemented here - deferred until a more specialized
 class/markups: WaterPumpsBase and OilPumpsBase
 
 WaterPumpBase
 -
 Note: no header implemented here - the general PumpsBase one suffices
 for all pumps pages
 
 wicket:panel id=body
 A body discussing water pumps
 /wicket:panel
 
 ...
 
 
 On the java side you'd have to addOrReplace(new
 WebMarkupContainer(header)) but it's essentially the same. Or am I
 missing some point?
 
 This is indeed very different. If it were not so then the wicket
 developers would never have conceived the need for the current
 child/extend tag pair.
 
 The power of inheritance at the markup level is that you can define
 markup once in a base markup file that is inherited by all derived
 markup files. The derived markup files only supply sections that provide
 specialized sections of markup - the rest, at render time, comes from
 the base class.
 
 You would typically use components (panels) within these specialized
 sections but using the panel mechanism as you describe above as a
 replacement for the powerful markup inheritance feature of wicket is not
 possible.
 
 In the panel example you give you must still provide all of the
 structural markup surrounding your panel tags in EVERY page's markup in
 your system and if you decide to make a system wide change of this
 structural markup you must edit every page's markup to reflect that
 change. In an OO markup world you provide the structural markup in as
 many pages as you want but at render time the only structural markup
 used is that provided in the base base - which is very powerful because
 you can make system wide changes by modifying only that single base
 page's markup. Wicket is the first framework I've seen that allows
 proper OO reuse concepts at the markup level.
 
 This is what many people wicket developers with an OO wiring in their
 brain are doing right now with the existing child/extend feature - and
 to great benefit.
 
 This new feature, or extension of the exiting feature, allows more than
 one section of markup to be specialized by derived (extended) markups
 whereas currently wicket only supports the deferred
 definition/implementation of a single markup section in any page. In
 other words we want to make a powerful feature even more powerful. 
 
 It must be stated again (for the benefit of those who have just recently
 joined this thread) that supporting multiple sections whose
 implementation can be deferred to extended markups does not equate to
 multiple inheritance (a big no no in the OO world). Multiple
 overridden sections is analogous to the support of multiple abstract
 methods whose implementations are provided in classes that extend the
 base class - which is supported in all good OO languages, including
 Java.
 
 -
 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13623108
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?


Hi Mats, let me try to explain what Chris and I see here that others don't -
may it be there or not ;)

You can of course do everything with panels that could be done with multiple
abstract sections (may they be named wicket:child or wicket:abstract).
However, if this is the only argument, you wouldn't need markup inheritance
at all! The proposed change is just an extension of exactly this markup
inheritance concept (that everybody loves) to make it even more powerful
than it already is.

I was quite new to wicket (which I still am) and came across a situation
where I wanted to use two abstract sections: one for a sub-navigation that
was common for several pages in a section and one for the actual content.
For me, as a wicket newbie, it would have been most natural to use markup
inheritance to solve this problem. Using abstract methods, while being a
nice solution (workaround?), didn't come to my mind at once, nor did I find
it somewhere in the docs.

imho, there are two possible solution to this problem:
1. promote using abstract methods for this in the docs as the wicket-way of
doing it
2. extend the current markup inheritance mechanism (which I tried to do with
my patch/prototype)

-- stefan


Mats Norén-2 wrote:
 
 On Nov 7, 2007 11:31 AM, Mats Norén [EMAIL PROTECTED] wrote:
 Hmm...I'm interested in seeing the difference as well. I would love to
 get it but right now I don't.

 Chris Colman wrote:
 This new feature, or extension of the exiting feature, allows more than
 one section of markup to be specialized by derived (extended) markups
 whereas currently wicket only supports the deferred
 definition/implementation of a single markup section in any page. In
 other words we want to make a powerful feature even more powerful.

 Is the above statement really true considering that by adding abstract
 methods to your page you defer the creation of the markup in just the
 same way as the new proposed solution?

 BasePage.java

 public BasePage() {
 addAbstract1(abstractId1);
 addAbstract2(abstractId2);
 }

 public abstract addAbstract1(String abstractId1);
 public abstract addAbstract2(String abstractId2);
 
 A little typo here..I meant:
 
 public BasePage() {
 add(addAbstract1(abstractId1));
 add(addAbstract2(abstractId2));
  }
 
 public abstract Component addAbstract1(String abstractId1);
 public abstract Component addAbstract2(String abstractId2);
 
 /Mats
 
 -
 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626055
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?


But the number of added panels needn't be the number of abstract section
(though it could). 

-- stefan 


Jan Kriesten wrote:
 
 
 hi stefan,
 
 And if somebody really needs 5 child areas, something else might be even
 messier than the page's constructor. I rather think that 2, 3 or in rare
 cases even 4 ids could make sense.
 
 i must disagree - i have a basepage which defines the default layout on a
 project, i.e. header, top-nav-container (imprint etc), navigation,
 content-left/-right/main, footer - this makes 7 panels which are added on
 the
 way down to the resulting page...
 
 but i don't use abstract methods for this, for it can get messy (as stated
 in
 other comments).
 
 regards, --- jan.
 
 
 
 -
 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13631624
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?


Well, if naming is your only concern, the attribute's name can easily be
replaced with something else than id ... e.g. name

wicket:abstract name=foo /

wicket:implement name=foo
some text
/wicket:implement

and remember that they can be optional as well:

wicket:abstract /

wicket:implement
some text
/wicket:implement

This way, its completely compatible with child/extend (which can be proofed
with the existing junit test for markup inheritance)

just a question: do i start to convince you? ;)

best regards


Bruno Borges wrote:
 
 Let me paste what I commented in WICKET-1134:
 
 *I think this improvement is just more of a way to override components
 declared in markups of a super class. Because this is what really happens.
 Let's check your example:
 
 In the BasePage, there are two fragments:
 - subNavigation
 - content
 
 What about if I want to have a fragment in SectionPage with id content,
 but not related with that content from BasePage? You see, the concept of
 extend/child, is the same as in OOP's inheritance. What goes in child, is
 from the subclass. Period.
 
 In Java, if you declare:
 class BasePage ... {
 protected Object someProperty;
 }
 
 class SectionPage extends BasePage {
 protected Object someProperty;
 }
 
 What happens here is that SectionPage.someProperty does NOT
 override/implement/whatever-you-wanna-call, BasePage.someProperty. What
 you
 want to do in HTML would be this in Java.
 
 I'm worry about people trying to subclass some WebMarkupContainer, and
 having to be carefully with components ids, just to _not_ match something
 that would generate strange output.
 
 If in SectionPage I add some component (like Label) with content id,
 what
 would happen? Throw a message: You cannot use this id because there's an
 abstract 'content' markup in BasePage.html. This would lead to code in
 HTML
 that has NO reference within it's Java class.
 
 This means that: what you don't see in Java, it *might* be possible to
 exist
 in the HTML.
 
 And what I like most of Wicket, is its ability to let me take control of
 everything, just from one source: Java. But if I'm going to be obligated
 of
 taking care of what people declare in HTML files that I can't see in some
 Java source code, then I will reconsider my framework's choice.
 
 Regards*
 
 Now, Stefan, let me reply your last comment in the issue:
 *No, ids used with abstract/implement are completely different from
 wicket:ids ... they are only used to construct (i.e. merge ... or link)
 the
 markup, so it is perfectly legal to use div wicket:id=foo when there
 is
 a wicket:abstract id=foo somewhere, as they won't be related.
 Therefore,
 no of the concerns you mention would apply, as ...
 
 The concept of abstract/implement is the same as in OOP's inheritance.
 What
 goes in child, is from the subclass! Exclamation mark! ;)*
 
 Ok, you propose a new attribute for extend/abstract, child/implement pair
 tags. And you say that this id attribute will NOT have any relationship
 with
 wicket:id. Well, isn't this something... scary? The documentation will
 have
 to take care of this, because it will _not_ be intuitive.
 
 Regards,
 
 
 On Nov 7, 2007 10:15 AM, Stefan Fußenegger [EMAIL PROTECTED]
 wrote:
 

 Hi Mats, let me try to explain what Chris and I see here that others
 don't
 -
 may it be there or not ;)

 You can of course do everything with panels that could be done with
 multiple
 abstract sections (may they be named wicket:child or wicket:abstract).
 However, if this is the only argument, you wouldn't need markup
 inheritance
 at all! The proposed change is just an extension of exactly this markup
 inheritance concept (that everybody loves) to make it even more powerful
 than it already is.

 I was quite new to wicket (which I still am) and came across a situation
 where I wanted to use two abstract sections: one for a sub-navigation
 that
 was common for several pages in a section and one for the actual content.
 For me, as a wicket newbie, it would have been most natural to use markup
 inheritance to solve this problem. Using abstract methods, while being a
 nice solution (workaround?), didn't come to my mind at once, nor did I
 find
 it somewhere in the docs.

 imho, there are two possible solution to this problem:
 1. promote using abstract methods for this in the docs as the wicket-way
 of
 doing it
 2. extend the current markup inheritance mechanism (which I tried to do
 with
 my patch/prototype)

 -- stefan


 Mats Norén-2 wrote:
 
  On Nov 7, 2007 11:31 AM, Mats Norén [EMAIL PROTECTED] wrote:
  Hmm...I'm interested in seeing the difference as well. I would love to
  get it but right now I don't.
 
  Chris Colman wrote:
  This new feature, or extension of the exiting feature, allows more
 than
  one section of markup to be specialized by derived (extended)
 markups
  whereas currently wicket only supports the deferred
  definition/implementation of a single markup section in any page. In
  other words we want to make

RE: Multiple wicket:child / tags on a single base page?

.
 
  -
  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/Multiple-
 %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
 tf4738673.html#a13623108
 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]
 
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626128
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

From the Java-side, it isn't visible, whether a component will be placed in
whatever html part. So you add all components in the constructor, yes.
However, it's as messy as adding 5 components is right now ... they will
just be added at different places.

And if somebody really needs 5 child areas, something else might be even
messier than the page's constructor. I rather think that 2, 3 or in rare
cases even 4 ids could make sense.

Is that what you meant?

-- stefan

Johan Compagner wrote:

no not the merging of markup.
but inside the constructor of the child/sub page.
Where do you make all the root components of all the child parts?
you will add that to the page itself right?

I just say that then it could be a bit messy when you have 5 child area's

johan

On 11/7/07, Stefan Fußenegger [EMAIL PROTECTED] wrote:

hi johan,

Johan Compagner wrote:

1 thing that does bother me a bit (but maybe i have to do a deeper look
into
the patch) how do you separate
the components in the constructor of the sub page.. i guess you just
add
all
the components over all the child fragments
in the page itself. That's not a nice separation... That can lead to
big
a
big mess.. Because what component belong to what child part.

I don't get what you mean here. However, my implementation is closely
related to Juergen's MergedMarkup.java (and admittedly partially copied)
and
does the same.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?


hi johan,


Johan Compagner wrote:
 
 1 thing that does bother me a bit (but maybe i have to do a deeper look
 into
 the patch) how do you separate
 the components in the constructor of the sub page.. i guess you just add
 all
 the components over all the child fragments
 in the page itself. That's not a nice separation... That can lead to big a
 big mess.. Because what component belong to what child part. 
 

I don't get what you mean here. However, my implementation is closely
related to Juergen's MergedMarkup.java (and admittedly partially copied) and
does the same.

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13629154
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?


Yes!

see: https://issues.apache.org/jira/browse/WICKET-1134

-- stefan 


Scott Swank wrote:
 
 I can see how wicket:abstract and wicket:implements tags could be
 a nice enhancement to the current wicket:extend and wicket:child
 tags.  Do you have a working, or mostly working, patch?
 
 -
 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13634545
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Wicket namespace?


In deed, it's an open issue: https://issues.apache.org/jira/browse/WICKET-693




Timo Rantalaiho wrote:
 
 On Mon, 05 Nov 2007, Stefan Fußenegger wrote:
 I was asking myself the same a while ago. Today I found a file named
 wicket-xhtml1-strict.dtd in the SVN. You can find it at
 http://svn.apache.org/repos/asf/wicket/trunk/jdk-1.4/wicket/wicket-xhtml1-strict.dtd
  
 
 But I don't know whether this file is supported or not, as I haven't
 found
 anything in the docs. Does somebody know more?
 
 I just know that I have used it and sometimes it has helped 
 me. I had to add the wicket: attributes to my editor (IDEA)
 by quick fix though, but that's just once per project.
 
 Your mileage may vary.
 
 I think that there is a Jira issue about this as well 
 (What to do with the Wicket DTD or something such), so if
 you have good ideas put them there :)
 
 Best wishes,
 Timo
 
 
 -
 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/Wicket-namespace--tf4753975.html#a13602399
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Wicket namespace?


Sure, dtd = old way, xsd = new way. But sadly, there is no official XHTML 1.0
Schema to extend (yet). However, there are two candidates for the future:
http://www.w3.org/TR/xhtml1-schema/ (work in progress) and
http://www.w3.org/TR/xhtml-modularization/ (working draft). Hence, the only
way to extend xhtml right now is by means of a DTD.

-- stefan


Will Jackson-2 wrote:
 
 I know you were not saying that it's not supported. I was assuming that it
 was not supported because I can't find a public url for that supports it
 :) 
 
 afaik extending the dtd is really just adding another dtd
 (http://www.w3.org/TR/1999/xhtml-modularization-19990406/developing.html#sec_6.5.2.).
  
 as far as the schema is concerned anything that can be done in a dtd can
 be done in a more elegant manner in an xsd (dtd = old way, xsd = new way).
 still curious why there isn't a public url that is published somewhere on
 it's use :(
 
 Stefan Fußenegger [EMAIL PROTECTED] wrote: 
 I didn't say it's not supported, I was just asking. And I don't think you
 have to use 2 DTDs. I think it rather is an extension of the standard
 XHTML
 DTD (that's why it is a DTD and not an XML schema). 
 
 -- Stefan
 
 
 
 Will Jackson-2 wrote:
 
 Thanks for the info... hmmm... I wonder why it is not supported? I would
 have assumed that they would use a xsd rather than a dtd. How would this
 be used? Using multiple dtds can get messy (not to mention they may cause
 issues in Internet Exploder).
 
 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
 
 
 Better:
 
 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xmlns:wicket=http://wicket.apache.org;
 xsi:schemaLocation=http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd
 http://wicket.apache.org/someWicketSchema;
 xml:lang=en
 
 Stefan Fußenegger  wrote: 
 I was asking myself the same a while ago. Today I found a file named
 wicket-xhtml1-strict.dtd in the SVN. You can find it at
 http://svn.apache.org/repos/asf/wicket/trunk/jdk-1.4/wicket/wicket-xhtml1-strict.dtd
  
 
 But I don't know whether this file is supported or not, as I haven't
 found
 anything in the docs. Does somebody know more?
 
 Regards, Stefan
 
 
 
 Frank Bille-2 wrote:
 
 There is no schema for it if thats what you mean.
 
 But you can set the namespace to wicket:xmlns=http://wicket.apache.org;
 
 Frank
 
 On Nov 5, 2007 10:42 PM, Will Jackson  wrote:
 
 no one knows what the Wicket namespace is?

 Will Jackson  wrote: Is there a Wicket xhtml
 namespace that will work with Eclipse content assist? I searched the
 forums,
 but can't find anything.

  __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around
 http://mail.yahoo.com

  __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around
 http://mail.yahoo.com

 
 
 
 
 -
 ---
 Stefan Fußenegger
 http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
 -- 
 View this message in context:
 http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597017
 Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around 
 http://mail.yahoo.com 
 
 
 
 -
 ---
 Stefan Fußenegger
 http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
 -- 
 View this message in context:
 http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597735
 Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around 
 http://mail.yahoo.com 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Wicket-namespace--tf4753975.html#a13602619
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?


The proposed extension would just lead to more convenience, as it saves us
from having to create child pages as page/panel pairs when their are 2
panels needed (assuming no inheritance at all)




John Krasnay wrote:
 
 On Tue, Nov 06, 2007 at 10:23:26PM +1100, Chris Colman wrote:
 
 In the panel example you give you must still provide all of the
 structural markup surrounding your panel tags in EVERY page's markup in
 your system and if you decide to make a system wide change of this
 structural markup you must edit every page's markup to reflect that
 change. In an OO markup world you provide the structural markup in as
 
 Huh? Why wouldn't the structural markup be inherited by child pages?
 
 To my mind, wicket:extend/wicket:child is just a convenience feature, to
 save us from having to create child pages as page/panel pairs.
 
 jk
 
 -
 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13609607
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

I posted a new message in Wicket - Dev:
http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html

It contains a patch that demonstrates the discussed enhancement. Please
comment!

-- stefan

Stefan Fußenegger wrote:

Hi folks,

I just stumbled on a situation where it would be useful to have two or
more wicket:child / tags in a base page. Just consider a layout that
consists of the usual footer, header, navigation, and content parts. But
now, the content should be arranged in two columns, e.g. two different
div /s.

To give a short example, the BasePage.html cloud look like this

body

!-- some layout markup --

div class=content_left
wicket:child /
/div

!-- more layout markup --

div class=content_rigt
wicket:child /
/div

!-- even more layout markup --
/body

And the Child.html markup would look like this:

body

div class=content_left
wicket:extend
!-- content of left column (first child) goes here --
/wicket:extend
/div

div class=content_rigt
wicket:extend
!-- content of right column (second child) goes here --
/wicket:extend
/div
/body

Wouldn't that be a desirable feature? I tried to run the above example
expecting to get an exception. The second wicket:child/wicket:extend pair
was happily ignored though.

Best regards, Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Make PageableListView row click


add javascript to your tr tags

pure html sample:
table id=test border='1' cellspacing='0' cellpadding='0'
  tr onmouseover=this.style.background='red';this.style.cursor='pointer'
onmouseout=this.style.background='white'; onclick=alert('bang')
tdTest/td
tdTest/td
tdTest/td
tdTest/td
  /tr
/table
(Source:
http://radio.javaranch.com/pascarello/2004/12/30/1104419159000.html)



Marco Aurélio Silva wrote:
 
 Hi all
 
 I'm using a PageableListView component and I want to make each row of the
 list clickable. I don't want to add a column with a label like details,
 I
 just want to click in any place of the row to go to details. Is there a
 way
 to do this?
 
 Thanks in advance
 Marco
 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Make-PageableListView-row-click-tf4759886.html#a13612378
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

Well, what I'd like to do is what I explained in my first post. One would
still have a one-one-relationship if it comes to files (Base.html, Base.java
- Sub.html, Sub.java). However, a Base.html might contain more than one
wicket:extend /. So this no longer an exact duplicate of the parent-child
relationship that is already specified by the java class hierarchy. It now
would be similar to abstract method, where the abstract class specifies one
or more extension points that are implemented by its subcasses ... abstract
methods. There isn't a restriction, that there is only one abstract method
per class!

My proof of concept would go the probably easiest way and just link the
first extend with the first child, the second extend with the second child,
the third ... you got the idea ;) At a later point it might be useful to
link them using ids (like the names of abstract methods).

You could than for instance do some hierarchies like this:

BaseClass - Application base class. Navigation on top, two columns with
wicket:extend
SectionOneBaseClass extends BaseClass - Sub-navigation in left column
SectionOneIndex extends SectionOneBaseClass - Navigation on top,
sub-navigation in left column and some fancy content in right column

I totally agree to anybody who argues that this is already possible by other
means. However, to me it seems to be the most natural and elegant way to do
this.

As I mentioned before, I don't know Wicket's inner workings too much, so I
will definitely need some pointers to the right directions.

My naive guess is that Wicket parses BasePage.html and looks for
SecionOneBaseClass.html and the first wicket:child / as soon as it finds a
wicket:extend /. The idea would know be to just add a counter to this
call, asking for the second wicket:child /, rather than the first (I doubt
that it's really going to be that easy though).

Bruno Borges wrote:

Stefan, try first giving us an example of what would you like to do. What
I
can see is that you want this:

BasePage.html
html
body
h1BasePage/h1
hr/
h3This is my child:/h3
wicket:child /
hr/
h3This is my OTHER child:/h3
wicket:child /
/body
/html

** Example of a child page:*
ChildPage.html
html
body
wicket:extend
h4ChildPage/h4
h5I'm your child/h5
/wicket:extend
/body
/html

Now, given this html, how do you see the Java code structured? What's your
vision?

On Nov 5, 2007 11:28 AM, Stefan Fußenegger [EMAIL PROTECTED]
wrote:

Eelco Hillenius wrote:

It would be quite feasible to add support for multiple overridden
sections using the above tag names while remaining backwards
compatible
with existing markup by continuing to support the old child/extends
tags working the way they always have.

It's kind of a predictable answer, but the best way to push new ideas
forward is to supply us with a patch, so that we can discuss some
working code. The current committers don't see much in the idea, but
that doesn't mean they wouldn't want to support at least the option of
plugging this in. And hey, maybe some working code convinces us :-)

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Hi eelco,

I'd love to do a proof of concept here. Admittedly, I don't know wicket's
inner workings very well. But if I get some support, I'd try implementing
this. I am currently looking through the code, but can't find where the
transition between parent and child takes place (in other words: the line
of
code that recognizes the wicket:extend tag and takes the appropriate
action). If somebody could point me to that line I would try to implement
this possible new feature ... well, I'll first estimate the time
necessary
to do so and see if I can afford it ;)

Regards

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Bruno Borges
blog.brunoborges.com.br
+55 1185657739

The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld

Re: Multiple wicket:child / tags on a single base page?

thanks for that advise.

hey chris, keep your fingers crossed. finally you could get your
wicket:abstract-wicket:override ;)

stefan

igor.vaynberg wrote:

if i were you i would use tags other then extend and child just so you
dont conflict.

-igor

On 11/5/07, Stefan Fußenegger [EMAIL PROTECTED] wrote:

Well, what I'd like to do is what I explained in my first post. One would
still have a one-one-relationship if it comes to files (Base.html,
Base.java
- Sub.html, Sub.java). However, a Base.html might contain more than one
wicket:extend /. So this no longer an exact duplicate of the
parent-child
relationship that is already specified by the java class hierarchy. It
now
would be similar to abstract method, where the abstract class specifies
one
or more extension points that are implemented by its subcasses ...
abstract
methods. There isn't a restriction, that there is only one abstract
method
per class!

My proof of concept would go the probably easiest way and just link the
first extend with the first child, the second extend with the second
child,
the third ... you got the idea ;) At a later point it might be useful to
link them using ids (like the names of abstract methods).

You could than for instance do some hierarchies like this:

I totally agree to anybody who argues that this is already possible by
other
means. However, to me it seems to be the most natural and elegant way to
do
this.

As I mentioned before, I don't know Wicket's inner workings too much, so
I
will definitely need some pointers to the right directions.

My naive guess is that Wicket parses BasePage.html and looks for
SecionOneBaseClass.html and the first wicket:child / as soon as it
finds a
wicket:extend /. The idea would know be to just add a counter to this
call, asking for the second wicket:child /, rather than the first (I
doubt
that it's really going to be that easy though).

Bruno Borges wrote:

Stefan, try first giving us an example of what would you like to do.
What
I
can see is that you want this:

BasePage.html
html
body
h1BasePage/h1
hr/
h3This is my child:/h3
wicket:child /
hr/
h3This is my OTHER child:/h3
wicket:child /
/body
/html

** Example of a child page:*
ChildPage.html
html
body
wicket:extend
h4ChildPage/h4
h5I'm your child/h5
/wicket:extend
/body
/html

Now, given this html, how do you see the Java code structured? What's
your
vision?

On Nov 5, 2007 11:28 AM, Stefan Fußenegger [EMAIL PROTECTED]
wrote:

Eelco Hillenius wrote:

It would be quite feasible to add support for multiple overridden
sections using the above tag names while remaining backwards
compatible
with existing markup by continuing to support the old
child/extends
tags working the way they always have.

It's kind of a predictable answer, but the best way to push new
ideas
forward is to supply us with a patch, so that we can discuss some
working code. The current committers don't see much in the idea, but
that doesn't mean they wouldn't want to support at least the option
of
plugging this in. And hey, maybe some working code convinces us :-)

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Hi eelco,

I'd love to do a proof of concept here. Admittedly, I don't know
wicket's
inner workings very well. But if I get some support, I'd try
implementing
this. I am currently looking through the code, but can't find where
the
transition between parent and child takes place (in other words: the
line
of
code that recognizes the wicket:extend tag and takes the appropriate
action). If somebody could point me to that line I would try to
implement
this possible new feature ... well, I'll first estimate the time
necessary
to do so and see if I can afford it ;)

Regards

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:

http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814
Sent from the Wicket - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Bruno Borges
blog.brunoborges.com.br
+55 1185657739

The glory of great men should always be
measured

Re: Multiple wicket:child / tags on a single base page?


well, i thought chris' suggestion to use abstract and override in order to
align it with the java keyword/annotation. I don't care whether it is
implement or override (but yes, names are important). i think i'll go for
implement though ... but if it finally becomes part of wicket, it will
become extend/child anyway, wouldn't it? but let's see what i can do here
first.



igor.vaynberg wrote:
 
 the complement to abstract is implement not override... names are
 important.
 
 -igor
 
 
 On 11/5/07, Stefan Fußenegger [EMAIL PROTECTED] wrote:

 thanks for that advise.

 hey chris, keep your fingers crossed. finally you could get your
 wicket:abstract-wicket:override ;)

 stefan



 igor.vaynberg wrote:
 
  if i were you i would use tags other then extend and child just so you
  dont conflict.
 
  -igor
 
 
  On 11/5/07, Stefan Fußenegger [EMAIL PROTECTED] wrote:
 
  Well, what I'd like to do is what I explained in my first post. One
 would
  still have a one-one-relationship if it comes to files (Base.html,
  Base.java
  - Sub.html, Sub.java). However, a Base.html might contain more than
 one
  wicket:extend /. So this no longer an exact duplicate of the
  parent-child
  relationship that is already specified by the java class hierarchy. It
  now
  would be similar to abstract method, where the abstract class
 specifies
  one
  or more extension points that are implemented by its subcasses ...
  abstract
  methods. There isn't a restriction, that there is only one abstract
  method
  per class!
 
  My proof of concept would go the probably easiest way and just link
 the
  first extend with the first child, the second extend with the second
  child,
  the third ... you got the idea ;) At a later point it might be useful
 to
  link them using ids (like the names of abstract methods).
 
  You could than for instance do some hierarchies like this:
 
  BaseClass - Application base class. Navigation on top, two columns
 with
  wicket:extend
  SectionOneBaseClass extends BaseClass - Sub-navigation in left column
  SectionOneIndex extends SectionOneBaseClass - Navigation on top,
  sub-navigation in left column and some fancy content in right column
 
  I totally agree to anybody who argues that this is already possible by
  other
  means. However, to me it seems to be the most natural and elegant way
 to
  do
  this.
 
  As I mentioned before, I don't know Wicket's inner workings too much,
 so
  I
  will definitely need some pointers to the right directions.
 
  My naive guess is that Wicket parses BasePage.html and looks for
  SecionOneBaseClass.html and the first wicket:child / as soon as it
  finds a
  wicket:extend /. The idea would know be to just add a counter to
 this
  call, asking for the second wicket:child /, rather than the first (I
  doubt
  that it's really going to be that easy though).
 
 
 
 
  Bruno Borges wrote:
  
   Stefan, try first giving us an example of what would you like to do.
  What
   I
   can see is that you want this:
  
   BasePage.html
   html
 body
   h1BasePage/h1
   hr/
   h3This is my child:/h3
   wicket:child /
   hr/
   h3This is my OTHER child:/h3
   wicket:child /
 /body
   /html
  
   ** Example of a child page:*
   ChildPage.html
   html
 body
   wicket:extend
 h4ChildPage/h4
 h5I'm your child/h5
   /wicket:extend
 /body
   /html
  
   Now, given this html, how do you see the Java code structured?
 What's
  your
   vision?
  
   On Nov 5, 2007 11:28 AM, Stefan Fußenegger
 [EMAIL PROTECTED]
   wrote:
  
  
  
   Eelco Hillenius wrote:
   
It would be quite feasible to add support for multiple
 overridden
sections using the above tag names while remaining backwards
   compatible
with existing markup by continuing to support the old
  child/extends
tags working the way they always have.
   
It's kind of a predictable answer, but the best way to push new
  ideas
forward is to supply us with a patch, so that we can discuss some
working code. The current committers don't see much in the idea,
 but
that doesn't mean they wouldn't want to support at least the
 option
  of
plugging this in. And hey, maybe some working code convinces us
 :-)
   
Eelco
   
   
  -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
   
  
   Hi eelco,
  
   I'd love to do a proof of concept here. Admittedly, I don't know
  wicket's
   inner workings very well. But if I get some support, I'd try
  implementing
   this. I am currently looking through the code, but can't find where
  the
   transition between parent and child takes place (in other words:
 the
  line
   of
   code that recognizes the wicket:extend tag and takes the
 appropriate
   action). If somebody could point me to that line I would try to
  implement
   this possible new feature ... well, I'll first

Re: Multiple wicket:child / tags on a single base page?


but why choose another name? as long as there is only one pair of however
named tags, the behaviour wouldn't change at all. It would only extend the
current functionality for those who place a second extension point in there
html files. 

But I am not in the core team, but curious to look under the hood. While I
would love to see this extension becoming part of wicket, I don't care too
much what happens with it as long as I have fun implementing it. ;)

And as numerous times mentioned before: This extension still aligns with how
class inheritance works in java, you only have to see html files as classes
and extension points as (abstract) methods. That's the only conceptual
change.

But there is still some time left to argue while I am hacking ;) 

Regards




igor.vaynberg wrote:
 
 On 11/5/07, Stefan Fußenegger [EMAIL PROTECTED] wrote:

 well, i thought chris' suggestion to use abstract and override in order
 to
 align it with the java keyword/annotation. I don't care whether it is
 implement or override (but yes, names are important). i think i'll go for
 implement though ... but if it finally becomes part of wicket, it will
 become extend/child anyway, wouldn't it?
 
 no it would not.
 
 as mentioned numerous times before, we like how it currently works
 because it aligns with how class inheritance works in java and thus is
 easy to understand.
 
 this would be an in-addion-to feature that people may choose to use.
 
 -igor
 
 -
 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13590818
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Wicket namespace?


I was asking myself the same a while ago. Today I found a file named
wicket-xhtml1-strict.dtd in the SVN. You can find it at
http://svn.apache.org/repos/asf/wicket/trunk/jdk-1.4/wicket/wicket-xhtml1-strict.dtd
 

But I don't know whether this file is supported or not, as I haven't found
anything in the docs. Does somebody know more?

Regards, Stefan



Frank Bille-2 wrote:
 
 There is no schema for it if thats what you mean.
 
 But you can set the namespace to wicket:xmlns=http://wicket.apache.org;
 
 Frank
 
 On Nov 5, 2007 10:42 PM, Will Jackson [EMAIL PROTECTED] wrote:
 
 no one knows what the Wicket namespace is?

 Will Jackson [EMAIL PROTECTED] wrote: Is there a Wicket xhtml
 namespace that will work with Eclipse content assist? I searched the
 forums,
 but can't find anything.

  __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around
 http://mail.yahoo.com

  __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around
 http://mail.yahoo.com

 
 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597017
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Wicket namespace?